🧮 Lesson 5.4: Compute Shaders — General-Purpose GPU Work

What Is a Compute Shader?

A vertex or fragment shader is locked into the rendering pipeline — it runs per vertex or per pixel, when the GPU draws. A compute shader has no such role: it's a program you launch on the GPU to do whatever you want, reading and writing arbitrary buffers and textures. It's the GPU as a general parallel processor.

Why bother? Because the GPU has thousands of tiny cores. For problems that are "do the same simple thing to a million elements" — every pixel of an image, every particle in a system, every cell of a simulation grid — the GPU annihilates the CPU. The catch is the same discipline Module 3 drilled: the work must be highly parallel and data-oriented, and getting results back to the CPU costs (so ideally you keep them on the GPU and render them directly).

Kernels & Thread Groups

When you dispatch, the GPU runs the kernel across a 3D grid of threads, organised into thread groups. The [numthreads(x,y,z)] attribute sets how many threads are in one group; your C# Dispatch(groupsX, groupsY, groupsZ) call sets how many groups. Total threads = groups × threads-per-group.

Writing the Kernel

A compute shader is a .compute asset (right-click ▸ Create ▸ Shader ▸ Compute Shader). Here's a complete kernel that fills a texture with an animated plasma — each thread computes one pixel's colour from its coordinates:

#pragma kernel CSMain          // declare the kernel entry point

RWTexture2D<float4> Result;    // the texture we WRITE (RW = read/write)
float Time;
uint Width, Height;

float3 hsv2rgb(float3 c)
{
    float3 p = abs(frac(c.xxx + float3(0.0, 2.0/3.0, 1.0/3.0)) * 6.0 - 3.0);
    return c.z * lerp(float3(1,1,1), saturate(p - 1.0), c.y);
}

[numthreads(8,8,1)]            // 8×8 = 64 threads per group
void CSMain (uint3 id : SV_DispatchThreadID)   // id = this thread's global (x,y,z)
{
    float2 uv = float2(id.x / (float)Width, id.y / (float)Height);
    float2 p  = uv * 6.0 - 3.0;

    // interference of several sine waves → a smooth plasma field
    float v = sin(p.x*1.5 + Time) + sin(p.y*1.7)
            + sin((p.x+p.y)*1.1) + sin(length(p)*2.0);
    v += sin(p.x*0.5 + sin(p.y*0.8)*2.0);

    float3 col = hsv2rgb(float3(frac(v*0.12 + 0.5), 0.8, 1.0));
    Result[id.xy] = float4(col, 1.0);          // write this pixel
}

RWTexture2D is a texture the shader can write (the RW prefix — an ordinary Texture2D is read-only). SV_DispatchThreadID gives each thread its unique global coordinate, so id.xy is exactly the pixel this invocation owns. No loop — the GPU runs a million of these at once.

Dispatching from C#

On the C# side you create a writable RenderTexture, wire up the kernel's parameters, and dispatch enough groups to cover the image:

using UnityEngine;

public class PlasmaCompute : MonoBehaviour
{
    public ComputeShader compute;    // assign the .compute asset
    public RawImage target;          // a UI RawImage to show it (optional)
    RenderTexture rt;

    void Start()
    {
        int w = 1024, h = 1024;

        // A RenderTexture a compute shader can write needs enableRandomWrite.
        rt = new RenderTexture(w, h, 0) { enableRandomWrite = true };
        rt.Create();

        int kernel = compute.FindKernel("CSMain");
        compute.SetTexture(kernel, "Result", rt);
        compute.SetInt("Width", w);
        compute.SetInt("Height", h);
    }

    void Update()
    {
        int kernel = compute.FindKernel("CSMain");
        compute.SetFloat("Time", Time.time);

        // groups = imageSize / numthreads  →  1024 / 8 = 128
        compute.Dispatch(kernel, 1024 / 8, 1024 / 8, 1);

        if (target != null) target.texture = rt;   // show the GPU result directly
    }

    void OnDestroy()
    {
        if (rt != null) rt.Release();   // free the GPU texture
    }
}

Two must-dos: set enableRandomWrite = true on the RenderTexture (or the GPU can't write it), and Release() it when done. Notice the result never comes back to the CPU — we hand the RenderTexture straight to the UI, so the data stays on the GPU where it's fast. Dispatching every frame with Time.time animates it.

The Result

Here is that exact kernel's output — a real capture of the RenderTexture the compute shader wrote, one thread per pixel across a million pixels:

This is the payoff of the whole approach: a million independent colour computations, done in a fraction of a millisecond, never touching the CPU. Swap the maths for a fluid step, a reaction-diffusion update, or a heightmap and the same structure drives real simulations.

Beyond Textures: Buffers

Textures are ideal for image-shaped data, but compute shaders shine on arbitrary data too — thousands of particle positions, physics bodies, boids. For that you use a GraphicsBuffer (the modern form; ComputeBuffer is the older equivalent): a raw GPU array of structs your kernel reads and writes.

struct Particle { public Vector3 pos; public Vector3 vel; }   // must match HLSL layout

// stride = bytes per element (6 floats × 4 = 24)
var buffer = new GraphicsBuffer(GraphicsBuffer.Target.Structured, count, sizeof(float) * 6);
buffer.SetData(particles);                    // upload
compute.SetBuffer(kernel, "Particles", buffer);
compute.Dispatch(kernel, Mathf.CeilToInt(count / 64f), 1, 1);
// buffer.GetData(particles);                 // read back ONLY if you must (slow)
buffer.Release();                              // always free it

In the kernel that's a RWStructuredBuffer<Particle> Particles;. The golden rule mirrors Module 3: keep the data on the GPU. Reading a buffer back with GetData stalls until the GPU finishes and copies across the bus — fine occasionally, poison every frame. Best of all, a GraphicsBuffer of positions can be fed straight into Graphics.RenderMeshIndirect to draw millions of instances the CPU never even sees.

When to Use Compute

Reach for a compute shader when the work is massively parallel, data-heavy, and ideally stays on the GPU:

• Image processing — blur, bloom, custom filters, histograms.
• Particle & boid systems — tens of thousands of agents updated and drawn without CPU round-trips.
• Simulations — fluids, cloth, reaction-diffusion, heightfields, cellular automata.
• Culling & LOD — GPU-driven visibility for huge scenes (what the GPU Resident Drawer from Lesson 2.4 does under the hood).
• Procedural generation — noise fields, meshes, textures built on the GPU.

If the work is small, branchy, or you need the answer back on the CPU immediately, a Burst job (Module 3) is often the better tool. Compute wins when the parallelism is enormous and the result feeds straight back into rendering.

Hands-on Challenge

Summary

🚀 What's Next?

You've now touched every rendering layer — the frame, HLSL, custom passes, and compute. In Lesson 5.5 you'll combine the shader and renderer-feature skills into the module's mini-project: a complete custom full-screen post-process effect, injected into URP and rendered live.