Chapter 4. Hello, Shaders!
In this chapter, you write your first shaders. We introduce HLSL syntax, the FX file format, data structures, and more. By the end of this chapter, you’ll have a base from which to launch the rest of your exploration into graphics programming.
Your First Shader
You might recognize the canonical programming example “Hello, World!” as a first program written in a new language and whose output is this simple line of text. We follow this time-honored tradition with the shader equivalent “Hello, Shaders!”—this time, your output is an object rendered in a solid color.
To begin, launch NVIDIA FX Composer and create a new project. Open the Assets panel, right-click on the Materials icon, and choose Add Material from New Effect. Then choose HLSL FX from the Add Effect dialog box (see Figure 4.1).
In the next dialog box, select the Empty template and name your effect HelloShaders.fx (see Figure 4.2).
Click Finish in the final dialog box of the Effect Wizard to complete the process. If all went well, you should see your HelloShaders.fx file displayed in the Editor panel and associated HelloShaders and HelloShaders_Material objects listed in the Assets panel. Notice that the Empty effect template isn’t empty after all—NVIDIA FX Composer has stubbed out a bit of code for you. This code is actually close to what you want in your first shader, but it’s written for DirectX 9, so delete this code and replace it with the contents of Listing 4.1. Then we walk through this code step by step.
cbuffer CBufferPerObject
{
float4x4 WorldViewProjection : WORLDVIEWPROJECTION;
}
RasterizerState DisableCulling
{
CullMode = NONE;
};
float4 vertex_shader(float3 objectPosition : POSITION) : SV_Position
{
return mul(float4(objectPosition, 1), WorldViewProjection);
}
float4 pixel_shader() : SV_Target
{
return float4(1, 0, 0, 1);
}
technique10 main10
{
pass p0
{
SetVertexShader(CompileShader(vs_4_0, vertex_shader()));
SetGeometryShader(NULL);
SetPixelShader(CompileShader(ps_4_0, pixel_shader()));
SetRasterizerState(DisableCulling);
}
}
Effect Files
Direct3D pipeline stages can be programmed through separately compiled shaders. For instance, you can house a vertex shader in one file (commonly with the extension .hlsl) and a pixel shader in a different file. Under this configuration, each file must contain exactly one shader. By contrast, HLSL Effect files enable you to combine multiple shaders, support functions, and render states into a single file. This is the file format we use throughout this text, and Listing 4.1 uses it.
Constant Buffers
At the top of your HelloShaders.fx file, you find a block of code starting with cbuffer. This denotes a constant buffer, whose purpose is to organize one or more shader constants. A shader constant is input the CPU sends to a shader, which remains constant for all the primitives processed by a single draw call. Put another way, cbuffers hold variables, “constant variables.” They’re constant from the perspective of the GPU while processing the primitives of a draw call yet variable from the perspective of the CPU from one draw call to the next.
In your HelloShaders.fx file, you have just one cbuffer containing only one shader constant, WorldViewProjection, of type float4×4. This is a C-style variable declaration in which the data type is a 4×4 matrix of single-precision floating-point values. This particular variable (WorldViewProjection) represents the concatenated World-View-Projection matrix specific to each object. Recall from Chapter 2, “A 3D/Math Primer,” that this matrix transforms your vertices from object space, to world space, to view space, to homogeneous space, in a single transformation. You could pass the World, View, and Projection matrices into the effect separately and then perform three different transforms to produce the same result. But unless you have a specific reason to do so, sending less data as input and performing fewer shader instructions is the better option.
Note the text WORLDVIEWPROJECTION following the colon in the variable declaration. This is known as a semantic and is a hint to the CPU-side application about the intended use of the variable. Semantics relieve the application developer from a priori knowledge of the names of shader constants. In this example, you could have named your float4×4 variable WVP or WorldViewProj without any impact to the CPU side because it can access the variable through the WORLDVIEWPROJECTION semantic instead of through its name. A variety of common semantics exist, all of which are optional for shader constants. However, in the context of NVIDIA FX Composer, the WORLDVIEWPROJECTION semantic is not optional; it must be associated with a shader constant for your effect to receive updates to the concatenated WVP matrix each frame.
Render States
Shaders can’t define the behaviors of the nonprogrammable stages of the Direct3D pipeline, but you can customize them through render state objects. For example, the rasterizer stage is customized through a RasterizerState object. A variety of rasterizer state options exist, although I defer them to future chapters. For now, note the RasterizerState object DisableCulling (see Listing 4.2).
Listing 4.2 RasterizerState declaration from HelloShaders.fx
RasterizerState DisableCulling
{
CullMode = NONE;
};
We briefly discussed vertex winding order and backface culling in Chapter 3, “Tools of the Trade.” By default, DirectX considers vertices presented counter-clockwise (with respect to the camera) to be back-facing and does not draw them. However, the default models included with NVIDIA FX Composer (the Sphere, Teapot, Torus, and Plane) are wound in the opposite direction. Without modifying or disabling the culling mode, Direct3D would cull what we would consider front-facing triangles. Therefore, for your work within NVIDIA FX Composer, just disable culling by specifying CullMode = NONE.
The culling issue is present within NVIDIA FX Composer because it supports both DirectX and OpenGL rendering APIs. These libraries disagree on the default winding order for front-facing triangles, and NVIDIA FX Composer opted for the OpenGL default.
The Vertex Shader
The next HelloShaders code to analyze is the vertex shader, reproduced in Listing 4.3.
Listing 4.3 The vertex shader from HelloShaders.fx
float4 vertex_shader(float3 objectPosition : POSITION) : SV_Position
{
return mul(float4(objectPosition, 1), WorldViewProjection);
}
This code resembles a C-style function, but with some key differences. First, note the work the vertex shader is accomplishing. Each vertex comes into the shader in object space, and the WorldViewProjection matrix transforms it into homogeneous clip space. In general, this is the least amount of work a vertex shader performs.
The input into your vertex shader is a float3, an HLSL data type for storing three single-precision floating-point values—it’s named objectPosition to denote its coordinate space. Notice the POSITION semantic associated with the objectPosition parameter. It indicates that the variable is holding a vertex position. This is conceptually similar to the semantics used for shader constants, to convey the intended use of the parameter. However, semantics are also used to link shader inputs and outputs between shader stages (for example, between the input-assembler stage and the vertex shader stage) and are therefore required for such variables. At a minimum, the vertex shader must accept a variable with the POSITION semantic and must return a variable with the SV_Position semantic.
Note
Semantics with the prefix SV_ are system-value semantics and were introduced in Direct3D 10. These semantics designate a specific meaning to the pipeline. For example, SV_Position indicates that the associated output will contain a transformed vertex position for use in the rasterizer stage.
While other, non-system-value semantics exist, including a set of standard semantics, these are generic and are not explicitly interpreted by the pipeline.
Within the body of your vertex shader, you’re calling the HLSL intrinsic function mul. This performs a matrix multiplication between the two arguments. If the first argument is a vector, it’s treated as a row vector (with a row-major matrix as the second argument). Conversely, if the first argument is a matrix, it’s treated as a column major matrix, with a column-vector as the second argument. We use row-major matrices for most of our transformations, so we use the form mul(vector, matrix).
Notice that, for the first argument of the mul function, you are constructing a float4 out of the objectPosition (a float3) and the number 1. This is required because the number of columns in the vector must match the number of rows in the matrix. Because the vector you’re transforming is a position, you hard-code the fourth float (the w member) to 1. Had the vector represented a direction, the w component would be set to 0.
The Pixel Shader
As with the vertex shader, the HelloShader pixel shader is just one line of code (see Listing 4.4).
Listing 4.4 The pixel shader from HelloShaders.fx
float4 pixel_shader() : SV_Target
{
return float4(1, 0, 0, 1);
}
The return value of this shader is a float4 and is assigned the SV_Target semantic. This indicates that the output will be stored in the render target bound to the output-merger stage. Typically, that render target is a texture that is mapped to the screen and is known as the back buffer. This name comes from a technique called double buffering, in which two buffers are employed to reduce tearing, and other artifacts, produced when pixels from two (or more) frames are displayed simultaneously. Instead, all output is rendered to a back buffer while the actual video device displays a front buffer. When rendering is complete, the two buffers are swapped so that the newly rendered frame displays. Swapping is commonly done to coincide with the refresh cycle of the monitor—again, to avoid artifacts.
The output of your pixel shader is a 32-bit color, with 8-bit channels for Red, Green, Blue, and Alpha (RGBA). All values are supplied in floating-point format, where the range [0.0, 1.0] maps to integer range [0, 255]. In this example, you’re supplying the value 1 to the red channel, meaning that every pixel rendered will be solid red. You are not employing color blending, so the alpha channel has no impact. If you were using color blending, an alpha value of 1 would indicate a fully opaque pixel. We discuss color blending in more detail in Chapter 8, “Gleaming the Cube.”
Your HelloShaders pixel shader accepts no apparent input parameters, but don’t let this confuse you. The homogeneous clip space position of the pixel is being passed to the pixel shader from the rasterizer stage. However, this happens behind the scenes and is not explicitly declared as input into the pixel shader.
In the next chapter, you see how additional parameters are passed into the pixel shader.
Techniques
The last section of the HelloShaders effect is the technique that brings the pieces together (see Listing 4.5).
Listing 4.5 The technique from HelloShaders.fx
technique10 main10
{
pass p0
{
SetVertexShader(CompileShader(vs_4_0, vertex_shader()));
SetGeometryShader(NULL);
SetPixelShader(CompileShader(ps_4_0, pixel_shader()));
SetRasterizerState(DisableCulling);
}
}
A technique implements a specific rendering sequence through a set of effect passes. Each pass sets render states and associates your shaders with their corresponding pipeline stages. In the HelloShaders example, you have just one technique (named main10) with just one pass (named p0). However, effects can contain any number of techniques, and each technique can contain any number of passes. For now, all your techniques contain a single pass. We discuss techniques with multiple passes in Part IV, “Intermediate-Level Rendering Topics.”
Note the keyword technique10 in this example. This keyword denotes a Direct3D 10 technique, versus DirectX 9 techniques, which have no version suffix. Direct3D 11 techniques use the keyword technique11. Unfortunately, the current version of NVIDIA FX Composer does not support Direct3D 11. But you won’t be using any Direct3D 11–specific features at the beginning of your exploration of shader authoring, so this isn’t a show stopper. We start using Direct3D 11 techniques in Part III, “Rendering with DirectX.”
Also notice the arguments vs_4_0 and ps_4_0 within the SetVertexShader and SetPixelShader statements. These values identify the shader profiles to use when compiling the shaders specified in the second arguments of the CompileShader calls. Shader profiles are analogous to shader models, which define the capabilities of the graphics system that are required to support the corresponding shaders. As of this writing, there have been five major (and several minor) shader model revisions; the latest is shader model 5. Each shader model has extended the functionality of the previous revision in a variety of ways. Generally, however, the potential sophistication of shaders has increased with each new shader model. Direct3D 10 introduced shader model 4, which we use for all Direct3D 10 techniques. Shader model 5 was introduced with Direct3D 11, and we use that shader model for all Direct3D 11 techniques.
Hello, Shaders! Output
You’re now ready to visualize the output of the HelloShaders effect. To do so, you first need to build your effect through the Build, Rebuild All or Build, Compile HelloShaders.fx menu commands. Alternately, you can use the shortcut keys F6 (Rebuild All) or Ctrl+F7 (Compile Selected Effect). Be sure you do this after any changes you make to your code.
Next, ensure that you are using the Direct3D 10 rendering API by choosing it from the drop-down menu in the main toolbar (it’s the right-most toolbar item, and it likely defaults to Direct3D 9). Now open the Render panel within NVIDIA FX Composer. Its default placement is in the lower-right corner. Create a sphere in the Render panel by choosing Create, Sphere from the main menu or by clicking the Sphere icon in the toolbar. Finally, drag and drop your HelloShaders_Material from either the Materials panel or the Assets panel onto the sphere in the Render panel. You should see an image similar to Figure 4.3.
This might be a bit anti-climactic, given the effort to get here, but you’ve actually accomplished quite a lot! Take a few minutes to experiment with the output of this shader. Modify the RGB channels within the pixel shader to get a feel for what’s happening.
Hello, Structs!
In this section, you rewrite your HelloShaders effect to use C-style structs. Data structures provide a way to supply multiple shader inputs and outputs with a bit more organization than as individual parameters.
To start, create a new effect and material in NVIDIA FX Composer. You can do this through the Add Effect Wizard, as you did at the beginning of this chapter, or you can copy HelloShaders.fx to a new file, HelloStructs.fx. I like the second option because you’ll often reuse your shader code, building upon the previous material. With a copied HelloStructs.fx file, you add it to NVIDIA FX Composer by right-clicking the Materials section of the Assets panel and choosing Add Material from File. Find and select your HelloStructs.fx file, and you’ll see newly created HelloStructs and HelloStructs_Material objects in the Assets panel.
Listing 4.6 contains a full listing of the HelloStructs.fx effect.
cbuffer CBufferPerObject
{
float4x4 WorldViewProjection : WORLDVIEWPROJECTION;
}
RasterizerState DisableCulling
{
CullMode = NONE;
};
struct VS_INPUT
{
float4 ObjectPosition: POSITION;
};
struct VS_OUTPUT
{
float4 Position: SV_Position;
};
VS_OUTPUT vertex_shader(VS_INPUT IN)
{
VS_OUTPUT OUT = (VS_OUTPUT)0;
OUT.Position = mul(IN.ObjectPosition, WorldViewProjection);
return OUT;
}
float4 pixel_shader(VS_OUTPUT IN) : SV_Target
{
return float4(1, 0, 0, 1);
}
technique10 main10
{
pass p0
{
SetVertexShader(CompileShader(vs_4_0, vertex_shader()));
SetGeometryShader(NULL);
SetPixelShader(CompileShader(ps_4_0, pixel_shader()));
SetRasterizerState(DisableCulling);
}
}
The differences between HelloShaders.fx and HelloStructs.fx are minor but significant because they establish the conventions we use throughout this text. First, note what has not changed. The CBufferPerObject and DisableCulling objects are the same, as are the main10 technique and its pass. The body of the pixel shader hasn’t changed, either. What’s new are the two structs named VS_INPUT and VS_OUTPUT. These names identify the structures as vertex shader inputs and outputs, respectively. Notice that the VS_INPUT struct has the same ObjectPosition input variable as the HelloShaders vertex shader. The only difference is that the variable is declared as a float4 instead of a float3. This removes the need to append the value 1 to the w component of the vector. Additionally, the vertex shader now returns a VS_OUTPUT instance instead of a float4, and the SV_Position semantic is no longer associated directly to the return value because it’s attached instead to the Position member of the VS_OUTPUT struct. That Position member replaces the previously unnamed return value of the vertex shader from the HelloShaders effect.
Next, examine the body of your updated vertex shader. Notice that you’re declaring and returning a VS_OUTPUT instance, and in C-programming fashion, you access the Position member of the instance through the dot operator. Also notice that the ObjectPosition member of the VS_INPUT parameter IN is used for the mul invocation. In addition, you’re using a C-style cast to initialize the members of the OUT variable to zero. Although this is not strictly necessary, it is a good programming practice.
Finally, observe that the input parameter for the pixel shader is the output data type from the vertex shader. You’re not using any members of the input in this example, but you will do so in future shaders. The point of this reorganization is that now you can add shader inputs and outputs without modifying the signature of your vertex and pixel shaders. The output of HelloStructs should be identical to that of HelloShaders, in Figure 4.3.
Summary
In this chapter, you wrote your first HLSL shaders! You learned a bit about the FX file format, constant buffers, and render states. You also began to explore HLSL syntax, including vector and matrix data types (such as float3, float4, and float4×4) and user-defined structs. And you put all this together within NVIDIA FX Composer to produce your first rendered output. The work you’ve accomplished in this chapter serves as a foundation for the rest of the shaders in Part II, “Shader Authoring with HLSL.”
Exercises
1. Change the values of the RGB channels in the HelloShaders or HelloStructs pixel shader, and observe the results.
2. Modify the DisableCulling rasterizer state object by setting CullMode = FRONT and then BACK, and observe the results.
3. Now that you have a couple effects, get comfortable working within NVIDIA FX Composer. Create Teapot, Torus, and Plane objects, and assign them either the HelloShaders or HelloStructs materials. Notice how all objects that are assigned the same material are impacted when you change and recompile the associated effect.