OpenGL-Kompatibilität, Namenskonventionen und ARB vs EXT

Ich dachte, ich hätte ein allgemeines Verständnis für die Funktionsweise von OpenGL-Namenskonventionen und -Erweiterungen gewonnen, bis ich auf einen Fall stieß, der mich verwirrte.

Hier ist mein bisheriges Verständnis:

Kein Suffix - z glGenBuffers(). Diese Funktion ist Teil des Kernprofils. Die Wiki-Seite teilt mir mit, dass dies dem Kernprofil ab Version 1.5 hinzugefügt wurde.

ARB - zB glGenBuffersARB(). Diese Funktion ist Teil der standardisierten GL_ARB_vertex_buffer_objectErweiterung. Die Spezifikation dieser Erweiterung wird GenBuffersARB()im Abschnitt "Neue Prozeduren und Funktionen" eindeutig deklariert . Der Abschnitt "Abhängigkeiten" sagt mir, dass ich möglicherweise aus einem 1.4+ Kontext darauf zugreifen kann, wenn die Hardware die Erweiterung unterstützt.

EXT - Dies sind herstellerspezifische Erweiterungen und Funktionen, die möglicherweise nur einige Hersteller unterstützen. Vertex-Pufferobjekt scheint keine EXT-Erweiterung in der Registrierung zu haben.

Hier ist, wo mein Verständnis zusammenbricht:

glGenFramebuffersWie das Wiki zeigt, wurde der Core in 3.0 erweitert.

Jetzt möchte ich auf die Framebuffer-Funktionen in einer niedrigeren Core-Profilversion als 3.0 zugreifen. Also möchte ich es als Erweiterung verwenden. Die Spezifikationsregistrierung gibt an, dass zwei Erweiterungen verfügbar sind - ARB und EXT .

Frage 1 - Wenn eine ARB-Erweiterung vorhanden ist, warum gibt es eine EXT-Erweiterung? Würden Sie nicht immer die standardisierte anstelle der herstellerspezifischen wählen?

Ein Blick auf die ARB-Spezifikation im Abschnitt "Neue Prozeduren und Funktionen" zeigt mir, dass die Erweiterung die GenRenderbuffers()Funktion definiert . Dieses Mal gibt es kein ARB-Suffix. Für GLEW gibt es überhaupt keinen Funktionsprototyp glGenRenderbuffersARB(). Seltsam.

Die EXT-Spezifikation hat jedoch eine GenRenderbuffersEXT()Funktion im Abschnitt mit den neuen Funktionen, und GLEW hat auch eine Funktion glGenRenderbuffersEXT().

Frage 2 - Warum kein ARB-Suffix, wenn es ein EXT-Suffix gibt? Wie funktioniert dies für ARB, wenn die Namen der ARB-Funktion und der Kernfunktion identisch sind?

Frage 3 - Ich möchte letztendlich Framebuffer-Funktionen von einem 1.4-Profil. Welche Erweiterung und welchen Funktionsumfang soll ich verwenden, damit ich eine maximale Abdeckung der Hardwarekompatibilität erhalte?

Frage 1 - In der Regel steht die EXT-Version an erster Stelle, wenn zwei oder mehr Anbieter zusammenarbeiten. ARB-Erweiterungen erfordern mehr Diskussion unter stimmberechtigten Mitgliedern von Khronos und können Änderungen gegenüber der EXT-Version aufweisen, bevor sie genehmigt werden. Siehe die Erweiterung GL_ARB_direct_state_access, die viele Änderungen im Vergleich zu GL_EXT_direct_state_access aufweist.

Frage 2 - Der Abschnitt Issues der Erweiterung GL_ARB_framebuffer_object gibt an, warum die Funktionen keine ARB-Suffixe haben:

(8) Warum haben die neuen Token und Einstiegspunkte in dieser Erweiterung keine Suffixe wie andere ARB-Erweiterungen?

   RESOLVED: Unlike most ARB extensions, this is a strict subset of
   functionality already approved in OpenGL 3.0. This extension
   exists only to support that functionality on older hardware that
   cannot implement a full OpenGL 3.0 driver. Since there are no
   possible behavior changes between the ARB extension and core
   features, source code compatibility is improved by not using
   suffixes on the extension.

Frage 3 - Wenn Sie Framebuffer-Objekte in einem Kontext verwenden möchten, in dem die GL-Version kleiner als 3.0 ist, müssen Sie sich die Erweiterungszeichenfolge ansehen:

1. Wenn GL_ARB_framebuffer_object unterstützt wird, verwenden Sie die Nicht-ARB-Funktionen.
2. Wenn nur GL_EXT_framebuffer_object unterstützt wird, verwenden Sie die EXT-Funktionen.
3. Wenn keine der beiden Erweiterungen unterstützt wird, müssen Sie wie bei pbuffers auf das Offscreen-Rendering auf Betriebssystemebene zurückgreifen.