Re: Bei 3dfx muss ich immer sofort an Glide denken

Ich habe OpenGL seit 1.1 genutzt, ich kenne die Performance recht gut.

Ich habe auch mit OpenGL entwickelt, schon ab 2001, und dann etwas später auch mit DirectX. Mit 3D- und Spielentwicklung habe ich dann erst 2010 aufgehört. Also gut 10 Jahre Erfahrung, einige davon noch von den pre-OpenGL 2.0 und "pre-VBO"-Zeiten.

Das habe ich aber nur erwähnt, weil du damit angefangen hast. Bitte lassen wir diese Argumente wo man versucht, den anderen zu disqualifizieren indem man behauptet, er hat mehr Erfahrung als das andere also er muss Recht haben.

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.

Ja, klar, das ändert aber nichts daran wie schlecht auch Display Lists immer noch für Spiele waren, verglichen mit anderen Techniken von später oder mit anderen APIs (DirectX) von damals. Obwohl Display Lists noch die bessere Alternative in der OpenGL-Welt waren wie du sagst. Sie waren ineffizient für dynamische Objekte und verschwendeten Bandbreite wie Irre. Bis die neuere GL-Extensions nicht aufgetaucht sind, war das eine erheblich Einschränkung des APIs, die grosse Performancenachteile verursacht hat.

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).

Stimmt, aber das ist alles irrelevant für unsere Diskussion. 2003 war Glide längst am Aussterben, DirectX war bei Version 8 oder vlt schon 9, und dann bringst du auch noch OpenGL3 ins Mix, wo weder 3dfx als Firma, noch Glide als Schnitstelle existiert hatten, um von der Nicht-Existenz von Glide-Fähigen Hardware am Markt überhaupt zu Schweigen. Mein Punkt ist, wir reden nicht von den ARB_vertex_buffer_object-Zeiten, wo viele Probleme von OpenGL schon behoben waren (natürlich nicht alleine durch VBOs), sondern wir haben über die Zeiten geredet, wo Glide noch relevant war. Da musst du um ein paar Jahre weiter in die Vergangenheit zurückgehen als 2003. Dass *später* OpenGL relativ OK war, das habe ich selbst auch gesagt, aber noch nicht in den Glide-Zeiten, was das ursprüngliche Thema ist.

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.

Nein, es ist kein Beleg, oder besser gesagt es ist ein Beleg für den Gegenteil. Denn OpenGL 4+ über Vulkan läuft natürlich immer noch langsamer als die gleiche App auf Vulkan alleine. Also, wenn man alleine durch die stupide Emulation von OpenGL über Vulkan nicht-vernachlässigbares Performance verliert (verglichen mit Vulkan pur), dann hat man quasi bewiesen, dass das Schnittstellendesign von OpenGL selbst ein Problem ist, also der Gegenteil von dem was du behauptest. Und wenn das heute immer noch ein Problem ist, dann war das in den 90-ern ein 10x grösseres Problem, weil damals nicht einmal die moderne und "schnelle" OpenGL APIs zur Verfügung gestanden sind.