Re: [Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again

[andrzej zaborowski]

Hi,

On 10 January 2012 09:29, Alon Levy <address@hidden> wrote:
> On Mon, Jan 09, 2012 at 08:57:50AM +0100, Andrzej Zaborowski wrote:
>> This is the host part of an OpenGL passthrough framework to make apps
>> run faster.  It has initially lived on nongnu.org as a separate project
>> by Even Rouault, later was picked up by me to use in the Poky
>> meta-distribution and later was picked up by various platform SDKs
>> for application developers.  It's still evolving but it would be good
>> to reduce maintaining cost and parallel evolution in different trees
>> by having it upstream.
>>
>> In 2010 Ian Molton started a discussion about it [1] and got some
>> feedback which I tried to address in these patches.  The code has gone
>> through major refactoring but I may have missed some things not having
>> the distance when looking at the code.  Suggestions welcome.
>>
>> Some discussion points:
>>
>> One of Anthony's comments in the old thread was that this could be a
>> temporary solution but where we really should be heading is towards a
>> paravirtual VGA (like the vmware-svga or the Spice one) that will be
>> OpenGL independent and secure.  While having such a thing would be
>> good, it's less likely to achieve near 1:1 performace and performance
>> is the whole point of the passhtrough.  Also it's apparently quite
>>  difficult to do, but seems that VMWare have managed it, so it's
>> possible.  I'd personally prefer to put effort in the emulation of
>> one of the real moden GPUs instead.
>
> I think you are right to push a passthrough implementation into qemu,
> for one it gives something working now. Not sure the performance will be
> any different then a paravirtual approach (just talking about server
> side rendering here), since it's basically doing the same thing, but it
> would certainly be simpler.

You're right, in the end there's no specific reason the paravirtual
approach should be slower, I guess it might work just as well.

>
> Do you have further thoughts about real GPU emulation? would you target
> an ATI (AMD) GPU, since they released specs?

I haven't looked at the specs, but it's worth to choose the simplest
one since these tend to be very complicated devices.
intellinuxgraphics.org has some documentation about Intel GPUs but if
I remember correctly things like the instruction set were not in those
specs.

>
>>
>> I think instead of going towards a paravirtual vga, this should be
>> going in the direction of a generic, almost-no-overhead virtio-based
>> RPC mechanism.  From what I read qmp provides a json based RPC
>> mechanism, this is totally not what we want here.  What I'd want is
>> a very simple binary RPC where, optimally, big buffers can be passed
>> as parameters to remote function calls with no single memcpy.  This
>> could be done by having a guest kernel driver allocate continuous
>> physical memory chunks on requests and pass physical addresses to host.
>
> qmp is not suitable for this, sure. Something like the qxl/svga device
> would work fine - you have a BAR for the continuous allocations. You
> could also do a device like that based on virtio queues.

(Just a note I forgot to add,
http://meego.gitorious.org/meego-developer-tools/meego-emulator-qemugl-x86/blobs/qemugl-on-0.14/hw/virtio-gl.c
is a custom virtio based transport for Qemugl but it's not included
here because it requires a bigger effort from the user to start using,
and the merging would have to be coordinated with other projects)

>
...
>> 1. http://thread.gmane.org/gmane.linux.kernel/1045340
>>
>> (Actual authors of each file are listed in the file headers, not
>> in the Signed-off-by)
>
> You can change the author of the patches with git commit --amend --author __,
> seems a little nicer.

I meant the authors of the source files and not patches.  I'm not in
contact with any of them.

>
> Running scripts/check-patch.pl on these I get multiple errors, but I
> guess you are waiting for some input before fixing those..

It didn't occur to me, but there are some good catches in the output
so yes, I'll correct before next iteration.  There's a lot of false
positives resulting from tricky preprocessor use and patch 2 contains
headers from an external project (Mesa).

Cheers