Performance Tests

Das Problem mit Bilder pro Sekunde

Das normale Vorgehen um die Performance einer Grafikanwendung zu vergleichen ist die Anzahl der gerenderten Bilder pro Sekunde zu messen. Dies ist jedoch im Fall von KWin keine Option aus mehreren Gründen. KWin ist optimiert so wenig wie möglich zu zeichnen. Performance ist das höchste Ziel und jedes überflüssige Zeichnen verschwendet CPU und GPU Zyklen. Daher wird nur gezeichnet wenn sich ein Fensterinhalt ändert oder ein Effekt einen weiteren Frame anfordert. Ansonsten ist KWin in einem Schlafzustand. Die Anzahl der Bilder pro Sekunde wäre also sehr niedrig und nicht vergleichbar, da das Aufwachen durch Änderungen des Fensterinhalts nichtdeterministisch ist.

Ein weiteres Problem liegt darin, dass KWin sich - wenn möglich - zur Frequenz des Bildschirms synchroniziert. Die maximale Anzahl der Bilder pro Sekunde ist somit beschränkt und liegt je nach Bildschirm zwischen 50 und 100. Selbst sehr schwache Hardware wird diese Anzahl erreichen und somit entfällt hier die Vergleichsmöglichkeit.

Nun gäbe es die Möglichkeit die Synchronization auszuschalten, womit KWin so oft zeichnen würde wie möglich. Aber nun gibt es das Problem wie man die Bilder pro Sekunde messen kann. KWin schreibt die Anzahl der Bilder pro Sekunde nicht nach stdout, sondern bietet einen zusätzlichen Effekt an. Dieser kann aber auf Grund willkürlicher Festlegung des Entwicklers maximal 100 Bilder pro Sekunde anzeigen. Der Effekt ist als Entwicklungswerkzeug gedacht und erfüllt dafür mit dieser Beschränkung seinen Zweck: 100 Bilder pro Sekunde ist gleichbedeutend mit alles funktioniert problemlos. Für die genaue und vergleichbare Messung der Bilder pro Sekunde ist dies nicht geeignet.

KWin FPS Effekt
KWin FPS Effekt

Es ist natürlich möglich den Quellcode anzupassen und eine höhere maximale Anzahl von Bildern pro Sekunde zu erlauben. Diese müsste aber ebenfalls willkürlich festgelegt sein und der Effekt würde verstärkt mit sich selbst beschäftigen und das komplette Rendering ausbremsen. Der Messvorgang würde also die Messung verfälschen. Eine weitere Verfälschung würde dadurch entstehen, dass der Effekt in jedem Frame einen repaint auslöst, wenn er aktiviert ist. KWin kann also nie in den Schlafzustand versetzt werden.

Messen der CPU Last

Ein besserer Vergleichswert für den Spezialfall der KWin Effekte ist das Messen der CPU Last. KWin versucht so wenig wie möglich zu zeichnen und soll vom Anwender nicht bemerkt werden. Es ist daher wichtig, dass die CPU Last niemals zu groß wird. Dazu kommt, dass KWins Funktionalitätsprüfungen die Effekte automatisch ausschalten, wenn die CPU Last zu hoch wird. Wäre die CPU Last des Würfels zu hoch, so würde Compositing ausgeschaltet.

Die CPU Last während der Ausführung der Effekte wird hauptsächlich von der Qualität des Grafikkartentreibers bestimmt. Hier gibt es leider je nach Hersteller große Unterschiede. Entscheidend ist zum Beispiel die Unterstützung von "direct rendering". Dies bedeutet, dass der OpenGL Treiber direkt rendert ohne den Umweg über den XServer. Der proprietäre Ati Treiber "fglrx" unterstützt aktuell kein direktes rendern für einen Compositing Manager. Das schnelle DRI und der Nachfolger DRI2 werden somit nicht genutzt und es können keine Shader eingesetzt werden. Sämtlichen OpenSource Treibern fehlt ebenfalls die Unterstützung von Shadern, da OpenGL 2 noch nicht implementiert ist.

KWin Schnee Effekt
Schnee Effekt als Vergleichsfaktor

Bei dem Vergleichen der CPU Last muss berücksichtigt werden, dass der eigentliche Compositing Vorgang auch Last verursacht. Durch die Verkettung der Effekte wird jedes Fenster von jedem Effekt bearbeitet. Dazu kommt der - je nach Treiber - aufwändige Texture from Pixmap Vorgang. Abschließend muss das Frame gerendert werden. Die Last welche durch diesen Vorgang erzeugt wird, soll natürlich bei der Betrachtung der Messung ignoriert werden. Mit dem Schnee Effekt besitzt KWin einen Effekt welcher diese Belastung sehr genau ermittelt. Der Schnee Effekt verursacht ununterbrochene Repaints des gesamten Bildschirms, zeichnet jedoch nur eine kleine Textur auf mehrere Quads. Der Zeichenvorgang ist dabei - sofern von der Hardware unterstützt - komplett in einen Shader ausgelagert und auch ohne Shader weitestgehend optimiert. Es kann also davon ausgegangen werden, dass die verbleibende Last, welche durch das Zeichnen der Schneeflocken ausgelöst wird, im Vergleich zum Compositing Vorgang vernachlässigbar klein ist.

Durchführen der Messung

Die CPU Last wurde mit dem von KDE bereitgestellten Systemmonitor Plasmoid gemessen. Pro 20 % ist eine Linie im Diagramm eingezeichnet. Bei der Messung wurde zunächst die Idle Last bestimmt, d.h. die CPU Last die das System hat, wenn keine Anwendung aktiv benutzt wird und KWins Compositing sich größtenteils im Schlafzustand befindet. In den folgenden Diagrammen wird diese Idle Last als rote Linie gekennzeichnet.

Um die Last des Compositing Vorgangs zu messen wurde der Schnee Effekt einige Zeit aktiviert. Hierbei ist jedoch zu erwähnen, dass nur mit NVIDIA Grafikkarten der Shader eingesetzt wurde. Bei allen anderen im Test verwendeten Grafikkarten wurde die nicht so stark optimierte Variante ohne Shader verwendet. Die Last des Schnee Effekts als Vergleichsfaktor ist in den folgenden Diagrammen als blaue Linie eingezeichnet.

Die Messung der Last durch den Würfel wurde jeweils zwei mal durchgeführt. Einmal ohne weitere Fenster auf dem Bildschirm (grüne Markierung), einmal mit einem zusätzlichen Fenster, welches um eine Bildschirmecke gelegt ist (orange Markierung). Der Würfel wurde gestart und mehrmals rotiert. Dazwischen wurden jeweils Pausen eingelegt, damit die CPU entlastet wird. Die globale Animationsgeschwindigkeit wurde während der Messung auf sehr langsam gestellt, dadurch dauern die einzelnen Animationen deutlich länger, die CPU wird somit länger, jedoch nicht stärker belastet. Die Ergebnisse sind somit genauer, spiegeln aber nicht die eigentliche Belastung unter Normalbedingungen wieder, da es keine Dauerbelastung gibt.

  System 1 System 2 System 3 System 4
Bezeichnung MacBook 5,1 Athlon X2 IWR PC-Pool Lenovo Netbook
Betriebssystem Kubuntu 9.04 Kubuntu 9.04 Kubuntu 9.04 Kubuntu 8.10 mit KDE 4.2
Prozessor Intel Core2 Duo P7350 AMD Athlon64 X2 4600+ Intel Pentium 4 Intel Atom CPU N270
Taktrate 2 GHz 1,8 GHz 3 GHz 800 MHz
RAM 2 GB 2 GB 2 GB 1 GB
Grafik NVIDIA GeForce 9400M ATI Radeon HD 4350 NVIDIA GeForce FX5200 Intel 945 GME
Treiber 180.53 8575 173.14.16 Mesa 7.2
OpenGL 3.0.0 2.1 2.1.2 1.4
System KDE Version Messung
System 1 KDE 4.2 KDE 4.2 auf System 1
System 1 KDE 4.3 KDE 4.3 auf System 1
System 2 KDE 4.2 KDE 4.2 auf System 2
System 3 KDE 4.2 KDE 4.2 auf System 3
System 4 KDE 4.2 KDE 4.2 auf System 4

Deutung der Messungen

Die Systeme sind nach ihrer Leistung sortiert. System 1 (MacBook) ist das stärkste System, System 4 (Netbook) das schwächste. Es wäre also zu erwarten, dass die CPU Last steigend ist. Für alle Messungen gilt, dass je niedriger und kürzer der Peak ist, desto besser. Zwischen den einzelnen Peaks sollte der Graph im Idealfall auf das Level der Idle Last (rote Linie) absinken, die einzelnen Peaks sollten im Idealfall niemals die blaue Linie des Schnee Effekts überschreiten. Die Last welche vom Würfel Effekt verursacht wird, ist der Bereich über der blauen Linie.

Betrachtet man die verschiedenen Messergebnisse, so sieht man, dass die Anforderung des Absinken auf Idle Last in allen Graphen erfüllt ist. Zum anderen sieht man, dass nur bei System 2 und 4 die Last des Schnee Effekts nicht überschritten wird. Dies lässt sich dadurch erklären, dass diese Systeme keine NVIDIA Karte verwenden und somit Shader nicht zur Verfügung stehen und die Optimierung des Schnee Effekts nicht voll greift. Trotzdem sind die Ergebnisse sehr aussagekräftig, da es zeigt, dass die Ausführung des deutlich komplizierteren Würfel, nicht mehr Last verursacht als das einfache Zeichnen einiger Schneeflocken. Insgesamt kann man auch keine merklichen Unterschiede zwischen der Würfel Animation mit und ohne zusätzlichem Fenster feststellen.

Die schlechteste Performance hat System 2, obwohl es nach der Reihenfolge das zweit stärkste System ist. Die verwendete Grafikkarte ist sehr modern, sogar moderner als die im MacBook. Die schlechte Performance lässt sich auf das bereits angesprochene fehlende direct rendering zurückführen. Leider gibt es für dieses Modell noch keinen freien Treiber, daher kann kein Vergleich mit einem Treiber, welcher DRI unterstützt, auf der gleichen Hardware durchgeführt werden. Betrachtet man dieses Ergebnis, so kann man eigentlich nur jedem Nutzer abraten Compositing mit dem fglrx Treiber zu verwenden, da jeder Effekt eine kleine Animation verwendet, welche Last auf dem hohen Level verursacht.

Am interessantesten sind die Messergebnisse der NVIDIA Systeme (1 und 3). Zuerst soll System 1 betrachtet werden, für welches zwei Messreihen vorliegen. Die erste betrachtet Ergebnisse mit KDE 4.2, wie alle anderen Systeme auch. Auf diesem System konnte aber auch eine Messung mit der Beta von KDE 4.3 durchgeführt werden. Hierbei ist anzumerken, dass die Beta selbst kompiliert ist und debugging Informationen enthält. Die generelle Performance ist daher etwas schlechter. Desweiteren gibt es in 4.3 einen größeren Umbau beim Zeichnen der Fensterdekorationen, welches zum Zeitpunkt der Beta 1 auch noch einige Regressions in der Performance hat. Diese werden bis zum endgültigen Release behoben sein. Der Würfel Effekt verwendet in 4.3 im Gegesatz zu 4.2 Face Culling und die Optimierung über glLists. Die Last ist in 4.3 generell etwas höher, jedoch sehr ähnlich wie im 4.2 Graph. Die Peaks erreichen etwa 5 bis 10 % höhere Werte als die Last des Schnee Effekts. Insgesamt sind diese Werte auch sehr gut unter dem Gesichtspunkt, dass drei Arbeitsflächen mehr gezeichnet werden, als im Schnee Effekt, dazu die Spiegelung und und die Zeichnung der Caps, welche wohl mit dem Zeichenaufwand der Schnee Flocken gleichgesetzt werden können. Dass der Effekt aufwändig ist, sollte für jeden Nutzer klar sein und Ergebnisse welche auf moderner Hardware um die 20 % liegen sind zufriedenstellend. Dazu muss man auch berücksichtigen, dass System 1 mit etwa 10 % eine sehr hohe Idle Last hat.

Betrachtet man nun das zweite NVIDIA System (3), so stellt man fest, dass sowohl der Schnee als auch der Würfel Effekt, deutlich höhere Werte erreichen als das erste System. Hierbei muss man jedoch berücksichtigen, dass das System insgesamt bedeutend älter ist. So verwendet es einen Single Core Prozessor und hat noch keine CUDA-fähige Grafikkarte und einen alten NVIDIA Treiber. Höhere Werte sind also zu erwarten. Die Streuung der Werte ist bedeutend größer als bei irgendeinem anderen System. Hervorzuheben ist, dass die Peaks während der Start- und Stoppanimation unter der Linie des Schnee Effekts bleiben, die einzelnen Rotationen jedoch über der Linie liegen. Eine mögliche Erklärung dafür ist, dass die Rotationen länger ausgeführt wurden als die Start- und Stoppanimationen. Bis auf eine Ausnahme bei System 1 ist dieses Verhalten auch in den anderen Messreihen zu sehen, jedoch ist niergends der Unterschied so groß. Der Abstand zwischen der blauen Linie und den Peaks ist dennoch nur leicht größer als bei System 1. Insgesamt kann man sagen, dass die Benutzung mit einem älteren System möglich ist, aber nicht optimal. Jedoch ist die Last besser als mit einer ATI Karte.

Das letzte zu betrachtende System ist das Netbook (4). Obwohl das modernste, ist es auch das schwächste. Wie System 3 hat es auch nur einen Prozessor und dazu auch nur ein GB Arbeitsspeicher. Im Gegensatz zu den anderen Systemen wurde hier ein Kubuntu 8.10 verwendet, d.h. es profitiert noch nicht von den Verbesserungen des XServer 1.6. Intel Grafik bereitet aber unter Kubuntu 9.04 starke Probleme, daher wurde auf ein Upgrade verzichtet. Die Last ist auf diesem System - wie erwartet - sehr hoch und die Peaks sind im Vergleich zu den anderen Messungen bedeutend länger. Betrachtet man aber den Anfang des Graphen vor Beginn der Messung der Idle Last, so sieht man, dass die normale Benutzung des Systems auch um die 40 % konstante CPU Last verursacht. Die Idle Last ist ebenfalls sehr hoch - ähnlich zu der des MacBooks. Die Messung kann aber die Aussage von System 3 bestätigen: auch auf schwächeren und älteren Systemen ist der Würfel zu benutzen. Man braucht keine Angst zu haben, dass der Selbsttest während der Würfelbenutzung Compositing ausschaltet.

Weitere Optimierungsmöglichkeiten

Natürlich bietet der Würfel immer noch Optimierungsmöglichkeiten. So könne man in Betracht ziehen für die Caps ein Vertex Buffer Object anstatt einer glList zu verwenden. Jedoch hat man dabei wieder das Problem, dass die freien Treiber die benötigte OpenGL Version nicht unterstützt. Der Effekt verwendet komplett die fixed functionality und nutzt keinen Shader für das Zeichnen. Gerade auch bei den Caps könnte dies interessant sein, da die Textur zuerst bearbeitet wird. So wird eine Hintergrundfarbe gesetzt und die Transparenz angepasst. Dies ließe sich wohl in einem Shader verbessern, würde aber nur Verbesserungen für die sowieso schon gut unterstützte NVIDIA Plattform bringen.

Für KDE 4.4 ist angedacht ein experimentelles OpenGL 3 Backend zu entwickeln. Dieses würde komplett auf fixed functionality verzichten und das komplette Rendern würde über Shader erfolgen. Der Würfel müsste dafür auch angepasst werden und es müssten die zwei gerade angesprochenen Optimierungen vorgenommen werden: VBO und Shader. Der Vorteil hierbei wäre, dass viele Optimierungen, auf die man auf Grund der fehlenden Treiberunterstützung verzichten muss, in einem OpenGL 3 Backend verwendet werden können, da diese Version diese Optimierungen (wie VBO) garantiert.