About

GPU Modules is a curated library of WebGPU building blocks distributed as source code. You browse modules on this site, copy them into your project with a CLI command, and modify them however you want.

Why this exists

There’s a wealth of GPU techniques — noise functions, sorting algorithms, distance fields, post-processing effects — that power games, simulations, creative tools, and data visualization. The knowledge is out there in papers, conference talks, and scattered shader snippets. But going from “I read about Perlin noise” to “I have a working WebGPU compute shader generating noise into a texture I can bind” is a real gap.

GPU Modules exists to close that gap. Every module is a working implementation of a known technique, with a live demo you can interact with, source code you can read, and a further reading section that links back to the original research and existing implementations in other languages.

The goal isn’t just to give you code to copy. It’s to build a knowledge base — a place where you can understand how these techniques actually work on the GPU, see them running in your browser, and then take the implementation into your own project and make it yours.

Why not npm install?

GPU code doesn’t compose the way regular JavaScript does. A noise function isn’t a black box you call — it’s a WGSL function you inline into your shader pipeline. A radix sort isn’t an API you import — it’s a set of compute shaders you dispatch in a specific order with your own buffer management.

Wrapping these in an npm package creates problems:

  • You can’t modify the shaders. GPU code needs to be tuned for your specific use case — workgroup sizes, texture formats, buffer layouts. A package’s public API can’t expose all of that.
  • WGSL doesn’t have an import system. There’s no #include, no module resolution. To use a noise function inside your own shader, you need the source — not a JavaScript wrapper around it.
  • Version conflicts are dangerous. Two packages depending on different versions of a GPU utility can’t share bind group layouts or pipeline caches. GPU state is global in ways that npm’s module system can’t handle.
  • You lose the learning. The whole point of these techniques is understanding how they work so you can adapt them. A dependency hides that.

Source-first distribution solves all of this. You get the files, you own them, you read them, you change them. The CLI is just a convenient way to fetch them — there’s no runtime, no dependency graph, no updates to break your build.

How it works

npx gpumarket add noise

This copies the module’s TypeScript and WGSL files into src/gpu-modules/noise/ in your project. That’s it. The files are yours — they’re not linked to a registry, they don’t auto-update, and they have zero dependencies.

Each module:

  • Expects a GPUDevice from you — it never creates its own adapter or device.
  • Produces GPU-native objects — GPUTexture, GPUBuffer, things you bind directly in your pipeline.
  • Cleans up after itself — every module has a destroy() method to release GPU resources.
  • Ships vanilla WGSL — no preprocessor, no custom syntax. The .wgsl files work from Rust/wgpu, Python/wgpu-py, or C++/Dawn by copying them directly.

A knowledge base, not just a registry

Every module ships with a further-reading.md file. This isn’t boilerplate — it’s a curated entry for the technique: why it exists, the original paper or research behind it, notable implementations in other languages and frameworks, and resources for learning more.

Over time, the collection of modules and their further reading becomes something larger than a code library. It becomes a map of GPU techniques — Perlin noise traces back to Ken Perlin’s 1985 paper, the radix sort links to Merrill & Grimshaw’s parallel GPU sort, the SDF flow module references the Jump Flooding Algorithm from Rong & Tan 2006.

If you’re building a game and need spatial partitioning, or a creative tool and need procedural textures, or a data visualization and need a fast GPU sort — you can find the technique here, see it working, understand the research behind it, and take the code. That’s the aspiration: a practical, growing knowledge base for GPU programming on the web.

Prior art

This model is inspired by shadcn/ui, which proved that distributing components as source code works better than packages for things developers need to own and customize. GPU code has even stronger reasons to work this way.