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

Hybrid View

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

    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
    1,065

    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
    149

    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
    1,065

    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
    249

    Default

    Unstable code might have regressions, more news at 11.

  7. #7
    Join Date
    Jun 2012
    Posts
    356

    Default

    Quote Originally Posted by Nuc!eoN View Post
    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
    You know, that fact this is considered acceptable says a lot for why people avoid linux. Things should not break. Period.

  8. #8
    Join Date
    Nov 2013
    Posts
    3

    Default

    DRM refers to Digital Rights Management code and that definitely has to do with encryption
    since it encrypts data to protect it.

    "Short for digital rights management, a system for protecting the copyrights of data circulated via the Internet or other digital media by enabling secure distribution and/or disabling illegal distribution of the data. Typically, a DRM system protects intellectual property by either encrypting the data so that it can only be accessed by authorized users or marking the content with a digital watermark or similar method so that the content can not be freely distributed."
    http://www.webopedia.com/TERM/D/DRM.html

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

    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
    570

    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
  •