[Mesa-dev] Introducing Virgil - 3D virtual GPU for qemu

[Dragomir Ivanov]

Dave, what is your motivation to use OpenGL renderer/translator, and not
native Gallium3D interface?
Yes, I know about the blobs performance/features, but wasn't the idea to
push even harder, so everyone uses FOSS drivers?
I have always asked myself, "Why the heck virual 3D is so hard to do?
Couldn't TGSI steam generated from guest Mesa3D just gets passed down to
host Gallium3D provider(Mesa3D again), and then pushed to pipe drivers?"


On Tue, Jul 23, 2013 at 4:11 PM, Michael Thayer
<michael.thayer at oracle.com>wrote:

> 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:michael.thayer at oracle.**com<michael.thayer at oracle.com>
>
> 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
>
> ______________________________**_________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130726/93e11ee4/attachment.html>