Well this thread was certainly a surprise, so I clicked on it. Anyhow, a few things:
- Personally, I don't buy the argument which peeps are stating that nVidia had said, that GPLing the drivers would make the systems (read as people's computers) less secure. The graphics card driver should have nothing to do with that, and given an open source operating system...I think someone fudging up on the recompilation of IP chains or something of the sort could be a more effective way to compromise system security
Same goes for packages such as open SSL, etc...
That nVidia doesn't want people to see where they have "driver specific optomizations", or what others would call cheats where it, for instance, looks for 3D Mark and then runs sub-optimal IQ to get more points sounds a lot more on the money IMO... I'm sure instances of this (both in ATI's as well as nVidia's drivers) which have become public knowledge are probably just the tip of the ice burg...
- Ultimately, from the users perspective, as opposed to the marketers perspective...if the driver source being open source resulted in more intense competition between ATI and nVidia to further optomize their drivers, knowing full well something they add today could be added by a competitor tomarrow; we the users would win. And a "this will only help X synthetic benchmark 'trick'" wouldn't cut it as people would more readily know. Again, good for the user who wants to know what real gaming performance they'll see when going to the store and considering which card; not how something can be optimized soley for a benchmark alone. Hardware improvements, and driver coding improvements that effect all apps would really be the only way to do it.
- As to competitors, it might not be an above board and widely talked about matter, but many times the competitor has a better idea of what a company is doing then the public. Sometimes, (if a competitor is reverse engineering a product), they might know something the manufacturer hadn't figured out yet, such as occured with the F00F bug in the original Pentium processor.
Within a day or so, I called another colleague who used to work at one of Intel's competitors. I told him about the bug. To which he responded: "yeah, I found that bug about a year and a half ago." If this bug was so easy for one or more of Intel's competitors to find, why hadn't they ever discovered it, disclosed it, or quietly fixed it? The answers lie in the nature of Intel's competition, and Intel's design verification methodology.
It is quite natural for Intel's competition to find bugs like this. They are in the microprocessor cloning business. Therefore, they must write programs that scan the entire opcode space in search of hidden and undocumented instructions. Invalid opcodes come in many forms. The most obvious form is an undefined instruction -- an opcode that doesn't map to any instruction. These opcodes are easy to scan programmatically. Other invalid opcodes are actually invalid encodings of valid instructions. These invalid encodings are often times overlooked when scanning for undefined instructions.
Intel's competition must find these instructions. Therefore they write programs that scan the entire invalid opcode space. A well-designed program will test all of the invalid opcodes and invalid encodings of valid opcodes. This is how my colleague found this bug 18 months ago. Even though he knew about the bug, his knowledge was the intellectual property of his company. Therefore he would have been prohibited from warning the Internet community, even if he wanted to warn them.
Reverse engineering, along with de-compiling a program is one of those "dirty little things" that many know about, though fewer will mention. It isn't something that isn't done, however... In some of the computer programming classes I have taken at uni, when the subject had come up for instance, the topic came down to a "yeah, I know what that is, though the university forbids us from discussing it...", a quick mention and attempt to get off the topic prompto...
I doubt that AMD would say that they've reverse engineered Intel's processors in an attempt to make sure their processor remains compatible with changes Intel's made to x86; but logic would dictate that if they aren't going to trust Intel to document everything for them, they will. That CPUid found the 96-bit unique identifier in my Athlon Tbird 1 GHz after Intel introduced this (and soon after removed it), I found sorta odd. Always figured AMD copied the circuitry over to the Thunderbirds, and latter when Intel removed it... AMD never officially announced adding this to their CPUs.
- How many games have been cross compiled to Linux isn't the entire answer. Someone who wants to game on Linux, would sort of need something like transgaming (kedega, or winex), or some other such addition to continue playing Windows games.
Even with Wine or transgaming however, one would still need drivers to the graphics card with hardware accelerated OGL support, for the D3D API calls to be mapped out to OGL calls for the game to play...
- Disbanding Linux driver support altogether would seem a little like throwing the baby out with the bathwater here. Perhaps a mention of what problems are being run into could result in someone who had a similar problem having a fix in mind.