My last blog post about the driver situation in the KDE Plasma Workspaces in version 4.5 caused quite some discussion. This is great and really required. But it also showed that there are quite some incorrect information about the current and future OpenGL compositing being spread. With this post I want to address some of the wrong assumptions I read, so that they won’t be spread any further and causing grieve to both the KWin developers and the driver developers.
1. The Plasma Workspaces require at least OpenGL 2:
Nothing changed: KWin still supports no compositing, XRender compositing and OpenGL compositing. Compositing is still an optional feature (but enabled by default if feasible) and that won’t change in the next years. Given the experience we have with enabling compositing by default it would be irresponsible in my opinion to require OpenGL for desktop computing. Being able to disable effects on the fly is an important and often used feature. The minimum OpenGL requirement is somewhere between OpenGL 1.1 and 1.3 and this has not changed since our first compositing release 4.0. OpenGL 2 features are only used for further optional features in 4.5, which are only enabled if the graphics driver supports it. In case of blur effect there is no requirement to OpenGL 2 at all as it only requires extensions already available for OpenGL 1.x.
2. KWin uses extensions unsupported by free drivers in 4.5:
In 4.5 we added two new optional features which require framebuffer objects (FBO) and GLSL shaders (lanczos) or framebuffer objects and GLSL shaders or ARB shaders (blur). Both are no new optional requirements. Already in 4.0 we shipped several optional effects which required GLSL (invert, blur, sharpen, looking glass and explosion) and framebuffer objects (blur, sharpen, looking glass). The first GLSL based effect was imported to SVN in March 2007, so three and a half years ago. In 4.2 we added two more optional effects using GLSL: sphere and cylinder and in 4.3 we added an optional FBO requirement to the logout effect (which is enabled by default). This one had been committed in February 2009, so 1.5 years ago. The funny thing is that the blur effect in 4.0 required more from the graphics driver than the blur effect we added to 4.5. At the time of 4.0 this did not cause any problems while running 4.0 with modern free drivers would result in the same breakage as we see with the 4.5 variant. In fact we already saw the external breakage in case of the logout effect. If I would use bugzilla I would be able to draw a nice graph when we added an optional effect and when it started to be broken.
3. KWin developers only care about proprietary drivers:
Both new effects have been implemented by a developer not using proprietary drivers. In fact both effects did not work with NVIDIA at the time when they were committed to trunk as we hit a bug in the proprietary driver. The lanczos filter explicitly checked in the source code if the NVIDIA driver is used and was disabled for it. So we did the same thing as we do for free drivers at that moment: we blacklisted the driver. In opposite to the blacklist for free drivers we added that to the code so the user would not have had the chance to change it and also a new driver version would not have re-enabled it (this is ensured in the blacklist solution for mesa drivers). Luckily I was able to find a workaround so that it works with NVIDIA, too. Personally I would like to test more with free drivers, but my Laptop has an NVIDIA card and my desktop has an Ati R700 card which are both unsupported with mesa drivers in the distribution of my choice.
4. KWin should not have delivered the effects enabled by default or at all:
The effects are optional and do not get enabled if the driver does not support the required extensions. In case that the required extension is supported but does not work the protection mechanism does not work (and I cannot think of any other mechanism to make that work with all drivers). This would also be the case if we would not have enabled the effects by default. So I do not see the advantage by disabling them. Not delivering the effects at all would be unfair to the users who can use the effects without problems (both mesa users and proprietary driver users) and also to the developers working on the effects. Last but not least we would have had to remove all the effects listed in section 2, because they require the same optional requirements.
5. KWin developers did not communicate with the Mesa developers:
More communication is always a good thing and it is true that there is hardly any communication. But we do not live in a perfect world and there are many reasons for bad communication and non-existing communication always requires two parts (btw blogging about the problems is also a form of communication ;-). For our given problems I do not see how more communication would have helped. As shown in section 2 we did not add new requirements and we have seen external breakage before (better said: now we know that it has been external breakage). I truly believe that communication between GNOME Shell developers and Mesa developers helps GNOME Shell, but GNOME Shell is in the lucky situation to develop for future driver versions. We have to live with the current driver versions. And communicating does not fix the drivers shipped by the distributions at the moment. The only recommendation we would have received would have been to not ship the effects by default – to that see section 4.
6. KWin developers do not report bugs:
I can only write for myself: I do not have a card supported by mesa drivers so I cannot report bugs. I could proxy between our users and the mesa developers but I think there are more useful ways to spent my time. Therefore we tell the users to report the bugs upstream. Oh and of course if we see the same crash being reported for the 50th time we do not tell them to report it as duplicates in the mesa bugtracker are as useless as in the kwin bugtracker.
7. KWin developers do not contribute patches:
It is difficult to develop drivers for hardware you don’t have. Furthermore I develop KWin and not drivers. I keep the development of drivers to the people competent in that area. If wine developers are competent enough to develop both wine and drivers they have all the respect I can give them. But I am not able to do it and I do not want to develop drivers.
8. It is common knowledge that hardware cannot support OpenGL 2, so you should not check for OpenGL 2:
Yes, that’s why we don’t check the version but the actually required extension. We know that the R300 chips do not support NPOT textures and that’s why we check if NPOT textures are supported before creating a texture.
9. It is common knowledge that the drivers do not fully support the extension just to be able to say they support OpenGL 2 to make broken games work:
What? Seriously? I have never read about it in all the OpenGL documentation I have read so far. I thought that’s why there is an extension system and the experience with proprietary drivers show that this is not how it is done in practice. If that is the way how it is in mesa than I am not surprised that Valve does not want to release Steam for Linux.
10. Mesa drivers need to ship the broken extensions as that makes some more games work:
That’s a little bit unexpected as that breaks the checks we have been using since 4.0. Maybe it would have been an idea to see what the important downstreams require? I am also a little bit surprised that supporting games seems to be more important than not breaking a desktop environment. Reading such arguments really hurts.
11. Because of adding blur my desktop freezes when changing KWin settings:
The change in KWin triggering a mesa bug causing the freeze is completely unrelated to blur and/or lanczos. The change makes KWin use direct rendering when it is supported and not just always enforcing indirect rendering for mesa drivers. With direct rendering enabled the desktop freezes when KWin restarts compositing and crashes with indirect rendering. Given the current state of investigation there might be a bug in KWin which triggers the mesa bug. But this is still unconfirmed and it seems that fixing the KWin bug does not solve the freezing bug in all situations. The only relation to blur is, that with indirect rendering mesa drivers are reporting support for extensions which do not work with indirect rendering which makes the complete desktop unusable. Just for the record: this does not happen with NVIDIA or fglrx driver.
12. KWin will require OpenGL 3 in 4.6:
No, please see my blog post where I wrote that I want to have OpenGL 3 support in 4.7.
13. KWin will require OpenGL 3 in 4.7:
No, this will also be only an additional feature. KWin supports multiple backends and it does not make any sense to remove a working backend which is required for all mesa users and users of graphic cards which cannot handle OpenGL 3.
14. OpenGL 3 does not add anything needed by a compositing manager:
Well let’s not talk about OpenGL 3 but about programmable pipeline (OpenGL 3) and fixed functionality (OpenGL 1). Anybody who has worked with both understands why I want to have a backend based on the programmable pipeline. I want to port KWin to OpenGL ES 2 which requires a programmable pipeline backend, so the OpenGL 3 port is more or less for free. So most of the things we need from OpenGL 3 are also supported by OpenGL 2, nevertheless OpenGL 3 gives some useful things: geometry shaders, forward compatible profiles to ease the porting, a required hardware standard and (sorry to say so) mesa does not support it. Given the experience we have made in 4.5 we would not be able to add a programmable pipeline backend without risking unease situations for our users. Therefore it is better to go for version 3 directly and lower the requirement to 2 when mesa is ready. This gives hopefully the best to both involved groups: our development is not stopped by mesa and mesa is not bothered with problems caused by our to high requirements.
15. KWin wants OpenGL 3 just for FBO:
I am able to read specifications and as shown in this summary, we have been using FBOs since 4.0.
16. KWin should add a legacy backend for Mesa:
Our backend is legacy. The forward compatible profile is not yet developed. The effects can make use of more functionality if the driver supports it.
17. KWin should use the last major OpenGL version before the one drivers announce:
So for 2.1. we would use 2.0, for 2.0 we would use 1.5 and for 1.5 we would use 1.4. Does that solve any of our problems? I doubt it as GLSL is around since 2.0, so dropping back to 2.0 does not help and FBOs are supported since 1.5? I just tried to look it up and it’s not really trivial to find information when an extension was added. So that approach just is not possible. It would also mean that we would remove functionality for users where it is working (e.g. proprietary drivers) as for code maintainability doing yet another fuzzy check on renderer would not work. Not to mention that the renderer string is not stable at all in mesa development.
To summarize the most important points of this post: KWin has not started requiring new unsupported features from the drivers, but has been using this optional requirements since our 4.0 release. Since the early days we had ensured that the optional requirements work and that KWin does not break when an optional requirement is not supported. Our code can handle two situations: supported and not supported. We now had to learn that there is a third unspecified state, which could be called "maybe supported", which we do not handle, cannot handle and won’t be able to handle. Given this historic background all claims about we should have known better or if we just had communicated better the problems would not have appeared are just wrong as our checks used to work in the past. The only possible solution would have been to remove existing functionality because the drivers upgraded their support from unsupported to maybe supported. I know that this sounds like finger-pointing and blaming others, but I just do not feel responsible for this external breakage. I completely understand that users are pissed-off and I would recommend them to talk to their distributions to ensure that when they release the next version which includes 4.5 it can be ensured that a driver is shipped that does not maybe support extensions. There are also more fun things to do than reading the bug reports by disappointed users and spending lot’s of my spare time on working around driver bugs.
Another important point from this post is: KWin will not require OpenGL 3 in future. The complete OpenGL 1 based code will not be removed. There is a lot talking about what KWin should do or should have done without checking the facts like e.g. seeing when KWin started to use GLSL.
=-=-=-=-=
Powered by Blogilo