I've been trying to understand the details of tessellation better, as present in XBOX and pre-RV870, and as mandated by DX11.
The way I've seen it explained is like this (for DX11)
- vertex shader transforms control points of a patch.
- hull shader determines parameters per patch for a fixed function tessellator
- the tessellator breaks up each patch into triangles
- domain shader does additional operations on the triangle vertices
- those triangles are (optionally) fed into the geometry shader
Is this more or less correct?
Questions:
- the fixed function tessellator works with bezier patches. Is that the only surface type it can work with? Are there different variants?
- If the tessellator only supports 1 kind of surface, is the same true for the input of the hull shader? That is: would it be possible to write the hull shader such that it converts a different kind of patch? (e.g.: a NURBS surface into a bezier patch?) Can a hull shader create new patches like a geometry shader? Or is the functionality of the hull shader limited to calculating whatever additional parameters are required for the HW tessellator? In case the hull shader cannot create additional patches, can it at least modify the incoming vertices or are those simply passed through unmodified from the vertex shader?
- The fixed function tessellator step: does it convert a bezier patch into a uniform grid of triangles? Or can it module the triangle density across the patch? The latter case would allow one to have only a few bezier patches for very large surfaces and still be efficient wrt the number of triangles.
- Why is there a domain shader at all? At first sight, one would think that domain shaders and geometry shaders can be merged into one? The only thing I can think of is that maybe a domain shader will have access to the patch control points while a geometry shader does not, but then why not simply extend the functionality of the geometry shader?
- There was some back and forth about whether or not tessellation in Fermi is hardware or software, as in: "done by the shaders". Given that hull shaders and domain shaders are called shaders, I assume that this discussion was then specifically about the fixed function tessellator step that sits between them? If this step were done in the shaders, then this would mean that you're basically have another geometry shader that converts a quad into tons of triangles, right? (Is this something a geometry shader could do on DX10 hardware?) Why would it be a bad thing for this to happen in a shader instead of fixed function hardware? I obviously understand that this will take away calculation power from the other shaders, but you could argue the same about going from fixed function vertex shader/pixel shader architecture to a unified architecture.
When you don't use tessellation, do you don't have hardware sitting idle.
- Wrt XBOX and pre-RV870: there were not hull shaders and domain shaders there. Which raises the question: how were the tessellation parameters calculated then? Some heuristic based on the proximity of input vertices? As for the domain shader: geometry shader coming to the rescue?
The way I've seen it explained is like this (for DX11)
- vertex shader transforms control points of a patch.
- hull shader determines parameters per patch for a fixed function tessellator
- the tessellator breaks up each patch into triangles
- domain shader does additional operations on the triangle vertices
- those triangles are (optionally) fed into the geometry shader
Is this more or less correct?
Questions:
- the fixed function tessellator works with bezier patches. Is that the only surface type it can work with? Are there different variants?
- If the tessellator only supports 1 kind of surface, is the same true for the input of the hull shader? That is: would it be possible to write the hull shader such that it converts a different kind of patch? (e.g.: a NURBS surface into a bezier patch?) Can a hull shader create new patches like a geometry shader? Or is the functionality of the hull shader limited to calculating whatever additional parameters are required for the HW tessellator? In case the hull shader cannot create additional patches, can it at least modify the incoming vertices or are those simply passed through unmodified from the vertex shader?
- The fixed function tessellator step: does it convert a bezier patch into a uniform grid of triangles? Or can it module the triangle density across the patch? The latter case would allow one to have only a few bezier patches for very large surfaces and still be efficient wrt the number of triangles.
- Why is there a domain shader at all? At first sight, one would think that domain shaders and geometry shaders can be merged into one? The only thing I can think of is that maybe a domain shader will have access to the patch control points while a geometry shader does not, but then why not simply extend the functionality of the geometry shader?
- There was some back and forth about whether or not tessellation in Fermi is hardware or software, as in: "done by the shaders". Given that hull shaders and domain shaders are called shaders, I assume that this discussion was then specifically about the fixed function tessellator step that sits between them? If this step were done in the shaders, then this would mean that you're basically have another geometry shader that converts a quad into tons of triangles, right? (Is this something a geometry shader could do on DX10 hardware?) Why would it be a bad thing for this to happen in a shader instead of fixed function hardware? I obviously understand that this will take away calculation power from the other shaders, but you could argue the same about going from fixed function vertex shader/pixel shader architecture to a unified architecture.
When you don't use tessellation, do you don't have hardware sitting idle.- Wrt XBOX and pre-RV870: there were not hull shaders and domain shaders there. Which raises the question: how were the tessellation parameters calculated then? Some heuristic based on the proximity of input vertices? As for the domain shader: geometry shader coming to the rescue?
