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

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

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

    Mesa 19.2.4 was released on Wednesday as an "emergency release" after a bug was discovered that made last week's Mesa 19.2.3 version buggy for all OpenGL drivers...

    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
    ...Did no one bother to run the code before release? How to you break them ALL and not notice?

    Comment


    • #3
      Originally posted by Snaipersky View Post
      ...Did no one bother to run the code before release? How to you break them ALL and not notice?
      That should be the question of the week on phoronix.

      Comment


      • #4
        Originally posted by Snaipersky View Post
        ...Did no one bother to run the code before release? How to you break them ALL and not notice?
        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.

        Comment


        • #5
          They rely soly on automated tests. If a case like that didn't get test there, every gets boom.
          Especially RadeonSI is extremely error prone. Two devs simply can't handle it. And they can be lucky, that valve sponsors some talented people.
          In anyway they need too long to fix bugs. And they don't have control about performance. Performance regressions get in most cases not fixed at all.

          Comment


          • #6
            Originally posted by cl333r View Post

            That should be the question of the week on phoronix.
            Bugs are a fact of life, and yes sometimes critical bugs will slip through several developers. The only thing we can do is reduce them through proper software design and development techniques, and QA/testing.

            Comment


            • #7
              Originally posted by Strunkenbold View Post
              They rely soly on automated tests. If a case like that didn't get test there, every gets boom.
              Especially RadeonSI is extremely error prone. Two devs simply can't handle it. And they can be lucky, that valve sponsors some talented people.
              In anyway they need too long to fix bugs. And they don't have control about performance. Performance regressions get in most cases not fixed at all.
              Are there plans to solve all that?

              Comment


              • #8
                I was curious as to why Fedora hadn't updated yet.

                Comment


                • #9
                  Originally posted by Strunkenbold View Post
                  They rely soly on automated tests. If a case like that didn't get test there, every gets boom.
                  Especially RadeonSI is extremely error prone. Two devs simply can't handle it. And they can be lucky, that valve sponsors some talented people.
                  In anyway they need too long to fix bugs. And they don't have control about performance. Performance regressions get in most cases not fixed at all.
                  Ironically i use mesa-git daily(self compiled for the custom flagsness) and that didn't broke on RadeonSI for me(at least in the last 2 months).

                  Also as an AMD only guy(for GPUs, i hate nVidia Blob), i can tell you that at least for Polaris, Tahiti, Cape Verde and Mullins Mesa rarely breaks for me, most of my issues with RadeonSI came from LLVM trunk breaking down.

                  You maybe right tho because there are certain families of AMD GPU with serious bugs like Tonga, Hawaii and other that need lots of workarounds and the more workarounds the more chance something will break for those chips

                  Comment


                  • #10
                    Originally posted by jrch2k8 View Post

                    Ironically i use mesa-git daily(self compiled for the custom flagsness) and that didn't broke on RadeonSI for me(at least in the last 2 months).

                    Also as an AMD only guy(for GPUs, i hate nVidia Blob), i can tell you that at least for Polaris, Tahiti, Cape Verde and Mullins Mesa rarely breaks for me, most of my issues with RadeonSI came from LLVM trunk breaking down.

                    You maybe right tho because there are certain families of AMD GPU with serious bugs like Tonga, Hawaii and other that need lots of workarounds and the more workarounds the more chance something will break for those chips
                    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.

                    Comment

                    Working...
                    X