Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

Jamie Lokier wrote:

> Dan Sandberg wrote:
>  
>
> > Creating a rectangular direct output area in OpenGL is actually like 
> > vitualizing a graphics card.
> >    
>
> That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
> And I believe SDL already supports XF86DGA when in full screen mode.
>
>  
>
> > It is updated at native speed
> >    
>
> Not necessarily.  When I tried using mplayer (a video player) with the
> video output set to use OpenGL, it was the slowest of all options -
> even slower than writing the images though X11 shared memory with a
> copy-to-screen bitblt for each frame.
>
> But then, OpenGL drivers vary considerably in their performance and quality.
>
>  
>
> > and you can select pixelformat for that 
> > area independent of the host pixel format and you do not have to be 
> > doing any RectangleBlit operation or causing any CPU-load - to my 
> > understanding at least.
> >    
>
> Well, OpenGL does a RectangleBlit each time it redraws the 3d
> rendering area, doesn't it?  If you have hardware accelerated OpenGL
> support, that shouldn't use much CPU.  But then, the same is true for
> old-fashioned hardware accelerated 2d bitblt, if the pixel format is
> supported.
>
>  
>
> > [...] I am not saying that any of todays possibilities in Qemu
> > should be retired, rather that it could be sort of a new plug-in
> > module for those who want a virtual display adapter with close to
> > native graphic performance and happen to have what is needed in
> > terms of graphic card and drivers.
> >    
>
> I agree it's worth a look, because it may be faster for some people,
> and because it provides access to image scaling (potentially hardware
> assisted), which classic X11 bitblt does not.
>
> It might be worth looking at mplayer's OpenGL driver, which does
> something similar to what Qemu would need.
>
> Other X features which can do similar things and may provide equal or
> better performance are: Xv (used to display video, but generally
> provides a resizable overlay; may or may not provide a usable pixel
> format), and Xrender.
>
> -- Jamie
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
Yes, in the worst case the OpenGL-driver is all software emulation and 
then it is slow and CPU-consuming.

It may also be that some old OpenGL-drivers have to emulate a direct 
output area by bitblt operations from an off-screen buffer to the 
on-screen buffer and then there will be no gain, I agree.
But technically that's not the only way to do the trick and newer boards 
should be capable of doing it much smarter without any bitblt operations 
involved.

I still remember my old favorite, the Amiga computer with its unique 
virtual screens that allowed multiple programs to coexist in the same 
physical screen, each with its own display buffer, pixel format and all 
rendering in full speed. That was never done by bitblt-operations, 
instead much smarter by synchronized on-the-fly switching between 
multiple display buffers as the electron beam painted the screen.

Lets say that you want to set up a 800x600 direct output rectangle with 
BGR-pixel format inside a 1600x1200 RGB host screen on a modern card 
with an adequate OpenGL driver.

When the screen is "painted" the DAC's read from the host video buffer 
(1600x1200) and interpret it as RGB. Somewhere they "hit" the left 
boundary of the separate viewport that you have set up and bang, on the 
fly they switch to reading 800x600-organized data from the other video 
buffer and interpreting it as BGR. Later on the same video line they 
"hit" the right boundary of the separate viewport and bang they switch 
back to reading from the main buffer and interpreting it as RGB.

As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are 
equally active and equally often updated on the same physical screen - 
without need for any moving data around, and without any time consuming 
activity at all taking place as all switches are done on the fly in the 
background by special hardware (if the board supports this).

It is like having two separate physical video boards, each with its own 
display buffer.

Regards
Dan