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

[Dan Sandberg]

Fabrice Bellard wrote:

> Dan Sandberg wrote:
>
> > Just curious...
> >
> > Are you using an OpenGL directdraw surface for the graphics emulation 
> > in Qemu?
> > If not, then consider the benefits:
> > 1. It is much faster than any native graphics 2D/3D primitives like 
> > Windows GDI
> > 2: It gives full control over things like window or fullscreen mode 
> > in any (almost) resolution and color depth.
> > 3. It is operating system independent.
> > 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
> > channel etc in hardware, all you have to do is select the pixelformat 
> > you like to use for the buffer and OpenGL does the rest - lightning 
> > fast, minimum CPU-load.
> > [...]
>
>
> I am not sure the bottleneck is in the rendering itself and the single 
> primitive that QEMU uses (display a rectangle of bitmap) is 
> accelerated by every graphic card since many years. But you are free 
> to modify the SDL library to include OpenGL rendering if it is not 
> already done :-)
>
> Fabrice.
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
OK,
I am no expert at Qemu's inner workings as you are, but I think I have 
seen mentioned that host and guest pixel formats should be kept 
identical for best performance eg. an undesired need to select 16-bit 
graphics on the host when one wants to use high resolution on the guest 
at which resolution the emulated graphics board only supports 16-bit. I 
also get the impression that the quest display area is updated less 
frequently than the native intervall probably to keep CPU-load down and 
also meaning that the guest OS waste CPU-time on rendering that is 
sometimes "thrown away" when it happens in between actual Qemu display 
updates.

To me this suggests that the needed RectangleBlit operation is not 
CPU-transparent and it seems from the discussions that the lower than 
native update frequency may introduce totally new problems like graphic 
artefacts or possibly the guest OS going out of sync with the emulated 
display adapter and a pointer that cannot keep up with fast movements 
sometimes.

Creating a rectangular direct output area in OpenGL is actually like 
vitualizing a graphics card.
It is updated at native speed 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.

The next logical step would be to emulate a more competent graphics 
board in this rectangular area including hardware acceleration for guest 
RectangleBlit operations etc. This would give much better 2D-performance 
for any guest OS that knows have to take advantage of it and of course 
OpenGL would be used for this too. It is more or less a mapping of 
OpenGL functionality between guest and host OS'es.

No fancy 3D OpenGL stuff is needed, only the very basic 2D functionality 
is required to boast performance in windowed enviroments so even old and 
cheap graphics cards would do the job. It is OS-independent as long you 
can find an OpenGL-driver.
I realize that the latter may be a problem in some cases so 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 am also not suggesting that you should do the hard work Fabrice. I am 
truly impressed of what you are doing and don't understand how you find 
the time.
I am also not suggesting that I know exactly how to do it, I am a 
beginner when it comes to OpenGL-programming and only starting to 
realize the possibilities of it.
So I only wanted to start the discussion and hopeing for an 
OpenGL-genious out there with lots of spare time. :)

Regards
Dan