[Solved] Difference between GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB?

Started by
3 comments, last by 21st Century Moose 11 years, 1 month ago

Hello,

I have a quick question: what's the difference between GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB? My friend google didn't find anything good. ;)

Thank you,

thecheeselover


Hello,

I have a quick question: what's the difference between GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB? My friend google didn't find anything good. ;)

Thank you,

thecheeselover

Hide yo cheese! Hide yo wife!

Advertisement

One constant belongs to the core API, and one belongs to an extension due to the ARB-suffix. They are probably defined to the same value, but that does not mean that you should mix them. If you're using the vertex buffer functions from the core API, then you should use the standard constant. If you're using the ARB-variant of the vertex buffer object extension, then you should use the one with the ARB-suffix.

For all practical purposes - none whatsoever. If you even look in your local friendly GL header file you'll find:


#define GL_ARRAY_BUFFER 0x8892
#define GL_ARRAY_BUFFER_ARB 0x8892

That's only part of the story however. The real story lies in the difference between glBindBuffer (and friends) and glBindBufferARB (and friends), and the tale begins with the way OpenGL evolves.

(Skip this bit if you're familiar with it already). The simplified version is that functionality begins with a new OpenGL extension (it doesn't always but let's pretend it does for the purpose of this discussion - it keeps things easier). In this case GL_ARB_vertex_buffer_object. Because it's an extension the tokens it uses are suffixed with "_ARB" (signifying it's an ARB extension) and the GL calls it uses are likewise suffixed with "ARB". Don't worry about what an "ARB extension is" for now - you can look it up later if you like, but for now just be aware that the term exists.

Over time a new core GL version is released (in this case it was 1.5) and selected extensions are promoted to the core. When that happens they're no longer extensions; they're an official part of OpenGL and if you have the GL version in which this happened (glGetString (GL_VERSION, ...) gives 1.5) then you don't need to do extension checking - you can just rely on them being always present. As part of this process, and to signify that it's no longer an extension, the "ARB" suffix is removed.

So glBindBuffer is the core OpenGL 1.5 version, glBindBufferARB is the earlier pre-OpenGL 1.5 version for drivers and hardware that supported it as an extension.

Now it gets a little more complex. Sometimes the functionality of the core version is exactly the same as the older extension, but sometimes it's not. Sometimes it gets changed a little during the promotion (this happened with GL_ARB_shader_objects). This can affect your choice (and the choice is your's) of which to use.

So - if you want to run on older, pre-GL 1.5, hardware you use the "ARB" suffixed version, if you don't care much about hardware that very very few people have any more, you can use the version without the suffix.

Now it gets more complex again. You can use the "ARB" suffixed version on newer hardware too, but beware - it's an extension, and no OpenGL implementation is obliged to support any extensions at all. If a vendor supplies an OpenGL 1.5 or higher driver, they may not export the GL_ARB_vertex_buffer_object extension. In practice they always will, but just be aware that the possibility is there.

It's also the case that if the functionality changed during the promotion process the older version may not be so important for your hardware vendor. It may not be getting bug fixes or performance and other driver improvements.

This is fun, isn't it?

So - pick your baseline supported GL_VERSION, rely on extensions for higher functionality where you want to use it (but always check availability and provide a fallback path) but for any functionality that's in core for the version you're coding to, don't use the suffixed versions and don't mix-and-match suffixed tokens with non-suffixed calls (or voce-versa).

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

I wondered this for a time, but I think that it doesn't really matter which one you use. Tbh, I even put it to the test with OpenGL and OpenGL ES. Each and every time, the same result... it worked! happy.png

Now, when you have two or more different extensions (i.e. GL_NV_texture_rectangle vs GL_ARB_texture_rectangle vs GL_EXT_texture_rectangle), then chances are you have a vendor specific extension, where using the ARB version is optimal.

In this particular case they're most likely identical on all hardware. Not guaranteed to be, but most likely. There are other cases from newer GL versions where the spec does guarantee them to be identical (see issue 6 at GL_ARB_vertex_array_object for an example) but there are other cases where they are quite clearly not - I mentioned GL_ARB_shader_objects before and you should read it to get a handle on how things can change between ARB extension and core (mix and match that with core and you'll get all kinds of interesting and exciting things happen!) True, it's a worst case, and true, the ARB are unlikely to do it again, but the key lesson is - don't mix and match unless you're absolutely certain they're absolutely identical.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement