Log in

No account? Create an account

July 2017
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

airlied [userpic]
Introducing Virgil - 3D virtual GPU for qemu

Virgil is a research project I've been working on at Red Hat for a few months now and I think is ready for at least announcing upstream and seeing if there is any developer interest in the community in trying to help out.

The project is to create a 3D capable virtual GPU for qemu that can be used by Linux and eventually Windows guests to provide OpenGL/Direct3D support inside the guest. It uses an interface based on Gallium/TGSI along with virtio to communicate between guest and host, and it goal is to provided an OpenGL renderer along with a complete Linux driver stack for the guest.

The website is here with links to some videos:

some badly formatted Questions/Answers (I fail at github):

Just a note and I can't stress this strongly enough, this isn't end user ready, not even close, it isn't even bleeding edge user ready, or advanced tester usage ready, its not ready for distro packaging, there is no roadmap or commitment to finishing it. I don't need you to install it and run it on your machine and report bugs.

I'm announcing it because there maybe other developers interested or other companies interested and I'd like to allow them to get on board at the design/investigation stage, before I have to solidify the APIs etc. I also don't like single company projects and if I can announcing early can help avoid that then so be it!

If you are a developer interested in working on an open source virtual 3D GPU, or you work for a company who is interested in developing something in this area, then get in touch with me, but if you just want to kick the tyres, I don't have time for this yet.


Most excellent! Have you seen the GL-in-Qemu work that Nokia did back in MeeGo and has been re-used by Intel/Samsung for Tizen? Fingers crossed that virgil ends up upstreamed this time, unlike that previous work!

most of the previous efforts were grossly insecure hacks and I was a bit active in making sure they never landed upstream!

I'm a bit confused. Are you just talking about running a vm stack locally ie host and guest on the same machine? or are you talking about running the vm remotely, then using the local display client as an offloaded 3d engine to rasterize?

It's all local so far, host and guest on same machine.

You can't really do 3d engine offload to a client, the bandwidth consumption is too much even for simple cases. At that point you are best using a codec for remoting.


So ideally, this could be very close to a pure pass-through between the Virgil driver on the client, and a Gallium-based driver on the host?

not really, since I'm not actually just passing through, and gallium host drivers don' t have an API at that level that is public or stable.

The problem with passing through is how you deal with security and contexts, in a normal desktop each 3D app talks to its own copy of the gallium driver, but in this case the whole VM is a qemu app and it is all talking to one driver, its a very different case, also the guest has to deal with swapbuffers and X rendering as well, the simple passthrough is what virtualbox mostly did and I find to be horrible and others have claimed insecure.


Ok... I was asking because of the FAQ entry about "Can we avoid GL on the host and go straight to gallium?" suggesting it was possible.

So, the software on the guest talks GL or DX to the Virgil driver, which maps it to Gallium, then maps it back to GL on the host for the native drivers to deal with? And if the latter use Gallium internally, that's not your concern?

guest talks GL/DX into Mesa or whatever DX, then we have a gallium virgl driver that linearises the gallium interface and sticks that over the pipe to the host. Then maps that back into GL on the host side.

If you piped gallium through it might save some overheads but you'd need a bit of extra work and also gallium isn't really a fixed public API, so it isn't versioned and can change, I intend to freeze the gallium api virgl uses.


Okay, that's clear, thanks.


Could the new Gallium Direct3D 9 state tracker form the basis of a Windows guest D3D driver?

Its probably at the wrong level, the Windows driver interface is slightly different than the programming API,

Though it would be a helpful guide.