Announcement

Collapse
No announcement yet.

Mesa 17.3 Remains Quite Buggy, Developer Calls For Better Handling In The Future

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

  • Mesa 17.3 Remains Quite Buggy, Developer Calls For Better Handling In The Future

    Phoronix: Mesa 17.3 Remains Quite Buggy, Developer Calls For Better Handling In The Future

    If you are making use of the Mesa 17.3 releases, have you found them to be buggier than normal for this open-source 3D graphics driver stack? There remains a higher than average amount of bugs still outstanding that have plagued Mesa 17.3, even with being up to 17.3.5...

    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
    Intel seems like to revert things recently - first firmwares, now mesa... what is next?

    Buggy ddx, won't make releases there... OK they switched to GLAMOR, but now they have problems there also

    This is released, this is not released, this is released, this is not released.... what kind of crap is that How about, to just do not make any releases and to be crappy always?

    It will be interesting to see what comes of this call for action.
    We should make an action and to revert their "i am watching you" Meltdowned CPUs and request fixed one... i think there is no other way any monopol can learn a lesson

    Also there should be a law, that they should be not alowed to never ever release new CPU with that M-shit anymore
    Last edited by dungeon; 22 February 2018, 01:57 AM.

    Comment


    • #3
      What do you think of Mesa's stability these days? What release management changes would you like to see occur for Mesa? Let us know in the forums.
      I think Mesa should be ditched from every distro, so that user could install what release he wants/needs. That would also save us from bugs no one will fix, but would also save us from lazy/crazy ideas that i don't want to mention at this time
      Last edited by dungeon; 22 February 2018, 02:35 AM.

      Comment


      • #4
        Originally posted by debianxfce View Post
        Distributions should have OIbaf ppa that is updated twice per day so users get bug fixes fast.
        Fixes & breakages same fast I believe on modern CPU you can compile mesa probably 100s of times per day, even without meson nor caches ... that would be fastest for you if you like to see how nice trunks behave at a moment but not so nice at another moment

        Problem with that is that you can only test that but you don't have time to use it, that makes you lazy, meson makes you lazy, even git makes you lazy... everything what is so fast leans to that it does not work at the end as you are starting to overlook things, on about ignorance i won't even want to start to discuss about That is also problem with some devs, they don't have time to use it so they could only believe how everything is fine and dandy, that community is so nice... meanwhile reality speaks different story, just look at bugzillas around
        Last edited by dungeon; 22 February 2018, 05:31 AM.

        Comment


        • #5
          Mesa 17.3 also regressed badly for me: x11perf -putiamge10 is now only at 30% the throughput it was with 17.2.
          Bisected and reported, no response till now :/

          Comment


          • #6
            17.3 makes Atom stutter terribly with files over 2k lines long, where 17.2.8 runs smooth as silk. I've also had a few other stability issues using 17.3, ie HDMI randomly dropping my main display and having to unplug/replug and run xrandr to bring it back up, pulseaudio then being randomly broken until I reboot... not good. So I've gone back to 17.2.8, and that is working well apart from font corruption of GNOME apps when I suspend it... that bug seems to be in GNOME itself, not the driver. From what I have been able to find out it's because GNOME is caching font data in display memory and that memory isn't preserved during suspend, and there's no way to clear the cache. :-( The only fix is to make subtle changes to the font preference to invalidate the cache. IE switch DPI from 144 to 145.

            Comment


            • #7
              DonĀ“t mesa devs do "continious integration" and "regression testing" or something like that. I only know the buzz words, but I thought those things are pretty common these days. Maybe its more difficult with mesa because you need a lot of real hardware and can not test in virtual machines reliably. Thus maybe they should corporate with michael or a serious big linux distrubution that has such a hardware park to test before release. The Linux Foundation (in the name of security?) or crowdfunding somehow would need to cover the costs.

              So yeah, I think mesa could be much more stable and this is not only since 17.3. If they do not test each driver at least once on one real machine and thus end up shipping a completely broken RADV, then something in their QA mindset / implementation is wrong.

              Comment


              • #8
                The worst part of Mesa is that it can freeze the hole system by just opening a game that previously worked fine. Though I thought most bugs get fixed before a final Mesa release, at least this was my hope. From my point of view what really needs a fix are the AMDGPU drivers, if I turn my monitor off and on again on Plasma-Wayland, the system crashes and the display stays black until reboot. Same issue appears if the monitor woke up from sleep.
                I think it is a valid point that Mesa needs some quality improvements.

                Comment


                • #9
                  Happens everywhere all the time.
                  I also noticed some regression in the r600 "range" (I don't know if DDX, mesa, libdrm, kernel's fault). But only on my E-350. I get flickering in sddm at the KDE login and also the screen freezes up (seemingly) every now and then so I have to swtich to VTx and back to X and then it works again for some time.
                  But driver regressions I can remember back to the DOS days (various) and W98 (nvidia blob). There's a good release, a bad release and then (hopefully) a good release again.

                  I guess the mesa devs might lack time and material for extensive (automated) testing?
                  Stop TCPA, stupid software patents and corrupt politicians!

                  Comment


                  • #10
                    Originally posted by R41N3R View Post
                    I think it is a valid point that Mesa needs some quality improvements.
                    Quality improvment when complexity has been so raised nowdays and when you have problems is a best to be done in a way that you just really drop support for oldest and clean things up after that

                    Just do that without any shame really as blobs do that too after couple years too, let say after every 3 years make new branch a leave couple of eldest gens in history Or just allow up to 6 years old in main, else goes to longterm branch with mainly kernel/x support up to 10 years and really good bye after that That should be official or if someone like even more that will be unofficial/extended but surely and clearly out.

                    I am somewhat sure these a broken anyway, better just leave them as stable before planned breakages
                    Last edited by dungeon; 22 February 2018, 05:35 AM.

                    Comment

                    Working...
                    X