Announcement

Collapse
No announcement yet.

AMD Improving The Linux Experience When Running New GPUs Without Proper Driver Support

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

  • AMD Improving The Linux Experience When Running New GPUs Without Proper Driver Support

    Phoronix: AMD Improving The Linux Experience When Running New GPUs Without Proper Driver Support

    While AMD provided upstream open-source driver support for the Radeon RX 7900 series launch, the initial user experience can be less than desirable if running a new Radeon GPU but initially running an out-of-date kernel or lacking the necessary firmware support. With a new patch series posted AMD is looking to improve the experience by being able to more easily fallback to the firmware frame-buffer when their AMDGPU kernel graphics driver fails to properly load...

    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
    With the new IP-based discovery "block by block" approach to how the open-source AMD Radeon Linux graphics driver is managing the hardware initialization with RDNA3 and moving forward
    Sounds like RDNA2 is already silently legacy.

    Comment


    • #3
      Originally posted by Espionage724 View Post
      Sounds like RDNA2 is already silently legacy.
      Kinda, but RDNA2 at this point is old enough that most modern LTS distros probably support it by now. As I see it, the benefit of this is so people with cutting-edge hardware but stable/LTS kernels can still have a usable system so they can figure out how to get their GPU fully functional without having to transplant a different GPU or resort to an iGPU.

      Comment


      • #4
        Finally. I wondered for a decade why failing graphic drivers need to ruin otherwise working simple system frame buffer graphic, ..! :-/

        Comment


        • #5
          Originally posted by schmidtbag View Post
          Kinda, but RDNA2 at this point is old enough that most modern LTS distros probably support it by now. As I see it, the benefit of this is so people with cutting-edge hardware but stable/LTS kernels can still have a usable system so they can figure out how to get their GPU fully functional without having to transplant a different GPU or resort to an iGPU.
          pretty much if the distro has 5.11 (technically 5.10) or higher rdna2 will work. with 5.15 being a LTS its pretty much a guarantee. the only new thing that be missing is mesh shader support that came with kernel 6.1 (gang support) but you need mesa 23 for it to work and that won't be released till next year.

          Comment


          • #6
            Originally posted by rene View Post
            Finally. I wondered for a decade why failing graphic drivers need to ruin otherwise working simple system frame buffer graphic, ..! :-/
            And the fix was just in 30 lines of code lol.

            Comment


            • #7
              Thankfully this is much less of an issue back when I was running a Day 1 R9 270X and had daily issues for 3 years, including 9 months of hard locking 1-3 times a day lol. Good times, good times.

              Now if something doesn't work it's usually just the small stuff, state tracking, hardware difference/unimplemented/changed stuff that just needs worked through. Hopefully it'll be worked out ahead and new issues can get rolled through 4-6 months before. With Intel floating their own new driver rework, maybe RadeonSI should get a facelift and rework to get rid of the cruft. NGG, different chips for compute, and SRIOV existing in only select places (but should be everywhere soon) I could see a rework being beneficial to keeping everything coherent, extend features so they can work sooner rather than later. It's not like, an issue, it's working well now. But eventually they'll have to de-platform RadeonSI and we should probably worry about that sooner rather than later. (SR-IOV)

              Although I will say this, Vulkan is pretty nice and the other RADV stack is baller. Vulkan has shown why they should do it open. And it's not even as open as it could be, hopefully they'll get that out closer to release, too.

              Comment


              • #8
                "However the problem is further exaggerated in the case of amdgpu because
                it has migrated to "IP discovery" where amdgpu will attempt to load
                on "ALL" AMD GPUs even if the driver is missing support for IP blocks
                contained in that GPU.‚Äč
                ...
                The perfect example of this is Ubuntu 21.10 and the new dGPUs just
                launched by AMD. The installation media ships with kernel 5.19 (which
                has IP discovery) but the amdgpu support for those IP blocks landed in
                kernel 6.0. The matching linux-firmware was released after 21.10's launch.
                The screen will freeze without nomodeset. Even if a user manages to install
                and then upgrades to kernel 6.0 after install they'll still have the
                problem of missing firmware, and the same experience."

                So the new IP discovery made this situation a bit worse... even though you could hit this before also in a couple of ways.

                Comment


                • #9
                  Michael, did you have any luck running tensorflow-rocm with those 7900 cards? I am unable to do so, but I am unsure whether it's simply my technically unsupported rocm platform (Archlinux), or if Rocm simply doesn't work for tensorflow on these cards yet. Relevent Github issue: https://github.com/RadeonOpenCompute/ROCm/issues/1880

                  Comment

                  Working...
                  X