From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cNR-0002LF-7U for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:11:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1cNI-00023q-UD for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:11:41 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:46670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cNI-00022X-OA for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:11:32 -0400 Message-ID: <51EE80FC.4080401@oracle.com> Date: Tue, 23 Jul 2013 17:11:24 +0400 From: Michael Thayer MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Mesa-dev] Introducing Virgil - 3D virtual GPU for qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dave Airlie Cc: mesa-dev@lists.freedesktop.org, qemu-devel@nongnu.org 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=20 your code (the Mesa part), and on the whole it looks like something we=20 could make good use of too, except that we would want to be producing a=20 stream of something closer to OpenGL which we could send over our=20 existing proxying mechanisms. Since you put the client and server code=20 conveniently close to each other in your clone of the Mesa repository,=20 my idea would be to add an build-time option to do this by pulling the=20 server-side code into the Gallium driver too - is that something you=20 could live with if I wrote code for it? My tendency is to output a=20 white-listed subset of OpenGL as a text stream which a custom winsys=20 back-end could send into a DRM driver. Regarding your comments on the=20 safety of passing OpenGL through, isn't a major part of the risk in the=20 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=20 above immediately either, as this will not make sense without a proper=20 DRM driver which we currently don't have, and which would be my first=20 target. Since this is my first proper visit to that part of the kernel=20 code I will probably take a little bit more time for it that you would. Regards, Michael --=20 ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.thayer@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 M=FCnchen Registergericht: Amtsgericht M=FCnchen, HRA 95603 Gesch=E4ftsf=FChrer: J=FCrgen Kunz Komplement=E4rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch=E4ftsf=FChrer: Alexander van der Ven, Astrid Kepper, Val Maher