fix(web): report real GPU backend; unblock the WebGL2 path#87
Merged
Conversation
The web build asks wgpu for BROWSER_WEBGPU | GL and compiles wgpu's `webgl` feature, but the GL path could never actually run. Three bugs, each fatal on its own, all on that path: - The instance carried no display handle. wgpu-core passes `raw_display_handle: None` for a canvas surface target and then fails with MissingDisplayHandle unless the *instance* supplies one, so surface creation died immediately. The WebGPU backend never reads it. - Device creation requested `Limits::default()`, which is unsatisfiable on GL: WebGL2 has no compute, so max_compute_workgroups_per_dimension is 0 against a default request of 65535. - The swapchain was configured with COPY_SRC unconditionally; a WebGL2 surface doesn't advertise it and Surface::configure rejects it. Also log the backend and adapter wgpu actually chose, instead of hardcoding "(WebGPU)". This does not make WebGL2 usable yet — Renderer::new_impl eagerly builds 14 compute pipelines and storage buffers, which WebGL2 (GLES 3.0) cannot provide at all; that needs a downlevel/2D-only init path. These are the prerequisites, and they are inert on WebGPU: the WebGPU path keeps the limits it always requested and was verified end-to-end (game boots and renders).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughChangesWeb initialization compatibility
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
proggeramlug
pushed a commit
that referenced
this pull request
Jul 11, 2026
PR #87/#88's web work pushed native/web/src/lib.rs to 2034 lines (limit 2000). Pure code motion, same pattern as input_ffi.rs: the Phase-1c material-system FFI section (compile/params/draw submission, instance buffers, texture arrays, reflection probes) moves to material_ffi.rs. lib.rs 2034 -> 1546; cargo check for wasm32-unknown-unknown green; validate-ffi passes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The web build asks wgpu for
BROWSER_WEBGPU | GLand compiles wgpu'swebglfeature — but the GL path could never run. Three separate bugs on it, each fatal on its own:raw_display_handle: Nonefor a canvas surface target and then errorsMissingDisplayHandleunless the instance carries one (wgpu-core 29 instance.rs:254). Surface creation died immediately. The WebGPU backend never reads it.Limits::default()is unsatisfiable on GL. WebGL2 has no compute, somax_compute_workgroups_per_dimensionis0against a default request of65535→request_devicefails outright.COPY_SRCon the swapchain. A WebGL2 surface doesn't advertise it, soSurface::configurerejects the config.Also: log the backend and adapter wgpu actually selected, instead of hardcoding
"(WebGPU)".Why it matters even though WebGL2 still can't render
A user reported the web build dying with
No WebGPU/WebGL adapter foundon macOS Sequoia. The root cause is that havingnavigator.gpuis not the same as having an adapter — Chrome ships the API on by default but hands back no adapter when graphics acceleration is off, the GPU is blocklisted, or it's a VM/remote session. wgpu picks its backend once, inInstance::new, purely on whethernavigator.gpuis defined (wgpu-29 api/instance.rs:74), so it commits to WebGPU and never looks at the GL backend we compiled in.These three fixes are the prerequisites for the GL path ever working. They are not sufficient:
Renderer::new_impleagerly creates 14 compute pipelines plus storage buffers and a 64KB joint uniform, and WebGL2 (GLES 3.0) has no compute shaders or storage buffers at all — wgpu only reportsCOMPUTE_SHADERSat GLES 3.1+. A real fallback needs a downlevel / 2D-only renderer init path (fits the existingsetDirect2DModeidea). Filing this separately.Risk
Inert on WebGPU. The limits change is explicitly scoped to
Backend::Gl, so the WebGPU path requests exactly the limits it always has; theCOPY_SRCmask is a no-op wherever the surface advertises the usage (i.e. everywhere WebGPU runs today).Verification
Built for
wasm32-unknown-unknownagainst currentmain. Drove the resulting build in a real headless Chrome:Bloom engine initialized (BrowserWebGpu on …), game renders and plays into level 1.navigator.gpu): now gets past instance/surface/device/swapchain creation and reaches renderer init, where it hits the compute-pipeline wall described above — i.e. exactly as far as these fixes are meant to take it.Summary by CodeRabbit