1. Conventional Wisdom can be dangerous
OpenSource SW, as a philosophy, can be very useful when applied properly. However, it can also be deadly - to schedules, project costs, and system performance - when misapplied to commercial/military computer systems that have non-trivial X graphics requirements.
OpenSource is most often applied to such systems by making use of the Xorg X servers, and the Xorg-compatible graphics drivers written by the graphics houses (graphics chip/card manufacturers). Since OpenSource is used successfully for myriad utilities of all flavors, it is natural to assume that it could be used for X graphics with equal success.
If a teaspoon of sugar tastes fo good, let's eat a barrelfull. X graphics represents a very large barrel. While OpenSource might be good for a snack, a large meal of it, as in the case of the X Window System is usually not enjoyable. Why?
2. Computer Graphics - Not Simple Utilities
The hardware capability of modern graphics chips, especially those with strong 3D support - which means most of them - are marvels of technology. Put a large chunk of fast memory and the output capability to drive two, four, or even eight large monitors along with the graphics chip on an add-in card, and you can have a super-computer on your hands. On a card that is plugged into your "normal" computer.
Think it through. The functional and often impressive images painted on the output monitors start with commands from your application(s), passed by the OS kernel to the graphics system SW, which is responsible for the generation and presentation of those images on the monitors, using the inputs from the applications program, operator devices, communications connections, and so on. Sounds kinda straightforward, if not acutally simple, right?
And, if you're running Windows, it most likely works without hassle. The graphics driver for the graphics card is provided by the graphics house, and all utilities needed for touchscreens, monitors, I/O devices and so on are available. Plug and Play. No worry about X servers, window managers, PCIe vs PCI bus chips, multiple xscreens, overlay images, remote displays, multiple displays per computer, Xinerama, and on and on.
MS takes card of most everything but the graphics driver - such things that are known in the X graphics world as the X server, the desktop (GUI), and infrastructure for the myriad peripheral device drivers. And, because the Windows graphics market is about fifty times the size of the UNIX graphics market, the graphics houlses take care that the Windows graphics drivers are high-quality, high-performance products.
3. A Quick Look At The Windows World
The first major difference is that the size of the market, as previously noted, is huge, compared to the UNIX market. Why is this important?
Well, let's start at the monitor connection(s) to the computer box, which is the output side of the graphics card. For this card we need a graphics driver. Ah, who better to write the graphics driver for a complex, high-performance graphics divice but the graphics house. After all, they designed the graphics chip, so who knows better how to get the most out of it with a graphics driver?
Hmmm, let's focus in a bit. The Windows graphics driver is written to a well-defined API that is specified and tightly controlled by MS. While there may be changes now and then to an API for a given Windows OS, one expects the Windows API to be reasonable fixed over time.
Thus the target interface for a Windows graphics driver is generally well defined and documented, and quite stable. What happens further up the path toward the kernel - the internal graphics infrastructure, the GUI and the kernel itself - is not a concern to the Windows graphics driver writer. MS takes card of (and controls) all that "stuff". Make the graphics driver meet the API specs and pass the qualifications tests, and you're mostly home free.
For each graphics chip, the graphics house will need a graphics driver for each Windows OS to be supported. And maintained. Kinda routine; the system works well, and the economics are in line (the cost of the driver SW is buried in the cost of the hardware without a pricing problem), so the card purchaser geta a "free" Windows graphics driver. He can plan on plugging in the card, loading the driver and focus on system issues other than graphics.
4. UNIX/Linux Graphics is a Different World
As previously noted, the UNIX/Linux graphics market is tiny compared to the Windows graphics market. This fact has played an important part in the mess that presently exists the UNIX graphics market.
The graphics chips/cards are generally high-performance and very sophisiticated devices. Some are powerful enough to "melt" your computer. Putting one or more modern graphics cards into a computer chassis in the UNIX world can be the beginning of a saga few have planned on.
Much like the Windows world, there is more than one OS kernel to consider. With Windows it is really a selection of the OS, not the kernel. With UNIX (which includes Linux here), picking an OS may not specify the kernel version. And picking a kerlel does not necessarily specify an OS. So let's see if we can make this simple.
First, if you choose to use a Linux kernel, which one should you choose. There are dozens (at last count) of Linux distributions, and each is allowed to "tweak" the kernel in their disturbution. You, as a systems designer, are allowed to customize your kernel also. So, there are many, many Linux kernels in play. Since the kernel is a key player in a system, the choice is non-trivial.
If you chose a UNIX OS from IBM, Sun (now Oracle), or HP, your kernel selection is goverened by the kernel available with the version of AIX, Solaris for SPARC, or HP-UX you chose. The rinkle here is that these OS generally do not support any graphics cards that IBM, Sun, or HP do not provide already integrated into their boxes. More on this later.
So, let's say you go the OpenSource route and choose Linux. After all CW (Conventional Wisdom) says it is a wise choice. So, pick a kernel, or at least pick a distribution, which will get you a kernel - in fact probably a choice of more than one from that distribution vendor. Yeah, I know we said "let's make it simple", and we are trying.
Next, you will need a graphics driver for the graphics card(s) you want to use in you system. Not a probem, since the graphics house provides Linux drivers for free for their graphics hardware. Just download one.
Uh, but is there a driver that works with the Linux kernel you chose? Ah, it's OpenSource, so if there is a problem, it will be an easy fix, considering all of those community developers out there available with a google.
So let's move on to the X server. It will be included with your distribution. In fact, you have the chouce of many, many versions of Xorg X servers from distributions and downloads. So many versions that its hard to count them. You can begin to narrow the choices by going back to the graphics house drivers to see which Xorg X servers they will hook up with. Then see if those versions of Xorg X servers will work with the kernel you have decided to use.
You see, as you proceed down this path, you will learn that the Xorg X servers are the epitome of complex OpenSource SW. That is, there are no formal specifications for the X Window System (since about X11R6.5), and without specs, things get a bit goosy, subject to change by the OpenSource Community without much concern for the consequences, the ricoches.
Oh, BTW, this eschewing of specifications by Xorg was apparently adopted from the Linux group, whose founding genius believes that specifications "inhibit innovation", and hence are not to be used. Mayge he is right. If innovation is evidenced by the number of Linux kernels generated per time period, there's a lot of innovatin' goin' on with Linux kernels.
But the Xorg X servers are the targets of the graphics house graphics driver writers. How can they develop drivers to the backend of an X server that is changing randomly, and frequently, and constantly? Funny you should ask. Maybe they just pick one and use it as the target in the hope that their customers will use that target X server. And maybe, just maybe, that X server will work with the version of Linux you plan to use.
Let's see now. The Linux kernel is a choice. The X server is a choice, The graphics driver is not a choice if it is the one from the graphics house, since it would be a given. But even if you are able to sift through the choices and selections and get some X graphics SW that works on your system, you are not home free, unless you can freeze your system, and archive the graphics SW, including your graphics applications. Any change anywhere in the SW chain and/or the hardware chain can result in nasty problems.
Certainly upgrading your Linux kernel to a newer one invites problems with the X server you are running. Chage the X server, and your graphics driver may not work with the newer one. Change your graphics card? No way.
Change your application to employ Xinerama across several monitors? Not a big problem if you only need graphics accelerated on one monitor. Or add some video windows to your Xinerama wall display? Good luck. Or howabout adding some OpenGL capability to your applications for a Medical or a Military customer? Have fun.
Many who have used or tried to use Linux have stumbled into the pitfalls of using OpenSource X graphics system SW. Sometimes it is the Llinux "expert" pushing OpenSource to his superiors, and sometimes it goes the other way.
Eigher way, it is often the case that when system problems are encountered, it is the engineers who suffer under the illusion (theirs and their boss') that the engineers must be missing some obscure thing or two, since "everyone knows" that Linux and OpenSource is the way to go, and everyone has only good things to say about it. Thus the engineers and their management tend to belief that with a little more time and maybe some help from an outside Linux "expert", the project will finally come together and can be shipped.
And sometimes, that happens. The system is finally shipped. Then something awful happens; the customer wants some goodies added to the graphics capabilites. Or the graphics card needed for more systems is obsolete and cannot be procured. Or the new computer systems ordered to replace the aging systems in the field can't boot with the graphics cards. Or a latent bug is uncovered with a new compile of one of the key applications, and the X server/graphics driver set burps.
These are familiar occurrences to Xi Graphics, who often get calls from engineers who have suffered for months (eighteen months in one case with a state highway department) trying to get Xorg to do something that one would rightly assume it could (and should) do, but cannot do because of very poor SW architecture. Often, within days of contacting Xi Graphics, the engineer has his system up and running. But not with Xorg X servers nor graphics house drivers.
Instead, their systems ship with Accelerated-X X servers and graphics drivers. Whether with Linux, AIX, SPARC, or HP-UX kernels, and reqardless of versions, the X servers and graphics drivers for a given graphics card are mostly all the same, making maintenance a breeze (we don't charge for our standard support), and allowing the development cost of a pargicular card to be amortized across the landscape.
|
|
5. Economics of Good SW Architecture
Contrast the economics of having essentially one X server for all platforms, kernels, and graphics cards, with the current "UNIX graphics mess" (the author's term) using Xorg X servers and graphics house drivers.
The graphics houses make very good Windows drivers. Thus it is obvioius that they know their hardware and how to write drivers to take advantage of the graphics hardware they make. So why are Linrx graphics drivers from the graphics houses so lacking for some applications?
Consider the economics from the vantage of the graphics house. First, the Windows drivers, then the Linux or UNIX drivers.
6. Windows Driver Economics
Writing a graphics driver that extracts the maximum performance from the graphics architecture of the hardware on a graphcs card is a non-trivial piece of work, even with a well defined and well documented API for the "front-end" of the driver to hook up to. With the advent of the "shader" logic on many graphics chips that allows the GPU instructions to be changed "on-the-fly", a compiler for a GPU archicture is a challenge in itself.
However, once the development tools specific to a particular graphics architecture are developed, they are useful over a range of versions of the graphics architecture, and the driver development now focuses on the target API.
As previously noted, this target API for the Windows OSs is specified and controlled by Microsoft. It is generally a stable target for a given Windows operating system, so experience with it is long lived, and maintenance is pretty much routine.
The fun, if it can be called that, is when MS introduces a new OS to the World, and the graphics API is significantly different from earlier ones, including changes to MS's 3D specifications. A major amount of time and money is spent by a graphics house (we surmise) in developing graphics drivers for the new MS specifications.
But, at least the graphics houses have specifications with which to work. And the costs can be borne by the large volume of graphics chip/cards sold into the Windows market.
7. UNIX Graphics Driver Economics
What is often not appreciated by the system developers in the UNIX market is that a graphics driver for a graphics chip/card in a UNIX/Linux system is at best only a distant cousin to a Windows driver for that same graphics chip/card, even though the graphics hardware is the same.
A driver development group at a graphics house will find it difficult (basically impossible) to obtain a well-defined, well-documented API for the back-end of the X server that the X Window System driver is to use as its target API for use on Linux, for example.
If the kernel is AIX, Solaris, or HP-UX, and the X server was developed by IBM, Sun, or HP respectively, the X server/driver interface exists, but will probably not be formally specified or well documented by the firms. And each one will be different, since the X Window System specification does not contain a specified API between the server and driver, the dix and ddx, respectively.
Chew on this a bit. The target graphics API (the back-end of the X server) is not well-defined, nor well-documented? But, you say, the Linux X server is OpenSource, so clearly the API is available! Well, one probably can find a graphics API for a Linux X server. Probably won't be well-defined, nor well-documented, unless one condiders the Xorg X server code to be the definition and documentation.
The graphics house driver group is to write Linux graphics drivers for their graphics hardware to a non-existent or at best a "goosy" interface and provide it with their cards for use by the OEM s and system builders for use with some Linux kernel and some version of an Xorg X server, and expect it to work?
With limited variables, such a particular laptop model, a specified Linux kernel version, and a particular Xorg server version, it certainly would be possible to write a Linux driver that could be made to work with the various pieces. With kernels and X servers of various versions, there is basically no hope of having a Linux driver with full hardware acceleration that would work "acurss the board". That partially explains why many free Linux drivers don't have hardware acceleration, but instead use the "FrameBuffer" approach which is quite slow.
OK, so at least it is possible to obtain from the graphics houses Linux graphics drivers that work in some system configurations, on some kernel/X server combination, and with varying degrees of performance. But at what cost to the graphics house - a cost that is typically to be buried in the price of the graphics card?
Because of the lack of stable, well-defined, and well-documented target APIs for UNIX graphics drivers, the cost to develop drivers can be much more expensive for UNIX than for Windows. And for a market that is much, much smaller that the Windows market.
Add to the development costs of the drivers the costs of trying to maintain them for a multitude of kernel and X server versions, and one can quickly understand why graphics drivers from the graphics houses are generally lacking in performance and features on Linux, and are mostly unavailable for other UNIX systems. The economics are just not there.
The result is that the commercial systems builders often find themselves with a nasty graphics problem on their hands late in the schedule, a problem that can bring a project or a production line to a full stop.
Often the problems are not solved by the engineers "finally" finding the key to the correct configuration or combination of pieces after another extension in the delivery schedule, because the problem doesn't fall into the category of "What am I doing worng?", with a quick fix just around the corner. Instead, the error was made early in the project planning process when it was decided that Linux and OpenSource would be kernel and graphics SW used for the project.
True, OpenSource is almost universally considered to be a "good thing", and anyone who suggests otherwise is often ridiculed. CW can be powerful. But it can also be powerfully wrong.
8. "Free," OpenSource SW Can Be Very Expensive
Just because good SW is "given away" with the pruchase of good hardware does not mean that the cost to develop and maintain that SW was insignificant. Often, it is developed at a very high cost and amortized across a large volume of hardware so as to allow the costs to be "buried" in the price of the hardware. When that large volume of hardware is not available, then something has to give.
That something may be a mix of availability, suitability, quality, performance, support, reputation, and so on. Xi Graphics has often been the "source of last resort" to turn to by firms in deep do-do because of the myth of the virtues of OpenSource for X Window System graphics. Some of the examples are cronicled in our Education Corner on our Web site, and others are being written up.
It is as if there is shame in having to call a perveyor of "proprietary, closed source" SW to get X working properly on a system or product. All other avenues are often exhausted by the time we get called, and expediting charges are sometimes incurred in order to get projects delivered on time after most of the time is already gone. Sometimes the solution is simple, fast and inexpensive using our off-the-shelf downloadable SW.
9. Proprietary Acceleated-X Is Economical
Inexpensive to own, not develop. On the other hand, when we develop an X server or a graphics driver, we are able to amortize the cost over a broad range of systems and market segments.
For example, a graphics driver for a particular graphics chip/card/architecture is usable across all UNIX/Linux kernels and computer platforms (porting required, of course). An Accelerated-X graphics driver does not know what kernel it is operating on, or what CPU architecture is involved. Maintaining one driver for all UNIX/Linux kernels and all platforms on which it is running reduces costs by some large factors. Making the SW very good in the first place is also a "good thing", expecially since Xi Graphics does not charge for normal maintenacne.
Another major economic factor is the fact that Xi Graphics develops and maintains its own X servers. They are high-quality, high-performance servers that also work on various platforms and with various kernels (porting required, of course). Currently, there are only a few X servers required that support all of the kernels and graphics chips/card covered by our entire product line. And only two kernel drivers are used (the kernel driver is between the kernel and the X server).
Our graphics drivers are designed to extract the maximum performance possible from a graphics architecture - known as hardware acceleration. We use the confidential register-level information provided to us by the graphics houses (under NDA, of course) that enables us to do this. We do not use any code from the graphics houses, nor do we require engineering support from them. Yet we get as much performance from their hardware as they get, often to their surprise, since some of that hardware is quite complex.
Our X servers have support for a very large number of features that are important to commercial systems builders and home users alike. Both the Accelerated-X graphics drivers and X servers conform to X Windows System specification X11R6.4, (the last formal specs for X) plus a number of later extensions that have "found their way in" without formal specifications.
Companies who use Linux and Xorg Xservers often have an in-house group of engineers familiar with Linux and Xorg X servers to maintaln their X SW, since the combination of Linux kernels, Xorg X servers and graphics house graphics drivers requires a lot of maintenance in most circumstances, Companies using Accelerated-X do not require such staff, since our SW is of high commercial quality, and maintenance is free to our customers when it is needed, which is seldom.
Thus, it is usually the case that our "proprietary, ClosedSource SW is the most economical way to go for UNIX systems employing the X Window System. Especially if you want it ot work "out-of-the-box" so you can ship on schedule, and enjoy years of maintenance-free, hassle-free performance from it for many years..
|