Announcement

Collapse
No announcement yet.

AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go

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

  • AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go

    Phoronix: AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go

    With the Linux 3.17 kernel, Mesa 10.3, and the newest Radeon microcode files, there's finally working Hawaii GPU support by AMD's open-source Linux graphics driver. The Radeon R9 290 series launched nearly one year ago and finally now the open-source driver is working right, so we've conducted some preliminary tests using the R9 290 compared to AMD's other Radeon GPUs on the open-source Linux driver.

    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
    Where do you get the newest Radeon microcode files? I'd like to try my 290X!

    Comment


    • #3
      It looks like DPM broke at some point and the card was underclocked for the rest of the tests.

      Comment


      • #4
        Now that was one of those benchmarks where I'm like: "Wow, that's impressive."

        Then you get some of the worst performance readings and I'm like: "Wow, that's impressive."

        Comment


        • #5
          more click-bait...
          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

          because reporting bugs is too hard

          Comment


          • #6
            Originally posted by asdfblah View Post
            more click-bait...
            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

            because reporting bugs is too hard
            I've already explained many times in the past why I generally don't (primarily swapping out hardware/software components too often to be able to follow-up on bug reports but also no time to do so, working on many different tests at once, etc).
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by Michael View Post
              I've already explained many times in the past why I generally don't (primarily swapping out hardware/software components too often to be able to follow-up on bug reports but also no time to do so, working on many different tests at once, etc).
              No idea if the test suit can do/does it already but wouldnt it be possible to have the output of journalctl -f (or other logs) published so someone can take a look at that in case something is wrong during the test?

              Comment


              • #8
                Originally posted by 89c51 View Post
                No idea if the test suit can do/does it already but wouldnt it be possible to have the output of journalctl -f (or other logs) published so someone can take a look at that in case something is wrong during the test?
                Yes, it long has uploaded all relevant system logs to OpenBenchmarking.org automatically that people can view from the given result file to see the various system information, etc. It's all public.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #9
                  Originally posted by Michael View Post
                  I've already explained many times in the past why I generally don't (primarily swapping out hardware/software components too often to be able to follow-up on bug reports but also no time to do so, working on many different tests at once, etc).
                  Hmm, you are right, I remember you telling me the same a while ago. Still, what if you simply report the bug and tell the devs that you have no time to help with it, and then post it in the article, hoping that someone else will also look at it? Also, afaik, radeon devs have the hardware to test things.

                  Comment


                  • #10
                    I've seen possibly related issues with other cards in past few months.

                    Originally posted by marek View Post
                    It looks like DPM broke at some point and the card was underclocked for the rest of the tests.
                    This sounds related to two other problems I've seen-on much smaller cards of the r600 generation. In the past few months, there has been an apparent DPM issue causing momentary freezes of a fraction of a second during video playback, no matter what the video output device and this is also sometimes sometimes visible while opening windows or switching virtual desktops in Cinnamon. It does not start right away, at first performance is clean. After running Firefox for a while or especially after running the Browser and Kdenlive at the same time for a while, the stutter freezes appear. Restarting X solves the problem every time, and as long as I only work with video or games (Critical Mass/Critter and 0ad mostly) it doesn't seem to come back. Running the browser and Kdenlive and turning on the second monitor will almost always invoke this, only restarting X seems to stop it. This is with the Radeon HD6750 and with the HD 5770, on FX-8120 (8 core) and Phenom II X4 respectively.

                    Either the last game in your test that gives full speed, or the first one that does not, could be doing something similar causing your reclocking to get screwed up. Running each game with a newly restarted X server might identify the culprit if only one runs slowly that way.

                    Also, on my FX 8120/HD6750 machine, it is possible to get issues requiring the video card to be removed and reseated. Last spring, I had a severe performance drop on top of the libSDL isues associated at that time with the DRI3 transition. Framerates in Scorched3d dropped by as much as 75%. Removing and reseating the video card fixed it, it seemed to be a bad connection somewhere. With newer kernels (or maybe another bad contact), I sometimes will get a refusal to modeset, the cure is the same. This happens rarely or I would switch the card to the next x16 slot down, having two of them. Check that you are not having a similar problem with a bad connection in the PCI-e slot.

                    Comment

                    Working...
                    X