Question

I’m confused about the real differences, if any, between the shader APIs integrated into the GL standard as of GL 2.0, and the shader API in the GL_ARB_vertex_program extension (and friends).

I take it that there are machines out there that might, for example, support glLinkProgramARB, but which might not yet support glLinkProgram. So what’s the benefit of using the non-ARB versions? Or is there none.

Answer 1

There are machines out there that might do a lot of things. There are machines that might not implement EXT_texture_filter_anisotropic. There are machines that might implement fragment shaders without vertex shaders. And so on.

The question you should ask your self is: do you care? Is it worthwhile to spend time and effort to support such machines? And do you want to support them in this way, rather than writing a fixed-function solution that will support them as well as older, non-shader hardware?

In general, if a driver doesn’t support 2.0, then I would suggest writing a 1.4-based rendering path for that driver. Either abandon shaders altogether for that hardware or, at most, use assembly shaders.

In any case, there is no compatibility between the extension version of GLSL (which FYI, is not exposed with GL_ARB_vertex_program. It’s GL_ARB_shader_objects, with GL_ARB_vertex_shader and/or GL_ARB_fragment_shader as appropriate) and the core version. So any new functions added since then, such as between 2.0 and 2.1, 2.1 and 3.0, etc, would not be available to it. You can’t shove a GLhandleARB into a function that expects a GLuint. Nor will functions that look for objects bound with glUseProgram(GLuint) work with the extension equivalent.