|
From: | Dan Sandberg |
Subject: | Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC |
Date: | Fri, 12 May 2006 17:36:59 +0200 |
User-agent: | Mozilla Thunderbird 1.0.7 (Windows/20050923) |
Jamie Lokier wrote:
Yes, in the worst case the OpenGL-driver is all software emulation and then it is slow and CPU-consuming.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 speedNot 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
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
[Prev in Thread] | Current Thread | [Next in Thread] |