Rollora
Kokü-Junkie (m/w)
Valve Mitarbeiter erklärt warum dank Nvidia, AMD und Intel OpenGL keine Chance hat
Einleitung:
Nach Jahren tut sich endlich mal wieder was bei den APIs. Dank AMDs Mantle bewegt sich was, neue Features werden diskutiert, Flaschenhälse wollen entfernt werden.
Doch es gäbe doch schon längst eine API die all das kann was Mantle und Direct X 12 uns versprechen: OpenGL. Noch dazu wo Mantle und DirectX proprietär sind und OpenGL offen ist.
Aber hier haben wir auch gleich ein Problem: Viele Köche verderben den Brei und OpenGL ist voll von Funktionen und Bibliotheken die "Sonderwünsche" beinhalten. Während Mantle eine kompakte API darstellt, und symbolisch wie das Projektil eines Scharfschützengewehrs einschlägt, ist OpenGL ein die Schrotladung einer Pumpgun: Mantle/DirectX trifft auf den Punkt, die Pumpgun verstreut ordentlich, ist auf große Distanz aber wenig wirkungsvoll. Wie gesagt symbolisch.
OpenGL ist älter, wird seit vielen Jahren von vielen Entwicklern (Köchen) weiterentwickelt. Ich habe vor Jahren aufgehört der Entwicklung zu folgen, und doch ist es interessant. Vorallem weil jetzt einer der größeren Entwickler die mit OpenGL arbeiten, sich zu Wort meldet: Valves grafikprogrammierer Rich Geldreich.
Kurzfassung:
Rich bricht es auf ein großes Problem runter. Die 3 Großen Grafikchipentwickler/Hersteller: Nvidia, AMD und Intel. Er nennt sie nur Vendor A, B und C, aber es ist klar wer gemeint ist:
Vendor A :
-hat die besten Ressourcen für OpenGL. Das beste Entwicklerteam, die sauberste Implementierung, die besten Tools. Es macht Spaß damit zu arbeiten und sie pushen OpenGL am ehesten weiter nach vor und als Alternative zu Mantle.
-Doch auf der Con-Seite hat Vendor A ein eher schwaches toolset, welches außerdem nur mit den eigenen Treibern funktioniert. Es gibt immer noch große Low-Level bugs.
-Außerdem ist dieser Vendor A spezielle Treiberfeatures für große Entwickler - nicht aber für kleine, und außerdem sind die Errungenschaften die bei Vendor A im Zusammenhang mit OpenGL gemacht werden, bei Vendor B oder C nicht einsetzbar:
-versucht möglichst sauber OpenGL zu implementieren, aber über Vendor B ist allgemein bekannt, dass er
- Vendor B meint es gut, hat aber (im Vergleich zu Vendor A) sehr limitierte Ressourcen und nur ein kleines Team. Auch interessant zu hören, die einen hätten unlimitierte Ressourcen, die anderen sparen.
- Der Treiber-Stack ist voll von Müll und keiner versteht ihn zu benutzen
Vendor C:
Vendor C hat gleich 2 große Entwicklerteams, aber keines davon interessiert sich für Grafik[3] und ist in dem Punkt viele Jahre hinter Vendor A und Vendor B, wenn es darum geht, die einfachsten OpenGL Features zu implementieren.
Vendor C führt zwar den Weg bei Open Source Treibern und geht am öffentlichsten mit Hardware-Specs um, aber was hilft das?
Ein Treiber ist Jahre hinter der Konkurrenz, der andere ist einfach unbenutzbar schlecht. Viele Codepfade funktionieren einfach nicht.
Vendor C hat außerdem keine debugging tools:
hier gibt es keinen "Gewinner" bei Vergleich zwischen Vendor A, B und C. Nur einen Verlierer: der Markt bzw der Kunde.
Wer sich weiter in die Materie einlesen möchte, dem sei Geldreich's Blog [4] generell empfohlen, er führt hier mindestens 30 weitere Gründe für und gegen OpenGL an.
DANKE auch an M4xw0lf, der meine News mit seinem Kommentar [5] (ganz unten auf Seite 1) ergänzt und einen noch tieferen Einblick gewährt.
Quellenverzeichnis
[1]: Why we can’t have nice things: Valve programmer discusses wretched state of OpenGL | ExtremeTech
[2]: Rich Geldreich's Blog: The Truth on OpenGL Driver Quality
[3]: Intel unveils Haswell’s graphics: Iris branding and improved performance per watt | ExtremeTech
[4]: Rich Geldreich's Blog
[5]: Ergänzender Kommentar von M4xw0lf
[6]: About The Khronos Group - für Interessierte: die Gruppe hinter den APIs OpenGL, OpenCL, WebCL, OpenMAX, OpenGL ES usw usf
Einleitung:
Nach Jahren tut sich endlich mal wieder was bei den APIs. Dank AMDs Mantle bewegt sich was, neue Features werden diskutiert, Flaschenhälse wollen entfernt werden.
Doch es gäbe doch schon längst eine API die all das kann was Mantle und Direct X 12 uns versprechen: OpenGL. Noch dazu wo Mantle und DirectX proprietär sind und OpenGL offen ist.
Aber hier haben wir auch gleich ein Problem: Viele Köche verderben den Brei und OpenGL ist voll von Funktionen und Bibliotheken die "Sonderwünsche" beinhalten. Während Mantle eine kompakte API darstellt, und symbolisch wie das Projektil eines Scharfschützengewehrs einschlägt, ist OpenGL ein die Schrotladung einer Pumpgun: Mantle/DirectX trifft auf den Punkt, die Pumpgun verstreut ordentlich, ist auf große Distanz aber wenig wirkungsvoll. Wie gesagt symbolisch.
OpenGL ist älter, wird seit vielen Jahren von vielen Entwicklern (Köchen) weiterentwickelt. Ich habe vor Jahren aufgehört der Entwicklung zu folgen, und doch ist es interessant. Vorallem weil jetzt einer der größeren Entwickler die mit OpenGL arbeiten, sich zu Wort meldet: Valves grafikprogrammierer Rich Geldreich.
Kurzfassung:
Rich bricht es auf ein großes Problem runter. Die 3 Großen Grafikchipentwickler/Hersteller: Nvidia, AMD und Intel. Er nennt sie nur Vendor A, B und C, aber es ist klar wer gemeint ist:
Vendor A :
-hat die besten Ressourcen für OpenGL. Das beste Entwicklerteam, die sauberste Implementierung, die besten Tools. Es macht Spaß damit zu arbeiten und sie pushen OpenGL am ehesten weiter nach vor und als Alternative zu Mantle.
-Doch auf der Con-Seite hat Vendor A ein eher schwaches toolset, welches außerdem nur mit den eigenen Treibern funktioniert. Es gibt immer noch große Low-Level bugs.
-Außerdem ist dieser Vendor A spezielle Treiberfeatures für große Entwickler - nicht aber für kleine, und außerdem sind die Errungenschaften die bei Vendor A im Zusammenhang mit OpenGL gemacht werden, bei Vendor B oder C nicht einsetzbar:
Vendor B:
-versucht möglichst sauber OpenGL zu implementieren, aber über Vendor B ist allgemein bekannt, dass er
ist, also kurzum: schlampig und inkompetent ist, was Treiberarbeit betrifft. Interessant ist das, von Entwicklerseite mal zu hören. Außerdem:
- Vendor B meint es gut, hat aber (im Vergleich zu Vendor A) sehr limitierte Ressourcen und nur ein kleines Team. Auch interessant zu hören, die einen hätten unlimitierte Ressourcen, die anderen sparen.
- Der Treiber-Stack ist voll von Müll und keiner versteht ihn zu benutzen
Vendor C:
Vendor C hat gleich 2 große Entwicklerteams, aber keines davon interessiert sich für Grafik[3] und ist in dem Punkt viele Jahre hinter Vendor A und Vendor B, wenn es darum geht, die einfachsten OpenGL Features zu implementieren.
Vendor C führt zwar den Weg bei Open Source Treibern und geht am öffentlichsten mit Hardware-Specs um, aber was hilft das?
Ein Treiber ist Jahre hinter der Konkurrenz, der andere ist einfach unbenutzbar schlecht. Viele Codepfade funktionieren einfach nicht.
Vendor C hat außerdem keine debugging tools:
Fazit:
hier gibt es keinen "Gewinner" bei Vergleich zwischen Vendor A, B und C. Nur einen Verlierer: der Markt bzw der Kunde.
Wer sich weiter in die Materie einlesen möchte, dem sei Geldreich's Blog [4] generell empfohlen, er führt hier mindestens 30 weitere Gründe für und gegen OpenGL an.
DANKE auch an M4xw0lf, der meine News mit seinem Kommentar [5] (ganz unten auf Seite 1) ergänzt und einen noch tieferen Einblick gewährt.
Quellenverzeichnis
[1]: Why we can’t have nice things: Valve programmer discusses wretched state of OpenGL | ExtremeTech
[2]: Rich Geldreich's Blog: The Truth on OpenGL Driver Quality
[3]: Intel unveils Haswell’s graphics: Iris branding and improved performance per watt | ExtremeTech
[4]: Rich Geldreich's Blog
[5]: Ergänzender Kommentar von M4xw0lf
[6]: About The Khronos Group - für Interessierte: die Gruppe hinter den APIs OpenGL, OpenCL, WebCL, OpenMAX, OpenGL ES usw usf
Zuletzt bearbeitet:
ich hätte nicht gedacht, dass ich irgendwann Bestätigung für meine These erhalten würde. Ich habe mir das Spielchen mit Mantel angeschaut und war recht amüsiert darüber als dann der neue Nvidia Wundertreiber kam. Meiner Meinung nach bereitet AMD mit deren API den Weg um in der Zukunft richtig Kohle rein zu holen. 
