Announcement

Collapse
No announcement yet.

ATI Radeon Driver Re-Write Still Has Work Left

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ATI Radeon Driver Re-Write Still Has Work Left

    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

  • #2
    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?
    Last edited by smitty3268; 06-12-2009, 10:09 PM.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


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

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by phoronix View Post
                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.

                Comment


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

                  Comment


                  • #10
                    Did you write bug reports, michael?

                    Anyway, thanks for telling us about the progress

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            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
                            Last edited by JeanPaul145; 06-13-2009, 10:02 AM.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X