u/BigAd4703

▲ 27 r/webgpu+1 crossposts

wgsl.run - a WGSL sandbox with live WebGPU preview, plus the C frontend it's built on

Live editor for WGSL with a WebGPU canvas underneath: type a shader, hit run, see it draw. Multi-file projects, share-via-URL, host JS override, OPFS-persisted.

Underneath: libwgsl — a from-scratch C99 WGSL frontend (lex / parse / resolve / const-eval / typecheck / validate). ~0.37 ms / Kloc warm parse, no dependencies, MIT.

Sandbox: https://wgsl.run Source: https://github.com/toprakdeviren/libwgsl VS Code: https://marketplace.visualstudio.com/items?itemName=toprakdeviren.wgsl-run

wgsl.run
u/BigAd4703 — 4 days ago
▲ 9 r/webgpu

I’ve been experimenting with running tokenization pipelines entirely on the GPU, and built a small project around BPE that runs fully in the browser.

No Python, no CUDA, no server — just WebGPU + WASM.

Demo: https://decoder.run/bpe

What it does

  • Train a BPE tokenizer directly in the browser on your own text files
  • All merge steps run on GPU compute shaders
  • Tokenization also runs on GPU using a compiled trie

Pipeline overview

  • Pre-tokenization: Unicode 17.0 word boundaries via WASM (codepoint-level, not byte hacks)
  • Training: batched merge loop on WebGPU (128 merges per roundtrip)
  • Compile: merge table → compact binary trie
  • Tokenization: chunked trie walk on GPU with shared-memory caching

Some details

  • ~25 compute kernels (pair counting, reductions, merges, prefix sums, compaction)
  • Open-addressing hash table for pair counting (~2M slots)
  • Blelloch prefix sum for stream compaction
  • Early stop and iteration control fully GPU-driven

This is still experimental, but I’m mainly curious about:

  • correctness vs CPU reference implementations
  • edge cases in Unicode handling
  • performance characteristics across different GPUs

Would love any feedback.

u/BigAd4703 — 19 days ago
▲ 11 r/webgpu

Hey everyone,

I’ve been working on a VSCode extension for Metal Shading Language (MSL) and just published an early version. Thought it might be interesting for people doing graphics / WebGPU work.

What it does

  • Real semantic highlighting (not regex-based)
  • Accurate diagnostics powered by an actual MSL front-end (via WebAssembly)
  • One-click Metal → WGSL transpilation
  • Live shader preview (WebGPU) — ShaderToy-style iteration inside VSCode

The key idea is: Instead of approximating the language, the extension uses the same parser/lexer as the compiler pipeline, so what you see in the editor matches real behavior.

Why WGSL?

I’ve been experimenting with bridging Metal shaders into WebGPU workflows, so the extension can: → take a .metal file
→ transpile it to WGSL
→ preview it instantly

Current limitations (early stage)

  • Live preview currently supports simple fragment shaders
  • No textures / compute yet
  • WGSL output still has gaps in edge cases

Demo-ish workflow

  1. Open .metal
  2. Run “Show Transpiled WGSL”
  3. Or launch Live Preview and tweak in real-time

Would love feedback

  • Parser gaps
  • WGSL correctness issues
  • Feature ideas (especially WebGPU-related)

Repo / issues: https://github.com/toprakdeviren/metal-shading-language-vscode-extension

Curious if anyone else is trying to bridge Metal ↔ WebGPU pipelines.

u/BigAd4703 — 20 days ago