Der traurige Zustand von OpenGL

OpenGL, so sollte man meinen, habe eine prachtvolle Zukunft vor sich: immerhin ist es ein offener Industriestandard, auf jeden Fall aber der Standard auf jedem Iphone/Ipad, Android-Telefon und Macintosh. Damit wird es zahlenmäßig gesehen an Microsofts DirectX (Xbox, Windows und Windows-Phones) weit vorbeiziehen. Aber weit gefehlt!

Ein Entwickler von Valve, Rich Geldreich, befasst sich aktuell in seinem Blog genauer zum Zustand von OpenGL und dessen Treibern. Das ist interessant, da Valve ja zum Bau seiner eigenen Konsole Steam Box auf Linux und damit OpenGL setzt - die haben also nichts gegen OpenGL, im Gegenteil, die finden es toll und liefern momentan ein Opensource-Produkt nach dem anderen ab, um damit besser arbeiten zu können.

In dem Artikel "Dinge, die mich bei OpenGL in den Wahnsinn treiben" schreibt denn auch Geldreich sehr plastisch, wo es denn bei OpenGL hakt. Das ist auf Englisch geschrieben, aber durchaus mal das Lesen wert.

Er ist unter anderem der Meinung, dass OpenGL den Mist von über 20 Jahren mit sich herum schleppe und einfach radikal von Grund auf neu geschrieben gehört. Wenn dies nicht bald geschehe, dann würden AMDs neues API Mantle als auch Direct X12 OpenGL performancetechnisch ungespitzt mal wieder in den Boden rammen. (Wobei da sicher diese Entwicklung, wie OpenGL bis zu 15x schneller laufen könnte, wohl nicht berücksichtigt ist).

Jedenfalls ist es ein interessanter Artikel aus der Siche eines Programmierers, der sich wirklich mit OpenGL auskennt.

Auch interessant ist noch sein Artikel "Die Wahrheit über die Qualität von OpenGL-Treibern", in dem er sich massiv über die unterschiedlichen Treiberqualitäten von Hersteller A, B und C auslässt. Unschwer zu erkennen handelt es sich dabei bei A um Nvidia, B um AMD und C um Intel.

Auch das liest sich interessant. Nvidia kommt relativ gut weg, der Treiber sei aktuell leistungstechnisch der Standard. Der Hersteller lege mehr Wert auf ein Funktionieren des Treibers als nun alle möglichen GL-Erweiterungen zu unterstützen. Aber auch der Treiber hatte so seine grundlegenden Fehler, die einfach nicht hätten passieren können und vor allem sei der Treiber so programmiert, dass er intern ganze Shader für Schlüsseltitel/spiele durch eigene ersetzen würde, nur damit die Leistung stimme. Der Hersteller mache da vor nichts halt. Allerdings habe eben Nvidia auch die beste, interne Qualitätskontrolle und das würde man deutlich spüren.

AMD dagegen kommt deutlich schlechter als ein Kuddelmuddel weg, sehr fehlerreich, inkonsistente Qualitätstests und das Treiberthreading sei komplett außerhalb der Kontrolle der offiziellen Entwickler. Leider könne man diesen Hersteller aber nicht ignorieren, da seine GPUs hardwaretechnisch sehr leistungsfähig und verbreitet seien, obwohl sie als Hersteller softwaretechnisch gesehen Idioten seien.

Die Treiber von AMD würden sich strikter an die Standards halten, aber da die meisten Leute nur mit Nvidia entwickeln würden und dann wenn es mit AMD nicht funktionieren würde, würden sie AMD die Schuld geben und nicht dem Status Quo von OpenGL an sich selbst.

AMDs Schlüsselerweiterungen funktionieren nicht, und er schaffe es einfach nach wie vor nicht, gewisse grundlegende Dinge zuverlässig zum Laufen zu bringen.

Außerdem habe AMD es bisher nicht geschafft, mal ein Treiberupdate rauszubringen, das nicht irgendetwas gleichzeitig kaputt machen würde, ein Fehler würde behoben und zwei neue eingeführt. Außerdem seien viele Entwickler von AMD zu Nvidia gegangen, und wenn man sich anschauen würde, was der Treiber intern so treibe, dann gäbe es da Zillionen an Fehlerworkarounds von diesen Leuten, die heute bei AMD keiner mehr verstehen würde.

Interessanterweise aber habe AMD ein fähiges Entwicklerteam für Debuggingtools, die sogar meist funktionieren, solange man mit AMD entwickeln würde.

Die langfristige Entwicklung des Treibers sei aber so, dass die Zuverlässigkeit ziemlich wahrscheinlich noch abnehmen würde.

Auf der Sonnenseite sei es aber so, dass sie die OpenGL-Spezifikationen auswendig kennen würden. Wenn man von ihnen Hilfestellungen bekommen würden, dann sei diese (ohne Erweiterungen) meist sehr vernünftig.

Intel wiederum sei eine Firma, die eigentlich nicht wirklich Grafik produzieren wollen, aber da der aktuelle Trend dazu gingen, Chipsatzgrafik auf dem Prozessor zu integrieren, es eben müssen. Es sei daher schwer, sauer auf sie zu sein, weil es eben nicht ihr Kerngeschäft sei.

Sie seien der Marktführer in Sachen Opensourcegrafiktreiber und haben so viel Geld, dass sie sogar zwei komplette Entwicklerteams für Treiber im Haus haben, für jedes Betriebssystem ein komplett eigenes. Außerdem seien die Hardwarespezifikationen komplett öffentlich.

Das Entwicklerteam sei schlau und sie würden direkt Open Source Wiz Kids anheuern, um den Treiber am Laufen zu halten. Der Treiber sei im Vergleich zu AMD und Nvidia am wenigsten fortgeschritten, aber er funktioniere, solange man nicht begreife oder darauf Wert legt, wofür "FPS" stünde. Wenn man gut darin sei, Fehler in dem Treiber zu beheben und Patches zu liefern, dann kriegt man sogar vielleicht einen Job bei Intel.

Geldreich schließt mit dem Fazit, dass, wenn man für OpenGL richtig entwickeln wolle, man sein Programm auf jeder Hardwareplattform erneut testen müsse, andernfalls habe man keine Garantie, dass es eben gescheit laufe. Und wenn man Fehler entdecken möge, dann müsse man auf die Hilfe der OpenGL-Gurus hoffen, ansonsten sei es mitunter sehr schwierig.

Oder anders gesagt: die OpenGL-Treiber aller drei Firmen saugen, aber sie seien eben das Beste, was wir momentan leider haben. Und nach Gelbreichs Meinung ist eben Nvidia momentan in Sachen OpenGL nach wie vor der beste Hersteller, den wir haben.

One thought on “Der traurige Zustand von OpenGL

  1. Justin

    Nun ich hatte ein halbes Jahr lang OpenGL im Studium und ein halbes Jahr DirectX... Ich kann dabei nur sagen OpenGL ist einfach zu aufwendig... Beide Sprachen sind zwar schwer und kompliziert auf den ersten Blick, aber DirectX hat es immerhin nicht verpasst endlich mal OOP einzuführen, während man bei OpenGL schon sehr viel in C++ tricksen muss, um überhaupt irgendwas objektorientiert machen zu können. Das heißt OpenGL klassen schreiben, aber das ist dann sowieso pseudoobjektorientierter Code, da bei OpenGL ähnlich wie bei einem interpreter die reihenfolge der funktionen wichtig ist... Und das ganze ist nun mal nur die Bequemlichkeit eines programmierers und betrifft nicht die Performance... Sicherlich lassen sich da noch einige Vorteile in der Performanz mit einbringen...

    Reply

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.