On Thu, Mar 19, 2009 at 09:57:51PM -0000, Sam Liddicott wrote: > hardhu wrote: > > Bryce Harrington wrote 23 minutes ago: (permalink) > >>> Why isn't there the possibility in Ubuntu to choose older versions of > >>> xorg and fglrx with a new release? > >> ROTFL. > > In this is Ubuntu developers attitude, I understand why bug #1 is still > > open.. > > guys.... intrepid still works... > > and remember it's closed-source-ati that isn't supported - and lets > think how long ago it was since ati got any money for that card - how > long should they support it? I think they've given value for money. > > However, the open source drivers _are_ being worked on for your card, > and this is how bug #1 is being fixed. Thanks, that's a better answer than mine. It's been a busy week for me as you can imagine. The fact is, with -fglrx being a binary proprietary driver, we're limited in what we can do. There are of course some legal limitations due to the licensing, but also some real technical limitations. Let me explain just one. All software communicates via standardized protocols and interfaces. Video drivers also have specific interfaces they use to talk to the X server, its libraries, and the underlying Linux kernel. Over time these interfaces evolve. We can broadly divide these evolutions into two classes: code (API) incompatibility, and binary (ABI) incompatibility. Code incompatibility means that ALL of the drivers must be recoded to be usable with the new X server. It can be caused, for example, if a function that used to take one argument, now takes too. E.g., foo(bar) changes to foo(bar, baz). This affects even open source drivers! The good news with open source is that generally whomever introduces the breakage, at least then goes through all of the video drivers hosted at freedesktop.org and fixes them. As you can imagine, the X developers strive to avoid these kinds of breakages, since they're a lot of work. Proprietary drivers are not hosted at freedesktop.org, obviously, so don't get this help. Further, the vendors need to keep their ears open even to hear about the changes, and then must research into what the change was, and allocate the engineering resources to address it. Binary incompatible changes are simpler, at least for open source drivers. These come about when some data structure gets a new field added, for example. They don't break source code, it just requires a recompilation of the code. As such, upstream doesn't worry too much about introducing such changes as they need them, and thus typically every new xserver release will contain a few of these kinds of changes. With open source drivers, this ain't a big deal - here at the distro level we can just queue up rebuilds of all affected drivers... EXCEPT for binary drivers. With binary drivers, we don't have the source code, so we can't recompile them ourselves to address the ABI changes. Instead, we must wait for the upstream vendors to provide us with re-builds of their drivers. This is why when a new Ubuntu gets its new xserver (and/or new kernel), the binary drivers stop working, and you have to switch to the open drivers (which get rebuilt at the point we put in the new xserver). This is why you can get weird errors when you use an old -fglrx with a newer xserver. This is why you can (sometimes) use the '-ignoreABI' option to xserver to force it to load a driver with an ABI mismatch. Now to return to the original question - if the old -fglrx is having an ABI (or even API) mismatch with the newer xserver, why not provide the old xserver as well? After all, this is routinely done in other areas where we have an API change, such as programming languages. This would involve maintaining two complete parallel X.org trees, including all drivers, libraries, server, and so on. We'd need to develop and debug a mechanism that allows you to transparently uninstall one complete X stack, install the other, transition your config settings, and so on. It would double our bug fixing load (since we need to provide fixes to two complete sets of code). We'd have double the load for fixing security issues. We'd probably have a whole heap of user confusion since they are faced with a choice of two X stacks, and would need to figure out why they should care about one over the other. So thus my chuckle. Not because it's impossible - actually it would work, that's what makes it funny - just that it would be a gargantuan amount of effort and pain, and all that just to work around an ABI problem that could be solved trivially if we just had access to the source code, and that's the irony. A much better question would be, "How do we get out of this situation so we all don't get hit by this again in the future?" From all the above you can probably see, the best answer is an open source driver. Not an open sourced version of -fglrx, but rather an improved -ati that supports the same range of hardware and has equally good performance and stability. The way we solve bug #1 is not to waste huge amounts of time shimming up proprietary code, but instead by investing all that effort into bringing the open source side of things to equal quality. And in fact, that's exactly what I (and various community members) have been hard at work on. * We've been hard at work triaging and fixing bugs in -ati: http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-ati/plots/xserver-xorg-video-ati-fullyear-open.png * After a lot of testing, we've switched -ati to EXA acceleration, which eliminates a number of bugs and provides better performance: https://blueprints.launchpad.net/ubuntu/+spec/radeon-change-xaa-to-exa * Working with upstream directly, we've added the 6xx/7xx EXA/Xv support in -ati into the kernel, even though it came pretty late in Ubuntu's cycle: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/334101 Regarding performance, also keep an eye on phoronix.com - they do comparisons of -ati and -fglrx periodically, and it is interesting to see the steady gains -ati makes. Indeed, for 2D performance -ati often wins out across the board. 3D is still -fglrx's forte but the gap has narrowed a lot, and the race has gotten quite competitive. Much of the praise for -ati's rapid improvement needs to go to AMD, because a lot of these improvements were made possible directly from their decision to provide hardware documentation publically, as well as the open source engineering efforts they've been funding. I can't speak to AMD's strategies obviously, but their actions have been completely consistent with the goal of achieving a high quality, high performance open source driver for their hardware. So what I'd ask of users who have been using -fglrx before, please give -ati a fair shake. Yes, it may have some bugs, and especially for games it may not be up to snuff yet, but a LOT of development effort is being focused into it. With all of us working together, there's no reason -ati can't be every bit as good as -fglrx (and better!) You can help the efforts quite directly yourself, by testing -ati heavily (e.g. by playing games on it!) on a variety of hardware, writing up good detailed bug reports, promoting it, helping us triage and upstream bugs, and (if you're technically inclined) sending in patches.