Originally Posted by bugmenot
A similar thing happened with the Intel drivers transition away from multiple independent drivers to a unified memory management model.
It came in stages, one after a while, and performance and stability suffered. KMS, GEM, UXA, etc etc. One feature after another.
Then you ended up with the low-point of reliability and performance when you had the Xorg driver that supported all the different combination of legacy and next-gen features. You could choose to go with the older stuff and get better performance in the benchmarks, or go with the newer stuff and get better usability with composited desktops.
Now, finally, with Fedora 12 the Intel drivers dropped the support for the legacy stuff and now rely entirely on KMS, UXA, and GEM all being functional. Now you have Phoronix articles praising the performance of F12 isntead of trying to account for the loss of performance in different Ubuntu versions.
Hopefully with the Radeon stuff they will take a more aggressive approach and thus shorten the time that users must suffer through the transition period, but I don't know how practical that will be considering the restricted resources in terms of time and manpower that goes on with typical X development stuff. The faster they can move to the unified memory management and get away from relying on the DDX for everything the faster they can concentrate on improving performance and application/game compatibility and introducing Gallium features.
And, yes, cheers to the developers. Everybody needs this stuff to work and I know it is hard work. Thank you.
"Now, finally, with Fedora 12 the Intel drivers dropped the support for the legacy stuff and now rely entirely on KMS, UXA, and GEM all being functional."
This isn't actually true. You can still use UMS (kernel parameter 'nomodeset') and EXA or XAA (AccelMethod in xorg.conf) on F12, if you really want to. You won't get a lot of interest from the developers if they turn out to be broken, but the codepaths are still there and mostly working.
There are a lot of things that are right with Fedora, but handling updates is not one of them. Sometimes an update gets stuck in testing limbo for ages (and nobody tests them either), despite the corresponding "stable" packages being pretty much broken.
Originally Posted by AdamW
You may want to take a look here: http://bugs.freedesktop.org/show_bug.cgi?id=22743
Originally Posted by ufaogros
This was a darkplaces bug, not a driver bug.
None of those packages are 'updates', yet. The developers are still working on them and haven't decided to submit them as official updates.
Originally Posted by remm
The XV high Cpu issue is known to the devs, so will hopefully get better with time.
Originally Posted by hobbes
There's a blog post by Dave Airlie about this stuff here:
it notes that some of the performance 'regression' is due to the new driver doing vsync, which we wouldn't want to disable (as you get tearing without it).
What actually happens is that, even in cases where current packages are demonstrably broken (as in, the user's installation no longer boots), propagating an update often takes days and days.
Originally Posted by AdamW
Indeed. This is because it's not as simple as slapping together a fix and stuffing it out, as that's what causes regressions.
It's funny, most people complain about Fedora updating too much, not too little.
I guess the specific complaint here is "updating too much in the initial release and *then* updating too little"
The tricky part is that post-release changes may be a big help for one group of users but a big problem for others, and figuring out which potential improvements should be released as updates can require as much or more testing than the original release.
In that case I guess there's a good argument for making most of the potential updates available only for cherry-picking by the user rather than something more-or-less automatic.
Last edited by bridgman; 11-27-2009 at 01:14 PM.