Announcement

Collapse
No announcement yet.

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

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

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

    Comment


    • #3
      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

      Comment


      • #4
        And not even r9 290x support on sight.

        Comment


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

          Comment


          • #6
            Unstable code might have regressions, more news at 11.

            Comment


            • #7
              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

              Comment


              • #8
                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 .

                Comment


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

                  Comment


                  • #10
                    I'm surprised Hollywood does not force removal of DRM code from prop drivers

                    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!

                    Comment


                    • #11
                      Originally posted by Luke View Post
                      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!
                      You seem confused.
                      http://en.wikipedia.org/wiki/Direct_Rendering_Manager

                      DRM has *nothing* to do with encryption.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            Digital restrictions management requires some form of encryption

                            Originally posted by droidhacker View Post
                            You seem confused.
                            http://en.wikipedia.org/wiki/Direct_Rendering_Manager

                            DRM has *nothing* to do with encryption.
                            I am of course speaking of digital restrictions management, not direct rendering! AMD and Nvidia both cooperate with Hollywood to support Blu-ray an DRMed streaming services If you look at descriptions of HDCP, it is based on moving encrypted content. The problem for Hollywood is that their advesary (the untrusted customer) must have the key to play the file, yet NOT have the use of that same key to copy the deciphered plain data to a file. This means the encryption is broken as soon as it is run on a system that permits the user to control their own computer, it's kernel, and access to the data busses. No "protected" path!

                            This is why it surprises me that Hollywood is not whining about Nvidia porting their Windows driver to Linux-or for that matter Windows XP, which predates the Microsoft-Hollywood alliance

                            Comment


                            • #15
                              Originally posted by d2kx View Post
                              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
                              That's the card I was considering. Except, I ultimately went with a used GTX 750. Made the right choice? It's not as powerful but at least, it works. Also, I don't need the extra 6/8-pin power connector.

                              I did have to do the same step in using nomodset and then installing the nvidia blob. I thought AMD had good open source support on newer (or at least, current gen.) cards.

                              Comment

                              Working...
                              X