Hi, I would like to know if I would loose anything if I pass the modelv matrix, and other stuff like that, that is already available inside a glsl program by a parameter (like Cg does).
I am including GLSL support in my engine and would like to keep the same interface on my shader class implementations. I have to pass this data to Cg… so I can just keep same methods for GLSL but empty ones… or really pass them in parameters.
Does resources are spent just to pass a parameter?
You mean like passing your modelview as a uniform mat4, but not using gl_ModelViewMatrix? In that case, there will be no resources allocated to gl_ModelViewMatrix. So there’s no waste. If you’re using ftransform() though it will of course use gl_ModelViewProjectionMatrix or gl_ModelViewMatrix/gl_ProjectionMatrix to do its work, so that will consume some uniforms.
Originally posted by Humus: You mean like passing your modelview as a uniform mat4, but not using gl_ModelViewMatrix? In that case, there will be no resources allocated to gl_ModelViewMatrix. So there’s no waste.
I’m also interested in this. Would it be a good idea to pass “everything” possible as uniforms? I’d like this to have a unified approach to GPU resources management in my programs.
I wouldn’t do this. Using the defined built-in uniforms should be preferred.
Specifying everything as your own uniforms is your responsibility (bugs) and overhead (performance), whereas using the built-in uniforms are automatically updated, under driver’s (optimized?) control, and the shader code is easier to understand for others due to standardized names.
Originally posted by Obli: I’m also interested in this. Would it be a good idea to pass “everything” possible as uniforms? I’d like this to have a unified approach to GPU resources management in my programs.
If you, like most people, use GLSL mainly because it being a high level language gives you benefits in terms of producitivity and readability of the code, then definitely yes, in most situations you should use uniforms. Exceptions are when transiting your program from the fixed function pipeline or when you’re mixing fixed function and programmable pipeline. In that case it can be more readable if you’re using built-in states.
Personally, the only built-in states that I use normally would be the gl_ModelViewProjectionMatrix. Other than that, I’m always using uniforms.
Originally posted by Relic: I wouldn’t do this. Using the defined built-in uniforms should be preferred.
Specifying everything as your own uniforms is your responsibility (bugs) and overhead (performance), whereas using the built-in uniforms are automatically updated, under driver’s (optimized?) control, and the shader code is easier to understand for others due to standardized names.
Built-ins are preferred only when what you’re doing is directly related to the underlying GL-state. I’ve seen plenty of abuse of built-in state, and there’s just no point of it. If you do per pixel lighting, then use uniforms. Don’t use gl_LightSource[0] just because it has the word “light” in it. It’s not related. If on the other hand you’re implementing your own tweaked GL-lighting, or if you need a fixed function fallback path, then gl_LightSource[0] could make sense.
Speaking of realiability and performance, if there’s any difference, it’s not going to be in favor of built-in states. A uniform updates the value for one and only one program object. Built-in states can potentially update all existing programs. Some variables also depend on multiple GL-states. These variables can also map to completely different shader constants for each program object.
Built-ins are preferred only when what you’re doing is directly related to the underlying GL-state. I’ve seen plenty of abuse of built-in state, and there’s just no point of it. If you do per pixel lighting, then use uniforms.Speaking of realiability and performance, if there’s any difference, it’s not going to be in favor of built-in states. A uniform updates the value for one and only one program object. Built-in states can potentially update all existing programs. Some variables also depend on multiple GL-states. These variables can also map to completely different shader constants for each program object.
one thing im not 100% certain on, if i go glLightfv(…, …) that light is set to the value until i change it eg if i access light_pos . now with various programs is it possible to change the light info once and it changes for all programs. what humus saiz seems to suggest no, from my reading of the spec im not 100% sure. personally i prefer he method of updating all programs at once.
Any shader program using built-in state will reference the current OpenGL state when it is invoked.
Means, set your OpenGL state once and the active program referencing that state will automatically use the current one.
User uniforms are per program state and need to be set manually for each program separately when needed.