Fix: Compute Shader Not Dispatching in Unity

Compute shaders in Unity are powerful but unforgiving. Unlike fragment shaders that at least show visual artifacts when something is wrong, a misconfigured compute shader simply produces nothing — no errors, no warnings, just an empty buffer. Here’s a systematic guide to diagnosing and fixing compute shader dispatch failures.

Thread Group Size Miscalculations

The most common cause of a compute shader that appears to do nothing is an incorrect dispatch call. The Dispatch(kernelIndex, threadGroupsX, threadGroupsY, threadGroupsZ) method specifies how many groups of threads to launch, not how many individual threads. If your shader declares [numthreads(8, 8, 1)] and your texture is 256x256, you need to dispatch (256/8, 256/8, 1) = (32, 32, 1) groups.

// WRONG: dispatching one thread per pixel
compute.Dispatch(kernel, 256, 256, 1);  // 256 * 8 = 2048 threads per axis

// CORRECT: dispatching one group per 8x8 block
int groupsX = Mathf.CeilToInt(256f / 8f);
int groupsY = Mathf.CeilToInt(256f / 8f);
compute.Dispatch(kernel, groupsX, groupsY, 1);

A subtler bug occurs when you pass zero for any dimension. If your data size is smaller than the thread group size, integer division rounds down to zero, and the shader runs zero threads. Always use Mathf.CeilToInt or add (threadGroupSize - 1) before dividing to round up.

// Safe calculation that handles non-multiples
int threadGroupSize = 64;
int dataCount = 100;
int groups = (dataCount + threadGroupSize - 1) / threadGroupSize;  // = 2, not 1
compute.Dispatch(kernel, groups, 1, 1);

Buffer Binding Mistakes

Every RWStructuredBuffer, StructuredBuffer, or RWTexture2D declared in your HLSL must be bound on the C# side before you call Dispatch. If you forget to bind even one buffer, the shader either reads garbage, writes to nothing, or — on some platforms — silently fails entirely.

// Shader side
// #pragma kernel CSMain
// RWStructuredBuffer<float3> Result;
// StructuredBuffer<float3> Input;
// float Multiplier;

// C# side — all three must be set
int kernel = compute.FindKernel("CSMain");
compute.SetBuffer(kernel, "Result", resultBuffer);
compute.SetBuffer(kernel, "Input", inputBuffer);
compute.SetFloat("Multiplier", 2.0f);

compute.Dispatch(kernel, groups, 1, 1);

Watch out for the kernel index parameter. Each kernel in your compute shader has its own set of bindings. If your shader has multiple #pragma kernel declarations, binding a buffer to kernel 0 does not make it available to kernel 1. You must call SetBuffer for each kernel that uses the buffer.

Another common mistake is creating a ComputeBuffer with the wrong stride. The stride must exactly match the size of the struct in your HLSL. A float3 is 12 bytes, not 16. A struct with a float3 and a float is 16 bytes due to packing. Use Marshal.SizeOf or calculate manually.

Reading Results Back to the CPU

Even when the shader dispatches correctly, you can get empty results if you read the buffer back too early. Dispatch is asynchronous — the GPU work is only queued, not completed, when the method returns. If you call GetData immediately, you may read the buffer before the shader has written to it.

// WRONG: reading immediately after dispatch
compute.Dispatch(kernel, groups, 1, 1);
resultBuffer.GetData(results);  // May contain stale data

// CORRECT: use AsyncGPUReadback for non-blocking reads
compute.Dispatch(kernel, groups, 1, 1);
AsyncGPUReadback.Request(resultBuffer, (request) => {
    if (!request.hasError) {
        var data = request.GetData<Vector3>();
        // Process results here
    }
});

For debugging purposes, calling GetData synchronously does work — it forces a GPU sync and waits for the dispatch to complete. It is just very slow and should never be used in production code. But if your debug read-back is also returning zeros, the problem is definitely in the dispatch itself, not in timing.

Platform Compatibility Issues

Compute shaders are not universally supported. They require DirectX 11+, Metal, Vulkan, or OpenGL ES 3.1+. WebGL 1.0 does not support them at all, and WebGL 2.0 support is limited. Older Android devices with OpenGL ES 3.0 will silently skip compute dispatches.

// Always check before using compute shaders
if (!SystemInfo.supportsComputeShaders) {
    Debug.LogWarning("Compute shaders not supported, using CPU fallback");
    RunCPUFallback();
    return;
}

// Also check specific feature requirements
if (SystemInfo.maxComputeWorkGroupSize < requiredGroupSize) {
    Debug.LogWarning("Thread group size exceeds device limit");
}

On Metal (macOS and iOS), compute shaders have different resource binding limits than DirectX. If your shader uses more than 31 buffers or 128 texture samplers, it will fail on Apple hardware even though it works fine on Windows. The Unity console may not show an error — the shader simply does not run.

Debugging with RenderDoc

When all else fails, attach RenderDoc to your Unity editor. Capture a frame, find the compute dispatch in the event list, and inspect the bound resources. RenderDoc will show you exactly which buffers are bound, what data they contain before and after the dispatch, and whether the dispatch executed at all. This is the single most effective debugging tool for compute shader issues and will save you hours of guesswork.

In the Unity Frame Debugger, compute dispatches appear as separate events. You can verify that the dispatch is being issued, but the Frame Debugger cannot show you buffer contents. For that level of inspection, you need RenderDoc or PIX on Windows, or Xcode’s GPU debugger on macOS.

Check your thread groups, bind every buffer, verify platform support.