pylo schrieb am 05.08.2021 21:08:
OpenGL ist zwar eine Schnittstelle und keine Implementierung, aber die Auslegung einer Schnittstelle gibt einen strikten Rahmen für konkrete Implementierungen vor, wie effizient sie höchstens implementiert werden können.
Das kann man so nicht sagen, denn das hängt stark davon ab was die CPU macht, was die GPU macht, was davon man im Userspace macht, was davon man im Kernelspace macht, wo man Daten hält, wie man Daten hält, in welche Formant man sie hält, wie Daten von wo nach wo wandern, usw. Und nichts von alle dem gibt der Standard vor.
Auch hatte OpenGL 1.1 zu Zeiten von Glide bereits Display Lists und Stacks für Matrizen und Attribute. Es war als nicht nötig jedes mal alles neu aufzusetzen, sondern man konnte Matrizen einfach auf den Stack auslagern und vorgefertigte Listen abarbeiten. Und statt Parameter einzeln zu füttern konnte man sie auch gleich dutzendweise als Array füttern. Nur weil OpenGL es erlaubte alles einzeln in Baby Schritten zu machen, so dass man Grafiken wie mit der Schildkröte malen konnte (https://de.wikipedia.org/wiki/Turtle-Grafik) heiß das nicht, dass man das nur so machen konnte oder dass das sinnvoll war, wenn man schnelle Grafik wollte.
Um beim selben Beispiel zu bleiben, niemand verwendet Immediate Mode heute, sondern Vertex Buffer Objects. Erst durch dieses und viele andere "neue" Extensions konnte OpenGL mit der Zeit die Performance erreichen die du heute kennst.
Ich habe OpenGL seit 1.1 genutzt, ich kenne die Performance recht gut.
Und Vertex Buffer Objekte gibt es seit OpenGL 1.5, also seit 2003, als ARB_vertex_buffer_object. Es war zwar optional, diese anzubieten, aber im Grunde haben das alle sofort unterstützt, denn eine ARB-Erweiterung (Architecture Review Board) war so gut wie Standard und ist nicht zu verwechseln mit herstellerspezifischen Erweiterungen. Es wurde erst mit OpenGL 3 in den Core Standard aufgenommen (also verpflichtend), aber so fast alles, das irgendwann im Core Standard lag war zuvor eine ARB-Eweiterung und oftmals war es bereits lange davor eine herstellerspezifische (oder es gab eine vergleichbare, herstellerspezifische).
Du kannst eine Vulkan-Wrapper-Implementierung von heute überhaupt nicht als Beispiel nutzen, wie schnell hätte OpenGL damals werden können.
Doch, kannst du, weil die ja Backward Kompatibel ist und ich darauf auch OpenGL 1.1 Code laufen lassen kann. Das komplette Verhalten der festen Render-Pipeline von OpenGL lässt sich heute per Shader nachbilden und diese Shader sind lachhaft im Vergleich zu Shadern, wie sie Games heute einsetzen.
Aber du verpasst hier den Punkt: Vulkan wurde gefordert, weil OpenGL zu langsam ist. Auf die Aussage "Na dann lasst es uns schneller machen" hieß es: Geht nicht. Und wir reden hier nicht von OpenGL 1.1, wir reden hier von OpenGL 4+ Und wenn OpenGL 4+ als Vulkan Wrapper auf der gleichen Hardware schneller ist als OpenGL 4+ direkt, dann ist das der Beleg dafür, dass diese Aussage gelogen ist, denn wie man sieht wäre das sehr wohl gegangen.
Wer schon mal eine OpenGL Implementierung oder Teile davon gesehen hat, der findet relativ schnell stellen, wo er sich an den Kopf fast und fragt
"Was soll das? Natürlich ist das langsam, wenn man das so macht!"
Und wenn man dann fragt, dann heißt es
"Ja ist es, aber um das besser zu machen, müssten wir die Berechnungen hierher umziehen und die Daten dann nicht hier sondern dort halten; und das müssten wir dann aber mit allen Daten machen und entsprechend alle Funktionsaufrufe umbauen, die auf diese Daten zugreifen."
Worauf ich als Entwickler nur Antworten kann
"Ja und weiter ...? Warum tut ihr das dann nicht?"
Und dann erfährst du den waren Grund, warum OpenGL langsam ist:
"Spinnst du? Das ist ja ewig viel Arbeit! Nur damit dann in ein paar Spielen die Framerate 10% höher liegt? Ne danke, da haben wir keinen Bock drauf. So wichtig ist OpenGL eh nicht, nutzt doch eh kaum noch jemand."
Das ist der Grund, warum OpenGL langsam war. Weil es Arbeit gewesen wäre, hier praktisch noch mal alles zu überdenken und die API komplett anders zu implementieren.
Denn wie viel hier am Treiber hängt, das sieht man wenn man mal den NVidia Treiber in Windows mit dem unter Linux und mit dem freien Treiber vergleicht. Obwohl die ersten beiden beide von NVidia kommen, ist der Windows-Treiber deutlich schneller und obwohl die letzten beiden unter Linux laufen, ist der freie deutlich langsamer. CPU, GPU, RAM und das restliche System sind aber immer gleich, an denen kann es also nicht liegen.
Nur mit Vulkan blieb ihnen diese Arbeit natürlich nicht erspart, hier mussten sie eine neue 3D API im Treiber implementieren und sich entsprechend alles komplett neu überlegen und alles nochmal neu optimieren. Und siehe da, stülpt man da jetzt wieder die alte, angeblich so langsame OpenGL API drüber, ist die auf einmal auch schnell. Oh wunder, oh wunder.
/Mecki