The Cost Of ATI Kernel Mode-Setting On Fedora 12

[drag]

What is the actual *reason* that it is slower?

Will color tiling be enabled with an update?

Thanks devs, you are doing an awesome job by the way.

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.

[AdamW]

"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.

[remm]

one more for phoronix - blindfrog is correct to note that this is being worked on even now. You may want to try with this Koji build of the ATI driver:

http://koji.fedoraproject.org/koji/b...buildID=142974

this build of Mesa:

http://koji.fedoraproject.org/koji/b...buildID=142633

this libdrm:

http://koji.fedoraproject.org/koji/b...buildID=142111

and this kernel:

http://koji.fedoraproject.org/koji/b...buildID=142993

and see how that combination performs.

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.

[oibaf]

This isn't news. I have filled bugs against this issue (https://bugzilla.redhat.com/show_bug.cgi?id=533244

You may want to take a look here: http://bugs.freedesktop.org/show_bug.cgi?id=22743
This was a darkplaces bug, not a driver bug.

[AdamW]

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.

None of those packages are 'updates', yet. The developers are still working on them and haven't decided to submit them as official updates.

[legume]

These issues are known to the devs?

The XV high Cpu issue is known to the devs, so will hopefully get better with time.

[AdamW]

There's a blog post by Dave Airlie about this stuff here:

http://airlied.livejournal.com/69074.html

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).

[remm]

None of those packages are 'updates', yet. The developers are still working on them and haven't decided to submit them as official updates.

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.

[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.

[bridgman]

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.