Raw WebGL and GLSL for Browser GPU Computation

I write browser GPU programs at the layer most sites hide: context creation, GLSL ES shader compilation, textures, framebuffers, packed state, ping-pong updates, and readback.

Run the minimum path Inspect shader machines Follow WebGL into RTL

The point is not another visual effect. It is to use the GPU as an inspectable computation substrate in an ordinary browser, without placing a framework between the reader and the machine.

The public work runs from a minimal raw-WebGL lesson through stateful cellular automata and into Cartilage, where a GLSL fabric installs and executes circuit-like spatial roles.

The Compute Pattern

WebGL exposes a graphics pipeline, but its programmable fragment stage can also evaluate the same local rule across a rectangular field of data. Textures hold the input state. A framebuffer-attached texture receives the output. A draw call invokes the fragment shader once per output location.

Stateful computation needs two fields. One texture is read while the other is written; then their roles swap. This ping-pong step avoids reading and writing the same storage in one pass. A separate display shader can turn packed machine state into visible marks without confusing the simulation rule with its rendering.

That pattern is visible in the preserved automata: packed RGBA state, neighbor reads, one active update function, a swap texture, and a display pass. Cartilage uses the same browser/GPU discipline to make routing, constants, MUX roles, ports, and region ownership visible.

What “Raw” Means Here

Control plane

JavaScript obtains the context, compiles and links shaders, allocates textures and framebuffers, binds inputs, issues draws, swaps state, and reads results.

Compute plane

GLSL ES 1.00 evaluates the local rule in parallel, using texture samples and uniform parameters.

State

Texture channels encode bits, small fields, directions, roles, ownership, or other per-cell values.

Inspection

Display shaders, readback, screenshots, frame sequences, and independent reports keep the evolving machine visible.

“No framework” is not a claim that frameworks are bad. It is a teaching and verification choice. When the topic is the browser-to-GPU boundary itself, the calls that allocate, compile, bind, execute, and read should remain close enough for a reader to inspect.

Five Evidence Routes

1 · Minimum path

Run GPU Code With Raw WebGL And GLSL

The direct setup path: browser context, GLSL shader source, compilation, program linkage, and a visible result. The shared site engine turns the code blocks into sequentially runnable snippets.

2 · Scaffold

WebGL GPGPU Scaffolding

The support structure around a compute shader: capabilities, textures, buffers, programs, framebuffers, and the JavaScript control path.

Vortex cellular automaton rendered from packed WebGL state

3 · Stateful machines

Browser/GPU Cellular Automata

Local symbol routing, six-neighbor reads, packed state, ping-pong updates, and separate display logic across the preserved 2019–2021 experiments.

Cartilage GLSL fabric showing local cell roles and routing marks

4 · Reconfigurable fabric

Cartilage Nested Instantiation

Local ports, parent pointers, serial configuration streams, and replaceable tile roles inside the canonical browser/GPU artifact.

5 · Browser to hardware model

Cartilage Core

A compact WebGL1 fabric beside an independent SystemVerilog implementation and self-checking Verilator testbench for one exact 252-bit installation.

Illustrated path from programmable film shading to GPU and matrix hardware

Context · History

Programmable Shaders Before AI Hardware

The sourced history from RenderMan-style shading through real-time languages, Brook and CUDA, AlexNet, and matrix engines. This is context for the abstraction—not the primary evidence of implementation skill.

Why The Browser Matters

An ordinary browser is a useful laboratory because the artifact, control code, shader code, input state, display, and explanatory article can travel together. A reader does not need a vendor IDE merely to see the machine move. Developer tools expose the source and runtime boundary.

That makes WebGL unusually good for architectural sketches whose state needs to be inspected spatially. It does not make a browser simulation identical to hardware. In Cartilage Core, the WebGL model is host-stepped texture ping-pong; the SystemVerilog separately models a continuous combinational application plane and locally routed configuration-clock edges. Agreement on a bounded example is evidence, not proof that the execution models are interchangeable.

Current Boundary

These pages establish substantial direct WebGL1 and GLSL ES 1.00 work. They are not a modern WebGPU curriculum, a cross-browser performance benchmark, or a claim that every preserved shader artifact follows current production practice.

The older material remains valuable for a narrower reason: it shows the machinery from first principles and keeps a long line of local-state experiments executable. New work can add WebGPU or native GLES paths without rewriting that history into something it was not.