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
