Dr. PIX

Dr. PIX provides some detailed analysis of a selected named event or draw call. This tool runs a number of experiments including checking on the clock speed, use of ESRAM, use of Compute Units, use of Hi-Z rejection, and provides a text report on what it has found and what the issues might be. This tool is available through the Deep Analysis tab in PIX.

Using Dr. PIX
Dr. PIX Experiments

Using Dr. PIX

Make a normal PIX capture, using the Capture Next Frame feature described in Capturing a PIX Frame.
Select a draw event. This can be made easier by selecting GpuWorkEvents or typing draw into the filter.
Select one of the titles in the Overall summary: or Details for selected event: lists.
An analysis normally takes a few seconds to run.
View the results. The Overall summary: panel is the frame overview and displays measurements for the entire frame. The Details for selected event: panel is the detailed event information and displays measurements for the selected draw event or named event from the Events hierarchy.

Dr. PIX Experiments

The following tables list the Dr. PIX experiments. Each experiment typically varies or disables some graphics functionality, in order to be able to isolate whether a particular feature of the graphics processor is being used to best advantage.

Basic Information
Performance
ALU Instructions
Primitives and Rasterization
Texture Fetches and Filters
Bandwidth
Mip Histogram
Anisotropic Filtering
Cache

Basic Information

Experiment	Description
Context rolls	A Context Roll experiment is available to artificially reduce the number of contexts available to the title. If the selected set of draw calls becomes any slower, that indicates they were constrained by context rolls. A context roll occurs when a state or shader change necessitates rolling all of the GPU registers to a new context. This limits throughput when rendering a series of small draws as there is a limited set of contexts. Context roll ratios near 1.0 indicate that draw calls are not being efficiently batched by shader. For small draw sizes, context rolls become very expensive.

Experiment

Description

Context rolls

A Context Roll experiment is available to artificially reduce the number of contexts available to the title. If the selected set of draw calls becomes any slower, that indicates they were constrained by context rolls. A context roll occurs when a state or shader change necessitates rolling all of the GPU registers to a new context. This limits throughput when rendering a series of small draws as there is a limited set of contexts. Context roll ratios near 1.0 indicate that draw calls are not being efficiently batched by shader. For small draw sizes, context rolls become very expensive.

Performance

Experiment	Description
Measured Duration with GPU Clock 12.5% Slower: 4670 ns (2.17% faster)	This value is the measured duration with the GPU Core Clock Speed set 12.5% slower than default. If the scene does not show much performance degradation, then you are likely main memory bound.
Measured Duration with Half CUs: 4970 ns (4.00% slower)	This value is the measured duration with half of the Compute Units (CUs) disabled. If the scene does not show much performance degradation, then you are likely not ALU bound and is probably not using the CUs as efficiently as it could.
Measured duration and Z/Stencil	There is a range of experiments with Z, Hi-Z, Stencil enabled and disabled. The Hi-Z experiment is designed to expose the scenario where Hi-Z rejection is disabled on the GPU. The experiment disables Hi-Z rejection, forcing the GPU to do per-pixel depth testing. If the percentage change between enabling and disabling Hi-Z testing is small, it typically means that something else in the scene is forcing Hi-Z rejection off - this can be verified by looking at the DB_PERF_SEL_DB_SC_TILE_HIER_KILL counter. There are several conditions which can force Hi-Z rejection off on the GPU, for example when a pixel shader writes to the depth or stencil buffer, a pixel shader has side effects such as UAV writes, stencil processing on stencil or z failures, and other situations such as pixels being discarded or perfect z counts. The intent is to alert you when the Hi-Z optimization is not working efficiently. There are three separate processes to the Z and Stencil experiments: Hi-Z/Stencil: Without this, all samples must be depth-tested individually. Fast Z/Stencil: Without this, clears of depth-stencil surfaces must write the clear value explicitly to every sample. Z/Stencil compression: Without this, depth-stencil surfaces must contain an explicit, separate depth-stencil value for each sample.
Texture sampler experiments	These experiments measure GPU savings when all pixel shader samplers are forced to disable bilinear, trilinear, or anisotropic filtering.
Parameter cache	Parameter cache is a block that receives vertex attribute outputs from SX (Shader export) and stores them until Pixel Shader waves are ready. The size of the Parameter Cache is limited and can be a bottleneck. This test attempts to estimate the effect of the Parameter Cache by reducing the number of active items in it. If you see performance scaling as the size of the PC decreases, look at packing/compressing VS output attributes because it might be a bottleneck.
Single-pixel Texture	This measures the GPU time savings when all textures in the draw calls are replaced with 1x1 textures, effectively eliminating time spent on texture cache misses. Large differences indicate poor texture cache utilization.
SIMD Occupancy Reduced	This value is measured with pipelining between events, and may therefore appear to be higher than in the Events view. This experiment measures the GPU time lost if the maximum number of waves per SIMD were lowered from 10 (the hardware limit) successively down to 1. One way to increase occupancy is to use fewer GPRs in your shaders.

ALU Instructions

Experiment	Description
ALU Timing Estimate	This value is the estimated amount of time spent on v_* vector ALU instructions per shader state. If this value is near to the actual measured time, then you are likely ALU bound.
ALU Rate	This value is the ALU instructions penalty for using quarter rate, and double instructions. An ideal rate is 1.0x. Higher values occur from using slower ALU instructions such as SQRT_F32 which runs 4.0x slower.
Shader analysis	A lot of shader statistics follow the ALU experiment information. Includes detailed Vertex, Pixel, Geometry and Export shader results.

Primitives and Rasterization

Experiment	Description
Quad Histogram	This value is the percentage of active pixels per 2x2 pixel quad. A high number of less than 4 pixel quads is commonly caused by tiny triangles and results in poor depth compression and poor pixel shader utilization. The "Post Hi-z" numbers include all quads which would be sent on to early-z, including some pixels which will fail the depth test and therefore will not be shaded, while omitting other pixels which have been handled by hi-z trivial accept and therefore will be shaded. The "Post Early-z" numbers include all quads which will be sent to the pixel shader, and these numbers are therefore most relevant to overall expense from quad inefficiency.
Vertex/Primitive Efficiency	These values cover primitives that are going through the vertex pipeline that are being thrown away by the GPU. High numbers here may indicate that additional CPU-side object culling is required.

Experiment

Description

Quad Histogram

This value is the percentage of active pixels per 2x2 pixel quad. A high number of less than 4 pixel quads is commonly caused by tiny triangles and results in poor depth compression and poor pixel shader utilization. The "Post Hi-z" numbers include all quads which would be sent on to early-z, including some pixels which will fail the depth test and therefore will not be shaded, while omitting other pixels which have been handled by hi-z trivial accept and therefore will be shaded. The "Post Early-z" numbers include all quads which will be sent to the pixel shader, and these numbers are therefore most relevant to overall expense from quad inefficiency.

Vertex/Primitive Efficiency

These values cover primitives that are going through the vertex pipeline that are being thrown away by the GPU. High numbers here may indicate that additional CPU-side object culling is required.

Texture Fetches and Filters

Experiment	Description
Texture Filter Cost for Bit Depth	Textures which are greater than 32bpp incur an additional filtering cost. 64bpp cost 2x normal, 96bpp cost 3x normal, and 128bpp cost 4x normal. The additional cost applies to bilinear, trilinear, and aniosotropic filtering.
Texture Tiling	Tiled textures can be more efficient for many situations. Linear textures are created for D3D11_USAGE_DYNAMIC textures.

Bandwidth

Experiment	Description
Memory Bandwidth	This is amount of memory read and written to main memory including coherent memory. Coherent memory comes from D3D11_USAGE_DYNAMIC resources and operates at half rate read and one quarter rate write.
ESRAM Bandwidth	This is amount of memory read and written to ESRAM. Dr. PIX disables ESRAM then re-runs the call. If there is no loss of performance in disabling ESRAM, then your app is probably not using ESRAM to its best advantage.
HUB Remote Transactions	HUB pre-translated transactions are very high latency memory transactions that occur when CB or DB accesses memory in inefficient pattern. This happens for example when you use linear tiling for your render targets. Each transaction can be 32 to 256 bytes in size so the number of bytes read may be variable.

Mip Histogram

Experiment	Description
Pixel Shader MIP Histogram:	This value is the percentage of texture samples read from each MIP level.

Anisotropic Filtering

No Anisotropic information is currently analyzed.

Experiment	Description

Cache

Experiment	Description
L2 cache	All memory requests by the GPU to or from DRAM or ESRAM go through the L2, except for a few components which have their own caches, such and DB and CB. There are 4 TCC (texture cache per channel) instances, each bound to a particular range of virtual addresses. Each instance is 128 KB in size, with a 64-byte cache line.
L1 cache	The TCP (texture cache per pipe) handles memory requests from shaders. When requests miss in the TCP, they go to the L2/TCC. There are 12 TCP instances, one per CU. Each instance is 16 KB in size, with a 64-byte cache line.
SQC I-cache	Each SQC services less than or equal to 4 CUs. It contains an I-cache and a D-cache (sometimes called K-cache), for shader instructions and shader constant data respectively.
SQC D-cache (K-cache)	D-cache (K-cache) efficiency. Duplicate misses are those which have already been requested from L2, but haven't returned yet.
DB depth/stencil cache	Stores uncompressed depth or stencil values, or compressed depth indices (PMask). There are four instances, one per DB, each one 8 KB in size. Together, they can hold 8192 depths, 65536 stencils, or 131072 indices.
DB depth plane cache	Stores plane equations for compressed depth tiles. There are 4 instances, one per DB, each one 3 KB in size. Together, they can hold 1024 depth planes.
DB htile cache	Stores hi-z and depth compression information. There are 4 instances, one per DB, each one 32 KB in size. Together, they can hold 2 Mpixels. For depth/stencil surfaces less than this size, after initial load, htile hit (null) should be 100.
CB color cache	Stores colors for render targets. There are 4 instances, one per CB, each one 4 KB in size. Together, they can hold 4096 pixels of 32 bpp color at 1xMSAA. Each cache line is composed of multiple sectors. There are two ways to miss the cache: Tag Miss: No line allocated in cache. Sector Miss: Line may or may not be allocated in cache, but data for sector not yet requested.
CB fmask cache	Stores index data (fmask) for compressed MSAA render target. There are 4 instances, one per CB, each one 4 KB in size. Together, they can hold 2048-16384 pixels worth of fmask data, depending on MSAA mode. Each cache line is composed of multiple sectors. There are two ways to miss the cache: Tag Miss: No line allocated in cache. Sector Miss: Line may or may not be allocated in cache, but data for sector not yet requested.
CB cmask cache	Stores tile data (cmask) for compressed render targets. Cmask data supports fast clears and MSAA/EQAA compression. There are 4 instances, one per CB, each one 1 KB in size. Together, they can hold 8192 tiles worth of cmask data. Each cache line is composed of multiple sectors. There are two ways to miss the cache: Tag Miss: No line allocated in cache. Sector Miss: Line may or may not be allocated in cache, but data for sector not yet requested.