Jump to content

  • Log In with Google      Sign In   
  • Create Account

[Solved] Difference between GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 thecheeselover   Members   -  Reputation: 330

Like
0Likes
Like

Posted 12 March 2013 - 05:56 PM

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!

Sponsor:

#2 Brother Bob   Moderators   -  Reputation: 8596

Like
1Likes
Like

Posted 12 March 2013 - 06:21 PM

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.


Edited by Brother Bob, 12 March 2013 - 06:22 PM.


#3 mhagain   Crossbones+   -  Reputation: 8276

Like
3Likes
Like

Posted 12 March 2013 - 06:28 PM

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


Edited by mhagain, 12 March 2013 - 06:29 PM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 blueshogun96   Crossbones+   -  Reputation: 1094

Like
1Likes
Like

Posted 12 March 2013 - 07:28 PM

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.


Follow Shogun3D on the official website: http://shogun3d.net

 

blogger.png twitter.png tumblr_32.png facebook.png

 

"Yo mama so fat, she can't be frustum culled." - yoshi_lol


#5 mhagain   Crossbones+   -  Reputation: 8276

Like
1Likes
Like

Posted 12 March 2013 - 07:41 PM

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.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS