The short answer
WebGPU provides GPU access; SharedArrayBuffer supports shared memory. They solve different problems. A browser exposing WebGPU does not establish that a threaded build is isolated, and isolation does not establish that a GPU adapter is available.
Two independent requirements
The graphics path starts with navigator.gpu, then adapter and device acquisition. Those are distinct stages. Exposing the API does not guarantee that the application can acquire the device features it needs.
The shared-memory path concerns cooperation between execution contexts such as workers. Secure context and cross-origin isolation are relevant here. Test both paths on the actual generated game page; testing this guide's origin would describe a different environment.
Sources: MDN WebGPU ↗ · MDN SharedArrayBuffer ↗ · Emscripten pthreads ↗
Read the checks as separate observations
Use the linked troubleshooting procedure for copyable checks and expected results. Record each result instead of reducing all browser requirements to a single supported/unsupported label.
| Observation | What it establishes | What remains to check |
|---|---|---|
| isSecureContext | Whether this page has a secure context. | GPU access, isolation and successful application startup are separate checks. |
| navigator.gpu | Whether this context exposes the WebGPU entry point. | Request an adapter; an exposed API is not an acquired GPU. |
| requestAdapter() | Whether an adapter is returned for this request. | Device features, application initialization and game rendering can still fail later. |
| crossOriginIsolated | Whether this document is cross-origin isolated. | The application's worker setup and GPU path still need their own checks. |
Sources: MDN WebGPU ↗ · MDN SharedArrayBuffer ↗
What COOP and COEP change
COOP controls how the document shares a browsing context group. COEP controls which cross-origin resources the document may embed. Their deployment settings affect whether shared-memory features are available to the document and its workers.
Use the local server supplied by the reviewed project and inspect the actual document response in Network. Setting a header on an unrelated website, adding an HTML meta tag, or changing only a file extension does not establish isolation for the game. Additional resource and embedding policies can matter; verify crossOriginIsolated rather than assuming the headers took effect.
Sources: Emscripten pthreads ↗ · MDN SharedArrayBuffer ↗
Choose a diagnostic from the symptom
- No WebGPU entry point: check the browser environment and secure context before investigating game-specific rendering.
- API present, adapter absent: follow adapter diagnostics and retain the exact result and environment.
- Worker or shared-memory startup failure: inspect isolation and the browser's actual error, then check the serving configuration.
- Application starts but disc reads fail: inspect the disc request, status and Content-Range. HTTP data delivery is a separate concern from GPU availability.
Common questions
Does crossOriginIsolated being true prove WebGPU works?
No. It reports isolation, not GPU adapter acquisition. Run the graphics checks separately.
Can these checks fix missing game features?
They help locate environment and startup failures. They do not implement missing console behavior or establish that a particular game stage is compatible.
Which browser versions are guaranteed to work?
This guide does not maintain an independently tested version matrix. Check the upstream browser notes and current MDN compatibility information, then record results on your exact browser, OS and hardware.