WebGPU for CAD: Real GPU in the Browser

For years, “CAD in the browser” meant one of two things: a thin client streaming rendered frames from a server, or a WebGL-based viewer that could rotate a pre-meshed model but not do real computation. Neither was satisfactory. Server-side rendering adds latency and requires expensive GPU servers. WebGL provides a graphics pipeline but no general-purpose compute --- you cannot run a constraint solver, evaluate a signed distance field at a million points, or generate a mesh on the GPU using WebGL alone.

WebGPU changes this. It is the first browser API that provides direct access to GPU compute shaders, and it makes real CAD computation in the browser architecturally viable.

What WebGPU Is

WebGPU is a W3C standard API for GPU programming in the browser. It provides:

• Compute shaders. General-purpose GPU programs that read and write buffer data without any graphics pipeline involvement. This is the critical capability that WebGL lacked.
• Modern graphics pipeline. Render pipeline comparable to Vulkan/Metal/D3D12, with programmable vertex, fragment, and (eventually) mesh shaders.
• Explicit resource management. The application manages buffers, textures, bind groups, and command encoders directly. No hidden driver magic.
• WGSL shading language. WebGPU Shading Language, a purpose-built language for WebGPU shaders. Alternatively, SPIR-V can be consumed by some implementations.

WebGPU is not WebGL 3.0. It is a clean-sheet design based on the concepts of Vulkan, Metal, and D3D12, adapted for the security and portability requirements of the web platform.

WebGPU vs. WebGL

Capability	WebGL 2.0	WebGPU
Compute shaders	No	Yes
Storage buffers (read/write from shaders)	No	Yes
Indirect dispatch/draw	No	Yes
Multiple command queues	No	Partial (single queue, multiple encoders)
Shader language	GLSL ES 3.0	WGSL
API style	OpenGL (stateful)	Vulkan-like (explicit, stateless)
Error handling	Silent failures, getError()	Validation layer with clear error messages

The compute shader capability is the game-changer for CAD. Everything else is a welcome improvement, but compute is what unlocks real engineering computation on the GPU in the browser.

What Compute Shaders Enable for CAD

SDF Field Evaluation

Evaluating a signed distance field at a million spatial points is embarrassingly parallel --- each point is independent. A compute shader dispatches a workgroup per spatial tile, evaluates the SDF at each point in the tile, and writes the results to a storage buffer. On a mid-range GPU, this runs at billions of evaluations per second.

For a CAD kernel built on implicit geometry, this means real-time visualization of complex models. The user modifies a parameter, the SDF is re-evaluated on the GPU in milliseconds, and the viewport updates immediately. No mesh extraction required for visualization --- the SDF can be ray-marched directly in a fragment shader using the compute-evaluated field data.

Mesh Generation

Marching cubes and its variants (dual contouring, surface nets) are parallelizable. The compute shader evaluates the SDF at grid vertices, classifies cells, generates triangle vertices, and writes them to an output buffer. GPU-accelerated marching cubes can extract a mesh from a 256x256x256 grid in under 10 milliseconds on current hardware.

Constraint Solving

Sketch constraint solvers (Newton-Raphson on a system of geometric constraints) benefit less from GPU parallelism when solving a single sketch, but benefit enormously when solving multiple independent constraint systems in parallel --- for example, evaluating design alternatives or running parameter sweeps.

BVH Construction and Traversal

Bounding volume hierarchies for spatial acceleration are built and traversed on the GPU. The construction is a parallel sort + hierarchy build. Traversal (for ray-casting, proximity queries, collision detection) is parallel across rays or query points.

Browser Support

As of early 2026, WebGPU is supported in:

• Chrome/Chromium --- Full support since Chrome 113 (May 2023). Stable and well-tested.
• Edge --- Full support (Chromium-based).
• Firefox --- Support shipped in Firefox 129 (2024). Stable.
• Safari --- Support shipped in Safari 18 (2024). Some feature gaps remain but the core compute pipeline works.

The coverage is sufficient for production deployment. Engineers using any modern browser on any operating system (Windows, macOS, Linux, ChromeOS) can access WebGPU compute.

For older browsers or environments without WebGPU, a WASM-based CPU fallback is the standard approach. The same algorithms run on the CPU via WebAssembly, slower but functionally identical.

How NeuroCAD Uses WebGPU

NeuroCAD’s architecture splits computation between the CPU (WASM) and the GPU (WebGPU):

• CPU (WASM): Constraint solving, parametric evaluation, feature tree operations, e-graph optimization, dependency graph management. These are inherently sequential or moderately parallel workloads that suit the CPU.
• GPU (WebGPU): SDF field evaluation, ray-marching for visualization, mesh extraction, spatial queries. These are massively parallel workloads that suit the GPU.

The kernel, written in Rust, compiles to WASM for the CPU path. Compute shaders for the GPU path are written in WGSL and dispatched through the WebGPU API via wgpu (a Rust WebGPU implementation that targets both native and web backends).

This dual architecture means the same kernel source code runs:

• In the browser with WebGPU acceleration.
• In the browser with CPU-only fallback (if WebGPU is unavailable).
• On the server as a native binary with Vulkan/Metal GPU acceleration.

The user sees the same interface and the same results regardless of the backend.

Performance Characteristics

WebGPU compute performance is close to native Vulkan/Metal on the same hardware. The overhead is primarily in the JavaScript-to-GPU command submission path, which adds microseconds per dispatch. For compute workloads that dispatch a few large kernels (field evaluation over a grid, mesh extraction), this overhead is negligible.

Practical numbers on a mid-range laptop GPU (Intel Iris Xe or equivalent):

• SDF evaluation at 1M points: 2—5 ms.
• Marching cubes mesh extraction (128^3 grid): 5—15 ms.
• Ray-marching 1080p viewport: 8—16 ms per frame (60+ FPS for most models).

On a discrete GPU (NVIDIA RTX 3060 or better), these numbers improve by 5—10x.

Limitations

• No ray tracing pipeline. WebGPU does not expose hardware ray tracing (RT cores). Ray-marching SDF in a compute shader is the alternative, which works well for implicit geometry but does not benefit from RT acceleration.
• Buffer size limits. WebGPU implementations impose maximum buffer sizes (typically 256 MB to 1 GB). Very large models may need tiling strategies.
• No shared memory between GPU and system RAM. All data transfer goes through explicit buffer mapping, which adds latency. Minimizing GPU-CPU round-trips is essential for performance.
• Shader compilation latency. The first dispatch after loading a new shader incurs compilation overhead (50—500 ms depending on shader complexity and driver). Caching compiled shaders across sessions mitigates this.

The Bigger Picture

WebGPU is not just about making CAD faster in the browser. It changes the deployment model. When the GPU is accessible from a web page, there is no need to install a native application, manage driver compatibility, or require a specific operating system. The engineer opens a URL and has GPU-accelerated CAD.

This matters for accessibility (any device with a browser), for collaboration (share a link, not a file), and for deployment (update once on the server, every user gets the new version immediately).

WebGPU is the infrastructure that makes browser-native engineering software practical. The GPU was the missing piece. Now it is here.