Announcement

Collapse
No announcement yet.

AMD Ryzen 4000 Mobile Series "Renoir" Graphics No Longer Experimental With Linux 5.5

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

  • AMD Ryzen 4000 Mobile Series "Renoir" Graphics No Longer Experimental With Linux 5.5

    Phoronix: AMD Ryzen 4000 Mobile Series "Renoir" Graphics No Longer Experimental With Linux 5.5

    While the Linux 5.5 kernel is expected to be released as soon as this Sunday, a last minute change to the AMDGPU DRM driver makes the Renoir graphics no longer treated as experimental. With that, there is open-source support out-of-the-box rather than being hidden behind a kernel module flag...

    http://www.phoronix.com/scan.php?pag...Not-Experiment

  • #2
    I hope this also means better support for Picasso 3500U processors as well. Running version 5.3.0-26 on Ubuntu Bionic. There is screen tearing when watching some videos.

    Comment


    • #3
      I don't know what this really means.
      Picasso is not experimental since a while and it has still issues every day. With my Ryzen 3400G, I still have many errors at every boot and during usage, most look like:
      WARNING: CPU: 0 PID: 174 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1894 write_i2c_default_retimer_setting+0x74/0x340

      I reported the issues on the kernel bugzilla, but with no success at all. I tried several kernels and none is without an amdgpu "cut here" message. 5.4.8-1 is the one I use now as it is mostly usable, but, after a failure, the gpu resets never succeed and I need to reboot if I want to avoid a complete lockup.

      I wonder when it will reach a satisfactory behavior.

      Comment


      • #4
        Originally posted by RamaSpaceShip View Post
        I don't know what this really means.
        Picasso is not experimental since a while and it has still issues every day. With my Ryzen 3400G, I still have many errors at every boot and during usage, most look like:
        WARNING: CPU: 0 PID: 174 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1894 write_i2c_default_retimer_setting+0x74/0x340

        I reported the issues on the kernel bugzilla, but with no success at all. I tried several kernels and none is without an amdgpu "cut here" message. 5.4.8-1 is the one I use now as it is mostly usable, but, after a failure, the gpu resets never succeed and I need to reboot if I want to avoid a complete lockup.

        I wonder when it will reach a satisfactory behavior.
        Well I look at it this way, at least it has gotten better with each kernel or mesa release.

        Frankly I look at this as good news in that software support is going to be there at launch day.

        Comment


        • #5
          It's kinda weird to me that they require you to use a flag to enable the existing support; is it that they prefer you get fallback modesetting and nothing else? Do they expect that to be a better experience than having unstable acceleration?

          Comment


          • #6
            Zen 2 second failure. One when they block the gaming overclock to 200MHz and now this - the same iGpu with previous generations. This will end up one failure to another, wait and see. It seems that the time when Amd was listening to people have come to an end -again-.

            Comment


            • #7
              Originally posted by RamaSpaceShip View Post
              I don't know what this really means.
              Picasso is not experimental since a while and it has still issues every day. With my Ryzen 3400G, I still have many errors at every boot and during usage...
              And others experience this with 2700U CPUs, as reported in https://gitlab.freedesktop.org/drm/amd/issues/991

              And even with the Polaris-based GPU I bought years ago amdgpu from any contemporary stable or experimental kernel crashes frequently, and this did not get better over time, but got so much worse that I have to use years old kernel revisions if I want to run that GPU for at least a day without crashing.

              Knowing that linux-5.5 might display some image on some recent APU is all nice and fine, but not having any reason to hope it won't crash on you quickly devaluates this into an experimental playground at best, no matter if the kernel driver is tagged "experimental".

              Comment


              • #8
                I hope to find a good deal on a Renoir based laptop so i can upgrade from my 2500U based laptop once there available.

                Comment


                • #9
                  Originally posted by Nille_kungen View Post
                  I hope to find a good deal on a Renoir based laptop so i can upgrade from my 2500U based laptop once there available.
                  Likewise.. but in my case I'm going from a 2009 Core 2 Duo 2.53 with embedded geforce 9400m to hopefully one of the top tier of 15w Renoirs. Hopefully my patience is rewarded.

                  Comment


                  • #10
                    This topic deserves so much more attention than I can give it right now. But I have to say that it's not usually a good idea to be an early adopter on Linux. regardless of whether we're talking GPU's or whatever else. it's the best idea to choose hardware that is already stable and is already in good shape at the time of your purchase. AMD doesn't have a fantastic record of getting newly released hardware perfectly stable on any OS. Although the windows drivers have tons of cool graphical configuration tools and more enthusiast level features, they aren't always stable either. But it's especially so on Linux because it's a second class OS that AMD has less resources devoted to. The point is just buy hardware that is already known to have stable drivers and your user experience on Linux will be much better.
                    Last edited by duby229; 01-23-2020, 08:55 PM.

                    Comment

                    Working...
                    X