From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kba17-00025T-AI for qemu-devel@nongnu.org; Fri, 05 Sep 2008 08:02:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kba16-00024t-9B for qemu-devel@nongnu.org; Fri, 05 Sep 2008 08:02:20 -0400 Received: from [199.232.76.173] (port=37448 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kba16-00024n-5d for qemu-devel@nongnu.org; Fri, 05 Sep 2008 08:02:20 -0400 Received: from mail2.shareable.org ([80.68.89.115]:43970) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kba16-0005m1-A6 for qemu-devel@nongnu.org; Fri, 05 Sep 2008 08:02:20 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Kba11-0000Xi-FF for qemu-devel@nongnu.org; Fri, 05 Sep 2008 13:02:15 +0100 Date: Fri, 5 Sep 2008 13:02:15 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window Message-ID: <20080905120214.GD1373@shareable.org> References: <48B81423.9050502@eu.citrix.com> <48BF4F4F.40208@codemonkey.ws> <48BFB318.206@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BFB318.206@eu.citrix.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Stefano Stabellini wrote: > Anthony Liguori wrote: > > > Stefano Stabellini wrote: > >> This patch comes from xen-unstable and adds opengl support for rendering > >> the guest framebuffer in the SDL window. > >> SDL is needed anyway to open the window and handle the events. > >> Opengl rendering is optional and can be turned off at both compile time > >> and run time (--disable-opengl). > >> Some of the benefits of using opengl are: > >> > >> -faster rendering, less CPU intensive, especially with good graphic > >> cards; > >> > > > > Have you measured this or is this just intuition? I've measured it with > > gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for > > rendering verses an XShmImage. > > > I wrote that because before my patches all the colour conversions were > done in vga_template; after the sdl shared buffer patch the colour > conversions are done by SDL that sadly most of the time still implements > them using CPU based algorithms. > The opengl code should be able to offload all the colour conversions to > the GPU. > So I was referring to SDL vs. OpenGL. Fwiw, in my experience with Xine and mplayer, drawing video updates to the screen using OpenGL was quite a lot slower than drawing them with XShmImage. That needs colour conversion as video doesn't even use RGB. Probably OpenGL is faster on some hardware, and slower on some hardware. Don't assume it's always faster. > Then there is the video memory versus system memory discussion: the > opengl patch loads the guest framebuffer into video memory then does the > conversion and blitting video->video that should be accelerated. > SDL_CreateRGBSurfaceFrom creates the surface in system memory so the > blitting shouldn't be accelerated. > I am saying should and shouldn't because it also depends on the video > card drivers and the opengl implementation. Yes it very much depends on the drivers and opengl implementation. It isn't always possible to map the guest framebuffer into video (texture) memory, and also some opengl implementations are not particularly fast at copying textures from CPU memory to texture memory. Another way to map guest framebuffer to video memory is the XF86DGA extension, which is great when you can use it. I think VMware uses it in full-screen mode. -- Jamie