Missing DSA functions

There are few DSA functions missing despite the update of the extension and because of a lack of “interact with” in the new OpenGL 4.0 extensions:

  • Attach an element buffer to a VAO
  • Attach a multisample texture to a FBO
  • Attach a transform feedback buffer to a transform feedback object
  • Set a subroutine uniform to a program
  • Set a patch parameter to program

And probably more…

subroutines are context state not program state.

Really? Oo

I have to look at that!

If I remember, we query the subroutine uniform from a program so I can’t imagine how they could be context state. Maybe the suroutine index? Well I don’t see the point either but this is more possible even if I don’t think we could use an index from a program A as a value of a subroutine uniform in a program B. Sound awful to manage inside a renderer anyway considering the OpenGL precedent.

EDIT: I checked, it seams to be a program state.

from OpenGL 4.0 (core profile) spec:

2.11.5 Subroutine Uniform Variables
Subroutine uniform variables are similar to uniform variables, except they are context
state rather than program state. Having subroutine uniforms be context state
allows them to have different values if the program is used in multiple contexts
simultaneously. There is a set of subroutine uniforms for each shader stage.

So you can query it per-program, but will get different results depending on which context is active.

Thanks Dan!

It still feels weird to me. Also I guess AMD implementation doesn’t follows this yet then. :stuck_out_tongue:

the spec also says after a glUseProgram the subroutine context state is reset to some arbitrary defaults. so my take is that the index vector we set for a bound program actually chooses the program permutation compiled with the associated subroutines. so maybe the glUseProgram call should have been substituted with a call taking a program object and an subroutine index vector. but glUseProgram + glUniformSubroutinesuiv does the same job, we just have to call them together on every bind.


Thanks for all these clarifications!

I see but I still don’t understand why it has been designed this way. Some multithreading planning ahead?

For me it’s another lack of consistency of OpenGL :stuck_out_tongue: