#Tessellation shader serial#
#Tessellation shader Patch#

As for the primitive mode, there are three choices: triangles, quads, and isolines. The latter two are optional and they have reasonable defaults - I won’t go into detail about them here. This specifies three things: a primitive mode, a vertex spacing, and an ordering. You’ll often see a TE shader with something like this at the top: More on these later.Īnother way of controlling how the Tessellator generates verts is through the layout qualifier on the TE shader’s inputs. This is done through the gl_TessLevelInner and gl_TessLevelOuter output variables. That’s because the “Tessellator” (the stage between the two new shaders) generates brand new verts by interpolating between the existing verts.Īs the name implies, the TC shader has some control over how the Tessellator generates new verts. The Tessellation Evaluation (TE) shader, however, usually processes more verts than you sent down in your draw call. Much like a VS program, each TC program transforms only one vertex, and the number of execution instances is the same as the number of verts in your OpenGL draw call. The Tessellation Control (TC) shader is kinda like a Vertex Shader (VS) with super-vision. GlDrawArrays(GL_PATCHES, firstVert, vertCount) // draw a bunch of patches

#Tessellation shader Patch#

GlPatchParameteri(GL_PATCH_VERTICES, 16) // tell OpenGL that every patch has 16 verts Unlike GL_TRIANGLES (where every 3 verts spawns a triangle) or GL_TRIANGLE_STRIP (where every 1 vert spawns a new triangle), the number of verts in a patch is configurable: To work with tessellation shaders, OpenGL now has a new primitive type: GL_PATCHES. However, much like geometry shaders, they can “see” all the verts in a single primitive.

#Tessellation shader serial#

They both execute on a per-vertex basis, so their programs typically don’t have serial loops like the old-fashioned geometry programs did. So, we now have two additional programmable stages at our disposal: Tessellation Control and Tessellation Evaluation. Now is the time for the obligatory diagram: (I used a red pen for the stages that are new to OpenGL 4.0) The New OpenGL 4.0+ PipelineĪlthough adding multiple GS invocations was helpful, performing highly-efficient subdivision demanded brand new stages in the pipeline. You can figure out which vert you’re on by looking at the built-in gl_InvocationID variable.

This tells the GPU that your GS should run three times on a single primitive. Nowadays you can do a bit better by specifying an invocations count at the top of your GS, like so: They didn’t do a great job of leveraging the massive parallelism in GPUs. Most GS programs had a serial loop that simply pushed out the verts of the new primitive(s), one vertex after another. The GS processing for a single primitive was initially limited to a single processing unit. It was not designed for large-scale amplification of vertex data. The GS unit turned out to be convenient for certain effects, but overall it was somewhat disappointing. And finally, the GPU could produce more primitives than it consumed. When Geometry Shaders (GS) first came out, we were all excited because we could finally write a shader that could “see” all the verts in a triangle at once. This entry gives an overview of tessellation and walks through an example of simple triangle subdivision in the next entry, we’ll focus on quad subdivision. This is the first of a two-part article on tessellation shaders with OpenGL 4.0+.