ATI Radeon Driver Re-Write Still Has Work Left

[phoronix]

Phoronix: ATI Radeon Driver Re-Write Still Has Work Left

To those running ATI Radeon graphics cards on Linux, this week has been very important with several key announcements having been made. The TTM memory manager is getting ready for inclusion into the Linux kernel, which finally will allow the open-source ATI driver (and soon the Nouveau driver too for NVIDIA hardware) to have kernel-based GPU memory management. With the memory management work set in the ATI driver via a mix of TTM and GEM, the ATI kernel mode-setting is also getting ready to be released as a staging driver within the Linux 2.6.31 kernel. The announcements this week have not been only about the GPU and Linux kernel, but the Radeon driver rewrite has also been merged to master. As we discussed in yesterday's news post, this Radeon Mesa re-write brings several key improvements immediately and there are still more features to come.

http://www.phoronix.com/vr.php?view=13956

[smitty3268]

Was it completely broken using TTM? Just wondering why you didn't try that.

Also, I thought FBO and pretty much everything new that was in this code was only enabled if you were using the new memory manager. Are you sure it was enabled for these tests?

Of course, the larger point you made here that the driver still has a long way to go is absolutely correct. It's exciting to finally see some progress, though. Hopefully 3D r6xx/r7xx won't be far behind.


*EDIT*
Yep, this link seems to confirm it - you're not enabling FBO for these tests. http://airlied.livejournal.com/66706.html
It also seems like they weren't aware of these serious regressions - maybe a non-mobility card would fare better?

[bulletxt]

Urban Terror and all the other games will run as they should with Ubuntu 11.04 . I just bet 20$ with my friend. I'm talking about r500 and above.

[Remco]

I think benchmarks are a little too early. There may be some use to knowing that the driver does't perform any better yet, but since the driver isn't even fully functional, that should come as no surprise.

Though it's nice to know that it doesn't perform worse either.

[benmoran]

It's exciting watching these things evolve. Looking forward to testing them out.

[mattst88]

This testing was done without the TTM memory management

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.

[damentz]

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.

[airlied]

Phoronix: ATI Radeon Driver Re-Write Still Has Work Left

To those running ATI Radeon graphics cards on Linux, this week has been very important with several key announcements having been made. The TTM memory manager is getting ready for inclusion into the Linux kernel, which finally will allow the open-source ATI driver (and soon the Nouveau driver too for NVIDIA hardware) to have kernel-based GPU memory management. With the memory management work set in the ATI driver via a mix of TTM and GEM, the ATI kernel mode-setting is also getting ready to be released as a staging driver within the Linux 2.6.31 kernel. The announcements this week have not been only about the GPU and Linux kernel, but the Radeon driver rewrite has also been merged to master. As we discussed in yesterday's news post, this Radeon Mesa re-write brings several key improvements immediately and there are still more features to come.

http://www.phoronix.com/vr.php?view=13956

What kernel did you use for the tests?

Dave.
Dave.

[d2kx]

It could be fun when Ubuntu 9.10 is shipping Linux 2.6.31 without TTM enabled but with Mesa 7.6 maybe.

[bugmenot]

Did you write bug reports, michael?

Anyway, thanks for telling us about the progress :)

[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 ! :cool:

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

[bridgman]

Yep... the thing to remember is that the goal of radeon-rewrite is to be able to use a single code base for both TTM and non-TTM systems, since both of them will need to be fully supported over the next year or two. On a non-TTM system, radeon-rewrite is supposed to be "no worse, and easier to maintain in the future", while on a TTM system it should provide a good base for adding new features (eg the VBO and OQ work already in progress).

Between non-TTM and TTM, testing on non-TTM systems is definitely the most time-critical since all future Mesa releases will be using this code base and any problems translate directly into regressions for current users.

Michael's testing confirmed that there is more work to do before the next Mesa release. This was understood by the devs before the merge, but the consensus was that it made more sense to merge now and get more people testing the code than to try and "make the code perfect in a branch" and drop it into master at the last minute.

[Pitabred]

So, say I have an Ubuntu 9.10 Karmic alpha install (kept updated), a Radeon 4670 (on an RS690/X1250 board, so I could test that, too)... would that be a non-TTM system? Would I be able to help with the testing?

[TechMage89]

Ubuntu 9.10 is a non-TTM system. TTM is in the process of being merged into the 2.6.31 kernel, but that hasn't gone through yet and Ubuntu 9.10 uses the 2.6.30 kernel.

Still, it might be useful to try it out and see if there are regressions or if there are any improvements. It might help the devs find problems with non-TTM systems.

[bridgman]

Note that neither radeon-rewrite nor mesa master include support for 6xx-7xx GPUs (6xx-7xx is in the 6xx-rewrite branch) so for now you'll need to test with a display connected to the RS690.

[tormod]

So, say I have an Ubuntu 9.10 Karmic alpha install (kept updated), a Radeon 4670 (on an RS690/X1250 board, so I could test that, too)... would that be a non-TTM system? Would I be able to help with the testing?
Yes, Karmic is (still) a non-TTM system. But please see http://phoronix.com/forums/showthread.php?t=17615 about testing out TTM/KMS on it :)

Ubuntu 9.10 will probably have 2.6.31, and it is not certain that 2.6.31 will have the radeon KMS. However, it is possible that Ubuntu 9.10 will patch the kernel for it if the bits get stable enough in time.

[benow]

Well, I thought enough time had passed and chose an asus mobo with ati 3300 HD onboard (1080p capable said the box). It sucks. Admittedly, it does work, but not well enough for 1080p. So after a couple reconfiguration attempts, I sent a nastly letter to AMD and bought a passive nvidia 9600GT. glxgears showed ~1200fps for the ATI (using their fglrx drivers) and ~12000+fps for an nvidia 6800 GTS (also w. proprietary drivers). Good luck ATI, perhaps I'll revisit their stuff in another couple years.

[NSLW]

I sent a nastly letter to AMD
They've got you, you know where :eek:

But to be serious, I think that someone should add big warning banner like big warning sign on Phoronix home site, which would advertise user not to buy ATI shitty products.

[Vash63]

Yes, Karmic is (still) a non-TTM system. But please see http://phoronix.com/forums/showthread.php?t=17615 about testing out TTM/KMS on it :)

Ubuntu 9.10 will probably have 2.6.31, and it is not certain that 2.6.31 will have the radeon KMS. However, it is possible that Ubuntu 9.10 will patch the kernel for it if the bits get stable enough in time.

Pretty sure 2.6.31 is confirmed to have Radeon KMS in the Staging section. I highly, highly doubt that Ubuntu includes modules or has built in support for stuff in the Staging section though, so you'd probably have to compile the kernel yourself on Ubuntu.