An open graphics stack, from kernel to colour.

Colour management

Do the maths in linear light

Averaging, blurring, blending and lighting are physically meaningful only in linear light. If you do them on sRGB-encoded values you get the classic dark, muddy edges. Convert to linear on the way in, stay linear while you work, and transform to the display only at the very end.

1. Pick a working space

   Linear sRGB (Rec.709 primaries) for web and video work; ACEScg for compositing and VFX where wider gamut and scene-linear behaviour matter.

2. Tag every input

   Textures, plates and renders must declare what they are. An untagged asset is a bug waiting to be discovered after delivery.

3. Transform with a config, not by hand

   An OpenColorIO config centralises every conversion so the whole team and every render node agrees. Never bake a manual gamma tweak into an asset.

4. Calibrate the display

   Measure with a colourimeter, generate an ICC profile, load it, and verify against a test chart. Repeat every few months, and after any driver change.

5. Verify the round trip

   Render a known reference — a colour chart or a set of patches — compare the measured result with the expected value, and record the delta.

Shading

Vulkan and GLSL without the folklore

Modern practice is explicit: you manage memory, synchronisation and pipeline state yourself, and in exchange you get predictable performance. SPIR-V is the portable intermediate representation, so your shader source compiles once and runs on RADV, ANV and NVK without per-vendor rewrites.

• Prefer Vulkan for new work — explicit control, and every open userspace driver implements it properly.
• Keep shaders small and inspectable — compile with optimisations off while debugging, and read the SPIR-V disassembly when something is odd.
• Validate every run in development — the validation layers catch lifetime and synchronisation bugs that otherwise appear only on one vendor.
• Profile, do not guess — use a real GPU profiler before rewriting a shader that was never the bottleneck.

Example

A fragment shader that respects colour space

#version 450

// Inputs arrive in linear light. Stay linear; do not
// apply gamma here — the display transform owns that.
layout(location = 0) in vec3 vLinear;
layout(location = 1) in vec2 vUv;
layout(location = 0) out vec4 outColour;

layout(set = 0, binding = 0) uniform sampler2D albedo;

// sRGB-encoded texture to linear light.
vec3 srgbToLinear(vec3 c) {
    return mix(c / 12.92,
               pow((c + 0.055) / 1.055, vec3(2.4)),
               step(vec3(0.04045), c));
}

void main() {
    vec3 base = srgbToLinear(texture(albedo, vUv).rgb);
    vec3 lit  = base * max(vLinear, vec3(0.0));
    outColour = vec4(lit, 1.0);   // still linear
}

Compile with glslangValidator -V shader.frag -o shader.spv and load the resulting SPIR-V module. The display transform — sRGB, PQ or an ICC profile — happens after tone mapping, never inside a material shader.

Honesty notes

Where open graphics still hurts

Pretending there are no gaps helps nobody. These are the friction points we hit regularly, and what we do about them.

• New hardware arrives before the driver — a card can be on sale for months before the open driver supports every feature. Check before you buy, not after.
• Feature parity is uneven — ray tracing, video encode and some extensions differ per vendor. Test your specific workload.
• Colour pipelines are easy to misconfigure — tools disagree about defaults, so set the working space explicitly in every application.
• Firmware is often a blob — the driver is open while the microcode is not. It is still far more inspectable than a closed driver stack.