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

Thread: Newer AMD Radeon GPUs Have Had A Tough Time With Linux 3.15

  1. #1
    Join Date
    Jan 2007
    Posts
    14,837

    Default Newer AMD Radeon GPUs Have Had A Tough Time With Linux 3.15

    Phoronix: Newer AMD Radeon GPUs Have Had A Tough Time With Linux 3.15

    Besides AMD's R9 290 "Hawaii" open-source support being broken and still not working right even after the hardware has been available to consumers for a half-year, with the Linux 3.15 kernel there's also problems right now for those with newer AMD Radeon GPUs...

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

  2. #2
    Join Date
    Feb 2008
    Posts
    945

    Default

    I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
    >>>>> I boot
    >>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
    >>>>> settings.
    >>>>> I haven't had a chance to bisect it yet, but it might be a similar
    >>>>> problem.
    Nah, yes for me too... i tried that Marek's memory pressured patches even before rc1 and that seems like does not work bug free so i tried that nearly month ago and got a hang . I tried FORCED game actually to test that new feature, game allocate more then 512MB on beauty settings and i limited it to that to see what will happens and got a hang . Great thing i can force amount of ram used as vram on AM1, so i can continue playing without a hang .

    As for Xonotic i dont see much of the slowness maybe let say around -2% here in 3.15 vs 3.14 And i think i dont see anything from those PTE patches . all that seems like more pointed for dedicated / powerfull cards .

  3. #3
    Join Date
    Nov 2012
    Posts
    144

    Default

    Puh I really hope that kernel 3.15 will be alright. I already need to skip kernel 3.14 becasue in this release my R7 260x is quite sincerely broken, and the fix is told to come only in 3.15 :s

  4. #4
    Join Date
    May 2010
    Posts
    89

    Default

    And not even r9 290x support on sight.

  5. #5
    Join Date
    Feb 2008
    Posts
    945

    Default

    Quote Originally Posted by narciso View Post
    And not even r9 290x support on sight.
    Ah i think i will say something very funny here , but i think those very high end Radeon cards never worked as expected with opensource driver .

  6. #6
    Join Date
    Jul 2007
    Posts
    242

    Default

    Unstable code might have regressions, more news at 11.

  7. #7
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,138

    Default

    My R7 260X doesn't even boot (Linux 3.13/3.14, Ubuntu 14.04 LTS) into the system, no matter if dpm is on or not. It only works with nomodeset (software rendering) and installing Catalyst afterwards. I have a feeling this will be fixed with the new firmware that had been pushed few weeks ago, but I haven't had the chance to try yet

  8. #8
    Join Date
    Feb 2008
    Posts
    945

    Default

    Quote Originally Posted by r1348 View Post
    Unstable code might have regressions, more news at 11.
    News at 02: Stable code have regressions too, rock stable code became unsupported as time goes .

  9. #9
    Join Date
    Jan 2009
    Posts
    1,406

    Default

    ... And this is one thing that'll be more likely be caught if AMD shares drm between catalyst and radeon.

  10. #10
    Join Date
    May 2013
    Posts
    538

    Default I'm surprised Hollywood does not force removal of DRM code from prop drivers

    Quote Originally Posted by liam View Post
    ... And this is one thing that'll be more likely be caught if AMD shares drm between catalyst and radeon.
    Given that even a proprietary driver runs over the Linux kernel and neutralizes any "protected" audio and video paths, I'm surprised Hollywood does not require carefully removing all DRM code or code that could be used to reverse-engineer DRM from AMD and Nvidia closed drivers capable of running with the "untrusted" Linux kernel.

    No computer can be simultaniously trusted by two parties who are in an adversarial relationship. It can be trusted by one or by none. Since users and kernel hackers control the Linux kernel, that means Hollywood does not control it and it can be (and SHOULD be) used as an attack vector against their DRM. Think: if the Nvidia blob is essentially the same code in Windows and Linux, an attack against Blu-Ray or streaming DRM written on a Linux box using Wine to trick the upstream provider could then be ported to Windows to allow all end consumers to copy their proprietary 5 channel sound without just cutting open the speaker cabinets to add resistors and mic jacks-and all their "encrypted" video footage.

    Would I use a kernel written by the police to decrypt and mount my encrypted drives full of raw protest video? No fucking way!

Posting Permissions

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