Repository navigation
WebGPU RayQuery Support #369
Description
I've been working on RayQuery support for the past few days, based entirely on copying the design of the current feature in gfx-rs/wgpu.
To get an interactive demo working required changes across gogpu/gputypes, gogpu/naga, gogpu/wgpu, and gogpu/gogpu. It also only supports the Vulkan backend.
You can see the branches across the various repositories:
- https://github.com/ahmedtd/gputypes/tree/rt-work
- https://github.com/ahmedtd/naga/tree/rt-work
- https://github.com/ahmedtd/wgpu/tree/rt-work
- https://github.com/ahmedtd/gogpu/tree/rt-work (Minimal changes needed here, mostly just the ability to plumb down wgpu features from app creation).
Based on these branches I was able to get a minimal interactive demo working (http://github.com/ahmedtd/gogames/blob/master/games/wgputest/cmd/windowtest/main.go)
Are you interested in merging this? If so, I will work on cleaning it up and moving my real-time interactive example into gogpu.
The current state of the branches are heavily vibecoded, but the overall guidance was to explicitly copy the interface and implementation choices from gfx-rs/wgpu.
Activity
fix(ir): compaction keeps and renumbers the special types (P0-IR-025)
kolkov commentedon Nov 3, 2026
Sorry for the slow answer. Yes, we want this.
Ray queries have been in the HAL since v0.32 (ADR-062), but the public API never got them. Your branches also show the Vulkan path could never have run: the RT procs weren't loaded, the extensions and features were never enabled, the geometry union had the wrong alignment and
vk-genignoredextnumber. So this is exactly the missing piece, ported from the right reference.Part of it is already in:
OpRayQueryProceedKHRafter traversal has finished). You had both fixed in your branch two weeks before we landed the same ports from Rust, thank you. gfx-rs/wgpu's seven ray query examples are now vendored in naga's tests, so your naga commit can be dropped. If you want a naga piece,acceleration_structure<vertex_return>isn't parsed yet (needed forray_cube_normals), and a PR for it is welcome.vk-genfixes landed (extnumber, the missing instance and device commands), so some of your Phase 2 should fall away on a rebase.How I'd like it to land:
BindingResourceand the minimum AS limits), then wgpu. wgpu's CI builds without a workspace, so it can only bump to a released gputypes. In wgpu itself, two PRs would review better: Vulkan HAL enablement first, then core, the public API and the examples. gogpu needs no PR from you: feat(config): let an app name the device features it requires gogpu#497 covers requesting features at app creation, andFeatureRayQuerygoes through it. gogpu requests the adapter's own limits by default, so a ray query device gets the acceleration structure limits the adapter reports. Your Vulkan enablement fills those in for Vulkan.core/ray_tracing_*.goand leftinternal/raytracing'sBuildContextunused because its semantics differ from wgpu-core. I agree wgpu-core's semantics should win, but the port should replace that code ininternal/raytracinginstead of living next to it. architecture: move ALL implementation to internal/ (ADR-070) #329 will also movecore/andhal/underinternal/. If you take this on, we'll agree on the order first so you don't have to rebase twice.Blas,Tlaswith instance slots,BuildAccelerationStructuresandBindGroupEntry.AccelerationStructureis the right call. Compaction can come in a follow-up. We're reviewing the whole public API before 1.0, and these types will go through that review. The Vulkan HAL enablement doesn't depend on it and can land earlier, as its own PR.You have a choice here, and either answer is fine:
Co-authored-by) and you're credited in the changelog.Which would you prefer?
docs: ray tracing is HAL code only, not usable yet