Comment 76 for bug 313027

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.