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

[iyxwsoekthsv]

Distributions should have OIbaf ppa that is updated twice per day so users get bug fixes fast.

Even though I regularly rely on the Oibaf PPA myself, I have actually also seen it completely break stuff. To the point of X not even launching anymore; requiring me to do a manual fix from a text mode recovery.

It can be good, life in Oibaf land... but it can also be sort of risky.

[ryszardzonk]

I way to get rid of bugs is to call them features. For instance for screen shown just say "Now shipping with new Gaussian Fast Fourier psychodelic transform enabled only on best platforms"

[ResponseWriter]

The most obvious bug I've noticed is that when using redshift, since 17.3.3 the screen flashes to an 'unshifted' state occasionally. It regressed between 17.3.2 and 17.3.3. I'll have to try git to see if it's fixed, otherwise try to bisect.

[theghost]

I have no issues since a long time with Ubuntu x-swat ppa (atm. mesa 17.3.3).

Those who cry here using Oibaf or Debian experimental should not wonder when their system breaks.
Every package is latest git or rc version.

Emil answer says all: https://lists.freedesktop.org/archiv...ry/186404.html
That reminds me of the good old days of broken Sandybridge support powered by Intel.
Since I switched to AMD I never looked back.

[aufkrawall]

The most obvious bug I've noticed is that when using redshift, since 17.3.3 the screen flashes to an 'unshifted' state occasionally. It regressed between 17.3.2 and 17.3.3. I'll have to try git to see if it's fixed, otherwise try to bisect.

Can't confirm with Polaris, works really well with xf86 DDX driver.

[leipero]

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.

I guess the mesa devs might lack time and material for extensive (automated) testing?

I don't use sddm, but what you are describing sounds like DDX problem, I had similar problem with "xf86-video-ati" where GDM would get corrupted, filed a bug and they resolved it, but it is not included in the last version (probably I need to check, didn't check in a while). Moved to modesetting, it works, I gave up. It's interesting, recently I've tested some Android x86 iso's on hardware, and while 7.1 uses mesa 17.x, Phoenix OS uses same kernel and everything, but Mesa 12.x (not sure what point version), and what is interesting here is that while playing "8 Ball Pool" on Android x86 7.1 with Mesa 17.x sound cracks all the time when ball hits anything, when spining wheel or getting oponent, while at Phoenix OS (basically same, based on Android x86 7.1) with Mesa 12.x there are no such problems, everything plays perfectly. It could be that I'm faulting Mesa while something else is at fault, but that's biggest difference between Android x86 7.1 and Phoenix OS v2.5.9.375.

I do not agree that all distributions should use latest Mesa, for this very reason mentioned above, I think best solution would be user option with recommended version (similar to how kernels are delt in Mint), that would be most logical way, so testing would give distribution developers reasons why they recommend one version over other. If you want latest release, just go rolling, and if you want latest commit, go git.

[Jumbotron]

So far so good with Padoka 17.3 Stable PPA on both my computers with AMD Bristol Ridge APU ( Carrizo refresh ). Oibaf, however, blew up both and had to revert back to 17.2 until Padoka 17.3 Stable PPA.

[tomtomme]

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.

I have this issue lately on x11 too...

[STiAT]

I actually didn't experience on the 17.x series, honestly.

But Mesa 18 is in RC4 and hell bughy at the moment. So ye, the call is good and right.

[linuxgeex]

The most obvious bug I've noticed is that when using redshift, since 17.3.3 the screen flashes to an 'unshifted' state occasionally. It regressed between 17.3.2 and 17.3.3. I'll have to try git to see if it's fixed, otherwise try to bisect.

Redshift works by setting hardware scaling factors in the RAMDAC via XRANDR extension. There's no unshifted state... what is probably happening is that you have 2 tasks competing for setting those scaling factors. IE your desktop environment may have a screensaver function that is scaling the brightness down while ignoring the color temperature, and redshift switches it back a second later, resulting in flicker. Try disabling display dimming features in the power saving preferences.

My guess is that your desktop introduced an optimisation where they moved from dimming via the compositor to using XRANDR, and that is why you're experiencing it coincidentally with the Mesa upgrade.