AMD Wavefront Occupancy Analysis for GLSL Shaders

The AMD Radeon Developer Tool Suite, primarily driven by the Radeon Developer Panel (RDP) and the Radeon GPU Profiler (RGP), analyzes wavefront occupancy for GLSL compute shaders by capturing low-level hardware telemetry directly from the GPU's Sequencer (SQ). By correlating the compiled SPIR-V or GLSL assembly with hardware-level events, the suite tracks active, stalled, and retired wavefronts, mapping resource constraints such as register pressure and Local Data Share (LDS) usage to identify bottlenecks limiting compute throughput.

Hardware Trace Capture

Analysis begins with the Radeon Developer Panel intercepting the application's runtime (typically Vulkan or OpenGL when compiling GLSL). When a profile capture is triggered, the driver enables hardware thread tracing on the GPU's Command Processor. The hardware Sequencer unit logs detailed execution events for every wavefront spawned across the Compute Units (CUs) or Workgroup Processors (WGPs). This trace data contains exact cycle timestamps for wavefront creation, execution phases, resource stalls, and termination without introducing the high overhead typical of software-based profiling.

Theoretical vs. Achieved Occupancy

RGP computes occupancy by comparing theoretical maximum capacity against achieved runtime performance:

• Theoretical Occupancy: Calculated statically based on the GLSL shader’s compiled resource footprint. RGP inspects the number of Vector General-Purpose Registers (VGPRs), Scalar General-Purpose Registers (SGPRs), and LDS allocation declared per workgroup (defined by layout(local_size_x, ...)). If a shader requires excessive VGPRs or LDS, the hardware scheduler cannot launch the maximum number of concurrent wavefronts per CU, lowering the theoretical ceiling.
• Achieved Occupancy: Measured dynamically during the trace. RGP monitors how many wavefront slots are actively populated across all SIMDs at any given microsecond of the compute dispatch. Discrepancies between theoretical and achieved occupancy highlight pipeline bubbles, latency stalls, or inadequate global work size.

Instruction-Level Stall and Latency Identification

Once trace data is loaded into RGP, the tool details the specific states of wavefronts across a unified timeline. Wavefront states are categorized into active execution, memory wait, ALU dependency stalls, or export/sync stalls. For GLSL compute shaders, RGP highlights latency introduced by texture sampling, global buffer access (SSBO), and workgroup barriers (barrier() or memoryBarrierShared()). Developers can trace a stalled wavefront directly back to the instruction line responsible for high-latency memory fetches or synchronization stalls.

Identifying Compilation Bottlenecks

The suite automatically generates a summary of limiting factors. If wavefront occupancy is constrained, RGP indicates whether the limiting resource is workgroup dimensioning, LDS capacity, or vector register usage. By analyzing the disassembled machine code alongside the high-level GLSL logic, developers can observe how register allocation changes across basic blocks, enabling targeted optimizations such as reducing variable scope, unrolling loops judiciously, or adjusting local workgroup sizes to maximize parallel execution on AMD RDNA and GCN architectures.