|
Hardware-accelerated Wall Displays
As was mentioned elsewhere on this Web site, hardware acceleration of wall displays may not be a requirement if the display is basically static.
However, if the display is large (lots of monitors/projectors) and dynamic, hardware acceleration may become very important in obtaining acceptable performance of the system. The power of modern GPUs is impressive, and can be used to significant adavantage to for moving windows around among a dozen or two monitors/projectors.
Wall display systems based on Xorg X servers seem to have a problem accelerating every monitor view for the large (maybe even the small) wall display systems. See, for example, the short Case Study of the Dept of Transportation system with nine monitors and four video windows.
Summit Series Wall Display SW (the HX Series, for example) does not have such problems, since all monitor views are fully hardware accelerated. The HX Series is used in railroad traffic control systems, which are certainly not static.
Hardware-accelerated OpenGL
The example of hardware acceleration above was for 2D operations, since IBM does not suggest the use of the GXT135P (or the newer GXT-145P) as a card for OpenGL, nor provide any SW support for OpenGL on it.
The card is not a strong 3D performer when compared to later Matrox or ATI cards that have hardware TCL (transform, clipping, lighting) support in the graphics 3D engines, which the G450 does not have. Nonetheless, the card can perform OpenGL 3d operations reasonably well with Accelerated-X SW if the operations do not need large texture memory, etc. (the G450 is limited to a max of 32MB of on-board graphics memory.
The Accelerated-X OpenGL rendering pipeline in the Summit Series products was developed "from the ground up" by Xi Graphics to provide full hardware acceleration that was available from the graphics cards/chips supported.
Presently OpenGL v1.5 is supported - as well as some later extensions - in some Summit Series products with certain graphics hardware. However, Accelerated-X OpenGL is not targeted at gamers, but rather at commercial systems that need OpenGL for such things as seismic data analysis, financial data presentation, flight cockpit simulation, and so on.
Making whiskers grow realistically is not high on our priority list, but as the applications on commerecial system become more sophisticated, we will enhance our OpenGL offering to include v2.1 when the customeers tell us that they need it.
DRI/DRM, the path taken by Xorg for implementing direct rendering of OpenGL when the application and the X server are both running on the same platform, is also something that is not on our list.
That approach was predicted by Xi Graphics at the time it was being put forth to be a wrong-headed idea. We were proved correct.
Summit Series OpenGL option does have direct rendering capability, however, and it is very fast, very stable, and does not require tight coupling with the kernel, as is the case with the DRI/DRM architecture.
With Xorg, direct rendering requires even the graphics driver to be interfacing with the kernel. Maintenance must be fun with such a system. Forward and backward compatibility issues must be really interesting, too, as graphics hardware changes, kernels are changed, and the Xorg X servers are changed.
|
|
Elements Required for FHA
Realizing high performance for a particular class of graphics applications through the utilisation of the available power of the graphics hardware in a system depends upon a number of factors.
The Graphics Driver
First and formost, the graphics driver for the chip/card being used in the system must be well written to extract the most from the available graphics hardware.
Graphics chip/card manufacturers generally write their own graphics drivers for thier hardware, and who knows the graphics architecture better than its designers? Most of the the results are supurb, since most of the hardware is used on Windows. The API for Windows - ridgedly controlled by Microsoft - is pretty well fixed, and well documented. Just to make sure, though, the drivers for Windows still are subject to certification.
In the case of another popular OS - Linux - the outcome seems to be rather lacking, sometimes to the point of being downright poor, to - in the extreme - unusable for some applications. Could it be that the API to which the graphics driver is a problem? Certainly the engineers know how to write hardware accelerated graphics drivers.
But just in case the Linux market is too small for the graphics houses to spend the time/money on Linux drivers, why don't the "third party" graphics drivers show better results? Because a) they cannot obtain all the necessary (confidential) information from the graphics manufacturers that is required to enable them do write a full hardware accelerated driver, or b) they are not very good graphics driver writers, since they don't make their living doing it. But even if they were expert at it, the results would not be any better than the drivers from the graphics houses. Here's why.
The Xorg X server
Most of the Linux graphics drivers written by the graphics card/chip manufacturers are written to run with an Xorg X server. Oops. A ridgedly controlled Xorg X server? A well documented API for an Xorg X server? A well designed and implemented Xorg X server? An Xorg X server that can use the hardware acceleration features designed into the graphics driver by the graphics manufacturer? Get the picture? But it gets worse. The OS kernel is involved, too. And it is not ridgedly controlled by Xorg.
Don't Forget the OS Kernel
Especially if it a Linux kernel. And especially if OpenGL in required. Not only are the Xorg X servers generally not stable (as in slow changing), well specified, well maintained, well documented works, when it comes to OpenGL, a small (or big) kernel change can blow things up. The reason is quite simple. The Xorg/Linux community believes that the way to increase the performance of graphics SW operations is to move some graphics operations into the OS kernel, al la Microsoft.
Well, well. Now when there are changes to the Linux kernel - a rather frequent occurrence - the effects can bring the graphics SW to its knees, since some of the Xorg OpenGL-related graphical routines are now Linux kernel modules. Oops. Check out DRI and DRM in the X.org world for more gory details. It's not pretty.
If one gets the idea that we are making the case for using Windows in order to get good graphics performance, far from it. Instead, we think we have a much better idea.
Since Xi Graphics develops its own commercial X servers and writes its own FHA graphics drivers (when the docs are available to it), and isolates the X server and drivers from the kernel as much as possible, we think we have the best solution for stavle, high performance, low manitenance X Window System SW for UNIX systems, including Linux systems.. For more see Summit Series World.
|