GLSL dmat4 Matrix Multiplication ALU Penalties

Utilizing double-precision 4x4 matrices (dmat4) in GLSL introduces severe ALU throughput penalties compared to standard single-precision (mat4) operations. This performance degradation stems from fundamental hardware constraints in modern GPUs, including heavily restricted double-precision (FP64) execution unit ratios, doubled register consumption leading to lower warp occupancy, and increased arithmetic instruction latency. Depending on whether shaders run on consumer or enterprise silicon, performing a dmat4 multiplication can reduce arithmetic throughput by a factor ranging from 4x to more than 64x.

Hardware FP64 to FP32 Throughput Ratios

Modern GPU architectures are heavily optimized for 32-bit floating-point (FP32) and lower-precision operations. Physical execution units for 64-bit floating-point arithmetic are scarce on consumer-grade silicon:

  • Consumer GPUs (NVIDIA GeForce / AMD Radeon): Gaming-oriented architectures typically feature an FP64-to-FP32 performance ratio between 1:32 and 1:64. In some architectures, dedicated FP64 units are omitted entirely or heavily throttled, forcing the compiler to emulate portions of 64-bit operations using complex multi-instruction sequences.
  • Workstation and Enterprise GPUs (NVIDIA Tesla/Data Center, AMD Instinct): Compute-focused enterprise accelerators often maintain a native FP64-to-FP32 ratio of 1:2. Even in this optimal scenario, FP64 math is fundamentally half the speed of equivalent FP32 math before accounting for other architectural overheads.

Because a matrix multiplication inherently consists of 64 fused multiply-add (FMA) operations, dispatching these instructions to hardware with a 1:32 or 1:64 throughput cap directly translates to an immediate 32x to 64x execution time penalty on consumer hardware.

Register Pressure and Occupancy Loss

A single-precision mat4 requires 16 32-bit floats, occupying 64 bytes (16 vector registers or 4 full SIMD vector slots). A dmat4 doubles this requirement to 16 64-bit floats, consuming 128 bytes per variable.

This footprint impacts performance in two distinct ways:

  1. Register Spilling: Multiplying two dmat4 instances involves holding the input operands, intermediate accumulation variables, and the result matrix simultaneously. The sheer volume of 64-bit state frequently exceeds the available fast register file per thread, triggering register spills into slower local scratch memory or GPU cache hierarchies.
  2. Reduced Occupancy: GPUs rely on massive thread concurrency (warps or wavefronts) to hide memory and arithmetic latencies. The heavy register footprint of dmat4 drastically limits the number of active threads a Streaming Multiprocessor (SM) or Compute Unit (CU) can host concurrently, eliminating the GPU's primary mechanism for latency hiding.

Instruction Latency and Execution Stalls

FP64 execution pipelines exhibit noticeably higher instruction latencies than their FP32 counterparts. While an FP32 FMA instruction typically resolves in 4 to 6 clock cycles, an FP64 operation often demands longer execution pipelines.

Because fewer physical FP64 ALUs exist per execution block, instructions cannot be continuously dual-issued or interleaved effectively. A thread issuing consecutive dmat4 calculations will rapidly encounter execution stalls while waiting for previous FP64 operations to clear the pipeline, serializing execution across the warp.

Architectural Summary

The throughput penalty of a GLSL dmat4 multiplication is compound rather than linear. It is calculated by multiplying the basic algorithmic cost (64 double-precision FMAs) against the hardware FP64 execution ratio (typically 1/32 to 1/64 on consumer cards), further compounded by a 50% or greater reduction in warp occupancy caused by register bloat. Unless numerical precision strictly mandates 64-bit stability—such as planetary-scale coordinate transformations or iterative numerical simulations—FP64 matrix multiplication should be avoided in performance-critical rendering pipelines.