GetActiveUniform index parameter

According to the spec (version 2.1, page 80), regarding the index parameter in glGetActiveUniform:

Note that index simply identifies a member in a list of active uniforms, and has no relation to the location assigned to the corresponding uniform variable.
Are we to infer from this that the index parameter is not to be taken as the position of the uniform as declared in the shader? In other words, if I have

uniform samplerCube EnvSampler;
uniform sampler2D DiffSampler;
uniform vec4 EyePosition;
uniform vec4 LightPosition;
uniform vec4 LightColor;

then an index of 4 will always return LightPosition, or more generally the 4th declared active uniform?

It might be nice to be able to rely on this ordering, for purposes of binding samplers (if nothing else).

P.S. My NV40 quietly allows a semantic attached to uniforms, like
uniform sampler2D mySampler : FOOBAR;
Any idea why?

Originally posted by Leghorn:
Are we to infer from this that the index parameter is not to be taken as the position of the uniform as declared in the shader?

The compiler is imho free to order the list of the active uniforms in any way it likes regardless of order in which they were declared in the shader. Theoretically the order might even change during each call to LinkProgram altrough that is unlikely if the program does not change.


P.S. My NV40 quietly allows a semantic attached to uniforms, like
uniform sampler2D mySampler : FOOBAR;
Any idea why?

As far as I know the nVidia GLSL compiler utilizes the same code generation backend as theirs CG compiler and theirs GLSL frontend allows some CG like constructs so this might be one from them. Latest versions of the driver at least warn about such constructs in compilation logs however the older versions accepted them silently.

Thanks, Komat.

Let me rephrase the question: why is there no semantic/metadata mechanism in glsl? Short of the planned intermediate language, which I presume they’re working on now, there’s no way to set uniforms without knowledge of the names in the shader, which makes it extremely cumbersome to write higher level scripts/wrappers for glsl (without actually parsing the shader yourself!). Anyone who has worked with fx files knows what I’m talking about and recognizes the value of such a construct; it’s nothing new.

If Nvidia has seen fit to add this feature, which is bound to be a trivial addition, why not expose a function to access this information in the API? At the very least, a simple semantic would be a start:

uniform sampler2D chickenFeathers: unit0; 

...

glGetActiveUniform(..., int maxSemanticLength, char* semantic);
glGetActiveUniformSemantic(...);
glGetActiveUniformMetadata(...);

Is anything along these lines planned for OpenGL 3.0? This doesn’t require the addition of a string type to the language (though that would likely be better for the purpose of encapsulating generic, user defined metadata–the compiler needn’t know or care about the contents).

Those APIs already exist. As always, check the spec.

Those APIs already exist.
What APIs?

It might be nice to be able to rely on this ordering
…and give up the performance.
The active uniform index is meant to be continous, but uniform location can be anything. If we are to force uniform locations to be continous we will have to sacrifice a bit of performance.
Let’s look at gl_Light[i].position - it could be implemented as uniform and it could have fixed location - your application cannot use this location for it’s own uniform. If your uniform locations are to be in continous space, then driver would have to do re-mapping every time you call glUniform. Also, keep in mind than you can link multiple shaders into one program. The same shaders used in different combinations simply need to have uniforms attached to different locations when linked.

why is there no semantic/metadata mechanism in glsl
Perhaps because the KISS rule :slight_smile: I have all my uniforms well handled and automated in my framework and it’s all so simple - no need for any abstract mechanisms if you can keep your feet to the ground.

[quote]Originally posted by Leghorn:
[b]

void GetActiveUniformARB(handleARB programObj, uint index, sizei maxLength,
			     sizei *length, int *size, enum *type, charARB *name)
int GetUniformLocationARB(handleARB programObj, const charARB *name)

void GetActiveUniformARB(handleARB programObj, uint index, sizei maxLength,
sizei *length, int *size, enum *type, charARB *name)
int GetUniformLocationARB(handleARB programObj, const charARB *name)
Hehe… Yes, but those don’t return a user defined semantic :slight_smile:

What would be even better is a generic annotation syntax, for describing sampler states and whatnot.

Wouldn’t that be cool? I don’t know; I’m beginning to feel alone in this thing, like a mushroom in a dark room.

Yes, queriable user defined data associated with the variables can be usefull. Currently the only way you can add that directly to the shader is to use some easy to parse syntax stored inside comments within the shader.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.