This page goes into detail about how to set up your captures for debugging shaders, as well as how to debug a shader and what controls are available.

# Including debug info in shaders

For the most part at least some debug information is included with shaders unless it is being explicitly stripped out at some point. There is usually an option to also include additional debug information - such as original source code in a high-level language. The exact process varies by API, but for D3D11 the flag /Zi to fxc or the equivalent flag to D3DCompile() will include additional debugging information, and /Qstrip_debug and /Qstrip_reflection will remove reflection information that can be useful - such as the names of variables in constant buffers.

# Debugging a vertex

Vertex debugging is invoked from the mesh viewer. With the mesh viewer open you can select the input vertex you wish to debug.

When a vertex is selected in the mesh data for the vertex input it will be highlighted along with the primitive it is part of in the mesh display, provided the display is in vertex input mode.

Either right click and choose debug vertex from the context menu, or click on the debug icon in the toolbar.

Launching vertex debugging from the mesh viewer.

From here the debugger will open with the vertex shader in the shader debugger. The inputs are automatically filled in from the mesh data.

Geometry and tessellation shaders are not yet debuggable.

# Debugging a Pixel

Pixel debugging is launched from the texture viewer. For more details on selecting the pixel to debug see .

When a given pixel is selected you can either choose the debug icon on the toolbar, or click the debug button underneath the pixel context. Each of these will launch the shader viewer with the selected pixel being debugged. The inputs to the pixel will be automatically filled in.

There are currently several things to note while pixel debugging:

- There is no pixel history at the moment, so the drawcall that you wish to debug must be selected as the current even when you attempt to debug the pixel.

- If a drawcall overdraws the same pixel several times then the results of debugging may not be accurate - RenderDoc attempts to pick the fragment that last passed the depth test but this isn't guaranteed and may not be perfect. There's also no way to choose a different fragment in the case of blending being used, or sample-frequency rendering.

# Debugging a Compute thread

To debug a compute thread simply go to the compute shader section of the pipeline state viewer and enter the group and thread ID of the thread you would like to debug. This thread will be debugged in isolation as with any other shader invocation.

This means there can be no synchronisation with any other compute thread running and the debugging will run from start to finish as if no other thread had run.

This feature is highly experimental and is provided with no guarantees yet! It may work on simple shaders which is why it is available.

# Debugging Controls

When debugging, at the moment the controls are fairly basic.

Controls for stepping through shaders.

The toolbar at the top gives controls for the program flow through the shader. Run and Run Backward simply run from the current position all the way through to the end or start of the program respectively.

The keyboard shortcuts for these controls are `F5` and `Shift-F5` respectively.

You can set a breakpoint by pressing F9 (this will also remove a breakpoint that is already there). When running in each direction or to cursor (see below) if execution hits a breakpoint it will stop.

The other controls allow for single stepping and limited running. Step forward will execute the current instruction and continue to the next - this includes following any flow control statements such as jumps, loops, etc.

Step backwards will jump back to whichever instruction lead to the current instruction. This does not necessarily mean the previous instruction in the program as it could be the destination of a jump. Stepping forwards and stepping backwards will always reverse each other. The shortcuts for these commands are `F10` and `Shift-F10`

The final control is to Run to the cursor. This will perform in a similar fashion to the "Run" command, but when it reaches the line that the cursor highlights it will stop and pause execution. It will also stop if it reaches the end of the shader.

The highlighted instruction at any given point indicates the next instruction to be executed - not the instruction that was just executed.

There is also a toggle available to control the 'default' interpretation of temporary register values - float or int. Since registers are typeless typically they are interpreted as float values, but with this toggle you can toggle them to be interpreted as integers.

# Debugging Displays

Currently there is only a very basic display when debugging shaders.

There are two windows that display different types of registers. The constants window will display input and constant buffer registers that are immutable throughout execution. This will also list registers for resources and samplers (with basic format information).

Constant, input and resource registers.

The other window will contain variable/mutable registers. These contain temporaries that are typically allocated up front and will update as you step through the execution of the shader. This window also contains the output registers.

Variable registers - temporaries and outputs.

The final window is initially empty but can be filled out as needed. This shows custom watch expressions and their values. Here you can write any expression involving an input, temporary or output register along with a swizzle and typecast.

Swizzles follow the standard hlsl rules - .[xyzw] or .[rgba] in any permutation or repetition will show those channels.

The custom typecast can be any of ,x ,i ,d ,f ,u ,b to display the register as hex, signed integer, double, float, unsigned, or bitwise respectively.

Watch window - custom register expressions evaluated.