Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualmhagain

Posted 12 March 2013 - 06:29 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).


#2mhagain

Posted 12 March 2013 - 06:29 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).

#1mhagain

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


PARTNERS