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