Announcement

Collapse
No announcement yet.

Mesa 19.2.4 Released As Emergency Update After 19.2.3 Broke All OpenGL Drivers

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

  • #11
    Originally posted by ms178 View Post

    That is one reason why I started to read the gfx-related mailing lists years ago, for spotting hw bugs and workarounds. Even though I cannot judge their significance, it more or less makes an impact on the quality of the product. And especially with ROCm, some of these hardware issues left customers out in the cold (e.g Tonga). My 6770M laptop experience wasn't exactly great either, you cannot even use DX11 on Windows 10 anymore and if you don't disable the lowest power state, you get weird minute long delays in 2D desktop usage. Despite all of this, I really like AMD's products (running Ryzen + Vega 56 on my main rig), but I hope that with their improving financials AMD can improve their processes to avoid these long list of hardware and software issues in the future.
    yeah, I did gave up on ROCm, is an impossible mess to sort through. For now i'm using amdgpu-pro opencl from AUR while i'm anxiously waiting for Clover over NIR project to reach CL 1.2 at least since at least part of HMM for AMDGPU already landed on the kernel.

    I think future wise this solution will be wayyyy better for 99% of the cases than ROCm.

    Comment


    • #12
      I am sure many Linux users would update to 19.2.3, even if the emergency update hadn't been replaced just because "its newer!" XD

      Comment


      • #13
        Hopefully fixes the bug where using Kate on Plasma Wayland session doesn't update the display, so I end up blindly typing and not seeing any change on screen. Turning off/on composition via keyboard shortcut seems to fix it.

        Comment


        • #14
          Originally posted by kpedersen View Post
          I am sure many Linux users would update to 19.2.3, even if the emergency update hadn't been replaced just because "its newer!
          Well, most Linux users have that automatically taken care of by their package manager. And the ones who do it manually are probably using mesa from git.

          Comment


          • #15
            Originally posted by abott View Post

            Go run every line of code in the driver and come back to report how easy it is to make sure that happens. In every combination of code, too.
            That's what testing is for, they should run tests, I'm sure Intel can afford it.

            Comment


            • #16
              Originally posted by abott View Post

              Go run every line of code in the driver and come back to report how easy it is to make sure that happens. In every combination of code, too.
              If we're speaking about corner cases, you're right. But this bug hits every driver in Mesa. It's not a case of every line of code and every combination of code.

              Comment


              • #17
                Originally posted by jrch2k8 View Post

                yeah, I did gave up on ROCm, is an impossible mess to sort through. For now i'm using amdgpu-pro opencl from AUR while i'm anxiously waiting for Clover over NIR project to reach CL 1.2 at least since at least part of HMM for AMDGPU already landed on the kernel.

                I think future wise this solution will be wayyyy better for 99% of the cases than ROCm.
                Interesting enough, rocm version is the only opencl working on Davinci Resolve.

                Comment

                Working...
                X