Quote Originally Posted by duby229 View Post
You write good code. There is no doubt about that... But the usefullness of some of your past projects is questionable. Why waste time writing good code that few or no people use? Your experience and skill is obvious.... But you use it on projects that don't matter.... When you bagan modularizing mesa it was excellent code but it had no chance of ever being adopted. When you implemented radeonhd and insisted on banging the modesetting hardware directly, you should have just used atombios from the beginning.
There are many reasons why AtomBIOS was not used.
* We only got documentation for it in late 2008, the amount of bringup work needed with or without AtomBIOS would've been the same, as we would have to find out how things fit together anyway.
* it's a bios, with all bugs and bad interfaces included.
* ATI still does not allow AtomBIOS to be flashed or fixed by users, 5 years on. The nouveau guys are providing their own FuC, but ATI has successfully managed to keep the AMD open source users dumb (this was ATIs game all along: silence the big ATI hatred, but keep fglrx for all serious users).
* AtomBIOS is then just another layer in between, another layer forcing us to be bug compatible with the Windows driver.
* AtomBIOS was promised to be ASIC specific, not board specific. This of course got thrown out of the window by the shortsighted ATI AtomBIOS/Windows driver developers for R600 already.
* AtomBIOS hides bad hw design. Like shifting half a register bank up 1 register from one generation to the other...
* AtomBIOS was promised to be a stable, but powerful, modesetting interface. It ended up seeing rather a lot of changes with every generation, and these changes could've just as easily been handled in proper C code, without any of the other issues.
* Bugs in the modesetting implementation could get fixed on all affected generations when found, not just only on the newest devices with the newest AtomBIOS versions (display unsync was broken from r500 until rv630 for instance).
* Shortsightedness in the AtomBIOS specification caused a massive standard breakage. Namely, the DDWG DVI standard has a hard requirement for a hotplug pin, but this was overlooked for R500 AtomBIOS, even though the hardware had it. This in turn meant that hotplug was never properly tested by ATI or board makers for all R500 generations. We worked around that, by guessing the pin order (which got us 90% correct usage), board quirk data (which got us to 98% correct usage and some boards with hotplug disabled), and this information was gathered easily by our vast user base in september through november 2007.
* AtomBIOS hid only the easy bits of modesetting. The tough bits we had to do ourselves, and ATI never provided us with relevant information there. Things like figuring out how everything fit together (for which ATI never provided information), getting stable dotclocks (which the radeon driver still hasn't managed today -- as they shortsightedly deleted the magic few lines to do so -- a magic few lines which represent several weeks of libv busywork), etc.
* AtomBIOS is a slightly higher level interface, one that changes with every generation too, and it gets in the way of new modesetting infrastructure that might in future come up. It makes it needlessly harder to abstract the hardware in a way that best matches the infrastructure.
* AtomBIOS is the bottom end of a "one source tree per ASIC version, freshly copied every time" graphics driver development mindset. Quite perpendicular to open source driver development.

And all of this on top of more obvious open source advantages, which i am not going to list again for the sake of... well. Brevity.

Did you really think that i did not think this one through? Did you really think that we made that decision purely on free-software-zealotry? Or could it be that we spent a lot of time discussing this, and gathering the pros and cons, and instead of going for the politically more acceptable solution (for ATI, but ATI always searched for new sticks to bash us with), went for the technically superior and long term maintainable option.

ATI got forced by AMD to accept the SuSE proposal. ATI got forced to hand us documentation. We got the 2 500page raw register descriptions out of ATI, and some bad bad AtomBIOS parser code. That was it. We had to write a disassembler for AtomBIOS to find out how things fit together anyway, and i know for a fact that writing C code for the basic modesetting was the same amount of work as using the AtomBIOS interfaces directly. My personal belief is that we were even faster because of that. Not using AtomBIOS allowed us to beat the political deadline that was secretly set on us delivering. Not using AtomBIOS meant that we shipped a driver, and that ATI could not stop us, and that we got a free driver, at all.

Heck. Hours before the first code release, ATI refused to give us clearance on the atombios parser. A last ditch attempt to stop us from shipping this driver. Our answer: "fine, then we ship without the atombios parser, we do not need it for 98% of the use cases". Minutes before we intended to push out the code, ATI then allowed us to change the license on the atombios parser.

Need any more, or have you had enough already?