Google's VirtIO-GPU "Venus" Vulkan Driver Merged Into Mesa 21.1

[WorBlux]

Once the infrastructure is stable, is there anything stopping it from being used on Windows? Creating a Windows Vulkan Driver that takes advantage of this would serioulsy bring virtualization costs in the enterprise down by being able to bypass the Nvidia tax for sharing GPUs for multiple Virtual Machines. I can definately see some company noticing this and spending some cash to hit that last mile.

Any windows graphics driver need to tie into WDDM, and as far as I can tell, it's directX native service, and also uses some exclusive extension and kernel features. So not only do you have to write the pass through driver need to write a full WDDM driver to tie it together. If Microsoft wanted to license the default software-backed WDDM and provide basic support for the effort it might be possible. However that's unlikely at the moment, as Microsoft is using every opportunity to prop up it's own DX12 graphics API. Having Vulkan or OpenGL suddenly be the best choice in virtualized enviroments wouldn't suit thier purposes. A compute-only driver might be easier but the people making money on compute don't really use Windows as a host, and are already reasonably served by existing extensions on data-center cards.

Vs. Linux where the display manager isn't tightly tied to any specific graphical backend. X is to old to to so, and the DRI extensions are only lightly lied to X specific GL ops. And Wayland is intentionally agnositic to API just caring about buffers that a passed by reference.

[Quackdoc]

Any windows graphics driver need to tie into WDDM, and as far as I can tell, it's directX native service, and also uses some exclusive extension and kernel features. So not only do you have to write the pass through driver need to write a full WDDM driver to tie it together. If Microsoft wanted to license the default software-backed WDDM and provide basic support for the effort it might be possible. However that's unlikely at the moment, as Microsoft is using every opportunity to prop up it's own DX12 graphics API. Having Vulkan or OpenGL suddenly be the best choice in virtualized enviroments wouldn't suit thier purposes. A compute-only driver might be easier but the people making money on compute don't really use Windows as a host, and are already reasonably served by existing extensions on data-center cards.

Vs. Linux where the display manager isn't tightly tied to any specific graphical backend. X is to old to to so, and the DRI extensions are only lightly lied to X specific GL ops. And Wayland is intentionally agnositic to API just caring about buffers that a passed by reference.

As stated in another post on the forum, virtio-gpu DOES have a WDDM driver being worked on (I think there is a functional to some degree build in redhat's brew), now that does NOT mean that 3d acceleration is working. however it is related work being done. I dont see a real reason why wined3d and dxvk couldn't make up most of the groundwork needed

[dragorth]

Any windows graphics driver need to tie into WDDM, and as far as I can tell, it's directX native service, and also uses some exclusive extension and kernel features. So not only do you have to write the pass through driver need to write a full WDDM driver to tie it together. If Microsoft wanted to license the default software-backed WDDM and provide basic support for the effort it might be possible. However that's unlikely at the moment, as Microsoft is using every opportunity to prop up it's own DX12 graphics API. Having Vulkan or OpenGL suddenly be the best choice in virtualized enviroments wouldn't suit thier purposes. A compute-only driver might be easier but the people making money on compute don't really use Windows as a host, and are already reasonably served by existing extensions on data-center cards.

Vs. Linux where the display manager isn't tightly tied to any specific graphical backend. X is to old to to so, and the DRI extensions are only lightly lied to X specific GL ops. And Wayland is intentionally agnositic to API just caring about buffers that a passed by reference.

I am not so certain you are right. First, mesa can be compiled to Windows to offer OpenGL. It doesn't use nor require WDDM. And neither Vulkan nor OpenGL require WDDM. So passing this through to Windows allowing accelerated Vulkan and OpenGL would work fine. We could use the existing virtual interface for this, allowing to get started.

DX is the only one "tied" to WDDM, however, MS themselves are creating a Linux DX implementation that doesn't require WDDM under Linux (though it relies on its Windows Host's WDDM, so you may not want that to count.) WDDM is practically only necessary for DX.

[WorBlux]

I am not so certain you are right. First, mesa can be compiled to Windows to offer OpenGL. It doesn't use nor require WDDM. And neither Vulkan nor OpenGL require WDDM. So passing this through to Windows allowing accelerated Vulkan and OpenGL would work fine. We could use the existing virtual interface for this, allowing to get started.

DX is the only one "tied" to WDDM, however, MS themselves are creating a Linux DX implementation that doesn't require WDDM under Linux (though it relies on its Windows Host's WDDM, so you may not want that to count.) WDDM is practically only necessary for DX.

As stated in another post on the forum, virtio-gpu DOES have a WDDM driver being worked on (I think there is a functional to some degree build in redhat's brew), now that does NOT mean that 3d acceleration is working. however it is related work being done. I don't see a real reason why wined3d and dxvk couldn't make up most of the groundwork needed

If you want to put pixels on screen, then WDDM is required. There was a project in the past, I forget the name got some degree of openGL compute working on windows but didn't get to the point of pixels.

And then redhat has the QXL/qemu driver/virtual GPU that provides some basic acceleration (SPICE helps a little more), but as you said, no 3-d to speak of.

I currently use QXL/Spice and it's fine for 2-D applications and basic window decorations, I tried intel GVT, and while it worked, I found it less than stable.

Wine3d/DXVk could be the basis of an userspace driver, but your still have the back end, essentially translating DMA-Buf , modesetting, and parts of the native compositor so support WDDM. That is code to manage the video buffers, memory allocation, and scheduling. And while Mesa can issue the hardware-specific instruction streams, it doesn't manage hardware directly as the kernel drivers do.

It's certainly not impossible, but it's not a small effort either. And without a business case behind it, it's the sort of highly technical, yet high convoluted work that very few want to hack out for fun.

ReactOS appearently doesn't have WDDM implemented yet, filling in there might provide the synergy and understanding needed to write a para-virtualization driver for windows. https://reactos.org/wiki/Missing_ReactOS_Functionality . (Combine the architecture buildout with the first guest driver)

As to the WSL/DX12 driver. DX12 was actually written with para-virtualization in mind, and the low level drivers can maintain groups of gpu processes in separate hardware contexts. They added a small driver to the kernel to let them create and manage these contexts/queues through the VM, and a userspace module (congruent to mesa but for DX12) to do the heavy lifting. Compute tasks with the proper back-end were working well, but last I heard they were still trying to work out the details on how to actually display pixels.

Here's and outline of WSL graphics flow, paying particular attention to VAIL. To get pixels pack on screen from a DX12 command stream, they still need to add a memory copy or shared memory device to get the pixels back to weston/wayland to properly compose a frame and send it. https://xdc2020.x.org/event/9/contri...ons_in_WSL.pdf

^the above based on preliminary research, not personal expertise.

[Quackdoc]

...

The Directx to vulkan needs to happen at some point between execution and VM, the issue is that virtio-gpu is a gateway for Opengl (and soon to be Vulkan) NOT directx. so idealy we want to convert ALL directx calls to vulkan, so the most idea place for this to happen would be at the driver level. though in theory, you could replace with system32 dlls and get some degree of functionality, but as you said, the meat of the work lies within the WDDM driver.

I didn't mean to understate the complexity of this if I did. WDDM DOD and Iddcx are considered simple for wddm driver development, WDDM is a very different beast then what we used to have (XPDM) and as you said, it is not work anyone would want to do in their free time unless they be masochists.

However there IS incentive and a large degree of it too. I already said it in my other posts but being brief, Game stream services, Google, Microshit themselves, VFIO gamers, App developers, Steam (to a degree), and more would get actual real world benefits from this. It could be the stepping stone needed for stadia and chromeOS to offer actual windows games. and the corporate side that doesn't want to spend thousands of dollars on nvidia licensing for basic GPU accelerated VMs.

THAT BEING SAID, it is A LOT of work, and A LOT of money to invest. for something that will realistically preform at about 50-70% performance, but who knows, maybe to someone that trade off is worth it.

[Quackdoc]

looks like some work has been merged working towards it hopefully not much longer

https://gitlab.com/qemu-project/qemu/-/commits/master?search=Virtio-GPU