GPU density-function evaluation: working prototype, measured ceiling, and why lighting looks like the better target

[gerofurlani07-gif]

Summary

I built a working prototype that evaluates Pumpkin's density-function graph on the GPU
via wgpu, and measured what it is actually worth. Sharing it because the infrastructure
may be more useful than the speedup, and because the measurement changed my mind about
where acceleration pays off.

Branch: https://github.com/gerofurlani07-gif/Pumpkin/tree/gpu-noise-acceleration

Nothing here is integrated into chunk generation yet — it is a validated prototype, not
a performance win you can run today. Numbers below are from an Intel Iris Xe iGPU.

What it does

A new opt-in crate, pumpkin-world-gpu, excluded from default-members so it does not
affect normal builds:

• Lowers BaseNoiseRouter::full_component_stack into a flat instruction list. That stack
  is already topologically ordered with index-based inputs, so it maps onto GPU bytecode
  almost directly.
• A WGSL interpreter evaluates the whole graph in one pass, one invocation per sample
  point, with intermediates in [node][point] layout to keep access coalesced.
• 27 of 28 node types are lowered. Both shipped routers compile end to end: overworld
  (217 nodes → 647 instructions) and nether.
• compile_router emits all ten named router outputs per point, so the aquifer and
  ore-vein samplers can get what they need from one dispatch and keep their branchy,
  stateful logic on the CPU.

Measured results

Overworld router, warm, best of ten iterations, ~1200 points per chunk:

chunks	CPU (ms)	GPU (ms)	speedup
1	9.58	2.25	4.25x
4	34.76	3.94	8.83x
16	140.69	10.98	12.81x
64	577.17	18.22	31.68x

But the honest number is the end-to-end one. cargo bench -p pumpkin-world --bench chunk_gen puts one overworld chunk at ~41.9 ms:

stage	share
lighting	37.4%
noise	35.9%
surface	9.4%
carvers	5.2%
everything else	<3% each

So this targets 35.9% of chunk generation, which caps the whole-chunk gain at 1.56x
no matter how fast the GPU path gets. The measured 12-30x on the stage works out to
roughly 1.5x per chunk. Lighting is the larger share and is untouched — doing both would
put the ceiling near 3.7x. And chunk generation is only part of what a server does, so
none of this is a server-wide multiplier.

Two findings that may matter regardless

1. f32 is not uniformly safe. The shader runs f32 (WGSL has no f64). For smooth
density values that only costs precision, but RangeChoice and IntervalSelect compare
a selector against a threshold, so one ulp does not shift the result slightly — it
selects a different subgraph.

Seven overworld threshold nodes read the same selector: a ClampedYGradient whose value
range equals its Y range, i.e. clamped identity on Y, compared against integer thresholds
(-60, 51, 321) that real block coordinates land on exactly. Vanilla computes it as a
lerp, and start + t * (end - start) does not return an integer Y exactly in f32. I
lower that case to a clamp instead, which is exact and fixed the divergence.

Not every case is fixable: EndIslands decides island contributions with
simplex < -0.9, and a genuine float computation near a threshold lands on opposite
sides in f32 and f64 — about one point in 240 in my sweep.

2. FindTopSurface does not fit a single-pass design. It walks Y downward in
cell-height steps, re-evaluating the density subgraph at each position until density
turns positive — a data-dependent loop of nested evaluations at positions not known
ahead of time. Same shape that keeps the aquifer on the CPU. It would need a multi-pass
design (evaluate over a Y range, then search the result).

Why I think lighting is the better target

I originally dismissed lighting as a poor GPU fit because it is a BFS flood fill. That
was a judgement about algorithm shape made without measuring cost, and it was wrong on
both counts:

• It is the largest stage at 37.4%, slightly above noise.
• Light levels are integers 0-15, so the entire class of f32 precision problems above
  simply does not exist there.
• BFS does not port directly, but iterative wavefront relaxation does: bounded at ~15
  passes by the light range, and each pass is a neighbourhood stencil, which is what GPUs
  are good at.

The per-chunk "light from scratch" path during generation looks like the tractable part.
Incremental relighting when a block changes is small and latency-sensitive, and my
measurements suggest small dispatches lose to the CPU anyway.

Validation approach

Every node type is checked against its real CPU implementation, not against my own
reimplementation, since a transcription error would otherwise agree with itself. The
strongest check evaluates the full 217-node overworld router on the GPU against the CPU
interpreter. There is also a threshold_audit example that reports how exposed a router
is to the branch-flip issue, meant to catch a future node that reintroduces an inexact
selector.

Where this could go

If there is interest, the parts I think are reusable independent of the speedup:

• The graph compiler and the flattening approach.
• The validation methodology, including the threshold audit.
• The multi-output pass, which is what the aquifer and ore-vein work would build on.

Open questions I do not have good answers for: whether a maintained GPU backend is worth
the coupling to the router's internals, and whether the ~1.5x (or ~3x with lighting)
justifies it for the workloads Pumpkin cares about. Happy to be told this is not worth
pursuing.

---

Disclosure: this work was done with the assistance of an AI coding agent. The
measurements are real and reproducible via the benchmarks and examples in the branch;
the design decisions and their limitations are described above as accurately as I can
state them.

[Q2297045667]

I'd recommend moving this discussion to Discord, as it has a larger and more active community. However, since you can share more detailed content here, I won't close this thread. Also, your testing and implementation are incredibly helpful to us!

[zhangxuan2011]

Moved, i saw it in #pumpkin-dev :)

Nice idea

[richardchen874-sys]

"GPU density-function evaluation: working prototype, measured ceiling, and why lighting" is a good agent-runtime surface because the real cost is whether the workflow completes cleanly across tools, retries, and provider behavior.

A compact provider matrix could track streaming, tool calls, structured output, usage reporting, timeout behavior, and fallback safety. That makes routing decisions easier to explain later.

I am testing a multi-model OpenAI-compatible API layer around official Chinese models, so the routing and usage-accounting parts of this are directly relevant to me. Which provider difference causes the most friction here: tools, streaming, usage reporting, or fallback behavior?

[Q2297045667]

？？？