Announcement

Collapse
No announcement yet.

The Dirty List Of GPUs With Open-Source Drivers Gone Wildly Wrong

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

  • The Dirty List Of GPUs With Open-Source Drivers Gone Wildly Wrong

    Phoronix: The Dirty List Of GPUs With Open-Source Drivers Gone Wildly Wrong

    This morning I shared the list of the 60+ graphics cards being tested under Linux for a set of very interesting articles coming up in the days ahead in this massive Linux graphics comparison in celebration of Phoronix.com's 10th birthday next week. While all of the graphics cards were tried, with the open-source drivers there were notable failures with both the AMD Radeon and Nouveau drivers...

    http://www.phoronix.com/vr.php?view=MTcwNjU

  • #2
    First Mate Rummey , that oibaf is funny .

    Comment


    • #3
      Bug #'s?

      You forgot to link to the detailed bug reports you filed upstream on each of the issues you found.

      Comment


      • #4
        Originally posted by Bryce Harrington View Post
        You forgot to link to the detailed bug reports you filed upstream on each of the issues you found.
        I've already been explained many times in the past why that doesn't end up (unfortunately) working out, but the two main issues come down to:

        - Already straining myself 18+ hour days / 7 days per week to work on Phoronix, PTS/OB/Phoromatic in a commercial capacity, plus other consulting, to make a living. Don't really have any other time. Already spent the past 7+ days working on this testing and not even done.

        - An even larger issue broadly is that I am constantly changing out software / hardware components when carrying out different testing... Soon as this testing is done, the hardware/software is changed out to do whatever testing is needed for the next article. Constantly running multiple systems and doing whatever is needed for the next article. Thus even if I were to do a bug report by magically creating more time in a day, I wouldn't be able to follow-up with testing or verification of patches/fixes, since by the time the developers have looked at a given problem, the system I found the issue on is likely already reconfigured for a completely different task.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          You don't need to fill bugs many of those are known ... But you can link to that bug, for example: "RadeonSI broadly: register allocation issues with Xonotic on higher quality settings.... / broken register spilling" that is all same bug:

          https://bugs.freedesktop.org/show_bug.cgi?id=75276

          Comment


          • #6
            And you should mention also that some users of oibaf repo complain today that Unity won't even start .

            http://www.phoronix.com/forums/showt...455#post420455

            Comment


            • #7
              You should just consider the thing as just a "in which state are the open-source drivers". That is to say, finality of the article. Automated testing is not designed to make bugs easier to report, just to see eventually if bugs happen. It's the same as "bug linking". Time consuming, so it's not easy to find them.

              Michael, you have to be very confident when seeing such screen corruption that the hardware won't burn to hell

              Comment


              • #8
                Michael, you should rent your hardware for bug testing!

                Comment


                • #9
                  X1800XT: bad rendering on some tests
                  X1950PRO: failed to schedule IB when it came to Tesseract test...
                  2005 called. They want their hardware back. Also they demand to know what that 'Tesseract' is.

                  Comment


                  • #10
                    Originally posted by Detructor View Post
                    2005 called. They want their hardware back. Also they demand to know what that 'Tesseract' is.
                    As said already, it's for a ten-year article trying to benchmark every GPU I have my hands on....

                    Tesseract has been covered many times: http://www.phoronix.com/scan.php?pag...ch&q=Tesseract
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #11
                      R7 260X reclocking issues... isn't that what the new microcode in the linux-firmware is supposed to fix, along with some others? It's neither in oibaf's PPA nor pushed to Ubuntu 14.04 LTS as an update, so I assume that's responsible for some of the AMD bugs.

                      Comment


                      • #12
                        Originally posted by d2kx View Post
                        R7 260X reclocking issues... isn't that what the new microcode in the linux-firmware is supposed to fix, along with some others? It's neither in oibaf's PPA nor pushed to Ubuntu 14.04 LTS as an update, so I assume that's responsible for some of the AMD bugs.
                        The firmware should fix it, but AFAIK, even with current kernel Git the R7 260X re-clocking support is still disabled by default.
                        Michael Larabel
                        http://www.michaellarabel.com/

                        Comment


                        • #13
                          There are known hangs with kernel 3.15 on Sea Islands (confirmed on Bonaire, not sure about the other chips). A workaround is also known. We won't probably have a fix in time for 3.15 final, so hopefully it will be in the next bugfix release (3.15.1 ?).

                          Kernel 3.14 works fine.

                          Comment


                          • #14
                            The sad state of r600 continues...

                            Comment


                            • #15
                              I think u do just something wrong, maybe I am wrong and 99-100% of the bugs would happen in lets say fedora rawhide too.

                              But I would never install ubuntu if I want to test free glx-drivers.

                              Ubuntus main advantage over something like fedora (for others its a disadvantage) is their commitment to non-free drivers to make it as easy as possible to install them.

                              And then u use a absolut non official ppa replacing some stuff.

                              Why not just try then if something like that happens, a fedora rawhide? its a distro where many developers from the free drivers work as major distro or package directly for it. or use ubuntu if needed and compile it yourself.

                              Its not convinient I know, but why test it then in the first place if most of your audience will not install your setup too?

                              I would never install fedora to test proprietary drivers, and the same is true about ubuntu and free drivers. Except I want to test how well ubuntu works specificly but want to test the drivers right?

                              Comment

                              Working...
                              X