GL_CURRENT_PROGRAM has been renamed GL_ACTIVE_PROGRAM, but is also part of a program pipeline object now.
A program pipeline object is sort of like a vertex array object, but for grouping together programs attached to each stage of the pipeline.
a program pipeline object contains:
-active program - glUniformXXX calls affect this program
-vertex shader program - attached to vertex shader stage.
-geometry shader program - attached to geometry shader stage.
-tess control program - attached to tess control shader stage.
-tess evaluation program - attached to tess evaluation shader stage.
-fragment shader program - attached to fragment shader stage.
Binding a different program pipeline object will change all this state in one go.
Calling glUseProgram(prog) binds prog to each state of the current program pipeline object. Calling glUseProgramStages(pipeline, GL_VERTEX_SHADER_BIT | GL_FRAGMENT_SHADER_BIT, prog); will attach prog to the vertex shader + fragment shader stages of the current program pipeline object.
The spec actually says that GL_ACTIVE_PROGRAM should be retrieved with glGetProgramPipelineiv(pipeline, GL_ACTIVE_PROGRAM, &active_prog); And doesn’t mention being able to retrieve it with glGetInteger at all, although it probably still works (haven’t tested it).
I’m currently trying to produce a more readable html version of the 4.1 core spec state table, because it’s hard for people to know what state belongs to what, with bind-to-edit hiding what is actually being modified.
The OpenGL spec just has the program pipeline object state + related context state dumped in with the program object state at the moment, but they should really be separated. The program object state PROGRAM_SEPARABLE that indicates whether a program is separable is missing from the table too.
I’d avoid glGetXXX calls where possible, because depending on how they’re implemented by the driver could have a large impact on performance, and it’s hard to tell which ones will have an impact. Even NVidia had slow glGet calls that didn’t need to be slow at one time when they re-wrote part of their driver. This is mentioned at http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=235486 (I assume it’s improved now - but not sure).
Some glGet calls will always force certain operations before them to be completed before you can get the result, such as reading pixels after drawing/reading buffer data after writing, or getting query results before polling to see if the result is ready.
ps. Does anyone know what the initial value for PROGRAM_SEPARABLE is meant to be? I assume it’s FALSE, but could be TRUE just as easily.