Redox Os is a microkernel operating system, completely different from monolithic kernels like Linux or BSD. I doubt it'll be easy to get existing ZFS drivers working on it at all.
We have used this with recent Intel GPUs that support SR-IOV. This is what you see in the video on the cyberus website. Intel hasn't managed to upstream the drivers for this yet and you have to piece together things, which is very unpleasant. But we are there to help, if someone wants to use this in a professional setting.
We used to have support for Intel GVT-g GPU virtualization as well, which was more of a software solution. This doesn't work with modern Intel GPUs anymore.
I wonder if it would be possible to use DXVK here for windows guests to play those unruly games. That is have a pass through direct x driver in windows that sends all the commands to dxvk which either sends the image back to the vm or renders directly on the screen.
Thank you for the info.
I use AMD consumer GPUs, none of them unfortunately support SR-IOV afaik, there are some developments from google around virtio-gpu(DRM native context) I've been following, I was hoping this was something similar.
AMD gpu drivers are in the linux kernel. They support even very old hardware. And linux only drops drivers when there are no users. So amd cards stay supported for basically their entire lifetime.
What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.
The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel.
clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.
It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.
And again you are wrong. It was debunked not a long time ago, and I think it was here on HN. The AMD drivers, kernel side, are still gigantic even excluding the generated register descriptions. Is this what we call a AI lie?
But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.
No, it doesn't. I know with 100% certainty ESP WiFi hardware is developed in-house and not shared. I think BL602 uses CEVA IP, not sure about that, but it certainly is not shared with ESP chips.
Sprite, how will Espressif react to this effort to open-source wifi? Will it help by releasing wifi phy documentation? Will it add DRM to block future efforts?
Virgl just sends opengl commands to the host. And it also has to copy some buffers back and forth. So it won't be as fast as vfio. But, there is a new feature called VirtGPU DRM native contexts which eliminates some of this overhead and run at near native speeds. Unfortunately it's only implemented for adreno/msm GPUs for now.I think there is work on the way for Intel and AMD GPUs.
I missed that development, thanks! As I understand it, it's not strictly muxing per se - you're basically siphoning off the interrupts from the M0 core using a hardware mechanism instead of firmware + IPC, so any firmware you might want to run on the M0 core still needs to be careful not to mess this up. But it's still an improvement.
