Problems with Desktop Effects in RC1

In 4.5 RC 1 we hit several driver bugs again. We fixed a bug which caused blur not to work, but that fix intoduced different problems with some drivers.

It is possible that effects get suspended directy on startup. In that case try disabling the blur effect! If this does not solve the issue disable direct rendering in advanced effects tab.

There are also some problems with taskbar thumbnails and present windows. The previews might be upside down, too bright or the effect might be too slow. The same problem does not appear in desktop grid! This is caused by driver bugs already fixed upstream. So please update your drivers. You can disable the filter which is used for this in the global effects level, but this will also disable animations in Plasma.

We have bugreports for all those issues. If you want to comment on them please note driver and version.

Akademy Talk: KWin Mobile

This weekend I prepared my slides for next weeks talk at Akademy about the mobile edition of KWin. I will talk about the reasons why we need a KWin mobile edition and why that will also benefit the desktop edition of KWin. For those who are not that familiar with KWin’s Compositing stack I will explain how the system works and where and how we can work on the OpenGL ES port. So that requires to illustrate the differences between the various OpenGL versions and what we have to do to get KWin’s codebase compiling on Maemo. As I have not yet started to implement the port (I think 4.5 is currently more important) I will also provide a roadmap on when we will see the pieces hitting trunk.

As my talk has a very special time slot I prepared a KWin effect on Friday evening for the talk. It’s a small but useful effect for the purpose and took me only about one hour to implement it and a nice effect to illustrate KWin’s flexibility, which is of course also part of the talk. Now I don’t want to spoil it, but I think it’s a nice and elegant solution to the problem that my talk collides with the second half of the quarterfinal Germany vs Argentina or Mexico. So please come to my talk and don’t stay in front of the TVs :-) I really love football and I can’t remember that I ever missed a German match at a World Cup. Given the way Germany played today, it will be really hard to miss the game. Who btw planned Akademy during World Cup?

I'm going to Akademy

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

Freude mit Mesa

Die freien Mesa Treiber haben in den letzten Jahren tolle und wichtige Fortschritte gemacht. Mesa ist eine der wichtigsten Komponenten des freien Desktops heutzutage. Für mich als KWin Entwickler die wichtigste Upstream Komponente – auch wenn ich selbst Mesa Treiber nicht nutze. Von Mesa ist es abhängig, ob man Compositing standardmäßig hat, ob Blur eingeschaltet wird und andere wichtige visuelle Eigenschaften. Die Treiber sind aber auch unglaublich wichtig für die Geschwindigkeit des Systems. Viele (vermutlich alle) Beschwerden über den langsamen KDE 4 Desktop lassen sich auf den Treiber zurückführen (proprietär und frei). Dies ist gerade in 4.5 sehr wichtig, weil wir Blur standardmäßig aktivieren werden, sofern der Treiber es unterstützt. Wir müssen uns also darauf verlassen können, dass die Entwickler nur das in der API anbieten, was die Hardware wirklich unterstützt.

Ich werde nun einige der Probleme beschreiben, die wir so mit den Mesa Treibern haben. Das ist aber kein Rant – ich schätze die Arbeit der Mesa Entwickler und bin ihnen sehr dankbar und freue mich darauf bald einen freien Treiber auch auf meinem System einsetzen zu können (Nouveau unter Debian unterstützt noch kein DRI).

KWin führt eine Whitelist über die Treiber, welche Compositing unterstützen. Also wir parsen den Version String, den man auch unter OpenGL Version in glxinfo findet, und ermitteln daraus den Treiber. Wäre das ganze standardisiert, dann wäre es richtig einfach. Ein vorbildliches Beispiel hier von NVIDIA:

OpenGL version string: 3.2.0 NVIDIA 195.36.24

Solange ich jetzt für KWin arbeite hat das bei NVIDIA nie Probleme verursacht. Zuerst die OpenGL Version, dann Hersteller und Treiber Information. Bei NVIDIA aktivieren wir falls die Version mindestens 173.14.12 ist. Die freien Treiber machten sich aber scheinbar einen Spaß daraus die Treiber Information immer wieder an eine andere Stelle zu schreiben und unsere Annahmen wichtige Information steht z.B. an zweiter Stelle haben dann plötzlich nicht mehr funktioniert. Das führte dann dazu, dass der Treiber nicht mehr in der Whitelist war und somit Compositing nicht mehr aktiviert wurde. Mittlerweile haben wir einen extra Parser für Mesa Treiber. (Richtig toll wäre natürlich wenn man sich auf die OpenGL Version verlassen könnte, aber das ist unmöglich, denn es gibt auch noch den Software Rasterizer und der nennt sich auch Mesa).

Im 4.4 Entwicklungszyklus hatten wir das Problem, dass einige Mesa Treiber die Anwendung in den Tod gezogen hatten, wenn man versuchte die Version zu ermitteln. Das Problem hierbei ist, dass man einen OpenGL Kontext braucht um die Version zu ermitteln und der Treiber die Anwendung in den Tod gezogen hat, wenn man einen Kontext erstellt. Das führte dann dazu dass KWin nicht mehr startete, denn wir schauen immer ob Compositing unterstützt ist. Zum Glück haben wir Logik um Crashes zu erkennen und deaktivieren dann sicherheitshalber mal Compositing. Schwieriger wurde es in den Systemsettings. Dort ist die gleiche Logik um zu schauen ob man Effekte einschalten kann mit dem Resultat, dass Systemsettings abstürzen sobald man auf "Desktop" geklickt hat. Das ganze wurde kurz vor Beta 1 zu solch einem Problem, dass wir noch schnell eine Sicherheitslösung eingebaut hatten, die etwas zu weit gegriffen hat und in der Beta mal eben Effekte für einige freie Ati Treiber deaktivierte.

In 4.5 verlangen wir den Treibern nun bedeutend mehr ab. Wir haben zwei grafische Effekte, welche programmierbare GPUs erfordern. Zum einen den neuen Blur Filter, zum anderen einen Filter um bessere Thumbnails zu erhalten. Diese Filter werden natürlich nur verwendet, wenn die Grafikkarte das auch unterstützt. Zum Glück macht es OpenGL einem einfach: es gibt Erweiterungen auf die man testen kann. Unsere neuen Filter brauchen die Erweiterungen GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_framebuffer_object und GL_ARB_shading_language_100. Wir überprüfen, ob die Erweiterungen vorhanden sind und aktivieren die Filter – so weit die Theorie. Unsere Effekte haben eine statische Methode welche aufgerufen wird bevor der Effekt geladen wird. Diese Methode führt die Überprüfung aus und sagt "Ja, ich funktioniere" oder "Nein, ich funktioniere nicht". Wenn Blur meint, dass er funktioniert, dann informiert er Plasma sofort darüber und Plasma verwendet nun bedeutend stärker transparente Hintergründe für die Popups. Nun wird so ein Popup mit starker Transparenz angezeigt, Blur Effekt springt an und versucht ein framebuffer object zu bekommen und hoppla funktioniert nicht. Somit kein Blur und das Popup ist unlesbar, weil zu transparent (siehe Bug 240956).

Das heißt also wir können nicht darauf vertrauen, dass das was der Treiber sagt was er unterstützt auch unterstützt ist. Also müssen wir manuell die Überprüfung durchführen, was natürlich unnötige Rechen- und Speicherzeit für alle Nutzer verschwendet. Es wird nun beim Start versucht ein framebuffer object der richtigen Größe zu erstellen und nur wenn das funktioniert wird Blur aktiviert. Gut Blur ist nun deaktiviert, Plasma verwendet nicht zu transparente Hintergründe – Problem gelöst.

Naja nicht wirklich: die Grafikkarte behauptet ja, dass Blur funktioniert also muss es machbar sein. Die Erklärung liegt im direkten und indirekten Rendering. Die benötigten Erweiterungen stehen nur bei direktem Rendering zur Verfügung. Wir verwenden für Mesa Treiber jedoch indirektes Rendering, d.h. alle OpenGL Befehle werden zuerst an den X Server übermittelt und von diesem an die Grafikkarte weitergereicht. Also unser oben beschriebenes Problem liegt darin, dass der Treiber behauptet Erweiterungen zu unterstützen welche nur mit einem direct rendering Kontext verfügbar sind.

Also brauchen wir einen direct rendering context. Wir haben auch Code, der ermittelt ob wir einen direct rendering context verwenden können. Dieser überprüft auf die glX Version. Wir brauchen die Funktion glXCreatePixmap(), welche seit glX 1.3 verfügbar ist. Also alles unter 1.3 kann kein direct rendering. Naja stimmt nicht ganz über eine Extension ist das auch in früheren Versionen verfügbar und Mesa unterstützt die. Also Code geändert und auf die Extension überprüft und nun gibt’s auch direktes Rendern für Intel Karten und somit Blur. Mission erfüllt: glückliche Anwender.

Schön wärs. Nun haben wir direktes Rendern, aber es gibt Karten, die sind einfach zu alt für Blur. Ergebnis: KWin startet und schaltet Compositing sofort aus (siehe Bug 242113). Der Treiber unterstützt OpenGL Shading Language für Grafikkarten, die das ganz bestimmt nicht können. Nun sind wir also kurz vor den RCs und bei vielen Nutzern werden die Effekte nicht mehr funktionieren, weil der Treiber etwas unterstützt, was die Hardware nicht kann. Wir könnten nun einfach direktes rendern wieder ausschalten für diese Treiber, aber das würde auch Effekte zerstören, die keine Shader brauchen, aber direktes Rendern – zum Beispiel den Logout Effekt.

Auch wenn ich nun viel über Intel geschrieben habe, gibt es auch Probleme mit anderen Mesa Treibern. Z.B. mit dem Treiber für Ati R600 Chips im kommenden OpenSUSE 11.3. Bei diesem werden alle Thumbnails und Fenster in Present Windows auf dem Kopf stehen (siehe Bug 240354). Das Problem ist im Treiber Entwicklungszweig bereits behoben und wir wollten das daher eigentlich ignorieren – bis ich gestern openSUSE auf meinem Zweitrechner mit R600 installierte…

Nun kann ich mir Gedanken dazu machen, wie wir am Besten eine Blacklist erstellen, die einfach von uns und den Distributionen erweitert werden kann. Vor allem wie man Treiber wieder von der Blacklist herunterbekommt ohne mit jeder neuen Treiberversion die Blacklist aktualisieren zu müssen. Whitelist funktioniert nicht – haben wir ja schon, wissen wir dass es eine schlechte Idee ist. Und ich glaube wir verwenden eine Whitelist, weil Blacklist bei Compiz zu Problemen geführt hatte…

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