Posted on

Optimization in KWin 4.6

Apart from the scripting interface KWin will not ship any major new feature in 4.6. Most of the work I did for 4.6 was to improve the overall performance of our compositing engine. One of the first improvements I added was for the text and icon overlays in our effects. Now the texture and geometry is always cached and Texture from Pixmap (TFP) is used instead of costly QPixmap/QImage conversations.

Another area which saw great improvements are effects which transform one window. These effects used to cause the whole screen to repaint even if only a small region changed. Most prominent visible is this with the Show Paint effect enabled and for example Sliding Popups or Wobbly Windows. Those effects are now repainting only the changed area which is a great improvement, especially considering that there is less blurring involved. The changes seem to make a difference as developers running trunk asked in #kwin if we changed something in Wobbly Windows. Of course not each effect does benefit from this change. It is an ongoing issue and one effect after another has to be improved.

Another area for optimization is not directly in the compositing engine but more in making use of the advantages of compositing in general. 4.6 will include a new effect to render the startup notification ("bouncing cursor"). The current way involves resizing and shaping a window and moving this window. With compositing enabled this can be a costly operation (for me the performance was so bad, that I disabled the notification completely). The new effect does the same animation as the legacy system without using a window at all. It is just a texture rendered on the screen. This means the whole window transformations are not needed and also the costly TFP operations are not required. Another nice side-effect is that the icon can now use an alpha channel – the old animation transformed each icon to a RGB-only icon. If compositing is not used the system will fall back to the legacy rendering which is btw. not part of KWin.

During the last week I worked on another optimization for our Lanczos filter. Especially in Present Windows the filter was causing some performance regressions. Highlighting one of the windows causes the complete screen to repaint (optimization opportunities see above) which caused a new Lanczos filtering for each visible window. The highlighting animation lasts for something like 200 msec with constant fullscreen repaints. It is obvious why this caused a performance regression. My changes cache each generated texture and use this whenever a repaint without change of content is required. So the highlighting does not require a recreation of the texture (the highlighting is added in a later step). So Present Windows in 4.6 will have the performance as it used to be in 4.4 with the improved thumbnails from 4.5. Of course the cache is useful to all places where the Lanczos sampling is used – be it Box Switch or Taskbar Thumbnails.

I hope that with this change the blacklist is no longer required for performance problems but can be used for driver problems only as intended. Also this allows to integrate the Lanczos improved thumbnails in more effects – e.g. Desktop Grid as in the image.

Improving the performance is of course an ongoing issue and there are still some areas where we can get some clever caching in place. For example blur might be a good candidate for improvements. But this is topic for a blog post "Optimization in KWin 4.7".

=-=-=-=-=
Powered by Blogilo

Posted on

KWin at UDS

The last week I had the opportunity to attend the Ubuntu Developer Summit in Orlando, Florida. I want to thank Canonical for making this possible. UDS is quite different from other Open Source conferences I have been so far (Akademy, Desktop Summit, Plasma sprints). UDS is really centered about the idea to get things done. The schedule is very exhausting with several one hour sessions per day and up to 14 parallel tracks.

Like Desktop Summit UDS offers the possibility to talk with developers from the "other side". But in addition to the GNOME folks you also have the X, kernel, etc. people around. This is especially from a KWin point of view a real advantage.

I am really glad that I had the opportunity to talk to the people working on Unity. This new desktop shell is a great challenge but also a great opportunity for the free desktops. There is lots to collaborate on and I noticed that Canonical wants to collaborate and is thankful that we as an upstream are collaborative – for example with the Status Notifier/Indicators. This brings me to KWin. As you might have heard of Unity will become the primary desktop shell in Ubuntu 11.04 with Compiz instead of Mutter as the Compositing Manager. This change (which I was aware of for quite some time) is in my opinion the right decision and like Sam I am glad to see development effort in Compiz increase and not Compiz becoming obsoleted by us and GNOME Shell. For us as KWin this brings great opportunities. Canonical is also aware of the driver regressions we run into our latest release. The hardware requirements for Unity are slightly higher than ours. Unity requires Framebuffer Objects (FBO), which we use in various effects (e.g. Blur). Canonical will set up a great testing environment to ensure that the quality of drivers does not regress. With KWin having a similar set of requirements chances are very good that we can profit from that effort. So at least for Kubuntu I am quite confident that 11.04 will be a great release for our users.

Apart from the collaboration on driver requirements the switch to Compiz will hopefully benefit us further. Canonical is really interested in improving the already good collaboration between KWin and Compiz further. Getting us exchanging more ideas and code will help us both and provide our user bases the best window management and compositing experience. The ideas of Canonical are very interesting and I am looking forward to see them happen. So great times are hopefully before us 🙂

One of the first areas we are going to collaborate is the future of window decorations. The idea of client side decorations is dead and we will work on improving what has be started at KDE with allowing the decorations to paint the background of the windows. This will hopefully result in a new theme specification which is finally worked out by the major window managers and cross desktop.

Apart from KWin/Unity I attended quite some Kubuntu sessions and I hope I could give some ideas and feedback to the developers. There is great stuff going on, but I keep that to other bloggers 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

KWin Bug Day am Sonntag 10.10.10

Wie gerade auf dem Dot angekündigt, wird morgen der erste KWin Bug Day sein. Es geht darum die immer größer werdende Zahl an offenen Bugs zu ordnen. Dazu gehört Bugs zu reproduzieren oder auch zu überprüfen ob Bugs überhaupt noch gültig sind, oder ob wir sie schon längst behoben haben. Hierzu braucht es überhaupt keine Programmierkenntnisse, eine aktuelle KWin Version ist völlig ausreichend. Daher meine Empfehlung: Morgen Update auf Kubuntu 10.10 und danach ab 13 Uhr im #kde-bugs IRC Channel auf FreeNode vorbeischauen und mithelfen.

Schon mal im Voraus vielen Dank an alle, die mithelfen 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

Neustart des KDE Commit-Digest braucht Helfer

Bis zum Februar 2009 gab es eine wöchentliche Zusammenfassung aller KDE Commits im Commit-Digest. Danach hat Danny Allen die Arbeit alleine nicht mehr stemmen können. Mittlerweile arbeitet er daran es neu zu starten mit der Hilfe von vielen Freiwilligen und hat dazu eine Webplattform aufgebaut. Nun braucht es Freiwillige, die mitarbeiten die Commits durchzugehen und wichtige Commits herauszuheben. Mehr Infos dazu in Dannys Blog.

Der Commit-Digest ist ein unglaublich wichtiges Instrument, da er die KDE Entwicklung noch transparenter macht. Die Anwender können dadurch gut die Entwicklung verfolgen und sehen woran die Entwickler arbeiten. Ich erinnere mich daran, dass ich wöchentlich den Digest verfolgte als es zum KDE 4.0 Release ging und der Digest war somit ein wichtiger Faktor, dass ich überhaupt mit der Entwicklung begonnen habe.

Also hier nun auch von mir der Aufruf: helft bitte mit den Commit-Digest wieder mit Leben zu füllen! Danke.

=-=-=-=-=
Powered by Blogilo

Posted on

Die Hoffnung stirbt zuletzt – oder wie man versucht auf freie Treiber umzusteigen

Wie einige vielleicht wissen, haben wir in KDE Plasma Workspaces 4.5 leichte Probleme mit den freien Grafikkartentreiber. Die einzige Möglichkeit so etwas für die Zukunft zu verhindern, ist dass wir mehr testen und größere Änderungen am Rendering Stack nur zu Beginn des Release Zyklus implementieren, so dass diese etwa 6 bis 7 Monate getestet werden können. Ich selbst nutzte nun KWin von trunk und nicht mehr von branch um mögliche Probleme möglichst schnell zu bemerken. Dies kann man aber nur wenn man auch die freien Treiber benutzt. Und hier wird es problematisch:

Bis vor Kurzem war mein Hauptsystem ein Notebook mit einer NVIDIA 9600M. Eine andere Grafikkarte einzubauen ist durch die Tatsache "Notebook" schon mal nicht möglich. Man hat also die Wahl zwischen dem proprietären Treiber und Nouveau. Als Distribution setze ich Debian Testing aka Squeeze ein. Die Version von Nouveau in testing unterstützt nur 2D was den Ansprüchen eines Entwicklers am OpenGL Compositing Bereich nicht genügt. Da Squueze bereits Feature Frozen ist, wird sich da auf absehbare Zeit nichts ändern. Jedoch existiert auch eine neuere Version in experimental, welche auch die neuste Kernel Version aus experimental benötigt. Damit bekomme ich OpenGL zum Laufen, sogar GLSL funktioniert recht gut, jedoch ist der Treiber für den Einsatz auf einem Notebook noch ungeeignet, da die Stromsparmechanismen noch nicht vollständig implementiert sind. Die Akkulaufzeit ist deutlich schlechter und Suspend to RAM ist bei mir gescheitert. Somit leider wieder zurück zum NVIDIA Treiber.

Seit ein paar Wochen habe ich ein neues System mit einer ATI R710 Grafikkarte, die ich vor etwa zwei Jahren gekauft hatte um neben NVIDIA auch mit Mesa und fglrx testen zu können. Leider hat sich seit damals die Situation nicht wirklich verbessert – zumindest unter Debian Testing. Mit dem freien radeon Treiber erreiche ich maximal einen Kernel oops beim Starten vom X Server – ein wirklich schönes Bild man startet zum ersten Mal und sieht nur einen schwarzen Bildschirm und kann auch nicht auf ein Terminal wechseln. Mit den Treibern und Kernel aus X sieht es etwas besser aus: X startet zwar immer noch nicht aber es gibt zumindest keinen oops, aber in dmesg findet man einen Crash Trace. Nun ist Testing natürlich mit Mesa 7.7 etwas alt (meine Vermutung warum ich die Probleme in 4.5 mit dem Intel System das mir zum Testen zur Verfügung steht nicht reproduzieren kann, ist dass Testing zu alt ist) und man könnte Mesa von Hand bauen. Wenn man KDE baut, sollte man das wohl auch schaffen. Hmm Wiki etwas veraltet: "Under some newer distributions, like Ubuntu 7.04". Mit längerem Suchen findet man dann doch eine Anleitung die recht aktuell aussieht, jedoch möchte ich einfach nicht Dateien unter /usr austauschen und X zu erklären, wo es mesa findet will irgendwie nicht – zumindest ändert sich am Ergebnis nichts: kein X Server.

Nun gibt es ja nicht nur einen, sondern zwei freie Treiber: radeonhd. Diesen könnte man auch mal ausprobieren, also installiert, xorg.conf angepasst und kdm neugestartet und wieder nichts. Also Rechner komplett neustarten und siehe da, es gibt Verbesserungen: X startet zwar nicht, aber man fällt zumindest auf ein Terminal zurück. Mit Hilfe einer größeren Suchmaschine war das Problem schnell gefunden: radeonhd funktioniert nicht mit Kernel Mode Setting (KMS). Nur wie deaktivieren? Die Suchmaschine sagt was von "nomodeset" in grub übergeben, jedoch sieht man beim Hochfahren sehr schön, dass KMS aktiviert wird. Tja unter Debian wird KMS dynamisch aktiviert, wenn der radeon Treiber geladen wird. Man muss also die Datei /etc/modprobe.d/radeon-kms.conf anpassen (völlig offensichtlich, oder?), danach startet auch X und siehe da, es wurde Farbe. Nur mein primärer Bildschirm hatte leicht verzehrte Farben. Login und sogar Desktopeffekte sind aktiv und nach Spielen mit XRandR sind die Bildschirme korrekt eingerichtet, nur wird der falsche Bildschirm als primär angesehen – aber OK. Leider ist die OpenGL Version nur 1.5 und da KMS ja nicht unterstützt ist, funktionieren Funktionen wie Shader (ARB und GLSL) und Framebuffer Objects leider nicht. Keine guten Voraussetzungen für die KWin Entwicklung mit diesem Treiber. Damit hätte ich noch arbeiten können, jedoch gab es leichte Probleme nach dem Suspend Test: der größere der beiden Bildschirme wollte einfach nicht mehr. Egal was ich in XRandR eingestellt hatte, ließ er sich nicht dazu überreden etwas anzuzeigen. Dieser Fehler hat sogar erfolgreich einen Neustart von X überlebt.

Tja da steh ich nun ich armer Tor und bin so klug als wie zuvor. Auf beiden Systemen läuft wieder der proprietäre BLOB. In der Gesmatheit meiner Feature Anforderungen sind die proprietären Treiber für mich weiterhin die einzige Wahl, kurz zusammengefasst gibt es folgende Showstopper:

  • Nouveau überlebt Suspend auf Notebok nicht
  • Radeon endet in Kernel oops
  • Radeonhd mag meinen Full-HD Bildschirm nicht

Nun gäbe es noch eine Möglichkeit das ganze Problem auf die Distribution zu schieben: laut der Meinung einiger Leute im Phoronix Forum sei das ja der Hauptgrund für die Probleme in 4.5, da ich die falsche Distribution nutze. Jedoch habe ich in regelmäßigen Abständen die Ati Karte mit verschiedenen Distributionen ohne Erfolg getestet. Zuletzt auch Kubuntu Maverick Beta, diese sollte ja das neueste mitbringen, was es so aktuell gibt. Und ja, X startet, jedoch startet X sich auch neu, wenn man Desktop Effekte aktiviert. Also kann ich auch bei einer Distribution bleiben, welche ich kenne und schätze. Rolling Release ist für mich undenkbar, da Treiber Probleme implizieren, dass ich nicht mehr an KWin entwickeln kann. Ein gewisses Grad an Stabilität benötige ich halt doch

=-=-=-=-=
Powered by Blogilo

Posted on

Demystifying OpenGL Desktop Effects

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

Posted on

Driver dilemma in KDE workspaces 4.5

KDE is currently blamed for errors in external components: the graphic drivers. I am lately reading quite some crap (e.g. on it news today) that we KWin devs knew about problems in the drivers and shipped 4.5 nevertheless with changes enabled which trigger the driver bugs. That is of course not true.

First let’s have a look on the checks KWin performs in desktop effects:

  • Desktop effects are only enabled if the driver is on a whitelist of known working drivers
  • The capabilities of the driver are verified by an external helper application
  • If KWin crashes while initializing the driver (you have to access OpenGL to know if OpenGL is supported), KWin will not try to enable desktop effects again
  • If KWin crashes twice in a row (not during driver initialization), desktop effects get disabled to prevent further crashes
  • Each effect verifies the required capabilities by testing against the supported OpenGL extensions. So for example the blur effect requires GLSL with fragment shaders and frambebuffer objects. Only if the driver supports these extensions the effect gets activated. If a driver does not support the extension it should not claim support for it. The extensions are the only reliable information we have from the graphics driver.
  • We have a test in 4.5.0 (removed in 4.5.1 – reason given below) that ensures that framebuffer objects are working in case the driver claims incorrectly support for the extension
  • We have a dynamic blacklist that disables effects which require an extension the driver claims incorrectly support for it
  • KWin has a selfcheck to test if desktop effects work at all, if not they are disabled
  • KWin has a runtime performance check. If the performance is bad, desktop effects are disabled on the fly

The most important fact in this list is, that KWin does not enable any functionality the driver does not claim support for it! Furthermore we have several runtime checks to ensure that our users have a smooth experience even if the drivers are claiming support for extensions they do not support. Many of these checks have been added in the 4.4 and 4.5 release cycle.

Now that I have explained all our checks we did to ensure a smooth user experience, I want to explain how it could happen that there are regressions in 4.5. In 4.5 we introduced two new features which require OpenGL Shaders: the blur effect and the lanczos filter. Both are not hard requirements. Blur effect can easily be turned off by disabling the effect and the lanczos filter is controlled by the general effect level settings which is also used for Plasma and Oxygen animations. Both new features check for the required extensions and get only activated iff the driver claims support for it. So everything should be fine, shouldn’t it?

Apparently not when it comes to the free graphics drivers (please note and remember: we do not see such problems with the proprietary NVIDIA driver!). We used to use indirect rendering for Intel drivers. In that case the driver still claims support for all the extensions which cannot work with indirect rendering, that is for example framebuffer object and shaders (NVIDIA does not support such extensions if direct rendering is not enabled). If we ask the driver if it is supported it says: "yes sure, everything is fine", till you try to use it. This caused serious problems with the blur effect. The effect checks at startup what is supported, sees that everything is supported and tells Plasma that blur is available. Plasma uses therefore the blur optimized theme and then blur just does not work. We do not see the problem on initial startup or creation of the resources, such as compiling the shader, we see it only during the painting pass. This results in completely transparent and impossible to read windows.

Of course this is unacceptable. Disabling the blur effect by default would not have been an option as users would have enabled it and have run into this driver issue. So we had to check it. I added a test to try to get a framebuffer object during initialization. If it fails KWin does not enable the blur effect. Fixed the issue for all Intel users. But this caused other problems, so for some drivers when using a "strange" resolution (e.g. multi screen) compositing cannot be enabled at all. We still do not know what is happening there and cannot debug due to missing hardware. This check had been removed in 4.5.1 again as it was causing problems.

We could drop the check because we had found a better solution: the free drivers also support direct rendering and so we activated it. Of course only when our test application running outside of KWin verifies that direct rendering works. So everything is fine: blur works and no more problems.

Well not if we have the graphics stack in X11. We saw some new problems appearing out of nowhere. The Intel driver seems to be able to support shaders for hardware that is not programmable, that means: software emulation. That’s a rather stupid idea. You use shaders because you want to have the power of the GPU, not the slow general purpose CPU. A GPU (even a bad one) is magnitudes faster in image processing tasks than a CPU and is highly parallel. We also saw issues like windows being rendered upside-down (this issue had already been fixed in mesa git master before we were aware of this problem). This issue hit for example all users of radeon driver in OpenSUSE 11.3. A very nice problem seems to exist for Intel drivers. Given the bug reports we can only conclude that the driver is not able to handle more than one GL context at the same time or started shortly after each other.

When I see these problems I think: "it looks like we are the first one to actually use the drivers". And then I start to think about it and realize: yes we are. Compiz does not yet use GLSL (Compiz’s Blur effect is written in GPU assembler. KWin blur also has an assembler part which is a fallback in case the driver does not claim support for GLSL), so we are probably the first ones to use these driver capabilities in a real world application. Now why are we using something that new? Because it is quite old: this is OpenGL 2 we are speaking about, a standard specified in 2004! Btw. Microsoft made use of blur by default when they introduced Vista, that was in 2006. So we are talking about functionality specified since six years and used by default by our competition for four years. Oh and please note: the same hardware runs fine in Vista or Windows 7 – at least that’s what we can see from the bug reports.

As those new problems appeared I worked on another solution. Just in case that you didn’t know: I don’t have such hardware, I could not reproduce any of these issues. It’s also important to know that we need special combinations of hardware, driver version, mesa version, X server version, kernel version and distribution to have either failed or working setups. So there are easily thousands of possible combinations. Testing everything is just impossible. We introduced a blacklist to workaround the most prominent issues concerning blur and lanczos filter. Lanczos is more important as it cannot be disabled as easy as blur. The blacklist is implemented in a way so that it can easily be extended. I tried to cloud source the problem of finding all broken drivers. This did not work out for 4.5 and for 4.5.1 I just did not find the time to write a new kconfig update script. I hope to get an update ready for 4.5.2.

So far I discussed about the problems we saw and new about before 4.5.0. Given that we introduced several additional checks to ensure a good and smooth setup and all the work we put into ensuring a smooth user experience, I am rather disappointed being blamed for what we did. In my opinion we did everything that is possible. The only other option would have been to withdraw blur completely (as explained: disabling by default would not have solved the problem). This would be rather bad given that we have a large user base which wants blur and have a working driver!

An issue we were not aware of before the release (bug was opened during beta phase, but not confirmed before the release) are freezes when changing any KWin related settings. In fact it is not a freeze. You can still use Alt+Shift+F12 to disable compositing and enable it again and everything works fine. We still do not know what caused the problem, but it seems to be related to enabling direct rendering by default. Unfortunately I am unable to reproduce this problem on the only Intel based hardware I have access to. The only solution so far is to disable direct rendering in general again, but this would be a regression for all users where it is working fine (see above: it cannot be reproduced on each Intel hardware).

So we are in a situation where each of the possible ways to go, is wrong. And it is all caused by the drivers claiming support for functionality they do not support. If they would not do that, we would not have those problems. It is a rather disappointing situation. I can only repeat what is listed in the release note: use the latest drivers.

I hope this brings some light on the problems and shows that we did everything that is possible to work around the driver bugs. The issues have to be fixed in the drivers!

=-=-=-=-=
Powered by Blogilo

Posted on

Crash statistics for KWin

KWin is one of those parts of the KDE workspace which receives crash parts for all parts of the stack. We see crashes in Plasma (kind of upstream to us), Qt and most likely in the graphics drivers and X itself. My subjective feeling was that we receive more for us useless crash reports than valid ones. So I just used the bugzilla search to get some numbers for the last year (August 1st, 2009 till today). As you should not trust any statistics you haven’t faked yourself, I used the search to set some more bugs to upstream, duplicate and so on 😉

  • Reported crashes: 330
  • Still open: 31
  • Fixed: 47
  • Set to duplicate: 159 (~ 50 %)
  • Upstream bug: 44
  • Missing backtrace: 37
  • Other (waiting for info, Compiz bug, etc): 12

What’s really bad is that half of the reported crashes are duplicates. And that’s although DrKonqui finds the right reports. In most cases I just copy&paste the bug number reported as a possible duplicate (thanks a lot for this feature). Among those duplicates we have one issue during the 4.4 cycle which caused 31 duplicates and which is now on number two of crashes with most duplicates. In lead is still the crash report for Compiz’ KDE4-Window-Decorator (I said we get crashes for the complete stack including competitive window managers 😀 ).

The upstream bugs are mostly driver related bugs. The number does not reflect reality perfectly as some driver crashes are set to duplicate. So we see that we have more crashes in drivers than crashes we fixed! The open bugs contain mostly crash reports where I think that they are also not valid, e.g. crash in malloc. Most of them are also missing a way to reproduce the crash or it is clearly wrong (yes kwin backtraces can tell what you were doing 😉

Oh and we could use a bug day. Since I started to work I don’t have the time any more to search for duplicates and the number of open bugs has increased by > 60 since the 4.4 release. And yes also those are mostly duplicates. It just needs someone to filter them 🙁

=-=-=-=-=
Powered by Blogilo

Posted on

Beautiful Screenshots

This weekend I finally sat down and wrote a screenshot effect for KWin. This effect redirects the rendering of any window into an off-screen texture and saves the texture into the home directory. The advantage of this effect is that it is hooked into the normal rendering process and so we can also capture the shadow and the translucency to get beautiful screenshots. If we capture a transparent window it does not show the windows below but only the captured window with the alpha channel turned on correctly. See for example:

Translucent Konsole with Oxygen shadows

Of course the effect is not meant to replace KSnapshot. Instead I prepared a patch which allows KSnapshot to use this effect when the user selected window under mouse cursor. The screenshot shown above was captured with this change to KSnapshot. I hope I will be able to merge this change, soon 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

Next generation OpenGL compositing in 4.6

In this blog post I want to give an overview on what I am planning and working on for KWin in KDE SC 4.6. The big topic for 4.6 is performance – in 4.5 we introduced the blur effect and our designers want to extend the usage of blur to all windows. This is currently not yet recommendable (yes there are widget styles on kde-look which offer this function, but KWin is not ready for it!), so we have to work on it.

In general there are three topics I will address in the next cycle:

  1. Mobile edition: port compositing stack to OpenGL ES 1.1 and/or 2.0
  2. Improve performance: render less, render faster and more frames per seconds during animations
  3. Stabilize the effect ABI to be able to provide BC latest in 4.7 (if it makes sense)

These three topics are very much related to each other. For a mobile port we need to improve the performance and port to OpenGL ES. This requires to cleanup the rendering code which gives us a more modern rendering code resulting (in theory (I do not trust drivers any more)) in better performance (render less and faster). As part of this I am aiming to use forward-compatible OpenGL Shaders by default for rendering. Yesterday OpenGL 4.1 was released and it would be nice to be able to use OpenGL 2 functionality in a real world application on Linux. So this is an urge to the driver developers: please get your drivers ready for 4.6 – we will stress them. In a next step I want to go to OpenGL 3 in 4.7, but the free drivers do not yet support this generation. (That’s perhaps a point to work together with Compiz developers)

Thanks to the improvements on the rendering stack our API gets into a state where it makes sense to think about guaranteeing BC. Currently we do not and break the ABI in each cycle several times (up to now I broke BC in trunk more than five times). Our API does not yet use d-pointers and we have many pure virtual classes, which will make it difficult. But the API itself has not changed much during the last cycles, so it’s pretty stable already. With 4.6 the compositing stack will have been used three years, with two years enabled by default, so it’s really time to think about it. But this is just an idea I have and is not yet discussed with other KWin developers and it will require lots of boring work.

So where are we? I started with improving the rendering code of our Plasma styled frames and moved the rendering code into the concrete implementations for XRender and OpenGL. That made it possible to get something like the following screenshot:

Boxswitch with blurred background

Also the rendering code is improved. Instead of recreating the icons in each rendered frame by doing a QPixmap -> QImage -> GLTexture conversation, the icon texture is reused and generated using Texture From Pixmap (TFP) as used for our window pixmaps (there are still some effects forcing a recreating in each frame, but this will soon be fixed). For passing the geometry to the GPU a vertex buffer object (VBO) is used instead of the very, very old glBegin/glEnd. This VBO is also cached, so each geometry is only created once and passed to the GPU once. My abstraction for VBO is able to fall back to legacy rendering if VBOs are not available (very unlikely), which gives us just one high level API call to do legacy, normal and modern (forward compatible) rendering. The old methods are deprecated although still used by the window rendering (this requires some more useful changes as they currently stream the vertices in each frame). For rendering the effect frames (and all other textures) triangles are now used instead of quads (unavailable on ES and OpenGL 3 forward compatible profiles).

And what next? We still have many things to improve. Especially window rendering has to be changed to cache the geometries (when it makes sense) and the clip regions. The clip regions are one of the reasons why I want to switch to Shaders (other reasons are Nuno’s wishes for effects – if you want to work on awesome effects get in touch with one of us). The API still needs some more cleanup and our compositing stack has to be split into parts for GLX and EGL. Nevertheless I think the API is already in a state where I think of daring to compile KWin effect library this weekend on Maemo to see what breaks (effects would not yet compile).

=-=-=-=-=
Powered by Blogilo