Wobei ich bei den Vendor Extensions ehrlich gesagt sagen muss, dass ich sie nie nutzen würde, wenn es nicht einen wirklich guten Grund dafür gibt. Die Dinger sind eigentlich eher dafür da, irgendwann mal als ARB-Extension spezifiziert zu werden, auf eine Art und Weise, mit der möglichst alle Hersteller klarkommen.
DocWindows schrieb:
Außerdem müsste dieses Gesamtpaket gar nicht gegen diesen merkwürdigen Grundsatz verstoßen, weil man es ja komponentenbasiert lösen kann, dann aber trotzdem ein einheitliches Programmiermodell hat.
Das ergibt keinen Sinn. Und zwar allein schon deshalb nicht, weil 3D-Grafik, Sound und Input so grundverschieden sind, dass sie gar nicht dieselben Programmiermodelle
erlauben.
- Wie funktioniert Grafik? Du sagst der Grafikkarte, was sie machen soll, erzeugst also
Befehle, und verwaltest Daten im VRAM.
- Wie funktioniert Audio? Du schreibst alle paar Millisekunden mal einen Audio-Frame voller Samples in einen Buffer und bist glücklich. 3D-Sound in Hardware hat doch heute eh kein Mensch mehr.
- Wie funktioniert Input? Wahlweise über Events oder Polling. Gibt es da irgendwelche Schnittstellen zu spezifizieren? Nein. Ist es sinnvoll, ein Command- oder Buffer-basiertes Programmiermodell darauf anzuwenden? Auch nicht.
Also selbst wenn alles in einer Library steckt, benutzt man letztenendes völlig verschiedene APIs. Das ist bei DirectX so (man muss sich nur mal für zwei Minuten die Dokumentation der verschiedenen Bestandteile anschauen, zumal einige davon, wie Zehkul schon sagt, deprecated sind), das ist bei SDL so, das ist bei GLFW so.
Ab davon bietet SDL praktisch alles, was man braucht, außer eben Grafik. Grafik geht da aber mit OpenGL, Vulkan, Direct3D, ... - und es ist plattformunabhängig. Hat ein Komplettpaket von Microsoft jetzt noch irgendeinen Vorteil? Vielleicht die bessere Dokumentation, das war es aber auch.
DocLinux schrieb:
189 Extensions insgesamt. Vendor Extensions habe ich nicht rausgerechnet. Dies gilt übrigens für den Intel-Treiber.
Wie viele davon sind Core Profile-Extension? Wie viele deprecated, also gar nicht mehr kompatibel mit einem GL 3.2+ Core Profile-Context? Welche Extensions nutzt das Programm tatsächlich?
Eine GL-Revision ist ja letztenendes nur eine Sammlung von ARB- und KHR-Extensions, die unterstützt werden
müssen. Als Entwickler kann man sich zumindest darauf verlassen, dass diese implementiert werden, wenn ein entsprechender Context erstellt werden kann.
Und wer Vendor Extensions für Produktionscode nutzt und sich dann wundert, dass der Wartungsaufwand steigt, hat ganz andere Probleme. Die sind auch weniger dafür da, um direkt verwendet zu werden (auch wenn man das natürlich tun
kann), sondern viel eher, um neue Features vorzustellen und irgendwann mal zu einer offiziellen, Vendor-
unabhängigen ARB-Extension zu werden. Z.B. AMD_pinned_memory => ARB_buffer_storage, NV_bindless_texture => ARB_bindless_texture.
D3D12 ist da nebenbei ja nicht besser. Da gibt es bestimmte Feature Levels, auf die Rücksicht genommen werden muss.
Jetzt kann man zwar sagen, dass man ja nur das nutzen muss, was auf jeder Hardware geht, aber a) nutzt man so sicherlich nicht alle Möglichkeiten modernerer Hardware, b) entspricht das doch exakt der Nutzung einer GL-Core-Version ohne zusätzlichen Extensions, oder aber man schreibt für jeden unterstützten Feature Level eigenen Code, was dann nicht besser wäre als diverse GL-Extensions zu nutzen.
DocMaxOSX schrieb:
Nein, es ist unkomfortabel, nicht so umfangreich und nicht so gut dokumentiert wie DirectX.
Unkomfortabel? Geht. DSA in GL 4.5 hat da massiv geholfen, und inzwischen unterstützt das auch jeder.
Umfangreich? Es ist ein 3D-API und kann als solches spätestens seit Version 4.3 mehr als D3D11 (MultiDrawIndirect + andere
AZDO-Techniken - allesamt mit Core Profile- oder offiziellen ARB-Extensions realisierbar).
Gut dokumentiert? Es gibt das
OpenGL-Wiki und zu jeder Extension ausführliche
Beschreibungen. So viel anders als die MS-Doku, die aus diversen Overviews und eben der API-Dokumentation besteht, ist das jetzt nicht.
Falls du
aktuelle Tutorials etc. meinst - mag sein. Mir fällt jetzt auf die Schnelle auch keines ein. Was aber auch daran liegt, dass ich OpenGL mitlerweise gut genug kenne, um mir Dinge auch aus API-unabhängigen Quellen erarbeiten zu können.
Tools? Meh. Ehrlich gesagt weiß ich nicht, was die großen Entwickler da brauchen, aber Debug-Funktionen, die - halbwegs brauchbare GL-Implementierung vorausgesetzt, insbesondere MESA - meckern, wenn man GL falsch benutzt, sind ohne großen Aufwand nutzbar, für Shader hat Nvidia ein Tool. Ist also auch nicht so, dass man es nicht benutzen könnte.
DocSolaris schrieb:
Wenn das alles so knallergenial ist, dann frage ich mich warum man OpenGL nicht öfter nutzt
a) weil man es nicht öfter nutzt und deswegen die Treiber von einem gewissen Hersteller scheiße sind und
b) weil es vor enigen Jahren technisch tatsächlich hinterher hing.
Zehkul schrieb:
während der Code vermutlich viel simpler ist. Naiv eben. Multithreading ist kompliziert.
Geht. Wenn man nicht in guter alter 90er Jahre-Java-Manier jeden Furz als riesige und undurchschaubare State Machine implementiert, lassen sich 98% aller Probleme mit Thread Pools, Queues und Multi-Buffering erschlagen. Multithreading an sich ist wirklich kein Hexenwerk.
... wer behauptet was anderes??
=> Was hat Nvidia hiermit zu tun? (abgesehen vom geringeren DX11 Overhead)
