15
$\begingroup$

I thought I had formed a general understanding of how OpenGL naming conventions and extensions worked, until I stumbled upon a case that confused me.


Here's my understanding so far:

No suffix -- e.g. glGenBuffers(). This function is a part of the core profile. The wiki page tells me that this was added to the core profile starting from version 1.5.

ARB -- e.g. glGenBuffersARB(). This function is part of the standardized GL_ARB_vertex_buffer_object extension. The spec of this extension clearly declares GenBuffersARB() in the "New Procedures and Functions" section. The "Dependencies" section tells me that I can potentially access this from a 1.4+ context, if the hardware supports the extension.

EXT -- These are vendor-specific extensions and functions that only some vendors may support. Vertex buffer object doesn't seem to have an EXT extension in the registry.


Here's where my understanding breaks down:

glGenFramebuffers, as the wiki shows, was added to the core in 3.0.

Now I want to access the frame buffer features at a lower core profile version than 3.0. So I want to use it as an extension. The spec registry tells me that there are two available extensions - ARB and EXT.

Question 1 -- If an ARB extension exists, why does an EXT extension exist? Wouldn't you always choose the standardized one over the vendor-specific one?

A look at the ARB spec in the "New procedures and functions" section tells me that the extension defines the GenRenderbuffers() function. No ARB suffix this time. GLEW doesn't have a function prototype for glGenRenderbuffersARB() at all. Weird.

The EXT spec does however have a GenRenderbuffersEXT() function in the new functions section, and GLEW also hasglGenRenderbuffersEXT().

Question 2 -- Why no ARB suffix if there's an EXT suffix? How does this work for ARB, given that the names of the ARB function and the core function are the same?

Question 3 -- I ultimately want Framebuffer features from a 1.4 profile. Which extension and which function-set should I use so that I get maximum hardware compatibility coverage?

$\endgroup$

1 Answer 1

9
$\begingroup$

Question 1 -- Usually the EXT version comes first as a collaboration between two or more vendors. ARB extensions require more discussion among voting members of Khronos and can have changes from the EXT version before getting approved. See the GL_ARB_direct_state_access extension which has many changes compared to GL_EXT_direct_state_access.

Question 2 -- The Issues section of the GL_ARB_framebuffer_object extension states why the functions do not have ARB suffixes:

(8) Why don't the new tokens and entry points in this extension have suffixes like other ARB extensions?

   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.

Question 3 -- If you want to use framebuffer objects on a context where the GL version is less than 3.0 you need to look at the extension string:

  1. If GL_ARB_framebuffer_object is supported, use the non ARB functions.
  2. If only GL_EXT_framebuffer_object is supported, use the EXT functions.
  3. If neither extension are supported, you need to fall back to OS level offscreen rendering like pbuffers.
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.