OpenGL Shading Language: Difference between revisions

From OpenGL Wiki
Jump to navigation Jump to search
(Adding infobox.)
(Augmented the article with more info. Still needs work.)
Line 1: Line 1:
{{missing}}
{{infobox feature
{{infobox feature
| core = 2.0
| core = 2.0
Line 4: Line 6:
}}
}}


The '''OpenGL Shading Language''' (GLSL) is a high level [[shading language]] with a C-like syntax. It was approved by OpenGL Architecture Review Board (ARB) for programming OpenGL compliant programmable hardware, thus giving developers more control of the graphics pipeline at the lowest level.
The '''OpenGL Shading Language''' (GLSL) is the principle [[shading languages]] for OpenGL. While there are several shading languages available for use in OpenGL, GLSL is the only one that is a part of the OpenGL core.
 
GLSL is a C-style language. The language has undergone a number of version changes, and it shares the deprecation model of OpenGL. The current version of GLSL is 1.50.
 
== Compilation model ==
 
GLSL is quite unique among shading languages due to its compilation model. Most shading languages use a simple, one-stage model: you give it a string representing a shader for one of the shader stages, and it gives you a shader object that you can bind to the context and render with.
 
GLSL uses a more complicated model based on the compilation of C programs. In C, a compilation unit, typically a single source file that may include several external header files, is compiled into an object file. A number of object files are then linked into a single program.
 
GLSL operates in a similar fashion. A set of source files, given as a series of strings, are compiled into a shader object. This is the analog of an object file. Unlike typical shading languages, there is no requirement that this shader object represent a full shader stage. The only limitation is that it can only compile code that is appropriate for a single, specific shader stage.
 
Shader objects are useless in that form, just as object files from compiled C programs are useless directly. Shader objects must be linked into a single program object. Unlike most shader languages, the program objects contain ''all'' shader stages at once. Only one program can be bound for rendering at any one time, and it is illegal for a program object to omit certain stages entirely.
 
{{legacy note|If the fixed-function pipeline is available, a program can omit one or more stages that the fixed-function pipeline can cover.}}
 
=== Terminology ===
 
Because of GLSL's unique compilation model, GLSL uses unique terminology.
 
According to GLSL's standard terminology, a ''shader'' is just a compiled set of strings for a particular programmable stage; it does not even need to have the complete code for that stage. A ''program'' is a fully linked program that covers multiple programmable stages.
 
For the sake of clarity, we will adjust this slightly. When the term ''shader'' is used, it will be synonymous with the GLSL concept of ''program''. To refer to a GLSL shader, the term ''shader object'' will be used.
 
== Language ==
 
GLSL is a C-style language, so it covers most of the features you would expect with such a language. Control structures (for-loops, if-else statements, etc) exist in GLSL, including the <code>switch</code> statement. This section will not cover the entire language in detail; the [http://www.opengl.org/documentation/glsl/ GLSL specification] can handle that. This section will hit the highlights of the important differences between GLSL and C.
 
=== Basic types ===
 
C has a number of basic types. What C does not have the concept of is basic vector-types: a basic type that intrinsically store more than one value. The OpenGL Shading Language does define vector types.
 
The basic non-vector types are:
 
* bool: conditional type, values may be either true or false
* int: a signed integer
* uint: an unsigned integer
* float: a floating point number
 
Each of these types, including booleans, can have 2, 3, and 4-component vector equivalents. The ''n'' digit below can be 2, 3, or 4:
 
* bvec''n'': a vector of booleans
* ivec''n'': a vector of signed integers
* uvec''n'': a vector of unsigned integers
* vec''n'': a vector of floating-point numbers
 
Vector values can have the same math operators applied to them that scalar values do. These all perform the component-wise operations on each component. However, in order for these operators to work on vectors, the two vectors must have the same number of components.
 
You can access vectors using the following syntax:
 
<pre>
vec4 someVec;
someVec.x + someVec.y;
</pre>
 
This is called ''swizzling''. You can use x, y, z, or w, referring to the first, second, third, and fourth components, respectively.
 
The reason it has that name swizzling is because the following syntax is entirely valid:
 
<pre>
vec2 someVec;
vec4 otherVec = someVec.xyxx;
vec3 thirdVec = otherVec.zyy;
</pre>
 
You can use any combination of up to 4 of the letters to create a vector (of the same basic type) of that length. So <code>otherVec.zyy</code> is a vec3, which is how we can initialize a vec3 value with it. Any combination of up to 4 letters is acceptable, so long as the source vector actually has those components. Attempting to access the 'w' component of a vec3 for example is a compile-time error.
 
Additionally, there are 3 sets of swizzle masks. You can use xyzw, rgba (for colors), or stpq (for texture coordinates). These three sets have no actual difference; they're just syntactic sugar.
 
==== Matrices ====
 
In addition to vectors, there are also matrix types. All matrix types are floating-point. Matrix types are as follows, where ''n'' and ''m'' can be the numbers 2, 3, or 4:
 
* mat''n''x''m'': A matrix with ''n'' columns and ''m'' rows. OpenGL uses column-major matrices, which is standard for mathematics users.
* mat''n'': A symmetric matrix with ''n'' columns and rows. This type is equivalent to
 
Swizzling does not work with matrices. You can instead access a matrix's fields with array syntax:
 
<pre>
mat3 theMatrix;
theMatrix[1] = vec3(3.0, 3.0, 3.0); //Sets the second column to all 3.0s
theMatrix[2][0] = 16.0; //Sets the first entry of the third column to 16.0.
</pre>
 
 
==== Structs and arrays ====
 
 
 
==== Constructors =====
 
All types have constructor syntax that allows you to create values of that type. Constructors use this general syntax:
 
  ''type''(''value'', ''value'', ...);
 
The ''type'' is the type you wish to create, be it scalar, vector, matrix, struct, or array.
 
Constructors for scalar types are special. They can
 
 
 
 
==== Samplers ====
 
Texture access is not as simple as reading a value from a memory address. Filtering and other processes are applied to textures, and how texture coordinates are interpreted can be part of the texture access operation. For these reason, texture access is somewhat complicated.
 
It starts with ''samplers'', a special type that GLSL defines. Each sampler represents a texture that is attached to the program. Samplers have a type that defines what kind of texture can be attached to them. The following samplers types are available:
 
* ''sampler1D''
* ''sampler2D''
* ''sampler3D''
* ''samplerCube''
* ''sampler2DRect''
* ''sampler1DShadow'': For doing shadow texture accesses. Depth formats are not required.
* ''sampler2DShadow''
* ''samplerCubeShadow''
* ''sampler2DRectShadow''
* ''sampler1DArray'': For array textures.
* ''sampler2DArray''
* ''sampler1DArrayShadow''
* ''sampler2DArrayShadow''
* ''samplerBuffer'': For [[Texture Buffers|buffer textures]]
* ''sampler2DMS'': For [[Multisample Textures|multisample textures]].
* ''sampler2DMSArray''
 
These samplers are for textures with floating-point [[Image Formats|image formats]]. For textures with integral image formats, you can preceed the sampler type with "i" for signed integers or "u" for unsigned integers. However, there are no integral "shadow" samplers.
 
 
=== Uniforms ===
 
The user of shaders is able to attach constant values to the linked program. These values are called "uniforms". There is special GLSL syntax for defining uniform variables.
 
 
 
==== Uniform blocks and buffers ====
 
 


==Background==
=== Stage inputs and outputs ===
The first forms of programmable GPUs appeard with the nVidia TNT series and with them came the nVidia register combiners (NV_register_combiners) for programming them. Though register combiners were not strictly a programming language they did give the programmer more freedom in terms of manually setting up the fragment end of the pipeline and doing cool effects, that were previously achieved in software for educational purposes and were too slow to be commercially viable.


Later on more support for fragment pipeline setup was provided in the form of NV_register_combiners2, NV_texture_shader, NV_texture_shader2 and NV_texture_shader3.  
Each stage in the shader pipeline can define a number of input values and a number of output values. There is an implementation-defined maximum number of inputs and outputs for each stage.


NVidia, later on came up with vertex programs (NV_vertex_program) with their Geforce 3 series. Vertex programs were much more convenient and provided the programmers with an assembly language for programming the GPU and loading those programs via an API.  
In a very few cases, there are also certain built-in outputs or inputs that can be used. These are generated or required by fixed-functionality processes. However, most inputs and outputs are user-defined.


Over the years different efforts from different IHVs (Independent Hardware Vendors) were combined and finally resulted in ARB_vertex_program (approved by ARB in June, 2002) and ARB_fragment_program (approved by ARB in September, 2002), and ATI was the first IHV to support them with their Radeon 9700 card.  
GLSL creates linkage between outputs from one stage and inputs to the next stage very simply. Because the entire program consists of all stages at once, the linkage is made via matching the variable names. It is illegal for the types of the two ; this will cause a linker error, similar to how defining the same non-static function in two different C object files is an error.


In the meantime 3DLabs had been considering options to "overhaul" the OpenGL API, dubbed OpenGL 2.0. This was supposed to be the first major revision of the API since OpenGL 1.1 back in the mid-90s. This was necessary because they were competing with, what was becoming an extremely popular API for games, DirectX 9.0 from Microsoft. Alongwith other proposals, one of the major component was a high level shading language that would provide the programmer with a high level syntax for programming the GPU. Dubbing it '''OpenGL Shading Language (GLSL)''' the proposal was presented to ARB and was finally accepted in June 2003 (OpenGL 1.5). New extensions (ARB_shading_language_100, ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader) were introduced which gave birth to GLSL 1.00 in June, 2003.


In September, 2004 (SIGGRAPH) OpenGL 2.0 specifications were released by the ARB with GLSL 1.10 as the shading language (a few modifications from GLSL 1.00).


==Details==
==== Attributes and draw buffers ====
===Data types===
The OpenGL Shading Language Specification defines 22 basic data types, some are the same as used in the C programming language, while others are specific to graphics processing.


*void – used for functions that do not return a value
For the stages at the start and end of the pipeline (vertex and fragment, respectively), the initial input values and final output values do not come from or go to shader stages. The input values to a vertex shader come from [[Vertex Attributes|vertex data]] [[Vertex Specification|specified]] in a [[Vertex Array Objects|vertex array object]], pulled from [[Vertex Buffer Objects|vertex buffer objects]]. The output values of a fragment shader are piped to particular buffers for the currently bound framebuffer; either the [[Default Framebuffer|default framebuffer]] or a [[Framebuffer Objects|framebuffer object]].
*bool – conditional type, values may be either true or false
*int – a signed integer
*float – a floating point number
*vec2 – a 2 component floating point vector
*vec3 – a 3 component floating point vector
*vec4 – a 4 component floating point vector
*bvec2 – a 2 component Boolean vector
*bvec3 – a 3 component Boolean vector
*bvec4 – a 4 component Boolean vector
*ivec2 – a 2 component vector of integers
*ivec3 – a 3 component vector of integers
*ivec4 – a 4 component vector of integers
*mat2 – a 2X2 matrix of floating point numbers
*mat3 – a 3X3 matrix of floating point numbers
*mat4 – a 4X4 matrix of floating point numbers
*sampler1D – a handle for accessing a texture with 1 dimension
*sampler2D – a handle for accessing a texture with 2 dimensions
*sampler3D – a handle for accessing a texture with 3 dimensions
*samplerCube – a handle for accessing cube mapped textures
*sampler1Dshadow – a handle for accessing a depth texture in one dimension
*sampler2Dshadow – a handle for accessing a depth texture in two dimensions


Apart from these built-in data types, user defined data types in the form of C structs are also supported. Refer to the GLSL specifications.
Because of this, there is a mapping layer for the program's inputs and outputs. The vertex shader's input names are mapped to attribute indices, while the fragment shader's output names are mapped to draw buffer indices. This mapping can be created before the program is linked. If it is not, or if the mapping does not cover all of the inputs and outputs, then the linker will automatically define what indices are mapped to which unmapped input or output names. This auto-generated mapping can be queried by the user after the program is linked.


===Operators===
GLSL provides many built-in operators for built-in data types. There is no need for the programmer to manually write overloaded operators (which is not supported anyway). Built-in common math operators like assignment, comparison, equality etc. are provided. Logical operators like logical and and or are also supported. Bitwise operators, although a part of the language (reserved tokens), are currently '''not''' supported as part of the GLSL 1.10 specifications. GLSL 1.20 specifications, however, promise a support for these operators.
Refer to the official [http://www.opengl.org/documentation/glsl/ GLSL specifications] for more details.


===Control Structures===
All sorts of C like control structures like if-else statements and loops are supported. Note that goto is not supported. Refer to the official [http://www.opengl.org/documentation/glsl/ GLSL specifications] for more details.


===Functions===
== Using GLSL shaders ==
Functions are also supported in GLSL. User-defined functions are supported and the standard GLSL library (GLSL stdlib) provides many built-in functions for performing mathematical and other graphics operations. This gives IHVs, the liberty to perform hardware specific optimizations for built-in functions.


===Compiling and Executing===
GLSL shaders are not standalone applications. Like all other shading languages they require a host application to load and execute them. All major languages like C, C++, C#, Delphi, Java, VB and many others support OpenGL and therefore the host application can be written in any of these languages.
GLSL shaders are simple text programs and the host application uses OpenGL API to compile and execute these shaders on the graphics hardware.


GLSL compiler is provided by the driver, which does not require the application to pre-compile the GLSL code into assembly. High level GLSL code can be compiled directly by the driver using OpenGL API calls. The compiled code can then be uploaded to the hardware. Refer to [http://www.opengl.org/documentation/glsl/ GLSL specifications] for more information.


====Caveats and Common Problems====
=== Building shaders ===
Vendor specific compiler, has its pros and cons. Vendors can have their own assembly and the compiler compiles GLSL code to that assembly. They can also have vendor specific optimizations both in the compiler and the code generation, depending on their hardware. However, non-standard GLSL compilers from vendors can result in non-portable GLSL code e.g. a shader compiled using compiler from Vendor A '''may not''' compile on a compiler from Vendor B if it contains some non-standard syntax that was allowed by Vendor A's compiler and not supported by Vendor B. Non-standard, does not necessarily mean a subset of the standard, it can easily be the '''superset''' of the standard, allowing high(er) level syntax, not supported by the standard.


To remedy this problem 3DLabs released [http://developer.3dlabs.com/downloads/glslvalidate/index.htm GLSLvaidate] that is a standalone fully GLSL standard compliant compiler which can compile and check your code for syntax errors. A shader compiled with GLSLvalidate is guaranteed to be GLSL standard compliant and should compile on any driver supporting the minimal GLSL syntax.


===A sample trivial GLSL Vertex Shader===
<pre><nowiki>void main(void)
{
    gl_Position = ftransform();
    //The above is for GLSL 1.00, 1.10, 1.20
    //Below, is for GLSL 1.30
    //Define your own uniforms!!!
    //Define your own vertex attribute!!!
    //gl_Position = ProjectionModelviewMatrix * AttrVertex;
}</nowiki></pre>


The minimal job a fully working vertex shader must do is pass on
=== Setting uniforms ===
a vertex position by transforming it from object coordinates
to eye coordinates using the modelview matrix, and to clip coordinates
by transformation with the projection matrix.  Here is such a minimal
shader:


<pre><nowiki>void main(void)
{
    gl_Position = gl_ProjectionMatrix*gl_ModelViewMatrix*gl_Vertex;
    //The above is for GLSL 1.00, 1.10, 1.20
    //Below, is for GLSL 1.30
    //Define your own uniforms!!!
    //Define your own vertex attribute!!!
    //gl_Position = ProjectionModelviewMatrix * AttrVertex;
}
</nowiki></pre>


===A sample trivial GLSL Fragment Shader===
<pre><nowiki>void main(void)
{
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}</nowiki></pre>


The minimal fragment shader must set the gl_FragColor.  If you
=== Setting samplers ===
just want to pass on the fragment color without modifying it,
then the minimalist example would look like this:


<pre><nowiki>void main(void)
{
    gl_FragColor = gl_FrontColor;
    //For GLSL 1.30, do not use gl_FrontColor. Define your own varying variable
}
</nowiki></pre>


==References==
*Rost, Randi. ''OpenGL Shading Language''. 1st ed. Pearson Education, Inc, 2004. ISBN 0321197895
*Kessenich, John, & Baldwin, David, & Rost, Randi. ''The OpenGL Shading Language''. Version 1.10.59. 3Dlabs, Inc. Ltd. http://developer.3dlabs.com/documents/index.htm


== See also ==
== See also ==
Line 134: Line 194:


==External links==
==External links==
*[http://www.opengl.org The Official OpenGL Web Site]
*[http://www.opengl.org/documentation/glsl/ Current Specification for the OpenGL Shading Language]
*[http://www.opengl.org/documentation/glsl/ GLSL Specifications]
*[http://www.opengl.org/documentation/red_book/ OpenGL Red Book]
*[http://www.opengl.org/documentation/red_book/ OpenGL Red Book]
*[http://www.opengl.org/documentation/blue_book/ OpenGL Blue Book]
*[http://www.opengl.org/documentation/blue_book/ OpenGL Blue Book]
*[http://developer.3dlabs.com/ GLSL Resources and Documentation]
*[http://developer.3dlabs.com/downloads/glslvalidate/index.htm GLSLvalidate Compiler]
*[http://www.opengl.org/documentation/extensions/ OpenGL Extensions]
*[http://www.opengl.org/documentation/extensions/ OpenGL Extensions]
*[http://www.lighthouse3d.com/opengl/ Tutorials and Examples from Lighthouse3D]
*[http://www.lighthouse3d.com/opengl/ Tutorials and Examples from Lighthouse3D]
*[http://nehe.gamedev.net Tutorials and Examples from Nehe]
*[http://nehe.gamedev.net Tutorials and Examples from Nehe]
*[http://www.typhoonlabs.com A GLSL Development Environment]
*[http://www.ati.com/developer/rendermonkey/ RenderMonkey Shader Development Environment]
*[http://www.ati.com/developer/rendermonkey/ RenderMonkey Shader Development Environment]
*[http://www.mew.cx/glsl_quickref.pdf GLSL Quick Reference Guide (pdf)]


[[Category:OpenGL Shading Language]]
[[Category:OpenGL Shading Language]]
[[Category:Shading Languages]]
[[Category:Shading Languages]]

Revision as of 20:17, 10 September 2009

This article is missing information. Further details can be found on the talk page.
OpenGL Shading Language
Core in version 4.6
Core since version 2.0
ARB extension GL_ARB_shader_objects, GL_ARB_vertex_shader, GL_ARB_fragment_shader, GL_ARB_shading_language_100

The OpenGL Shading Language (GLSL) is the principle shading languages for OpenGL. While there are several shading languages available for use in OpenGL, GLSL is the only one that is a part of the OpenGL core.

GLSL is a C-style language. The language has undergone a number of version changes, and it shares the deprecation model of OpenGL. The current version of GLSL is 1.50.

Compilation model

GLSL is quite unique among shading languages due to its compilation model. Most shading languages use a simple, one-stage model: you give it a string representing a shader for one of the shader stages, and it gives you a shader object that you can bind to the context and render with.

GLSL uses a more complicated model based on the compilation of C programs. In C, a compilation unit, typically a single source file that may include several external header files, is compiled into an object file. A number of object files are then linked into a single program.

GLSL operates in a similar fashion. A set of source files, given as a series of strings, are compiled into a shader object. This is the analog of an object file. Unlike typical shading languages, there is no requirement that this shader object represent a full shader stage. The only limitation is that it can only compile code that is appropriate for a single, specific shader stage.

Shader objects are useless in that form, just as object files from compiled C programs are useless directly. Shader objects must be linked into a single program object. Unlike most shader languages, the program objects contain all shader stages at once. Only one program can be bound for rendering at any one time, and it is illegal for a program object to omit certain stages entirely.

Legacy Note: If the fixed-function pipeline is available, a program can omit one or more stages that the fixed-function pipeline can cover.

Terminology

Because of GLSL's unique compilation model, GLSL uses unique terminology.

According to GLSL's standard terminology, a shader is just a compiled set of strings for a particular programmable stage; it does not even need to have the complete code for that stage. A program is a fully linked program that covers multiple programmable stages.

For the sake of clarity, we will adjust this slightly. When the term shader is used, it will be synonymous with the GLSL concept of program. To refer to a GLSL shader, the term shader object will be used.

Language

GLSL is a C-style language, so it covers most of the features you would expect with such a language. Control structures (for-loops, if-else statements, etc) exist in GLSL, including the switch statement. This section will not cover the entire language in detail; the GLSL specification can handle that. This section will hit the highlights of the important differences between GLSL and C.

Basic types

C has a number of basic types. What C does not have the concept of is basic vector-types: a basic type that intrinsically store more than one value. The OpenGL Shading Language does define vector types.

The basic non-vector types are:

  • bool: conditional type, values may be either true or false
  • int: a signed integer
  • uint: an unsigned integer
  • float: a floating point number

Each of these types, including booleans, can have 2, 3, and 4-component vector equivalents. The n digit below can be 2, 3, or 4:

  • bvecn: a vector of booleans
  • ivecn: a vector of signed integers
  • uvecn: a vector of unsigned integers
  • vecn: a vector of floating-point numbers

Vector values can have the same math operators applied to them that scalar values do. These all perform the component-wise operations on each component. However, in order for these operators to work on vectors, the two vectors must have the same number of components.

You can access vectors using the following syntax: 

vec4 someVec;
someVec.x + someVec.y;

This is called swizzling. You can use x, y, z, or w, referring to the first, second, third, and fourth components, respectively.

The reason it has that name swizzling is because the following syntax is entirely valid: 

vec2 someVec;
vec4 otherVec = someVec.xyxx;
vec3 thirdVec = otherVec.zyy;

You can use any combination of up to 4 of the letters to create a vector (of the same basic type) of that length. So otherVec.zyy is a vec3, which is how we can initialize a vec3 value with it. Any combination of up to 4 letters is acceptable, so long as the source vector actually has those components. Attempting to access the 'w' component of a vec3 for example is a compile-time error.

Additionally, there are 3 sets of swizzle masks. You can use xyzw, rgba (for colors), or stpq (for texture coordinates). These three sets have no actual difference; they're just syntactic sugar.

Matrices

In addition to vectors, there are also matrix types. All matrix types are floating-point. Matrix types are as follows, where n and m can be the numbers 2, 3, or 4:

  • matnxm: A matrix with n columns and m rows. OpenGL uses column-major matrices, which is standard for mathematics users.
  • matn: A symmetric matrix with n columns and rows. This type is equivalent to

Swizzling does not work with matrices. You can instead access a matrix's fields with array syntax: 

mat3 theMatrix;
theMatrix[1] = vec3(3.0, 3.0, 3.0); //Sets the second column to all 3.0s
theMatrix[2][0] = 16.0; //Sets the first entry of the third column to 16.0.


Structs and arrays

Constructors =

All types have constructor syntax that allows you to create values of that type. Constructors use this general syntax: 

 type(value, value, ...);

The type is the type you wish to create, be it scalar, vector, matrix, struct, or array.

Constructors for scalar types are special. They can



Samplers

Texture access is not as simple as reading a value from a memory address. Filtering and other processes are applied to textures, and how texture coordinates are interpreted can be part of the texture access operation. For these reason, texture access is somewhat complicated.

It starts with samplers, a special type that GLSL defines. Each sampler represents a texture that is attached to the program. Samplers have a type that defines what kind of texture can be attached to them. The following samplers types are available:

  • sampler1D
  • sampler2D
  • sampler3D
  • samplerCube
  • sampler2DRect
  • sampler1DShadow: For doing shadow texture accesses. Depth formats are not required.
  • sampler2DShadow
  • samplerCubeShadow
  • sampler2DRectShadow
  • sampler1DArray: For array textures.
  • sampler2DArray
  • sampler1DArrayShadow
  • sampler2DArrayShadow
  • samplerBuffer: For buffer textures
  • sampler2DMS: For multisample textures.
  • sampler2DMSArray

These samplers are for textures with floating-point image formats. For textures with integral image formats, you can preceed the sampler type with "i" for signed integers or "u" for unsigned integers. However, there are no integral "shadow" samplers.


Uniforms

The user of shaders is able to attach constant values to the linked program. These values are called "uniforms". There is special GLSL syntax for defining uniform variables.


Uniform blocks and buffers

Stage inputs and outputs

Each stage in the shader pipeline can define a number of input values and a number of output values. There is an implementation-defined maximum number of inputs and outputs for each stage.

In a very few cases, there are also certain built-in outputs or inputs that can be used. These are generated or required by fixed-functionality processes. However, most inputs and outputs are user-defined.

GLSL creates linkage between outputs from one stage and inputs to the next stage very simply. Because the entire program consists of all stages at once, the linkage is made via matching the variable names. It is illegal for the types of the two ; this will cause a linker error, similar to how defining the same non-static function in two different C object files is an error.


Attributes and draw buffers

For the stages at the start and end of the pipeline (vertex and fragment, respectively), the initial input values and final output values do not come from or go to shader stages. The input values to a vertex shader come from vertex data specified in a vertex array object, pulled from vertex buffer objects. The output values of a fragment shader are piped to particular buffers for the currently bound framebuffer; either the default framebuffer or a framebuffer object.

Because of this, there is a mapping layer for the program's inputs and outputs. The vertex shader's input names are mapped to attribute indices, while the fragment shader's output names are mapped to draw buffer indices. This mapping can be created before the program is linked. If it is not, or if the mapping does not cover all of the inputs and outputs, then the linker will automatically define what indices are mapped to which unmapped input or output names. This auto-generated mapping can be queried by the user after the program is linked.


Using GLSL shaders

Building shaders

Setting uniforms

Setting samplers

See also

External links

Retrieved from "http://www.khronos.org/opengl/wiki_opengl/index.php?title=OpenGL_Shading_Language&oldid=2558"