Martin Takes His Mesa Issues To The List

[phoronix]

Phoronix: Martin Takes His Mesa Issues To The List

Over the weekend there was a rant by Martin Gr??lin, the lead developer of the KWin compositing window manager for KDE, about Intel's open-source driver breaking. This is the second time in recent times that the driver has outright failed with KDE, which threatens the Intel KWin support in Ubuntu 11.04, but this time it's over the OpenGL renderer string being changed and KWin using that to determine direct rendering support. Martin has now written a very lengthy e-mail to the developers of Mesa...

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

[pingufunkybeat]

Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P

OMG, that is awesome!

[RealNC]

Wow. Wall of Text. I'd be surprised if any of the devs will even try to read that.

[DanL]

Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P

Awesome! Maybe I should hope to find some video acceleration under my Christmas tree?

[curaga]

Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P

[DanL]

Oh and btw the Debian Easter Bunny gave me a present:

Debian Easter bunny? Yes! I hope mesa Santa brings more r600g goodness (hyperZ, etc.)

[mgraesslin]

Oh and btw the Debian Easter Bunny gave me a present:

OpenGL vendor string:                   X.Org
OpenGL renderer string:                 Gallium 0.4 on AMD RV710
OpenGL version string:                  OpenGL ES 2.0 Mesa 7.10
OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.0
GLSL version:                           1.0.16
Mesa version:                           7.10
X server version:                       1.9.5
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
kwin(17037) KWin::Workspace::setupCompositing: Initializing OpenGL compositing

[mgraesslin]

OK, maybe a dumb question but if the blacklist was removed some weeks ago and the recent mesa change broke a whitelist did the whitelist replace the blacklist ?

The whitelist which broke is for enabling direct rendering. The blacklist was for disabling features which broke on some driver/hardware combo.

[bridgman]

I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

The problem was that the discussion started as blog posts, which then triggered posts on other blogs, and spread around the internet that way (there were some third- and fourth-order discussions going on). The responses mostly followed the blog posts, unfortunately.

The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.

I didn't actually see "lack of understanding" as much as "unfortunate timing".

No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)

The discussion at the time suggested that only one driver was really considered working (NVidia proprietary) which would make the whitelist pretty simple. If there was a much larger list of working drivers then I agree that would make a whitelist more difficult, but that was not the messaging at the time (it was more along the lines of "the NVidia proprietary driver works and the OpenGL 2.x standards have been out for years so if it's not working on your drivers you guys must all be stupid ).

I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.

Seems reasonable.

As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.

OK, maybe a dumb question but if the blacklist was removed some weeks ago and the recent mesa change broke a whitelist did the whitelist replace the blacklist ?

[mgraesslin]

There were a lot of options discussed - it's hard to believe that none of them were feasible :

I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.

No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

First lets have a short look at the time frame:

• April 26th: Soft Feature Freeze for 4.5
• May 11th: Hard Feature Freeze and Soft Message Freeze
• May 26th: Release Beta 1
• June 9th: Release Beta 2
• June 17th: Mesa 7.8.2 BOOM - KWin starts to break
• June 22nd: Hard Message Freeze
• June 23rd: RC1 release

At the time we noticed we had severe problems with Mesa 7.8.2 our release was basically done. For us it is important to provide users the best possible user experience and to not release a broken release. This implies to workaround issues in drivers rather than to wait for fixes. Our users don't care whether it's the driver or the desktop which is broken. Our users want a working desktop.

- use the GL 1.5-ish code paths by default (which worked on all drivers) and make GL 2.x code paths a user option

User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

- use a (DX9-ish) subset of GL 2.x which could be supported on all of the hardware where that level of support was exposed

All our code scales down. We added better checks to 4.6 - for 4.5 it was too late due to feature freeze.

- use a small set of functional tests rather than blacklisting, discussed with driver devs to use what "should work", driver devs would prioritize anything that crashed those tests

Again: feature freeze. As a side remark, KWin had had one functional test in it's code base which started to break with Mesa in 4.5. Considering that we are not so interested in functional tests any more ;-) I am not fond at all of feature tests as that will delay the overall startup of the KDE Plasma Workspaces.

- work with the driver devs to identify a set of extensions/levels which could be used to identify drivers that would work well with KWin

This would of course have helped for 4.6, but not for 4.5. I hope I explained in my mail that at that time I was very time constrained and our priority was making KWin work with the current driver and not the next driver.

- in the worst case, whitelist for GL 2.x code paths rather than blacklist

We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)

I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.

As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.