[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CCAC68F.7050903@codemonkey.ws>
Date: Fri, 29 Oct 2010 08:05:19 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: virtualization@...ts.linux-foundation.org,
QEMU Developers <qemu-devel@...gnu.org>,
virtualization@...ts.osdl.org,
Ian Molton <ian.molton@...labora.co.uk>,
Avi Kivity <avi@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
On 10/29/2010 06:18 AM, Rusty Russell wrote:
>> Fixed - updated patch tested and attached.
>>
> OK. FWIW, I think this is an awesome idea.
Paravirtual OpenGL or the actual proposed implementation? Have you
looked at the actual code?
If I understand correctly, the implementation is an RPC of opengl
commands across virtio that are then rendered on the host to an
offscreen buffer. The buffer is then sent back to the guest in rendered
form.
But it's possible to mess around with other guests because the opengl
commands are not scrubbed. There have been other proposals in the past
that include a mini JIT that would translate opengl commands into a safe
form.
Exposing just an opengl RPC transport doesn't seem that useful either.
It ought to be part of a VGA card in order for it to be integrated with
the rest of the graphics system without a round trip.
The alternative proposal is Spice which so far noone has mentioned.
Right now, Spice seems to be taking the right approach to guest 3d support.
Regards,
Anthony Liguori
> I understand others are skeptical,
> but this seems simple and if it works and you're happy to maintain it I'm
> happy to let you do it :)
>
> Cheers,
> Rusty.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists