High Level Shading Language - Practical Rendering and Computation with Direct3D 11 - page 329

Cube Textures
Cube textures are a special case of texture arrays meant for representing the six sides of a
cube, and are often used for reflection or environment maps. While they can be accessed
like a normal texture array through the Texture2DArray type, they can also be declared
as a TextureCube type. When calling a Sample method on TextureCube, the texture co-
ordinate passed in is a normalized three-component direction vector. The texture is then
sampled by choosing the texel pointed to by the direction vector. This usage is further
described in the cube texture section of Chapter 2.
Read/Write Textures
Read/write textures function in a similar manner to read/write buffer resources. Random-
access reads and writes are supported through the array operator, and GetDimensions can
be called to query the size of the resource. The read/write resource object types supported
in HLSL are RWTexturelD, RWTexturelDArray, RWTexture2D, RWTexture2DArray, and
RWTexture3D.
6.6 Dynamic Shader Linkage
Since programmable graphics hardware has become mainstream, applications employing
three-dimensional graphics have developed increasingly large and complex sets of shader
code for implementing their graphical features. However prior to Direct3D 11, HLSL pro-
vided no built-in means of enabling dynamic dispatch in shader programs. Shader Model
3.0 introduced the ability for shaders to dynamically branch on values. However, the heavy
performance penalties of doing so made it prohibitively expensive as a means for imple-
menting dynamic dispatch. Static branching has also been supported since Shader Model
2.0, but its limitations on the number of branches, as well as performance implications,
have made it similarly inadequate. Consequently many applications resorted to statically
compiling all required permutations of a shader program, either by using macros and con-
ditional compilation or by piecing together code from smaller fragments. While this ap-
proach has the advantages of not requiring dynamic branching, and provides the optimizer
with full access to a complete program, the number of required permutations grows expo-
nentially as new options are added. This is often referred to as the shader combinatorial
explosion. Thus, programmers have often been faced with a difficult choice between de-
creasing shader performance, increasing shader compilation times, or making their shader
build pipeline more complex.