ATI Radeon Driver Re-Write Still Has Work Left

[MùPùF]

I noticed a performance drop from ~5 to ~10fps with tremulous with the merge in the master branch on my xpress 200m card.
I used to be between 25 and 40fps, now, I'm between 17 and 35fps.

Hope to get the performance back when using TTM/KMS and DRI2.

[JeanPaul145]

As much as I'm hoping that TTM/GEM and KMS are nearly bug-free (since this means that they can get to the R600/R700 code sooner - and I'm in desperate need of it since I've been "reduced" to using the radeon driver for my HD4870), I'm thinking this is not quite the case. In fact, I'll be pleasantly surprised if by the time Fedora 12 and Ubuntu 9.10 come out, we have a fully functioning R600/R700 driver (never mind the speed of the thing, I'm just talking feature parity to the R500 cards).

off-topic, but still relevant (and no, it's not intended as a flame, I would like a serious answer to this, from someone working at AMD if possible):
Seriously, what the hell is happening at AMD over there? They rip out support for older cards, so I think "finally, my HD4870 will work smoothly on my ubuntu 9.04 system". Apparently not: the 9.5 fglrx driver is so riddled with performance regressions when bundled with X.org latest-and-greatest, that now I'm stuck using the radeon driver, which, as is common knowledge, doesn't support any accelerated 3D operations at all. 2D and Xv work fine, though, quite possibly even better than fglrx -_-".

I am actually growing jealous of those people having smooth experiences on their nvidia cards, which is incredibly ironic: I *used* to own an nvidia-based laptop, sold that one, in the time they were getting severe performance regressions, and bought myself a nice high-end system with an HD4870 in it.

[bridgman]

Hi JeanPaul145;

>>Apparently not: the 9.5 fglrx driver is so riddled with performance regressions when bundled with X.org latest-and-greatest

Is the performance regression with the driver (9.5 relative to 9.4/9.3, Xorg unchanged), or Xorg (between new and older versions of Xorg, driver unchanged) ? There was an Xorg patch removed in 1.6 (which had been in earlier versions of Xorg) which AFAIK introduced a performance slowdown for users running with Compiz. Since the open source driver doesn't support Compiz you wouldn't see the performance issue there -- but you should be able to get the same performance gain by disabling compositing when running fglrx.

[JeanPaul145]

Hi JeanPaul145;

>>Apparently not: the 9.5 fglrx driver is so riddled with performance regressions when bundled with X.org latest-and-greatest

Is the performance regression with the driver (9.5 relative to 9.4/9.3, Xorg unchanged), or Xorg (between new and older versions of Xorg, driver unchanged) ? There was an Xorg patch removed in 1.6 (which had been in earlier versions of Xorg) which AFAIK introduced a performance slowdown for users running with Compiz. Since the open source driver doesn't support Compiz you wouldn't see the performance issue there -- but you should be able to get the same performance gain by disabling compositing when running fglrx.

Hi Bridgman, thanks for the quick reply.
I can't rightly tell, since I upgraded them at the same time: until about a week ago I used to run Ubuntu 8.10 with fglrx 9.4. Then I cleanly installed (as opposed to upgrade with synaptic) Ubuntu 9.04 and installed fglrx 9.5. Seemed to work ok for a few secs, until I tried to minimize a window. A delay of more than a second for something much-used and basic as that is completely unacceptable to me.
However, if it wasn't fglrx, I apologize to that driver and its developers.

It raises the question though: Why would they remove a patch that actually degrades user experience? was it because it was rotting-in-the-fridge-for-half-a-year code? And even if it was, it seems there's a lot more of that in the x.org repositories...

Next to all of the above, my main reason for running fglrx right now is because I'm somewhat of an eye-candy junkie (let's face it, gaming on Linux is a nice ideology, but it's just not happening atm). If I turn off compositing, my reason to use fglrx vanishes with it.
Of course, right now I'm running radeon, which isn't an ideal situation for a lot of reasons - not the least of which being I'm not sure any sort of power management is used for R600/R700 chips (with a TDP of 150W a radeon HD4870 is quite a power-hungry beast).

EDIT: sorry for the novelization :P

[bridgman]

As I understand it, the patch was removed because on certain GPUs (not ours AFAIK) it resulted in on-screen corruption which sometimes brought back older screen info. This was treated as a security issue and so the patch was pulled. Something like that anyways, I haven't found a clear discussion in one place so you have to piece things together from multiple threads.

The consequence of backing out the patch seems to be large downloads from graphics memory to system memory, which is where the time is going. I believe our devs are looking into it to see if there is some way to accelerate those transfers, but that's all I know right now.

Alex added some power savings features to the radeon driver a month or so ago. I think you want "ForceLowPowerMode" but check the radeon man page to be sure.

[Melcar]

As I understand it, the patch was removed because on certain GPUs (not ours AFAIK) it resulted in on-screen corruption which sometimes brought back older screen info. This was treated as a security issue and so the patch was pulled. ...

It's funny that this is exactly what happens now with fglrx . Oh well, this sort of stuff always happens; fix something to break something else. Just hope it eventually gets resolved.

[bridgman]

Yeah, some days you're the hydrant

It happens; the problem that it fixed on other GPUs was felt to be more severe than the problem it introduced on our GPUs, so...

[kernelOfTruth]

Alex added some power savings features to the radeon driver a month or so ago. I think you want "ForceLowPowerMode" but check the radeon man page to be sure.

I'm not having a sensor directly on my 4850 but I believe those poewr-saving features do a good job already

currently I'm using

        Option     "ForceLowPowerMode"  "True"
        Option     "DynamicPM"          "True"
        Option     "ClockGating"        "True"

great job guys !

[DeepDayze]

My thinkpad T42 has this card:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]

Would this benefit from the radeon rewrite?

EDIT: Would the new TTM and/or mesa be of benefit for this one?

[tormod]

Why? TTM (and before that, KMS) are requirements for getting any improvements out of this new code.

Surely since you run this site you're aware of that -- so why did you not use TTM? If that's for another article, why not state it? It makes this article look half-baked.

Mesa 7.6 benchmarks are meaningless without TTM. Not to mention, there should be more bugs without it since that's what all the new code is for.

I'm appalled that these tests were even done. It's like taste testing two different bags of tea, seeped into iced water.

It makes perfectly sense to test the new mesa even with a current (non-TTM) kernel. The radeon-rewrite had several goals, other than making a radeon mesa capable of using TTM, the code was also reworked to be better shared among all radeon cards, and for both DRI and DRI2. This meant rewriting also the old non-TTM path (DRI1 and not DRI2).

The new code is meant to work as well as the old code did, and has now replaced the old code in mesa. It will be used by normal users as soon as mesa 7.6 is released, and until the default kernel uses TTM (2.6.31 or later) it will be the default mesa stack. So finding regressions in the rewritten DRI1 code is definitely important, and it is good that Phoronix looks into this. Many developers are focusing on the DRI2 path and are not giving so much attention to the old path since it "soon" will not be of use any longer. The radeon-rewrite got merged even with many known regressions (search for radeon-rewrite on bugs.freedesktop.org), but hopefully they will be fixed quickly now that this is in the main (master) branch.