The Texture Is Not for Pixels

The GPU doesn't care about your cat photos. To a compute shader, a texture isn't a collection of colors or a visual asset; it’s a multidimensional, hardware-optimized block of addressable memory that can dodge the annoying limitations of standard storage buffers.

If you’ve spent any time writing WebGPU compute shaders, you’ve likely hit the "Buffer Wall." You try to allocate a massive array for a simulation, only for the browser to scream because you exceeded maxStorageBufferBindingSize. On many mobile devices and even some integrated desktop chips, that limit is surprisingly low—often just 128MB or 256MB.

But textures? Textures are the loophole.

The Secret Life of Storage Textures

In WebGPU, a GPUBuffer is a linear stretch of memory. It’s predictable and simple. However, a GPUTexture is backed by hardware-specific tiling patterns (often called swizzling). Instead of rows following each other linearly, pixels are stored in "blocks" or "Z-order curves" to ensure that looking at a pixel’s neighbor is fast in any direction.

When we treat a texture as Storage, we stop thinking in RGB and start thinking in XY coordinates.

Breaking the Size Limit

While your storage buffer might be capped at 256MB, a 16k x 16k texture is perfectly legal on most modern hardware. If you’re using rgba32float format, that single texture holds about 1GB of data.

Here is how you define a storage texture in your JavaScript/TypeScript setup:

const size = 8192; // An 8k texture

const computeDataTexture = device.createTexture({
  size: [size, size],
  format: 'rgba32float', // 4 floats per pixel = 16 bytes
  usage: GPUTextureUsage.STORAGE_BINDING | GPUTextureUsage.TEXTURE_BINDING
});

// Total memory: 8192 * 8192 * 16 bytes = 1,073,741,824 bytes (1GB)

By using this instead of a buffer, you've just quintupled your available memory space on restrictive hardware without breaking a sweat.

WGSL: Reading and Writing Without UVs

When using textures for compute, we throw sampler out the window. We don't want interpolated values; we want the raw bits. In your WGSL code, you'll use textureLoad and textureStore with integer coordinates.

@group(0) @binding(0) var myData: texture_storage_2d<rgba32float, read_write>;

@compute @workgroup_size(8, 8)
fn main(@builtin(global_invocation_id) id: vec3u) {
    let coords = id.xy;
    
    // Read the "pixel" as raw data
    let value = textureLoad(myData, coords);
    
    // Do some heavy math
    let result = value * 2.0 + vec4f(0.5, 0.1, 0.0, 1.0);
    
    // Write it back exactly where it belongs
    textureStore(myData, coords, result);
}

Notice there are no floats in the coordinates. No 0.5 or 1.0. We are using vec2u (unsigned integers) because we are treating this texture like a 2D array, not an image.

Why 2D Locality Matters

Why bother with the 2D overhead if your data is just a list of particles? Because of the L1 Cache.

When a compute shader reads from a linear buffer, it pulls a "line" of data into the cache. If your algorithm needs to look at "neighbors" in a grid (like in a fluid simulation or a Game of Life implementation), the neighbor "above" you in a linear buffer might be thousands of bytes away, causing a cache miss.

Textures are physically laid out in memory to keep 2D neighborhoods close together. This means textureLoad(coords + vec2u(0, 1)) is often significantly faster than calculating a manual index in a flat array.

The Gotchas (Because there's always a catch)

I’d be lying if I said this was a free lunch. Using textures as memory comes with some "fine print" you need to respect:

1. Format Strictness: You can't just store anything. You're limited to specific formats like rgba32float, rgba16float, or r32float. If your data doesn't fit into groups of 4 floats (or ints), you’ll end up wasting "channels."
2. Alignment: Some devices are picky about read_write storage textures. You might have to split them into two separate bindings: one texture_2d<f32> for reading and one texture_storage_2d<...> for writing.
3. No Atomics: You can't perform atomic operations (like atomicAdd) on texture pixels easily. If you need global counters, you’ll still need a small GPUBuffer on the side.

When to Switch

Stop using buffers when:
* You are building a grid-based simulation (SDFs, heat maps, fluids).
* You hit the maxStorageBufferBindingSize limit.
* You need to pass data directly to a fragment shader for rendering (you can skip the "copy buffer to texture" step entirely).

The texture isn't a picture. It’s a 2D-spatial-aware-memory-block that happens to play nice with the GPU's fixed-function hardware. Start using it that way, and your WebGPU apps will feel a lot less cramped.