Dynamic Tessellation - Practical Rendering and Computation with Direct3D 11 - page 419

detail exists in the definition of the InputPatch, which has 12 control points, and in the
definition of outputcontrolpoints, which has 4.
As shown in the next section, the domain shader only needs to know about the 4
control points that define the boundary of the tile being currently rendered. Only the hull
shader constant function needs the 8 neighboring points to generate tessellation factors.
Consequently, there is no need to send the data further down the pipeline. This is good,
because unless the GPU driver is extremely clever and automatically removes this data, it,
would serve only to increase resource usage unnecessarily.
The patchconstantfunc attribute in Listing 9.4 points to the hsPerPatch entry
point in Listing 9.5. This is where Greg Snook's algorithm is really implemented.
struct HS_PER_PATCH_OUTPUT
{
float edgeTesselation[4] : SV_TessFactor;
float insideTesselation[2] : SV_InsideTessFactor;
};
HS_PER_PATCH_OUTPUT hsPerPatch
(
InputPatch<VS_OUTPUT, 12> ip
, uint PatchID : SV_PrimitiveID
)
{
HS_PER_PATCH_OUTPUT o = (HS_PER_PATCH_OUTPUT)0;
// Determine the midpoint of this patch
float3 midpoints [] =
{
// Main quad
ComputePatchMidPoint(ip[0]. position, ip[l]. position, ip[2].
position, ip[3] .position)
// +x neighbor
, ComputePatchMidPoint(ip [2]. position, ip[3]. position,ip [4].
position, ip[5] .position)
// +z neighbor
, ComputePatchMidPoint(ip[l] .position, ip[ 3]. position,ip [6].
position, ip[7] .position)
// -x neighbor
, ComputePatcnMidPoint(ip[0]. position, ip[i]. position, ip[8].
position, ip[9] .position)
// -z neighbor
, ComputePatchMidPoint(ip[0]. position, ip[2]. position, ip[10].
position, ip[ll] .position)