Intel Mesa Gives Problems With KDE's KWin, Again

[locovaca]

But this time, it's not KDE who released a new version, it was Intel, and they didn't check if it works. Now KDE is facing the possibility that compositing will be broken on Ubuntu for the next 6 months.

Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?

[Temar]

Why is it Intel's responsibility to test KDE's code out with their driver?

Because there is no point in having a driver which does not work with widely used software. We are not talking about a random 3D application here but about one of the major Linux desktops. Testing their driver on the major Linux desktops is the least Intel can do.

[pingufunkybeat]

Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?

Compiz and Mutter. And any other application which is used daily by tens of millions of people.

I mean, if people expect KDE guys to test several dozen drivers (and I do), then I'd expect a driver dev to have a quick check whether he broke the second most widely used window manager under Linux.

[pingufunkybeat]

P.S. It's still wrong to rely on the renderer string, and I still have no better solution for enabling basic functionality on software people expect to just work.

[marek]

Marek, how would you test correctly if a driver provides appropriate functionality?

It is known since the last KWin fiasco that you can't trust the advertised functionality,

When some Kwin dev (maybe Martin again?) claimed that, no open driver developer knew about broken advertised functionality. We thought everything was alright, everything worked fine for us. Most games ran beautifully. The drivers do NOT claim to support things they do not support. As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.

Moreover, the NVIDIA OpenGL implementation is far from being compliant, so if something works on NVIDIA, it pretty much means it might not work anywhere else. I *like* proprietary drivers, but relying solely on NVIDIA ones might lead to frustration as you can see in various Martin's blog posts. Unlike NVIDIA, both Catalyst and Mesa try to follow the OpenGL specification to the letter, even though the spec is sometimes self-contradictory or doesn't make sense.
Further reading on the subject (a little bit more technical): http://www.g-truc.net/post-0348.html

and checking for direct rendering is also a hack which doesn't even work anymore. Blacklists caused their own set of problems, and if there is no check, KWin will crash all the time, like 4.5 did.

What is the correct way to check this?

The best way is to communicate and do the job right. Linux will never work if developers ignore each other. The Kwin devs should assume everything works and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.

The worst scenarios are:
- Reverting to an older version without telling anyone and hoping the problem will be fixed in the next version (it won't).
- Blacklisting the software without telling anyone (again, it won't get fixed until either a developer runs into it or a user reports it). And don't forget to make a blog post about it to piss off everybody else.

As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.

[pingufunkybeat]

As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.

I agree that communication is important and desirable, but if the drivers crash, then surely something is wrong. Drivers should never crash, and this is what was happening with KWin 4.5, using advertised functionality. On all drivers, not just Intel, it was a Mesa bug.

Regardless of whether it was reported correctly to the Mesa devs, or tested at the right time before releasing, which is a different issue.

As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.

But some people don't use modules. And DRI2 is only used by open drivers, as is exposing stuff through sysfs. Perhaps it's better than grepping the renderer string, but it's bound to be considerably more complicated and is also bound to change between driver versions, leading to complex logic.

I don't know of a single, reliable way of detecting what the driver can actually accelerate reliably. Ideally, they would all accelerate everything reliably, but unfortunately this is not likely to be the case soon.

[smitty3268]

The best way is to communicate and do the job right.

Agreed, but this works both ways. In this case, it seems like the Intel driver developers should have gotten this news out to people using the driver.

The Kwin devs should assume everything works

That's what they did for 4.5, and it didn't turn out very well.

and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.

Definitely. However, often the response is "fixed in latest git" which doesn't really help the KDE devs much. They have to work with older drivers that are actually being shipped in distributions, or people complain. And I don't think it's reasonable to force the distros to always ship the latest git drivers either.

I think everyone can agree that they way KDE is parsing that string is hacky, but I think they have a point complaining here. Why would Intel change the userspace API (even if it's a hack, they know people are using it) like that in a point release which is supposed to be bugfixes only? Or at least that's what i thought they were meant to be. Just wait for 7.11 to come out. There also wouldn't have been an issue if the change hadn't occurred right before an Ubuntu release but right after a KDE release - presumably they were trying to sneak some fixes in for Ubuntu, and managed to completely break the other desktop as a result. It doesn't really matter who's to blame at that point, all the user knows is they updated a package and everything broke. That shouldn't happen in a point release, IMHO.

[roentgen]

Most games ran beautifully.

Hell of test you did there. Especially when it comes to Linux.
Maybe we should all ditch desktop environments and find a way to run apps from the CounterStrike console.

PS: running radeon here and all I see is degraded performance with every Mesa / Xorg / kernel upgrade. Both gnome3 and kde.

[airlied]

Hell of test you did there. Especially when it comes to Linux.
Maybe we should all ditch desktop environments and find a way to run apps from the CounterStrike console.

PS: running radeon here and all I see is degraded performance with every Mesa / Xorg / kernel upgrade. Both gnome3 and kde.

Must be the test we added for noticing if the user has posted dumb stupid shit to phoronix and slowing his machine down.

Dave.

[smitty3268]

Must be the test we added for noticing if the user has posted dumb stupid shit to phoronix and slowing his machine down.

Dave.

hahahaha.

Still, wouldn't you agree that a proper testing procedure before releasing a "stable" release would be: 1. launch Gnome + compiz, 2. launch Gnome + Mutter, 3. launch KDE, and test to make sure all continue to work? And if not, email the project in question to try to figure out why a stable release broke something?

I think much of the frustration here is coming from the fact that a project like Compiz or KDE are used by about 50% of users. Even the most popular game is probably in single digits. So it seems like more attention should be given to one rather than the other, and it seems like the opposite is actually true.