Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

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