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

Figure 9.10. Original height map. Figure 9.11. Debug rendering using original algorithm.

One simple change to the algorithm can help reduce this problem and also exercise
another new feature in the Direct3D 11 pipeline—the compute shader.
The preceding diagrams show a case where a 256x256 heightmap is represented by a
16x16 grid. This means that for each patch rendered, the domain shader has a 16 x 16 grid of
pixels to draw samples from. However, the hull shader, which is responsible for selecting
the LOD, has no knowledge of this information. If it were able to analyze the appropriate
grid of pixels later used by the domain shader, it could quite easily make a much more
informed decision about the tessellation factors.
While a hull shader can read pixels from a texture bound to one of its samplers, it
would be unnecessarily inefficient to have the constant function make 256 (16x16) texture
samples on each invocation. However, if it had a lookup table that stored precomputed
values, it could simply pull in the necessary values with a single sample operation.

Pre-Processing the Height Map
Although it is a pre-processing step in this context, the approach that will be taken is very
similar to the concept of post-processing, which has been common in real-time graphics
for several years.
The input heightmap will be divided up into kernels; each kernel area will have its
pixels read in, and four values will be generated from the raw data, which can then be
stored in a 2D output texture. This texture will then be indexed by the hull shader to enable
it to have the previously described context when making LOD computations.
The key design decision is how to map the 16x16 height map samples down to a
single per-patch output value.