Page 1 of 2 12 LastLast
Results 1 to 10 of 11

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,388

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

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

  2. #2

    Default

    Where do you get the newest Radeon microcode files? I'd like to try my 290X!

  3. #3
    Join Date
    Jan 2009
    Posts
    629

    Default

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

  4. #4
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    458

    Default

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

  5. #5
    Join Date
    Oct 2012
    Posts
    273

    Default

    more click-bait...
    http://www.phoronix.com/scan.php?pag...t141beta&num=2
    because reporting bugs is too hard

  6. #6

    Default

    Quote Originally Posted by asdfblah View Post
    more click-bait...
    http://www.phoronix.com/scan.php?pag...t141beta&num=2
    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).

  7. #7
    Join Date
    Jan 2009
    Posts
    1,735

    Default

    Quote 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?

  8. #8

    Default

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

  9. #9
    Join Date
    Oct 2012
    Posts
    273

    Default

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

  10. #10
    Join Date
    May 2013
    Posts
    609

    Default I've seen possibly related issues with other cards in past few months.

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •