Pushing / popping the current program

[phoenix_wrath]

Hello Forum.
With the spec for OpenGL4.1 , there are tons of deprecations.
One of them is the fact that glPushAttrib will no longer be there as of 4.1.

Here is the challenge : Suppose one of my vendoes creates a 3D engine based on OpenGL and lets me intervene in a post-Draw stage, after the whole scene was drawn (For my own reasons). In the standard fixed-function architecture I pushAttrib to all attrib bits, change the states of the machine , and then do my stuff. When I'm done , I popAttrib and all is well. As of 4.1 it won't be this way. Almost everything will be in the shader program , which is fine with me, yet I could not find a way to "Push" the current shader program and then "pop" it , there is no getprogram which returns the current active program so that I may keep its ID , insert my program , and when done , re- use the old ID in order to re-activate the old program. Did I miss anything about that in the spec , or is it something there is a solution for (Or is it something the ARB needs to think about)? something like getProgram with (0) returns the current running program ID....
Thank you .

[YarUnderoaker]

Sounds like the right hand does not know what left hand is doing. You must make your state machine, which remembers the current shader program.

[carsten neumann]

GLint currProgram;
glGetIntegerv(GL_CURRENT_PROGRAM, &currProgram);

[Dark Photon]

As of 4.1 it won't be this way.

Unless you allocate a compatibility profile.

[YarUnderoaker]

GLint currProgram;
glGetIntegerv(GL_CURRENT_PROGRAM, &currProgram);

gDebugger said

Using "Get" or "Is" functions slows down render performance. These commands force the graphic system to execute all queued OpenGL calls before it can answer the "Get" or "Is" query.

[Leith Bade]

You could hook glUseProgram and track the last used program yourself...

[Alfonse Reinheart]

Using "Get" or "Is" functions slows down render performance. These commands force the graphic system to execute all queued OpenGL calls before it can answer the "Get" or "Is" query.

That's a lie. It might cause that, depending on the get in question. But simply asking what object is bound to what binding point would not have to cause that.

[YarUnderoaker]

glUseProgram(1); // Async call, command stored to queue
glUseProgram(2); // Async call, command stored to queue
glGetIntegerv(GL_CURRENT_PROGRAM, &currProgram); // Wait for all queue executing, read state from GPU -> because OpenGL do not have internal state machine and just brute-force switching state (send command to GPU) to prevent mismatch for sake of stability

[Alfonse Reinheart]

glUseProgram(1); // Async call, command stored to queue

Here's what this call actually looks like (in pseudo-code):

void glUseProgram(GLuint programId)
{
  if(g_context->IsTransformFeedbackActive())
  {
    OpenGLError(GL_INVALID_OPERATION);
    return;
  }
 
  if(!ProgramIdWasGenerated(programId))
  {
    OpenGLError(GL_INVALID_VALUE);
    return;
  }
  if(!IsProgramId(programId))
  {
    OpenGLError(GL_INVALID_OPERATION);
    return;
  }
 
  ProgramObject *pProgram = GetProgramFromId(programId);
 
  if(!pProgram->IsSuccessfullyLinked())
  {
    OpenGLError(GL_INVALID_OPERATION);
    return;
  }
 
  g_context->pCurrProgram = pProgram;
  g_context->currProgramId = programId;
}

This is all context state. Nothing is stored in a queue, because none of this command executes asynchronously.

The call to IsSuccessfullyLinked (checking if the program was linked) must happen synchronously. The OpenGL spec requires it.

Binds are not asynchronous. Especially program object binding. Remember: until you render with the program, or change the program's state, the GPU neither knows nor cares what you bind to the context.

The kind of state where you might have to wait are things that aren't error checked (outside of making sure that the inputs are within tolerances). Like what the current blend function is. Or the current polygon winding mode. And so forth. Things that translate directly to the GPU doing something.

Binding a program does not require the GPU to do something. Implementations may initiate a DMA when binding a program, since it suggests intent to render. But considering the need to bind to modify uniforms, even that is somewhat unlikely.

[phoenix_wrath]

Thanks everybody for the kind responses. I like it where my questions arise a debate.

As for YarUnderoaker: A sentence like :
"Sounds like the right hand does not know what left hand is doing" is not very unuseful in forums like this, consider trying to deeper understand the question, reading the 4.1 spec rather than teaching everyone your deductive logic.

As for the topic discussed:
I didn't find the glGetIntegerv(GL_CURRENT_PROGRAM, &currProgram); on the new 4.1 spec, will it still be supported ?
As of the 4.1 there will still be support for UseProgram , yet a new , more encapsulated Pipeline emerges from 4.1 , and there is a comment about CURRENT_PROGRAM becomming ACTIVE_PROGRAM there, yet again , there is no GetIntegerv with a CURRENT_PIPE or ACTIVE_PIPE so that if I am creating an Engine , yieling control to the user at a post-draw stage, I must instruct the user to call some "Push current engine state" method and "pop current engine state method" in order for the state to be kept. Am I right ? Thise does remind me a bit of DX....