How Do GLSL Compute Shaders Work Outside Graphics?

GLSL compute shaders allow developers to leverage the massive parallel processing power of the GPU for general-purpose computing tasks independently of the traditional rasterization pipeline. This article details the structural components of a compute shader in GLSL, how work is organized into local and global workgroups, how data is passed and synchronized using storage buffers, and how execution is invoked from host OpenGL code.

The Compute Shader Paradigm

Unlike vertex, fragment, or geometry shaders, compute shaders exist outside the fixed-function rendering pipeline. They do not take traditional vertex attributes as inputs, nor do they output directly to a framebuffer. Instead, they operate as standalone programs capable of reading from and writing to arbitrary memory locations via Shader Storage Buffer Objects (SSBOs) and image load/store units.

Internal Shader Structure and Workgroups

Compute shaders organize execution around threads, known as invocations. These invocations are grouped into local workgroups, which are defined directly inside the GLSL source code using a layout qualifier.

#version 430 core

// Define the 3D dimensions of a local workgroup
layout (local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

// Bind a Shader Storage Buffer Object for input and output
layout(std430, binding = 0) buffer DataBuffer {
    float data[];
};

void main() {
    // Determine the unique global thread index
    uint globalIndex = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * (gl_NumWorkGroups.x * gl_WorkGroupSize.x);
    
    // Perform computation
    data[globalIndex] *= 2.0;
}

GLSL provides several built-in variables to determine the execution context of each thread:

• gl_NumWorkGroups: The total number of workgroups dispatched by the host application along the X, Y, and Z axes.
• gl_WorkGroupID: The 3D index of the current workgroup within the global dispatch grid.
• gl_LocalInvocationID: The 3D index of the current thread relative to its local workgroup.
• gl_GlobalInvocationID: The unique 3D index of the thread across the entire execution space, calculated as gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID.
• gl_LocalInvocationIndex: A 1D flattened representation of gl_LocalInvocationID.

Host-Side Invocation

Running a compute shader requires setting up the shader program and dispatching workgroups via the OpenGL API on the CPU side:

1. Compilation and Linking: The shader source is compiled with GL_COMPUTE_SHADER and linked into a standard shader program using glLinkProgram.
2. Buffer Binding: Storage buffers (such as SSBOs) are allocated and bound to the matching binding points specified in the GLSL code using glBindBufferBase.
3. Dispatching: The host invokes the shader grid using glDispatchCompute(num_groups_x, num_groups_y, num_groups_z).

For example, dispatching a grid to cover a 1024x1024 domain using local workgroups of 16x16:

glUseProgram(computeProgram);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, ssbo);

// Dispatch 64x64 workgroups (64 * 16 = 1024 threads per dimension)
glDispatchCompute(64, 64, 1);

Synchronization and Memory Barriers

Because compute shader invocations execute asynchronously and concurrently, data hazards can occur when subsequent rendering commands or compute dispatches access the same memory.

Within the GLSL shader, execution across threads in the same workgroup can be synchronized using barrier(), and memory writes can be flushed using memoryBarrierShared() or memoryBarrierBuffer().

On the host side, synchronization is enforced using glMemoryBarrier(). Calling glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT) or glMemoryBarrier(GL_BUFFER_UPDATE_BARRIER_BIT) guarantees that all write operations performed by the compute shader complete before subsequent commands read the updated buffer data.