LIVE LAB / PROTOCOL 1
Know what
the numbers mean.
This is a local portfolio prototype with fresh WebGPU computation. Its first test is an algorithm comparison using an external reference suite. It is not an official BrowserBench score or a reproduction of native D3D12 performance numbers.
Three implementations, one operation
Compute an exclusive uint32 prefix sum, modulo 2³². Inputs use a fixed xorshift32 seed (20260910), with full-width random values, small random values or all ones. The displayed sizes are 262,144, 1,048,576 and 4,194,304 elements.
| Path | Implementation | Adaptation |
|---|---|---|
| Project · 1 item/thread | Hierarchical Blelloch, 256 threads, one item per thread. | WGSL translation of the project's additive BlockScanPass / AddScanOffsets. |
| Project · 4 items/thread | The same hierarchy, four items per thread. | A fixed candidate, not a hardware-selected winner or the project's single-pass backend. |
| GPUPrefixSums · RTS | Upstream reduce-then-scan WGSL, original 256-thread / four-uint4 defaults. | Unmodified upstream source; prepend enable subgroups;. Include a separate inclusive-to-exclusive GPU pass in the measured operation. |
Partial vec4 inputs are padded with zeros; validation compares the requested logical count. The external source is the WGSL variant, so its constants differ from the HLSL version used by the project's native external benchmark.
Measurement protocol
- Allocate resources and compile every pipeline outside the timed region.
- Poison each output with 0xdeadbeef, execute and compare every element against the same full CPU oracle.
- Warm up each implementation with three full operations.
- Collect 18 batches per path, 32 complete operations per batch. Cycle all six permutations of the three paths to balance order. All paths execute sequentially.
- Bracket the complete batch with GPU timestamps, including recursive passes, offsets and the external semantics adapter. Divide by 32 for milliseconds per operation.
- Poison and validate each path again. Only then enable result export.
The median and P95 describe the 18 batch means, not individual frame times, and are descriptive statistics from one run. They do not establish a confidence-qualified speedup. Batching reduces timer quantization; very short operations may still be unresolved. These runs reuse resident resources and are not a cold-cache benchmark.
If timestamps are unavailable, the page explicitly reports submission wall time from queue submission to completion. It includes waiting and is not GPU-only time. Both modes exclude input generation, resource creation, pipeline compilation, command encoding, CPU validation, upload/readback and chart rendering. This is not end-to-end application latency.
Changing tabs aborts the run and discards partial results. Device loss, shader errors or a failed output check publish no score. Your browser and other workloads can affect clock state, temperature, scheduling and cache behavior. No artificial sleeps, recorded timings or video playback drive the comparison.
Source identities
- GPUPrefixSums snapshot: 98d93a4 · retained WGSL source · upstream license notices.
- HLSL project snapshot: 9bba9fe · browser adaptation · measurement runner.
The browser adapter and runner are new portfolio integration code. GPUPrefixSums is the credited external implementation, not work authored by Edwin. The public HLSL project contains additional backends and native SDK functionality that this small browser adapter does not implement.
How the native evidence fits
The existing R9700 external comparison includes faster external implementations, inconclusive comparisons and an incompatible input-domain case. The website does not turn historical internal-baseline improvements into wins against GPUPrefixSums or AMD Parallel Sort.
Shader Hitch's 35.706 → 4.210 ms result describes native first-use scene-reveal P95 on R9700 / D3D12. It is distinct from warmup-window performance, which has its own duration tradeoffs and outliers. Data Layout's recorded heatmap is from synthetic native IL2CPP workloads. Neither measurement is produced by this browser scan test.
Benchmark shortlist for the next iteration
| Candidate | Best fit | Decision |
|---|---|---|
| GPUPrefixSums | Scan, compaction foundations and GPU tuning. | Included. External reference algorithms; this site supplies a new browser harness. Not a standardized browser score. |
| WebGL Aquarium | Recognizable scene for draw-call, instancing and submission comparisons. | Strong next visual workload. A port is required to connect the project's actual optimization. A WebGPU adaptation must not be described as unmodified Aquarium. |
| WebGPU Radix Sort | Browser-ready sorting reference. | Candidate, pending reuse/license and semantics checks; less broadly established than browser benchmark suites. |
| MotionMark | Browser graphics-engine performance. | Recognized benchmark, but it does not expose the project's D3D12 or Burst kernels. Unsuitable for claiming those projects' speedups. |
| Unity ECS samples | Burst data layouts and real Unity application workloads. | Possible later Web build. A sample scene is not automatically a standard benchmark. |
Unity has announced Web Burst / Job System support in 6.4, and WebGPU leaving experimental status in 6.6. The actual project version, package compatibility, browser capabilities and hosting headers still need validation. These announcements do not verify a Web build of the user's packages.
Project captures and profile
- Profile copy is grounded in the saved LinkedIn implementation/readback record from 9 September 2026; LinkedIn was not re-read live during this website build.
- Shader Hitch: actual Player comparison capture, not a generated mockup.
- PoseLoop: scene 10 development comparison. The 0.800 recall printed in this image is scene-specific, not an aggregate claim.
- Data Layout: retained formal IL2CPP heatmap from the 3 September local GitHub audit. Project and native evidence.
Prototype validation
The compute module has been executed on an RTX 4090 through the Node Dawn Vulkan backend, with full-output checks for boundary and large input sizes. This validates computation in that runtime. Browser UI, WebMCP, mobile layout and cross-device performance have not been verified in a browser. No browser automation was used.