Announcement

Collapse
No announcement yet.

Why The R9 290 & Other Select Radeon GPUs Are Performing Miserably On Linux 4.7

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

  • Why The R9 290 & Other Select Radeon GPUs Are Performing Miserably On Linux 4.7

    Phoronix: Why The R9 290 & Other Select Radeon GPUs Are Performing Miserably On Linux 4.7

    With this weekend's 5-Way Mesa 12.1-dev + Linux 4.7 Git Radeon Comparison and other tests I've done on Linux 4.7 Git with Radeon hardware, the R9 290 has regressed to the point of performing noticeably worse than other AMD GCN GPUs... Many other Phoronix readers with different Rx 200/300 graphics cards have also confirmed their graphics cards performing poorly on Linux 4.7...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It seems to be an Ubuntu specific error, because I didn't get any noticeable performance regressions when i switched to 4.7RC3 on my Arch Install. The only regressions I got were when I used the development Mesa builds (12.1), and even those were slight at worst (around 80% of the normal performance). I will try again and see if I get that DPM error.
    UPDATE: Here is what I got: https://www.dropbox.com/s/l2kr1p4m4t....7RC3.jpg?dl=0
    No DPM issues here, performance also stayed the same. I got my kernel from the ArchLinuxCN repo, if that means anything.
    UPDATE2: Which exact model/BIOS of R9 290 do you have, Michael? Can the card BIOS make a difference?
    Last edited by SirCoolCat; 20 June 2016, 10:16 AM.

    Comment


    • #3
      I thought PTX could bisect and find the issue automatically, why haven't you done that yet?

      Comment


      • #4
        Originally posted by Qaridarium

        maybe he needs money?
        He needs beeeeeer, more beeeeeeer.

        Comment


        • #5
          Everybody likes more to bisect beers then code in these hottie days

          Comment


          • #6
            Originally posted by Qaridarium

            maybe he needs money?
            Time = money. Building both mesa and the kernel takes a lot of time. Building them more than once takes even more time. That time can go for productive work, while people who actually work on the kernel probably know about the issue already and have some fix in their minds.

            Comment


            • #7
              Bisecting between the kernel 4.6-rc5 to 4.7-rc3 took me a big 13 recompilations + reboots (less than two hours).

              Comment


              • #8
                Lots of PM changes i linux 4.7-and lots of bugs. With both AMD Phenom II and AMD FX bulldozer, the cpufreq governors are there but some change hides them from cpu scaling applets. The MATE app won't see anything but "performance" even after code changes to build with Linux 4.7. The Ubuntu indicator-cpufreq will see the userspace governor and on Phenom see the "ondemand" governor. Acts like kernel modules not loading:modprobe (desired governor) and it will be visible to both the MATE and Ubuntu indicator cpufreq applets. I ended up using a script triggered by systemd to load the governors, then select "ondemand." It works, but I do hope this is but the teething pains of new governors.

                Between using linux 4.7 with the governors loaded and the recent r600g mesa changes though I've gotten a big performance boost: The old 2d "criticalmass" or "critter" game will show high speed rendering (but not displaying) hundreds of fps, and speed up further with the CPU locked on high. Now the CPU governor has much less effect on that somewhat synthetic benchmark, and the framerate now exceeds that of Catalyist back in 2012 with no render errors. A month ago that game topped out at 680fps theoretical, now over 1,000 same as Catalyst back in 2012. That game used to drop strings of frames to the point of running rough unless framerates exceeded 300fps, no sign of that bug in over a year except on a netbook.

                Performance in Scorched3d a little harder to compare to 2012 Catalyst results as the game has changed a bit, but getting about the same framerates I got in those 2012 tests with everything maxed out (about 72fps max on Radeon HD 6750/1080p monitor). Game maps are sometimes heavier now, but maps that were used then and are still used not (the smaller ones) should be comparable. For reference, my first experiments with the open drivers on Scorched3d in summer 2012 with default video settings netted less than 20fps.

                I don't expect much improvement in 0ad, but that is a totally CPU bound game as it is an RTS game with one main thread and sometimes some half load secondaries. Haven't tested it with the new kernel and Mesa yet however.

                Comment


                • #9
                  With 4.7rc4 performance of R9 380 is still bad... I don't see any problems with DPM via dmesg, just one (probably minor) error:
                  amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
                  however I see above error since few kernel releases.

                  Comment


                  • #10
                    Originally posted by nadro View Post
                    With 4.7rc4 performance of R9 380 is still bad... I don't see any problems with DPM via dmesg, just one (probably minor) error:

                    however I see above error since few kernel releases.
                    I get the same on my R9 280X with Mesa 11.2.2 on 4.6:

                    Code:
                    [    1.818856] radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff

                    Comment

                    Working...
                    X