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

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

                    Working...
                    X