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
Qemu-devel@nongnu.org
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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel