The web site is put together by David Methvin, President. methvin@xig.com
BTW, while David intends a friendly tone with the "This'n'that" type abbrevs (ever heard of Toys'R'Us, who even got the R backwards?) most of his typos are intended. He does also reply to email sent to the webmaster and he puts up a prominent mailto: for the webmaster on the front page, just below the spot you discuss. It is not exactly a secret.
I think that coming clean about the quality of the code should be applauded. I've bought hardware products where after three months I'm still using beta drivers. If I'd known, I'd have been unlikely to buy the product at that point. As it is, I'm now unlikely to ever buy anything from that company again, because they weren't upfront about their code quality.
Freedom to change the software? that is a bogus argument but is does precisely demonstrate why Accelerated-X is a product. You should also be aware that XFree86 is not GPL'ed code, though it is freely available.
I am an ex-academic. I appreciate that rms' ideas might encourage diversity and novelty in creating algorithmic solutions. However, most of an X Server these days isn't novel solutions that can be patented, but technowledgery. It is knowing which registers to poke on a graphics chip, in which order, at which time intervals, to get a correct and clear image. This is not IP in the traditional sense, and I don't think the propogation of this knowledge would do much for any other field of software development.
X Servers and graphics chips are intrinsically pretty boring. You have to follow someone else's fifteen year old ideas about what graphics should be like and marry it to an insanely complex new chip that was developed a few weeks ago with inadequate documentation.
If the sources for Accelerated-X were made available, it wouldn't significantly add to the IP value of free software. The registers to drive a Matrox chip faster can't be applied to make an ATI or any other graphics chip faster, much less a non-graphics chip. They can, however, be applied to make an XFree86 implementation of an X Server for a Matrox chip yet faster.
All that would be accomplished by making Xi Graphics source code available would be to give a transient speed increase to XFree86 at the expense of the loss of a few dozen jobs. At the end of the process, you'd still have an XFree86 team that generates slower X Servers that fail the X test Suite and that are less robust than Accelerated-X.
What you'd be missing is a source for an X Server implementation that makes some effort to be faster, better and offers timely support.
I do believe that making novel algorithms available can improve other efforts. For example, there is little doubt that public inspection of crypto code is valuable. However, public availability of which register to poke is not, in my mind, of the same order.
It is however, valuable. If your machine crashes because some programmer can't be bothered to correct a bug, you may lose hours of work. If you can't correctly display an image of some project on which you are working, you may cause millions of dollars of lost productivity when a pipe or wire is sent the wrong way because it was drawn incorrectly because a programmer ignored the X specs or thought that their opinion about the significance of meeting the spec was important.
I do believe that open inspection of security code and OS code can improve it. I do not believe, with practical evidence, that open inspection of complex register poking code for graphics, has much to recommend it. I don't think rms' model for software improvement applies usefully to improving register poking on graphics chips.
XFree86 already demonstrates that the principle isn't working. I can crash XFree86 far faster and more easily than I can crash Accelerated-X. I can make XFree86 display incorrectly far more easily than I can make Accelerated-X display incorrectly. These are not the result of algorithmic improvements unique to Accelerated-X. They are the result of significant practical effort to find the best set of registers to poke and of a QA process intended to find errors before a user sees them. IMO, this is entirely not the point of GPL.
AFAIK, the point of GPL was to find a better algorithm, not a better register. The GPL makes no claim about the quality of the code it is to produce; that has been inferred and is the subject of religious adherence to creed rather than repeatable practical measurement. In any case, as I started off pointing out, XFree86 is not GPL'ed... you probably have to apply a different argument for non-GPL bt freely available sources;-)
FWIW, I can contribute anecdotal evidence about Linux' stability versus Windows. I can contribute practical, measurable, repeatable evidence about XFree86 versus Accelerated-X stability and correctness. Two different types of data. I'd welcome a practical, repeatable and measurable way to demonstrate Linux reliability versus Windows, rather than refutable anecdotal evidence. I'd love to see an independent group test the verifiable behavior of XFree86 and Accelerated-X Servers for stability and correctness.
Xi Graphics was born as X Inside in 1994 in Denver Colorado because that's where I was living then. I have never been part of XFree86, though I cooperated with Steve Matewski(sp) to produce an early version of an XFree86 X Configuration utility as part of the Prime time freeware collection, some time around 1990.
Of the other two co-founders, one was never involved in any software development at all and is not a programmer.
The technologically significant co-founder was also never a member of XFree86, but he contributed the sources that XFree86 used. Thomas Roell was the developer of X386, the free software X Server before XFree86. He remains the primary developer for the company and has developed most of the ideas that form the basis for XFree86 4.0, several years ago.
We have not hired four XFree86 developers at any time in the company history. AFAIK, we have interviewed several XFree86 developers over the five years we've been running, but we've never hired any. Our X Server/graphics chips hires are usually made from hardware driver developers that we train to understand graphics chips. If anything, we add to the pool of graphics hardware expertise.
The cards supported represent (most of) those chip makers that have provided databooks for their 3D engines.
There are no databooks available for the 3Dfx 3D hardware; there is a 2D databook, so Xi Graphics has been able to offer support for some 3dfx hardware in 2D/X mode. AFAIK, XFree86 relies on using a binary library provided by 3Dfx (GLIDE), which is not open source/GPL/whatever. The IP remains in the hands of 3Dfx and free software offers an interface to the real binary proprietary driver.
There is no support for the Matrox boards because of missing critical data for the 3D hardware. Some of the 3D hardware is openly documented by Matrox, but certain portions that give useful speed increases are not described. If 3D Accelerated-X claimed support for the Matrox boards using partial documentation, the performance would be lower than should be available, users would be disappointed. This is not a problem for free software developers; they can offer suboptimal software and people are grateful to have their card supported in any way at all. It is probably unacceptable for us to claim support and then deliver a small fraction of the speed that the card should deliver.
Similar properties apply to nVidia. The "free" X Server has been developed by an nVidia employee. Although the source code is available for XFree86, the data book is not available. Consequently if there is a bug or if someone wants to extend or improve the nVidia X Server, e.g. for higher speed or to fix a bug, there is no reasonable way to do so. The availability of source does not mean that you control the software; the IP remains in the hands of those with the databook.
The G200 isn't supported by 3D Accelerated-X because of the lack of documentation for the G200. Some 3D docs are freely available from Matrox. However, one of the main performance gains for 3D hardware acceleration is in a bit of documentation not disclosed by Matrox, even under a Non-Disclosure Agreement.
Free software developers and users will find that a G200 with some 3D hardware acceleration is faster than a G200 with no hardware acceleration, but Xi Graphics has always aimed for the maximum hardware acceleration. With missing information, this isn't possible and would make both the G200 and 3D Accelerated-X look relatively pathetic, and probably attract justifiable criticism if we charged full price and delivered a small fraction of the cards possible speed under Windows. That is clearly not a problem for free software.
The X Server is not the operating system kernel. It runs in user space. It needs to be root privilige because it accesses and manipulates low level hardware directly. If you have a piece of software that can change register contents and some of those registers change things like bus handling (e.g. DMA, IRQ) then you can do things to make the machine stop working. Try running your system with interrupts disabled. The kernel may be working, but it is getting nothing useful done. FWIW, a properly X Server can cause the kernel to panic, but only via system calls. The other poster that referred to this wasn't clear, but I think they might have intended that the X Server itself can't generate panics. In 1994/1995 one of the most common kernel halt problems reported with Accelerated-X on Linux and FreeBSD was a defective system call for keyboard handling. This has been corrected in both kernels for about four years. However, when it existed, remapping the casp lock key to be a control key would eventually provoke the kernel crash. So, you are right that the X Server is a user level process. It is, however, unusual in UNIX programs in that from user space, it manipulates low level hardware. That does not make intrinisically less safe than running the same code from the kernel. There are many modes of failure of an X Server. Some of them result in system lockup. Some result in the X Server locking up. Some result in incorrect response to a correct request. Only (extensive) testing finds the problems. Only diciplined programming and a respect for the customers data results in the bugs being fixed. Cheers, JeremyC.
I don't get your point. Accelerated-X updates are free. Check out the Anon-FTP site. Update to 5.0.3 was published very recently, for free, or the cost of a call to your ISP.
We typically support overlapped older and newer Linux technologies for some time. For example, we supported both a.out and ELF concurently for about 18 months and we've been supporting libc5 and glibc2 for some time.
So, I guess we agree. We offer free bug fixes and new products are new money, just like video playback (tried playing a DVD in that hypothetical VCR, have you;-) ). New product releases for us, are a consequence of a new feature and inability to offer a compatible update with previous release.
When we looked at the Creative Labs X Server, it was indistinguishable from the XFree86 Server, which in turn was drawn from the nVidia sources.
Having source code for the X Server doesn't matter if you don't have the databook for the graphics chip. Without the data book for the graphics chip, you are in pretty much the same state as someone without the source code. There is some small stuff you can do, but considering that the errata for a graphics chip may rival the size of the databook, you are unlikely to ever work out what is wrong and how to fix it.
You make the point for us. Your X Server is crashing, you don't know why and there is, in practical terms, no way for you to fix the XFree86 sources. For a fee, we take responsibility for the X Server.
Accelerated-X use still uses "classic" Intel UNIX X Server design of a root privilige process that directly accesses graphics hardware. Workstation designs usually use a kernel device driver. Xi Graphics (under contract) has done Workstation style designs, too.
Do they help? Umm, not really. If you get the code wrong, it goes wrong as easily in the kernel as in user space.
What does help? Testing, testing, testing... Most of the bugs we find aren't caused by X Server design, but by graphics chip changes or misleading statements in databooks and sometimes by human error (typographic errors in coding).
Every Accelerated-X driver module is subjected to many automated tests and several types of human testing. We use things like the freely available X Test Suite and our own tools. We also monitor an automated problem reporting mail address. Accelerated-X has a feature that when it crashes, most of the time it will generate a human readable crash dump and email it. That finds some failures that we miss in the standard testing, or identifies new hardware variants that crash with the normal code.
The X Server is the graphics driver. Crudely, a program isn't X if it doesn't use an X Server. The X Server handles the keyboard (via system calls), mouse (via system calls), system memory (via system calls), the bus (directly controlled with registers, for graphics purposes) and directly controls the other graphics hardware (graphics memory, DAC, CRTC, graphics engine, bus interface).
What you describe sounds exactly like an X Server crash, probably caused by an incorrect configuration or because the hardware is more recent than the X Server support. Cheers, JeremyC.
Both are fine for me.. but you don't report the graphics card that you use. Just because it crashes for you, doesn't mean that it will crash on all graphics cards on all X Servers.
The 4.61 crash sounds like a netscape bug. The 4.7 crash sounds like an X Server crash. Most X Server crashes are h/w dependent. Usually, a bug that can kill or disrupt one X Server on one h/w platform is completely irrelevant to a different X Server and graphics chip. It may not even affect a different revision of the same graphics board (e.g. different memory type or different graphics chip revision).
Changing bit planes is not plausible with X. In the very first exchange between X client and X Server, the X Server offers the visuals and color depths supported and the resolution. There is no protocol request or event to notify the X client that the Server has changed these characteristics and there is no way for a client to ask the X Server to change them.
Probably the easiest way to gain a similar effect is to use a graphics card that can support hardware overlays. That way you can have both 8bpp applications (using 255 colors) and 24bpp applications. Use the 8bpp overlay planes as a default and your WM and other simple apps will save system memory and don't interfere with the separate 24bpp planes at all.
'ps', 'top' and most other process listing utilities do not seperate system memory and driver memory use. Many (most) graphics chips are now used with memory mapping. This can result in the X Server memory mapping more memory than exists in the system. I've seen systems where the X Server uses 150% of available memory and apps use the other 80%;-) That's more of a defect in process listing tools than in the X Server or the X Window System.
Accelerated-X should be fine with the i740 in 24bpp color depth, both in the normal AGP and in the StarFighter PCI version. That's not an X failure or a Linux failure...
The problem is probably your X Server, but could be the operating system. One way to find out, is to see if ay one else can correctly perform the operation. If they can, and you can't, the cause is probably that netscape aks sthe X Server to do something and the X Server fails.
There are some things that can be done to deliberately mess up an X Server. IMO, running Netscape is no excuse for an X Server to crash or lock up.
A malicious or poorly written app can cause X Server problems with a very simple cause, memory exhaustion. X permits clients to store data in the X Server. When swap space is exhausted, the X Server dies, or the client does. Accelerated-X has a internal mechanism to send panic log files if the X Server crashes. Although this is usually directed to root@localhost, many customers do as we suggest and change the settings to bugs@xig.com. That way, we can monitor the causes of crashes and see if there is a pattern. The most common in the years that I've watched that list, are memory allocation failures. This is usually caused by someone running happily in 8bpp, increasing to 24bpp when Accelerated-X performance makes it possible, and failing to realise that graphical apps may now use 4X memory. Swap fills and either the app or X crashes when asked to allocate more memory. I'm not aware of any mechanism in X to report "memory limits near", though since X Servers are networkable, it is plausible that a client on a remote machine would be unable to determine free memory on the display system... Cheers, JeremyC.
Slashdot Mirror
BTW, while David intends a friendly tone with the "This'n'that" type abbrevs (ever heard of Toys'R'Us, who even got the R backwards?) most of his typos are intended. He does also reply to email sent to the webmaster and he puts up a prominent mailto: for the webmaster on the front page, just below the spot you discuss. It is not exactly a secret.
I think that coming clean about the quality of the code should be applauded. I've bought hardware products where after three months I'm still using beta drivers. If I'd known, I'd have been unlikely to buy the product at that point. As it is, I'm now unlikely to ever buy anything from that company again, because they weren't upfront about their code quality.
Cheers, JeremyC.
I am an ex-academic. I appreciate that rms' ideas might encourage diversity and novelty in creating algorithmic solutions. However, most of an X Server these days isn't novel solutions that can be patented, but technowledgery. It is knowing which registers to poke on a graphics chip, in which order, at which time intervals, to get a correct and clear image. This is not IP in the traditional sense, and I don't think the propogation of this knowledge would do much for any other field of software development.
X Servers and graphics chips are intrinsically pretty boring. You have to follow someone else's fifteen year old ideas about what graphics should be like and marry it to an insanely complex new chip that was developed a few weeks ago with inadequate documentation.
If the sources for Accelerated-X were made available, it wouldn't significantly add to the IP value of free software. The registers to drive a Matrox chip faster can't be applied to make an ATI or any other graphics chip faster, much less a non-graphics chip. They can, however, be applied to make an XFree86 implementation of an X Server for a Matrox chip yet faster.
All that would be accomplished by making Xi Graphics source code available would be to give a transient speed increase to XFree86 at the expense of the loss of a few dozen jobs. At the end of the process, you'd still have an XFree86 team that generates slower X Servers that fail the X test Suite and that are less robust than Accelerated-X.
What you'd be missing is a source for an X Server implementation that makes some effort to be faster, better and offers timely support.
I do believe that making novel algorithms available can improve other efforts. For example, there is little doubt that public inspection of crypto code is valuable. However, public availability of which register to poke is not, in my mind, of the same order.
It is however, valuable. If your machine crashes because some programmer can't be bothered to correct a bug, you may lose hours of work. If you can't correctly display an image of some project on which you are working, you may cause millions of dollars of lost productivity when a pipe or wire is sent the wrong way because it was drawn incorrectly because a programmer ignored the X specs or thought that their opinion about the significance of meeting the spec was important.
I do believe that open inspection of security code and OS code can improve it. I do not believe, with practical evidence, that open inspection of complex register poking code for graphics, has much to recommend it. I don't think rms' model for software improvement applies usefully to improving register poking on graphics chips.
XFree86 already demonstrates that the principle isn't working. I can crash XFree86 far faster and more easily than I can crash Accelerated-X. I can make XFree86 display incorrectly far more easily than I can make Accelerated-X display incorrectly. These are not the result of algorithmic improvements unique to Accelerated-X. They are the result of significant practical effort to find the best set of registers to poke and of a QA process intended to find errors before a user sees them. IMO, this is entirely not the point of GPL.
AFAIK, the point of GPL was to find a better algorithm, not a better register. The GPL makes no claim about the quality of the code it is to produce; that has been inferred and is the subject of religious adherence to creed rather than repeatable practical measurement. In any case, as I started off pointing out, XFree86 is not GPL'ed... you probably have to apply a different argument for non-GPL bt freely available sources ;-)
FWIW, I can contribute anecdotal evidence about Linux' stability versus Windows. I can contribute practical, measurable, repeatable evidence about XFree86 versus Accelerated-X stability and correctness. Two different types of data. I'd welcome a practical, repeatable and measurable way to demonstrate Linux reliability versus Windows, rather than refutable anecdotal evidence. I'd love to see an independent group test the verifiable behavior of XFree86 and Accelerated-X Servers for stability and correctness.
Cheers, JeremyC.
Of the other two co-founders, one was never involved in any software development at all and is not a programmer.
The technologically significant co-founder was also never a member of XFree86, but he contributed the sources that XFree86 used. Thomas Roell was the developer of X386, the free software X Server before XFree86. He remains the primary developer for the company and has developed most of the ideas that form the basis for XFree86 4.0, several years ago.
We have not hired four XFree86 developers at any time in the company history. AFAIK, we have interviewed several XFree86 developers over the five years we've been running, but we've never hired any. Our X Server/graphics chips hires are usually made from hardware driver developers that we train to understand graphics chips. If anything, we add to the pool of graphics hardware expertise.
Cheers, JeremyC.
There are no databooks available for the 3Dfx 3D hardware; there is a 2D databook, so Xi Graphics has been able to offer support for some 3dfx hardware in 2D/X mode. AFAIK, XFree86 relies on using a binary library provided by 3Dfx (GLIDE), which is not open source/GPL/whatever. The IP remains in the hands of 3Dfx and free software offers an interface to the real binary proprietary driver.
There is no support for the Matrox boards because of missing critical data for the 3D hardware. Some of the 3D hardware is openly documented by Matrox, but certain portions that give useful speed increases are not described. If 3D Accelerated-X claimed support for the Matrox boards using partial documentation, the performance would be lower than should be available, users would be disappointed. This is not a problem for free software developers; they can offer suboptimal software and people are grateful to have their card supported in any way at all. It is probably unacceptable for us to claim support and then deliver a small fraction of the speed that the card should deliver.
Similar properties apply to nVidia. The "free" X Server has been developed by an nVidia employee. Although the source code is available for XFree86, the data book is not available. Consequently if there is a bug or if someone wants to extend or improve the nVidia X Server, e.g. for higher speed or to fix a bug, there is no reasonable way to do so. The availability of source does not mean that you control the software; the IP remains in the hands of those with the databook.
Cheers, JeremyC.
Free software developers and users will find that a G200 with some 3D hardware acceleration is faster than a G200 with no hardware acceleration, but Xi Graphics has always aimed for the maximum hardware acceleration. With missing information, this isn't possible and would make both the G200 and 3D Accelerated-X look relatively pathetic, and probably attract justifiable criticism if we charged full price and delivered a small fraction of the cards possible speed under Windows. That is clearly not a problem for free software.
Cheers, JeremyC.
The X Server is not the operating system kernel. It runs in user space. It needs to be root privilige because it accesses and manipulates low level hardware directly. If you have a piece of software that can change register contents and some of those registers change things like bus handling (e.g. DMA, IRQ) then you can do things to make the machine stop working. Try running your system with interrupts disabled. The kernel may be working, but it is getting nothing useful done. FWIW, a properly X Server can cause the kernel to panic, but only via system calls. The other poster that referred to this wasn't clear, but I think they might have intended that the X Server itself can't generate panics. In 1994/1995 one of the most common kernel halt problems reported with Accelerated-X on Linux and FreeBSD was a defective system call for keyboard handling. This has been corrected in both kernels for about four years. However, when it existed, remapping the casp lock key to be a control key would eventually provoke the kernel crash. So, you are right that the X Server is a user level process. It is, however, unusual in UNIX programs in that from user space, it manipulates low level hardware. That does not make intrinisically less safe than running the same code from the kernel. There are many modes of failure of an X Server. Some of them result in system lockup. Some result in the X Server locking up. Some result in incorrect response to a correct request. Only (extensive) testing finds the problems. Only diciplined programming and a respect for the customers data results in the bugs being fixed. Cheers, JeremyC.
We typically support overlapped older and newer Linux technologies for some time. For example, we supported both a.out and ELF concurently for about 18 months and we've been supporting libc5 and glibc2 for some time.
So, I guess we agree. We offer free bug fixes and new products are new money, just like video playback (tried playing a DVD in that hypothetical VCR, have you ;-) ). New product releases for us, are a consequence of a new feature and inability to offer a compatible update with previous release.
Cheers, JeremyC.
Having source code for the X Server doesn't matter if you don't have the databook for the graphics chip. Without the data book for the graphics chip, you are in pretty much the same state as someone without the source code. There is some small stuff you can do, but considering that the errata for a graphics chip may rival the size of the databook, you are unlikely to ever work out what is wrong and how to fix it.
You make the point for us. Your X Server is crashing, you don't know why and there is, in practical terms, no way for you to fix the XFree86 sources. For a fee, we take responsibility for the X Server.
Cheers, JeremyC.
Do they help? Umm, not really. If you get the code wrong, it goes wrong as easily in the kernel as in user space.
What does help? Testing, testing, testing... Most of the bugs we find aren't caused by X Server design, but by graphics chip changes or misleading statements in databooks and sometimes by human error (typographic errors in coding).
Every Accelerated-X driver module is subjected to many automated tests and several types of human testing. We use things like the freely available X Test Suite and our own tools. We also monitor an automated problem reporting mail address. Accelerated-X has a feature that when it crashes, most of the time it will generate a human readable crash dump and email it. That finds some failures that we miss in the standard testing, or identifies new hardware variants that crash with the normal code.
Cheers, JeremyC.
What you describe sounds exactly like an X Server crash, probably caused by an incorrect configuration or because the hardware is more recent than the X Server support. Cheers, JeremyC.
The 4.61 crash sounds like a netscape bug. The 4.7 crash sounds like an X Server crash. Most X Server crashes are h/w dependent. Usually, a bug that can kill or disrupt one X Server on one h/w platform is completely irrelevant to a different X Server and graphics chip. It may not even affect a different revision of the same graphics board (e.g. different memory type or different graphics chip revision).
Cheers, JeremyC.
Probably the easiest way to gain a similar effect is to use a graphics card that can support hardware overlays. That way you can have both 8bpp applications (using 255 colors) and 24bpp applications. Use the 8bpp overlay planes as a default and your WM and other simple apps will save system memory and don't interfere with the separate 24bpp planes at all.
'ps', 'top' and most other process listing utilities do not seperate system memory and driver memory use. Many (most) graphics chips are now used with memory mapping. This can result in the X Server memory mapping more memory than exists in the system. I've seen systems where the X Server uses 150% of available memory and apps use the other 80% ;-) That's more of a defect in process listing tools than in the X Server or the X Window System.
Accelerated-X should be fine with the i740 in 24bpp color depth, both in the normal AGP and in the StarFighter PCI version. That's not an X failure or a Linux failure...
Cheers, JeremyC.
Cheers, JeremyC.
There are some things that can be done to deliberately mess up an X Server. IMO, running Netscape is no excuse for an X Server to crash or lock up.
> Cheers, JeremyC.
A malicious or poorly written app can cause X Server problems with a very simple cause, memory exhaustion. X permits clients to store data in the X Server. When swap space is exhausted, the X Server dies, or the client does. Accelerated-X has a internal mechanism to send panic log files if the X Server crashes. Although this is usually directed to root@localhost, many customers do as we suggest and change the settings to bugs@xig.com. That way, we can monitor the causes of crashes and see if there is a pattern. The most common in the years that I've watched that list, are memory allocation failures. This is usually caused by someone running happily in 8bpp, increasing to 24bpp when Accelerated-X performance makes it possible, and failing to realise that graphical apps may now use 4X memory. Swap fills and either the app or X crashes when asked to allocate more memory. I'm not aware of any mechanism in X to report "memory limits near", though since X Servers are networkable, it is plausible that a client on a remote machine would be unable to determine free memory on the display system... Cheers, JeremyC.