Atomic Float Operations with GL_EXT_shader_atomic_float

This article provides an overview of how the GL_EXT_shader_atomic_float extension expands GLSL capabilities by enabling native atomic operations on floating-point data types. Traditionally, GLSL restricted atomic operations strictly to integer types, forcing developers to rely on complex compare-and-swap loops for floating-point calculations. By integrating GL_EXT_shader_atomic_float, developers can directly perform atomic read-modify-write operations on scalar float and associated vector memory layouts across buffer storage blocks, shared memory, and images.

The Limitation of Native GLSL Atomics

Standard GLSL restricts built-in atomic functions—such as atomicAdd, atomicExchange, and atomicCompSwap—to 32-bit unsigned and signed integers (uint and int). When algorithms like order-independent transparency (OIT), weight accumulation, or physics simulations required atomic updates to floating-point buffers, developers had to implement workarounds.

The standard workaround involved casting floating-point values to integers using floatBitsToInt and running an atomicCompSwap inside a spin loop until the operation succeeded. This approach caused severe thread divergence, high memory contention, and performance bottlenecks on modern GPU architectures.

How GL_EXT_shader_atomic_float Modifies GLSL

The GL_EXT_shader_atomic_float extension removes these software loops by introducing native atomic instructions that hardware can execute in a single memory transaction.

To use these capabilities in a shader, the extension must first be declared:

#version 450
#extension GL_EXT_shader_atomic_float : enable

Once enabled, the extension overloads standard atomic built-in functions to accept 32-bit floating-point (float) types in addition to integers:

• Buffer and Shared Memory Operations: Overloads atomicAdd and atomicExchange to accept inout float targets stored in shared workgroup memory (shared) or Shader Storage Buffer Objects (SSBOs).
• Image Operations: Introduces imageAtomicAdd and imageAtomicExchange targeting floating-point image variables with formats like r32f.

Handling float and vec Types

The primary extension specifically introduces scalar 32-bit float operations. In GLSL, operations on vector types (vec2, vec3, vec4) are executed per-component:

1. Component-wise Access on Vector Arrays: In storage buffers containing vector arrays, developers target individual vector components directly:

   layout(std430, binding = 0) buffer DataBuffer {
       vec4 data[];
   };
   
   void main() {
       // Atomically adds to the red component of a specific vector
       atomicAdd(data[gl_GlobalInvocationID.x].r, 1.5);
   }

2. Multi-component Images: For vector images (such as multi-channel accumulation buffers), atomic writes target specific coordinates and address scalar components within the image binding.

3. Relation to GL_EXT_shader_atomic_float2: While GL_EXT_shader_atomic_float establishes fundamental scalar float additions and exchanges, its companion extension, GL_EXT_shader_atomic_float2, expands this functionality to include 16-bit floats (float16_t), minimum/maximum operations (atomicMin, atomicMax), and direct packed vector arithmetic.

Underlying Compilation and SPIR-V Translation

When compiling GLSL to SPIR-V for Vulkan or modern OpenGL drivers, GL_EXT_shader_atomic_float maps high-level function calls directly to dedicated SPIR-V atomic instructions using the AtomicFloat32AddEXT capability.

Instead of generating conditional branch instructions and comparison loops, the compiler emits a single OpAtomicFAddEXT instruction. The underlying GPU hardware processes the floating-point addition at the memory controller or L2 cache level, guaranteeing thread safety, minimizing bandwidth usage, and significantly improving compute shader throughput.