qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Mesa-dev] Introducing Virgil - 3D virtual GPU for qemu


From: Michael Thayer
Subject: Re: [Qemu-devel] [Mesa-dev] Introducing Virgil - 3D virtual GPU for qemu
Date: Tue, 23 Jul 2013 17:11:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

Hello David,

On 18/07/13 08:48, Dave Airlie wrote:
since I suppose these communities would be most interested in this and
might not all read my blog or G+ stream,

"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.
[...]
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."

Sorry I didn't get round to answering earlier. I have taken a look at your code (the Mesa part), and on the whole it looks like something we could make good use of too, except that we would want to be producing a stream of something closer to OpenGL which we could send over our existing proxying mechanisms. Since you put the client and server code conveniently close to each other in your clone of the Mesa repository, my idea would be to add an build-time option to do this by pulling the server-side code into the Gallium driver too - is that something you could live with if I wrote code for it? My tendency is to output a white-listed subset of OpenGL as a text stream which a custom winsys back-end could send into a DRM driver. Regarding your comments on the safety of passing OpenGL through, isn't a major part of the risk in the shader code anyway, which we can't really not pass through either way?

I would probably not be able to get on to writing the code I mentioned above immediately either, as this will not make sense without a proper DRM driver which we currently don't have, and which would be my first target. Since this is my first proper visit to that part of the kernel code I will probably take a little bit more time for it that you would.

Regards,

Michael
--
ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:address@hidden

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher



reply via email to

[Prev in Thread] Current Thread [Next in Thread]