Overview: programs
Shader programs contain the code used by the GPU to render the graphics. More information on the rendering pipeline can be found at the Khronos Wiki. The list of supported stages and their shader filenames are as follows:
| Shader Stage | File Extension |
|---|---|
| Compute | .csh |
| Vertex | .vsh |
| Geometry | .gsh |
| Fragment | .fsh |
| Tessellation | .tcs, .tes |
The shader code of a stage of a program should be located in the file <program_name>.<stage_extension>. For example: composite.vsh, deferred8.fsh, gbuffers_terrain.gsh, setup.csh
Program Order
The following is the list of shader programs in the order they’re executed:
| Shader Programs | Program Type |
|---|---|
| setup (no suffix, 1-99) | Compute Only |
| begin (no suffix, 1-99) | Composite-Style |
| shadow | Gbuffers-Style |
| shadowcomp (no suffix, 1-99) | Composite-Style |
| prepare (no suffix, 1-99) | Composite-Style |
| gbuffers (opaque) | Gbuffers-Style |
| deferred (no suffix, 1-99) | Composite-Style |
| gbuffers (translucent) | Gbuffers-Style |
| composite (no suffix, 1-99) | Composite-Style |
| final | Composite-Style |
Note: Other than some gbuffers programs being before/after deferred, the order of gbuffers programs is not fixed.
Gbuffers-Style
Gbuffers-style programs render the actual geometry of Minecraft, such as blocks, entities, etc. These consist of the gbuffers and shadow programs. The gbuffers programs render the scene from the player camera’s perspective, and if enabled the shadow program will render the scene from the light source’s perspective. These passes require vertex and fragment shaders, and also support geometry and tessellation shaders, but do not support compute shaders.
Note: These are the only programs with direct access to geometry specific information through vertex attributes (and certain uniforms).
Composite-Style
Composite-style programs render a single quad covering the output texture (unless only compute shaders are present). These programs consist of the begin, shadowcomp, prepare, deferred, composite, and final programs. These programs don’t have direct access to any geometry attributes, and instead rely on reading information from textures, buffers, or uniforms. Composite-style programs are commonly used for post-processing effects, deferred rendering, and compute passes. Each composite-style pass can include up to 100 programs by adding a suffix (1 to 99) in addition to a program with no suffix. final is the only exception, as there can only be one final program.
Composite-style programs support vertex, fragment, geometry, and compute stages. Usually composite-style programs require vertex and fragment shaders, however if a compute shader is present these are optional. Compute shaders (if present) will be executed before the vertex stage of a given program.
Compute Only
As the name suggests, compute only programs only support compute shaders. The only such programs are in the setup pass, which are executed once after shader load and during window resize. Like composite passes, setup supports suffixes (1 to 99) in addition to a program with no suffix.
Compute Shaders
Compute shaders break the OpenGL fixed pipeline and allow more direct access to graphics hardware. For more information, see the Khronos Wiki.
In Iris, compute shaders can be used in compute only pass, or included in composite-style passes, using the .csh file extension. In composite-style passes, compute shaders will always execute first (before the vertex stage if present). Up to 27 compute shaders files can be included in a single pass by appending the _a through _z suffixes to the filename in addition to a shader file with no suffix. These shaders will execute one after the other in alphabetical order (starting with the no-suffix file if present), unless allowConcurrentCompute is used (in which case they will execute potentially simultaneously but will all finish before starting the vertex stage).
Local size is defined as follows: layout (local_size_x = <size_x>, local_size_y = <size_x>, local_size_z = <size_z>) in;.
Work group count can be defined one of three ways:
- Fixed size: a const in shader file
const ivec3 workGroups - Screen size: calculate work groups as a multiplier of screen resolution, a const in shader file
const vec2 workGroupsRender - Indirect: specify work groups in an SSBO through
indirect.pass
If no work group count is provided, the default value of one work group per pixel will be used (const vec2 workGroupsRender = vec2(1.0, 1.0);).
Unlike fragment shaders, compute shaders cannot directly write to color attachments, instead they can only write to colortex and shadowcolor buffers through imageStore. Additionally, if multiple shader invocations are writing/reading to the same location in memory simultaneously, atomic operations (on images and/or shared memory) or memory barriers should be used.
Tessellation Shaders
Tessellation shaders allow splitting of a single triangle into multiple triangles during runtime. This can be used to add more detail to displaced geometry such as for waving water effects or displacement maps. For more information, see the Khronos Wiki.
Iris supports tessellation only for gbuffers-style passes. It recognizes the tessellation control shader in a .tcs file, and the tessellation evaluation shader in a .tes file. Only triangles are supported (no quads or isolines). The TESSELATION_SHADERS feature flag is required to use tessellation shaders.