Virtio-gpu-gl through already existing Windows Mesa Driver

[imwhocodes]

Hi

From what I get a virtio-gpu windows guest driver already exist but there is no support for 3D acceleration with VirGL (on host) as renderer

On Linux a 3D acceleration on a virtio-gpu-gl is supported through Mesa Drivers

For windows there is support for Mesa Driver, I would like to investigate the possibility of using this drivers to interact with the virtio-gpu of this repo so to enable 3D acceleration on windows

The basic idea is:

1. Virtio-gpu-gl driver exposing a vGPU
2. Mesa driver using such vGPU
3. WindowsOS using Mesa Driver

(I know about VFIO, GPUPassthrough, Nvidia Grid ecc, but this would be a more Flexible, Hardware Agnostic and Open Source option)

Is this achievable? Or am I missing something?

Thanks,
Luca

[YanVugenfirer]

Hi Luca,

Sorry for the late reply, had some public holidays.

Yes, in general this is something achievable, But will need some effort.
Also there is some work from Valve that can be used as reference: https://github.com/ValveSoftware/Proton

Do you want to work on it and need some guidance?

Best regards,
Yan.

[imwhocodes]

Hi Yan

I would like to try to work on it on spare time

I'm experienced c++20 programmer (mostly baremetal) and IT admin but I'm getting a bit lost on the implementation details (with missing or hidden documentation).

Here is as I understood a possible complete architecture:

From what I get full Mesa already support a virtio-gpu and I think the gallium conversion is here
yet I didn't found where it hook up with the actual vGPU

On your side code I did't deep dive into it yet but seem like you already exposing virtio-gpu-gl as a pcie device and in the header the are definitions for 3D commands

What I'm missing?

Thanks,
Luca

[vrozenfe]

@imwhocodes
What is the "virtual pcie" device on that diagram?
In my understanding one of the critical things there is adding the WDDM RENDER stuff to the existing DOD driver.
(Some of the work toward building a FULL WDDM virtio-gpu driver has been done already but it is still not completed yet.
When this job will be done, we can add an OpenGL Installable Client Driver, or any other ICD to the project)

You can take a look at https://studiopixl.com/page3/ . But you need to understand that due to luck of Rendering Driver
functionality this project was done as a kind of hack for the POC purpose only.

Cheers,
Vadim.

[imwhocodes]

Hi Vadim

Nathan Gauër blog and Talks were the first thing I checked out before opening this issue, referencing to his work this is what I mean about virtual PCIE

And about mesa in the stack:

Actually I just realised checking out the ICD repo that the author himself is saying:

Once you observe the virtio-gpu implementation on the host receiving commands from the OpenGL sample app, you are good to go! Next step is to implement a proper ICD (reuse MESA), and integrate with D3DKMD properly.

and from what I get ICD was the most underdeveloped part

On the DoD Driver side it seem like only an extension of the current VirtioGPU code present in this repo (it should only move buffer around between Host and Guest)

[imwhocodes]

@YanVugenfirer Do you have any clarification or hints?

Thanks

[Quackdoc]

I wonder if it might even wind up being easier to use vitio-gpu venus? I realize that it still isn't merged into qemu so there might not be a lot you can actually do on that end right now but the patches are being worked on. I wonder if it might be easier to get vulkan acceleration in the guest then it would be opengl via venus.

also it might not be too bad to try and port D3D10UMD to NIR from TGSI to try and get that working with virgl, or even zink if the vulkan route could wind up proving more beneficial, (I assume that the performance would be better at the very least). and if that does work I believe from there it can be extended to d3d11. IIRC that should be able to provide desktop acceleration.

well regardless, another resource is a talk that I think was from 2020? it was something called virgl and windows if I am remembering it correctly. that could be a good chunk information there.

EDIT: some potentially useful resources.

https://www.youtube.com/watch?v=aBgYNDLXuyg
https://github.com/pal1000/mesa-dist-win
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10687

[YanVugenfirer]

@imwhocodes Hi Luca,

I think while ICD can be most probably done with not much effort by reusing Mesa and other existing projects, I think this is a least interesting part.
We need to implement (or reuse from other projects) the layer that will translate DirectX 10+ to something that can be used on the host side.

Best regards,
Yan.

[orowith2os]

Wanted to pop in and give some bits of info.

• Pass through Vulkan and OpenGL calls to the host via venus and the like.
• Bundle DXVK (and VKD3D) like Intel does for their Windows driver (which doesn't have D3D11 and older support) for Direct3D support.

DXVK and VKD3D don't officially support Windows (only Linux/Wine) so you'd have to provide support for any bugs that occur there, though that could be useful for improving the projects if you were to fix the bugs and upstream them.

[YanVugenfirer]

Wanted to pop in and give some bits of info.

• Pass through Vulkan and OpenGL calls to the host via venus and the like.
• Bundle DXVK (and VKD3D) like Intel does for their Windows driver (which doesn't have D3D11 and older support) for Direct3D support.

DXVK and VKD3D don't officially support Windows (only Linux/Wine) so you'd have to provide support for any bugs that occur there, though that could be useful for improving the projects if you were to fix the bugs and upstream them.

Sure. That's the usual mode of operation for us - if needed we fix issues in other projects and upstream them.

[ss8688]

Could something like microsoft's gpu-pv easier?

[voidpointertonull]

Could something like microsoft's gpu-pv easier?

Doesn't really seem to have anything useful to offer as it seems to just expose Windows specific features to the guest, and it heavily relies on closed source blobs both on the host and the guest side.