GLSL : common mistakes: Difference between revisions

From OpenGL Wiki
Jump to navigation Jump to search
Ldo (talk | contribs)
m glUseProgram: explicit ordering
Flfirsla (talk | contribs)
No edit summary
 
(15 intermediate revisions by 5 users not shown)
Line 6: Line 6:


=== How to use glUniform ===
=== How to use glUniform ===
If you look at all the glUniform functions (glUniform1fv, glUniform2fv, glUniform3fv, glUniform4fv, glUniform1iv, glUniform2iv, glUniform3iv, glUniform4iv, glUniformMatrix4fv and the many others), there is a parameter called count.<br>
If you look at all the {{apifunc|glUniform|*v}} functions, there is a parameter called count.
<br>
What's wrong with this code? Would it cause a crash?<br>
  //Vertex Shader
  uniform vec4 LightPosition;
  //In your C++ code
  float light[4];
  glUniform4fv(MyShader, 4, light);


The problem is that for count, you set it to 4 while it should be 1 because you are sending 1 vec4 to the shader.<br>
What's wrong with this code? Would it cause a crash?
What's wrong with this code? Would it cause a crash?<br>
  //Vertex Shader
  uniform vec2 Exponents;
  //In your C++ code
  float Exponents[2];
  glUniform2fv(MyShader, 2, Exponents);


The problem is that for count, you set it to 2 while it should be 1 because you are sending 1 vec2 to the shader.<br>
<source lang="glsl">
What's wrong with this code? Would it cause a crash?<br>
// Vertex Shader
  //Vertex Shader
uniform vec4 LightPosition;
  uniform vec2 Exponents[5];
</source>
  //In your C++ code
  float Exponents[10];
  glUniform2fv(MyShader, 5, Exponents);


There is nothing wrong with it. We want to send 5 values of vec2.
<source lang="c++">
// In your C++ code
float light[4];
// Fill in `light` with data.
glUniform4fv(MyShader, 4, light);
</source>
 
The problem is that for count, you set it to 4 while it should be 1 because you are sending '''1''' {{code|vec4}} to the shader. The count is the number of that type (4f, which corresponds to {{code|vec4}}) that you are setting.
 
Consider this:
<source lang="glsl">
// Vertex Shader
uniform vec2 Exponents[5];
</source>
 
<source lang="c++">
// In your C++ code
float Exponents[10];
glUniform2fv(MyShader, 5, Exponents);
</source>
 
This is correct. The length of the array is 5, which is what we tell {{apifunc|glUniform|2fv}}.


=== glUniform doesn't work ===
=== glUniform doesn't work ===


You probably did not bind the correct shader first. Call glUseProgram(myprogram) first.
You probably did not bind the correct shader first. Call {{apifunc|glUseProgram|(myprogram)}} first.
 
=== glGetUniformLocation and glGetActiveUniform ===
Although not strictly a mistake, some wonder why {{apifunc|glGetUniformLocation}} returns -1. If there is a uniform that you are not using, the driver will optimize your uniform out. Drivers are really good at optimizing code. If you are using your uniform, but none of the values computed from that uniform contribute to any output from the shader (directly or indirectly), the uniform will usually be optimized out.


=== glGetUniformLocation ===
Typically this is not a problem, since if you pass -1 instead of a valid uniform location to the {{apifunc|glUniform}} calls, they will quietly do nothing anyway. But you will also get -1 if you misspell the variable name to {{apifunc|glGetUniformLocation}}, so keep this in mind.
Although not strictly a mistake, some wonder why glGetUniformLocation returns -1. If there is a uniform that you are not using, the driver will optimize your uniform out. Drivers are really good at optimizing code. If you are using your uniform and it is clear that the uniform will never effect the output, the uniform will get optimized out.


=== glUseProgram ===
=== glUseProgram ===
When should you call glUseProgram?
When should you call {{apifunc|glUseProgram}}?
 
glUseProgram needs to be called before you setup a uniform. There are several versions of the glUniform* function depending if your variable is a single float, vec2, vec3, vec4, a matrix, etc. Notice that the glUniform* functions do not take the program ID (your shader) as a parameter.


What if you want to get the location of a uniform? Notice that glGetUniformLocation takes the program ID (your shader) as a parameter. No, you do not need to call glUseProgram before calling glGetUniformLocation.
{{apifunc|glUseProgram}} needs to be called before you setup a uniform (unless you have GL 4.1 or {{extref|separate_shader_objects}}, and can use {{apifunc|glProgramUniform}}). There are several versions of the {{apifunc|glUniform}} function depending if your variable is a single float, vec2, vec3, vec4, a matrix, etc. Notice that the {{apifunc|glUniform}} functions do not take the program ID (your shader) as a parameter.


What if you want to render? glUseProgram needs to be called before you use glDrawArrays or glDrawElements or glDrawRangeElements or whatever draw function you are using. It may seem obvious that you need to bind your shader before you render your object but some newcomers seem to call glUseProgram after glDrawArrays or glDrawElements or glDrawRangeElements or whatever.
Getting the location of a uniform, such as from {{apifunc|glGetUniformLocation}}, does not require calling {{apifunc|glUseProgram}}. {{apifunc|glGetUniformLocation}} already takes the program to get the location from.


=== Uniform Names in VS, GS and FS ===
{{apifunc|glUseProgram}} is needed for rendering. You must use the program you intend to render with before issuing a [[Vertex Rendering|rendering call]].


So what happens if you have the same exact uniform name in both the vertex shader and geometry shader and fragment shader?
=== Uniform Names across shader stages ===


Yes, it is legal to have the same uniform name in all shaders.
It is legal to have the same uniform defined in different shader stages.


When you call glGetUniformLocation, it will return one location. When you update the uniform with a call to glUniform, the driver takes care of sending the value for each stage (vertex shader, geometry shader, fragment shader).
When you call {{apifunc|glGetUniformLocation}}, it will return one location. When you update the uniform with a call to {{apifunc|glUniform}}, the driver takes care of sending the value for each stage (vertex shader, geometry shader, fragment shader).


This is because a GLSL program contains all of the shader stages at once. Programs do not consider uniforms in a vertex shader to be different from uniforms in a fragment shader.
This is because a GLSL program contains all of the shader stages at once. Programs do not consider uniforms in a vertex shader to be different from uniforms in a fragment shader.
Keep in mind that this applies to all uniforms : float, vec2, vec3, vec4, mat3, mat4, bool, sampler2D, sampler3D and the many others.


== Miscellaneous ==
== Miscellaneous ==


=== Enable Or Not To Enable ===
=== Enable Or Not To Enable ===
With fixed pipeline, you needed to call <code>glEnable(GL_TEXTURE_2D)</code> to enable 2D texturing. You needed to call <code>glEnable(GL_LIGHTING)</code>. Since shaders override these functionalities, you don't need to glEnable/glDisable. If you don't want texturing, you either need to write another shader that doesn't do texturing or you can attach a all white or all black texture, depending on your needs. You can also write one shader that does lighting and one that doesn't.
With fixed pipeline, you needed to call <code>glEnable(GL_TEXTURE_2D)</code> to enable 2D texturing. You also needed to call <code>glEnable(GL_LIGHTING)</code>. Since shaders override these functionalities, you don't need to glEnable/glDisable. If you don't want texturing, you either need to write another shader that doesn't do texturing, or you can attach an all-white or all-black texture, depending on your needs. You can also write one shader that does lighting and one that doesn't.


Things that are not overriden by shaders, like the alpha test, depth test, stencil test... calling glEnable/glDisable will have an effect.
For things that are not overriden by shaders, like the alpha test, depth test, stencil test, calling glEnable/glDisable ''will'' have an effect.


=== Binding A Texture ===
=== Binding A Texture ===
Line 75: Line 78:
nVidia drivers are more relaxed. For example:
nVidia drivers are more relaxed. For example:


float myvalue = 0;
<source lang="glsl">
float myvalue = 0;
</source>


The above is not legal according to the GLSL specification 1.10, due to the inability to automatically convert from integers (numbers without decimals) to floats (numbers with decimals). Use 0.0 instead. With GLSL 1.20 and above, it is legal because it will be converted to a float.
The above is not legal according to the GLSL specification 1.10, due to the inability to automatically convert from integers (numbers without decimals) to floats (numbers with decimals). Use 0.0 instead. With GLSL 1.20 and above, it is legal because it will be converted to a float.


float myvalue1 = 0.5f;
<source lang="glsl">
float myvalue2 = 0.5F;
float myvalue1 = 0.5f;
float myvalue2 = 0.5F;
</source>


The above is not legal according to the GLSL specification 1.10. With GLSL 1.20, it becomes legal.
The above is not legal according to the GLSL specification 1.10. With GLSL 1.20, it becomes legal.


float texel = texture2D(tex, texcoord);
<source lang="glsl">
float texel = texture2D(tex, texcoord);
</source>


The above is wrong since <code>texture2D</code> returns a <code>vec4</code>. Do one of these instead:
The above is wrong since <code>texture2D</code> returns a <code>vec4</code>. Do one of these instead:


float texel = texture2D(tex, texcoord).r;
<source lang="glsl">
float texel = texture2D(tex, texcoord).x;
float texel = texture2D(tex, texcoord).r;
 
float texel = texture2D(tex, texcoord).x;
=== Functions inputs and outputs ===
</source>
 
Functions should look like this
vec4 myfunction(inout float value1, in vec3 value2, in vec4 value3)
instead of
vec4 myfunction(float value1, vec3 value2, vec4 value3)


=== Not Used ===
=== Not Used ===
In the vertex shader
In the vertex shader
gl_TexCoord[0] = gl_MultiTexCoord0;
<source lang="glsl">
gl_TexCoord[0] = gl_MultiTexCoord0;
</source>
and in the fragment shader
and in the fragment shader
vec4 texel = texture2D(tex, gl_TexCoord[0].xy);
<source lang="glsl">
vec4 texel = texture2D(tex, gl_TexCoord[0].xy);
</source>


zw isn't being used in the fs.<br>
zw isn't being used in the fs.<br>
Line 111: Line 119:


=== Sampling and Rendering to the Same Texture ===
=== Sampling and Rendering to the Same Texture ===
{{main|Framebuffer_Object#Feedback_Loops}}
Normally, you should not sample a texture and render to that same texture at the same time. This would give you undefined behavior. It might work on some GPUs and with some driver version but not others.
Normally, you should not sample a texture and render to that same texture at the same time. This would give you undefined behavior. It might work on some GPUs and with some driver version but not others.


The extension [[http://www.opengl.org/registry/specs/NV/texture_barrier.txt GL_NV_texture_barrier]] can be used to avoid this in certain ways. Specifically, you can use the barrier to ping-pong between two regions of the same texture without having to switch textures or buffers or anything. You still don't get to read and write to the same location in a texture at the same time unless there is only a single read and write of each texel, and the read is in the fragment shader invocation that writes the same texel.
The [[Texture Barrier]] feature can be used to avoid this in certain ways. Specifically, you can use the barrier to ping-pong between two regions of the same texture without having to switch textures or buffers or anything. You still don't get to read and write to the same location in a texture at the same time unless there is only a single read and write of each texel, and the read is in a fragment shader invocation that covers the same sample as the texel it is writing.


[[Category:OpenGL Shading Language]]
[[Category:OpenGL Shading Language]]
[[Category:Best Practices]]
[[Category:Best Practices]]

Latest revision as of 11:31, 2 January 2018

The following article discusses common mistakes made in the OpenGL Shading Language, GLSL.

Uniforms

How to use glUniform

If you look at all the glUniform*v functions, there is a parameter called count.

What's wrong with this code? Would it cause a crash?

// Vertex Shader
uniform vec4 LightPosition;
// In your C++ code
float light[4];
// Fill in `light` with data.
glUniform4fv(MyShader, 4, light);

The problem is that for count, you set it to 4 while it should be 1 because you are sending 1 vec4 to the shader. The count is the number of that type (4f, which corresponds to vec4) that you are setting.

Consider this:

// Vertex Shader
uniform vec2 Exponents[5];
// In your C++ code
float Exponents[10];
glUniform2fv(MyShader, 5, Exponents);

This is correct. The length of the array is 5, which is what we tell glUniform2fv.

glUniform doesn't work

You probably did not bind the correct shader first. Call glUseProgram(myprogram) first.

glGetUniformLocation and glGetActiveUniform

Although not strictly a mistake, some wonder why glGetUniformLocation returns -1. If there is a uniform that you are not using, the driver will optimize your uniform out. Drivers are really good at optimizing code. If you are using your uniform, but none of the values computed from that uniform contribute to any output from the shader (directly or indirectly), the uniform will usually be optimized out.

Typically this is not a problem, since if you pass -1 instead of a valid uniform location to the glUniform calls, they will quietly do nothing anyway. But you will also get -1 if you misspell the variable name to glGetUniformLocation, so keep this in mind.

glUseProgram

When should you call glUseProgram?

glUseProgram needs to be called before you setup a uniform (unless you have GL 4.1 or ARB_separate_shader_objects, and can use glProgramUniform). There are several versions of the glUniform function depending if your variable is a single float, vec2, vec3, vec4, a matrix, etc. Notice that the glUniform functions do not take the program ID (your shader) as a parameter.

Getting the location of a uniform, such as from glGetUniformLocation, does not require calling glUseProgram. glGetUniformLocation already takes the program to get the location from.

glUseProgram is needed for rendering. You must use the program you intend to render with before issuing a rendering call.

Uniform Names across shader stages

It is legal to have the same uniform defined in different shader stages.

When you call glGetUniformLocation, it will return one location. When you update the uniform with a call to glUniform, the driver takes care of sending the value for each stage (vertex shader, geometry shader, fragment shader).

This is because a GLSL program contains all of the shader stages at once. Programs do not consider uniforms in a vertex shader to be different from uniforms in a fragment shader.

Miscellaneous

Enable Or Not To Enable

With fixed pipeline, you needed to call glEnable(GL_TEXTURE_2D) to enable 2D texturing. You also needed to call glEnable(GL_LIGHTING). Since shaders override these functionalities, you don't need to glEnable/glDisable. If you don't want texturing, you either need to write another shader that doesn't do texturing, or you can attach an all-white or all-black texture, depending on your needs. You can also write one shader that does lighting and one that doesn't.

For things that are not overriden by shaders, like the alpha test, depth test, stencil test, calling glEnable/glDisable will have an effect.

Binding A Texture

NVIDIA and Types

nVidia drivers are more relaxed. For example:

float myvalue = 0;

The above is not legal according to the GLSL specification 1.10, due to the inability to automatically convert from integers (numbers without decimals) to floats (numbers with decimals). Use 0.0 instead. With GLSL 1.20 and above, it is legal because it will be converted to a float.

float myvalue1 = 0.5f;
float myvalue2 = 0.5F;

The above is not legal according to the GLSL specification 1.10. With GLSL 1.20, it becomes legal.

float texel = texture2D(tex, texcoord);

The above is wrong since texture2D returns a vec4. Do one of these instead:

float texel = texture2D(tex, texcoord).r;
float texel = texture2D(tex, texcoord).x;

Not Used

In the vertex shader

gl_TexCoord[0] = gl_MultiTexCoord0;

and in the fragment shader

vec4 texel = texture2D(tex, gl_TexCoord[0].xy);

zw isn't being used in the fs.
Keep in mind that for GLSL 1.30, you should define your own vertex attribute.
This means that instead of gl_MultiTexCoord0, define AttrMultiTexCoord0.
Also, do not use gl_TexCoord[0]. Define your own varying and call it VaryingTexCoord0.


Sampling and Rendering to the Same Texture

Normally, you should not sample a texture and render to that same texture at the same time. This would give you undefined behavior. It might work on some GPUs and with some driver version but not others.

The Texture Barrier feature can be used to avoid this in certain ways. Specifically, you can use the barrier to ping-pong between two regions of the same texture without having to switch textures or buffers or anything. You still don't get to read and write to the same location in a texture at the same time unless there is only a single read and write of each texel, and the read is in a fragment shader invocation that covers the same sample as the texel it is writing.