Difference between revisions of "Fragment Shader"

From OpenGL.org
Jump to: navigation, search
(Inputs)
(Outputs)
Line 85: Line 85:
  
 
== Outputs ==
 
== Outputs ==
 +
 +
User-defined output values from the fragment are written to one or more color buffers in the current [[Framebuffer Object|framebuffer]].
 +
 +
There are some built-in output values with special meaning:
 +
 +
<source lang="glsl">
 +
out float gl_FragDepth;
 +
</source>
 +
 +
; {{code|gl_FragDepth}}
 +
: This output is the fragment's depth. If the shader does not statically write this value, then it will take the value of {{code|gl_FragCoord.z}}.
 +
: To "statically write" to a variable means that you write to it ''anywhere'' in the program. Even if the writing code is technically unreachable for some reason, if there is a {{code|gl_FragDepth = ...}} expression ''anywhere'' in the shader, then it is statically written.
 +
: {{warning|If the fragment shader statically writes to {{code|gl_FragDepth}}, then it is the responsibility of the shader to statically write to the value in ''all circumstances''. No matter what branches may or may not be taken, the shader must ensure that the value is written. So, if you conditionally write to it in one place, you should at least make sure that there is a single non-conditional write sometime before that.}}
 +
 +
OpenGL 4.2/{{extref|conservative_depth}} allows the user to specify that modifications to {{code|gl_FragDepth}} (relative to the {{code|gl_FragCoord.z}} value it would have otherwise had) will happen in certain ways. This allows the implementation the freedom to not turn off [[Early Depth Test]]s in certain situations.
 +
 +
This is done by re-declaring {{code|gl_FragDepth}} with a special layout qualifier:
 +
 +
<source lang="glsl">
 +
layout (depth_<condition>) out float gl_FragDepth;
 +
</source>
 +
 +
The {{param|condition}} can be one of the following:
 +
 +
; {{code|any}}
 +
: The default. You may freely change the depth, but you lose the most potential performance.
 +
; {{code|greater}}
 +
: You will only make the depth ''larger'', compared to {{code|gl_FragDepth.z}}.
 +
; {{code|less}}
 +
: You will only make the depth ''smaller'', compared to {{code|gl_FragDepth.z}}.
 +
; {{code|unchanged}}
 +
: If you write to {{code|gl_FragDepth}}, you will write exactly {{code|gl_FragDepth.z}}.
 +
 +
Violating the {{param|condition}} yields undefined behavior.
 +
 +
GL 4.0/{{extref|sample_shading}} brings us:
 +
 +
<source lang="glsl">
 +
out int gl_SampleMask[];
 +
</source>
 +
 +
; {{code|gl_SampleMask}}
 +
:This defines the sample mask for the fragment when performing [[Multisample|mutlisampled rendering]]. If a shader does not statically write to it, then it will be filled in by {{code|gl_SampleMaskIn}}.
 +
: {{warning|Just as with {{code|gl_FragDepth}}, if a fragment shader writes to it at all, it must make sure to write to the value for all execution paths. But it must ''also'' make sure to write to each element in the array. The array is sized the same way as for {{code|gl_SampleMaskIn}}.}}
  
 
=== Output buffers ===
 
=== Output buffers ===
 +
 +
=== Dual-source blending ===
 +
 +
== Special Operations ==
 +
 +
Unlike every other shader stage, fragment shaders have implicit derivatives generated. As such, they can [[GLSL Sampler#Texture lookup in shader stages|use the majority of the texturing functions]]. You still need to watch out for [[GLSL Sampler#Non-uniform flow control|non-uniform flow control]].
 +
 +
Fragment shaders also have access to the {{code|discard}} command. When executed, this command causes the fragment's output values to be discarded in the same way that a fragment is discarded if the depth test failed. Thus, the fragment does not proceed on to the next pipeline stages.
 +
 +
Normally, [[Early Depth Test|early tests]], performing the depth/etc test before the fragment shader, is a transparent optimization. However, with GL 4.2/{{extref|shader_image_load_store}}, early depth tests can be ''forced'' for a fragment shader using this syntax:
 +
 +
<source lang="glsl">
 +
layout(early_fragment_tests) in;
 +
</source>
 +
 +
{{warning|This ''does not'' mean that you can subvert the meaning of the depth test. You cannot, for example, perform the depth test with one value and then write a different value to the depth buffer than the one you tested. If you attempt to write to {{code|gl_FragDepth}} when you force early-fragment tests, then the value written '''''will be ignored.''''' The value written to the depth buffer will always be the value tested ''against'' the depth buffer.}}
  
 
== See also ==
 
== See also ==

Revision as of 20:09, 3 October 2012

A Fragment Shader is a user-supplied program that, when executed, will process a Fragment from the rasterization process into a set of colors and a single depth value.

Overview

The fragment shader is the OpenGL pipeline stage after a primitive is rasterized. For each sample of the pixels covered by a primitive, a "fragment" is generated. Each fragment has a Window Space position, a few other values, and it contains all of the interpolated per-vertex output values from the last Vertex Processing stage.

The output of a fragment shader is a depth value, a possible stencil value (unmodified by the fragment shader), and zero or more color values to be potentially written to the buffers in the current framebuffers.

Inputs

The inputs to the fragment shader are either generated by the system or passed from prior fixed-function operations and potentially interpolated across the surface of the primitive.

The user-defined outputs from the last Vertex Processing stage will be interpolated according to their assigned interpolation qualifiers. The fragment shader must define its user-defined inputs exactly as they were defined in the last Vertex Processing stage (with the exception of the centroid​ qualifier).

System inputs

Fragment shaders have a lot of input variables who's values are generated primarily by the rendering system.

in vec4 gl_FragCoord;
in bool gl_FrontFacing;
in vec2 gl_PointCoord;
gl_FragCoord​
The location of the fragment in window space. The X, Y and Z components are the window-space position of the fragment. The Z value will be written to the depth buffer if gl_FragDepth​ is not written to by this shader stage. The W component of gl_FragCoord​ is 1/Wclip, where Wclip is the interpolated W component of the clip-space vertex position output to gl_Position​ from the last Vertex Processing stage.
The space of gl_FragCoord​ can be modified by redeclaring gl_FragCoord​ with special input layout qualifiers:
layout(origin_upper_left) in vec4 gl_FragCoord;
This means that the origin for gl_FragCoord​'s window-space will be the upper-left of the screen, rather than the usual lower-left.
layout(pixel_center_integer​) in vec4 gl_FragCoord;
OpenGL window space is defined such that pixel centers are on half-integer boundaries. So the center of the lower-left pixel is (0.5, 0.5). Using pixel_center_integer​​ adjust {{code|gl_FragCoord)) such that whole integer values represent pixel centers.
Both of these exist to be compatible with D3D's window space. Unless you need your shaders to have this compatibility, you are advised not to use these features.
gl_FrontFacing​
This is true if this fragment was generated by the front-face of the primitive; it is false if it was generated by the back-face.
gl_PointCoord​
The location within a point primitive that defines the position of the fragment relative to the side of the point. Points are effectively rasterized as window-space squares of a certain pixel size. Since points are defined by a single vertex, the only way to tell where in that square a particular fragment is is with gl_PointCoord​.
The values of gl_PointCoord​'s coordinates range from [0, 1]. Standard OpenGL convention uses a upper-left origin for point-coordinates, so (0, 0) is the bottom left. However, the origin can be switched to a bottom-left origin by calling glPointParameteri(GL_POINT_SPRITE_COORD_ORIGIN, GL_LOWER_LEFT);

OpenGL 4.0 and above define additional system-generated input values:

in int gl_SampleID;
in vec2 gl_SamplePosition;
in int gl_SampleMaskIn[];
gl_SampleID​
This is an integer identifier for the current sample that this fragment is rasterized for.
Warning: Any use of this variable at all will force this shader to be evaluated per-sample. Since much of the point of multisampling is to avoid that, you should use it only when you must.
gl_SamplePosition​
This is the location of the current sample for the fragment within the pixel's area, with values on the range [0, 1]. The origin is the bottom-left of the pixel area.
Warning: Any use of this variable at all will force this shader to be evaluated per-sample. Since much of the point of multisampling is to avoid that, you should use it only when you must.
gl_SampleMaskIn​
When using multisampling, this variable contains a bitfield for the sample mask of the fragment being generated. The array is as long as needed to fill in the number of samples supported by the GL implementation.

User overridden inputs

Some built-in inputs will take values specified by OpenGL, but these values can be overridden by user control.

in float gl_ClipDistance[];
in int gl_PrimitiveID;
gl_ClipDistance​
This array contains the interpolated clipping plane half-spaces, as output for vertices from the last Vertex Processing stage.
gl_PrimitiveID​
This value is the index of the current primitive being rendered by this rendering command. However, if a Geometry Shader is active, then the gl_PrimitiveID​ is what the GS provided as output. If the GS did not output a value, then the fragment shader gets an undefined value.

GL 4.3 provides the following additional inputs:

in int gl_Layer;
in int gl_ViewportIndex;
gl_Layer​
This is either 0 or the layer number for this primitive output by the Geometry Shader.
gl_ViewportIndex​
This is either 0 or the viewport index for this primitive output by the Geometry Shader.

Outputs

User-defined output values from the fragment are written to one or more color buffers in the current framebuffer.

There are some built-in output values with special meaning:

out float gl_FragDepth;
gl_FragDepth​
This output is the fragment's depth. If the shader does not statically write this value, then it will take the value of gl_FragCoord.z​.
To "statically write" to a variable means that you write to it anywhere in the program. Even if the writing code is technically unreachable for some reason, if there is a {{{1}}}​ expression anywhere in the shader, then it is statically written.
Warning: If the fragment shader statically writes to gl_FragDepth​, then it is the responsibility of the shader to statically write to the value in all circumstances. No matter what branches may or may not be taken, the shader must ensure that the value is written. So, if you conditionally write to it in one place, you should at least make sure that there is a single non-conditional write sometime before that.