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

[computerquip]

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

It takes 3 years just to get decent support in Mesa it feels like.

[dungeon]

for that you want the opposite: distros should provide selection of mesa releases. if your distro doesn't, choose better one

Nope, distros should provide either just and only one mesa version or not any mesa at all... because more versions of any software usually means no one care about quality of it Of course when you have such a software you shouldn't depend on it, nor to provide it by default.

It is total bullshit to "support" one asic with several drivers, because that is not support that is "i don't care but here i am again" trolling-technology ... have in mind these AMD drivers severity specially on GCN 1.0/1.1, all that is glorious bullshit - put also different versions there and there would be 20 paths to one single asic, but who cares about that, as it should be "one asic one driver" and good bye - no one serious wanna do that, their bugzillas and also distro bugzillas would be overfilled, but no one would fix anyhing anyway

Here Mesa seems incapable so can't provide stable release even with 6 RC and after 5 points on 17.3... 11 updates and still have obvious and glorious bugs That only means, no one care - they only have one path and that is master or their own whatever development shitty branches
And if releases are with this much additional effort this much borked, what you think of master? That is even more borked. Mesa relases looks like they are just for the fun or just because it is fancy to do releases, otherwise have no particular meaning

Simple logic says - if Mesa can't release 4 drivers per year, try to reduce it to 3 or even better just 2 so that users would know what also llvm release is better combo with particular mesa release Or of no one care about releases there, simply don't release it.

Or even more simplier logic - of no one care, no one of users should ever fill any bug nor to lose any minute on that

[dungeon]

When you are so superior, create all Oibaf ppa packages for Debian sid. 32-bits too. Make your Debian package repository public available.

Why should i do that? I don't see neither fun nor need there to make daily packages for users who should already know how and why they use moving (not for regular users) target such as Sid

BTW, i don't think i am superior to anyone. Statistics says that people like me are minority as i mostly just operate on mine raw IQ130 so maybe it is that

Altough Sid is nice for developers, just install it as mini as possible, ignore packages that you don't want and then compile everything of your interest yourself from git, kernel, X, mesa, whatever else... make a scripts and enjoy yours all git of your preference rolling box. I have such install on one partition, that never breaks, but i know it "never breaks" for me-only, so i don't recommend that to regular users as their definition of "never breaks" is likely different

Currently i am on Debian 8 running todays linux-next-20180223 and FGLRX, that should be broken long ago but not for me for some reason

There on FGLRX i also wanted to check and to see how 'x11perf -putimage10' people mentioning here is actually 4 times faster then mesa's before regression and about 12 times faster if i compare that mesa with regression So i am sorry but from this POV that bug is laughable to me since i don't feel that is regression but that this was much slower already even before that

That is how developemnt of performance is going, you improve something at expense of something else i guess Maybe there are GLAMOR wars among several users in Mesa nowdays and performance goes like this like that there same as for composition it will be never perfect, since there is no perfection there by design

I always feels like classic ddx and amdvlk would be enough to be modern and productive, path to avoid GL altogether (thus Mesa too) but to no avail i am not a customer nor OEM so i don't exist - these "who knows who they are" customers wanna run preferably all-bloat-all-layers-only it seems - good luck with that

[swizzler]

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

It's from Linuxhippy.

That bug was written 3 days ago! I got the impression that Linuxhippy's bisection was ignored or missed.

There is a tiny set of developers working long hours to bring stable, performant, feature-rich open source drivers to AMD users. Bisecting bugs like Linuxhippy is really helpful to them and to *all* of us. They won't be able to respond immediately though.

Keep in mind that these community developers are able to create a driver which is better in many ways than the port from the much larger closed source windows driver. At any moment, AMD management could unilaterally decide that desktop Linux is not worth the effort, and could cancel fglrx. They can't cancel Mesa as easily.

We should all be like Linuxhippy and try to help them with bisections and testing of the release candidates.

[nuetzel]

That bug was written 3 days ago! I got the impression that Linuxhippy's bisection was ignored or missed.

There is a tiny set of developers working long hours to bring stable, performant, feature-rich open source drivers to AMD users. Bisecting bugs like Linuxhippy is really helpful to them and to *all* of us. They won't be able to respond immediately though.

Keep in mind that these community developers are able to create a driver which is better in many ways than the port from the much larger closed source windows driver. At any moment, AMD management could unilaterally decide that desktop Linux is not worth the effort, and could cancel fglrx. They can't cancel Mesa as easily.

We should all be like Linuxhippy and try to help them with bisections and testing of the release candidates.

Are you talking to me?
I've only pointed _you_ to Clemens (! - alias Linuxhippy) bug #.
How development goes, is what I know ~25 years (Linux) and since 1995 (Mesa).
Have you looked in _my_ answer to 'Linuxhippy'?
Have you looked into the 'source'?
Maybe: https://cgit.freedesktop.org/mesa/me...4648a7723961cb

[nuetzel]

There on FGLRX i also wanted to check and to see how 'x11perf -putimage10' people mentioning here is actually 4 times faster then mesa's before regression and about 12 times faster if i compare that mesa with regression So i am sorry but from this POV that bug is laughable to me since i don't feel that is regression but that this was much slower already even before that

So, why can't you add this 'GREAT' (new') information on the 'right' bug# under https://bugs.freedesktop.org/show_bug.cgi?id=105171, then? --- Or are you talking here just for fun or to your self?

[dungeon]

So, why can't you add this 'GREAT' (new') information on the 'right' bug# under https://bugs.freedesktop.org/show_bug.cgi?id=105171, then? --- Or are you talking here just for fun or to your self?

Why should i do that, one bump is enough - OP in that bug test on radeon, bisect is there so that is more than enough from user... he should test it on amdgpu also, but also on fglrx for himself if he wants, because he have several drivers for the same Kaveri asic

Bug might hit radeon only, but not amdgpu and certainly not fglrx and who knows about amdgu-pro... he have four official drivers for asic (plus God knows how much different versions of these could be), so it might not be a bug of high priority if it happens only on one at the time in a first place

He also runs it seems several heads on that APU '4k + FullHD displays' (not sure how much more of these FHD displays are there) so bug might appear only in his scenario, etc...

Whatever, i would say it again if you missed that - more drivers per asic is plain crazy, that just disperse any quality.

[carewolf]

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.

That is incredible difficult to with with graphics hardware. You can't use virtual machines for instance, but need to maintain actual physical machines for testing.

[carewolf]

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 had that with the proprietary NVidia drivers. They worked around it by creating two OpenGL contexts, as only the first one was flickering.....