Ray Tracing Tracking Issue
For the current implementation see https://github.com/gfx-rs/wgpu/blob/trunk/docs/api-specs/ray_tracing.md. For prior details see #1040
Acceleration structures
Features
- [x] Basic #6291
- [ ] Compaction ~~#6609~~ #7285
- [ ] Update instead of build if possible and preferred.
- [ ] Custom intersections (AABBs). #7701
- [x]
as_halfor acceleration structures. #7303 - [ ] limits #6803
Nice to have (less important features / underlying APIs still in development)
- [ ] Micromaps (opacity and displacement)
- [ ] Partitioned TLASes - PTLAS - (may not require any / much API change)
- [ ] Cluster geometry (CLASes)
- [ ] Extended acceleration structure vertex formats (f16x4, snorm16x4 ect.)
Design
- [ ] Reconsider
build_acceleration_structures_unsafe_tlasafteras_halhas been added.
Known Bugs
- [ ] #6727
- [x] #6859
Support
- [x] Vulkan
- [x] DX12 #6777
- [ ] Metal #7402
Ray Queries
Features
- [x] Basic #6291
- [x] Commit candidate intersections #6759
- [ ] remove undefined behavior #6761
- [x] ray query get vertex return #6763
Design
- [x] #6778
Known Bugs
- [x] #6731
Support
- [x] Vulkan
- [x] DX12 #6777
- [ ] Metal (naga support, not exposed due to no acceleration structure support yet)
Ray Tracing Pipeline
- [ ] Decide on basic design
- [ ] Implement basic design #6760
@Vecvec I'd like to get involved on this feature. #6609 seems like branch needs fixed to be compatible with upstream and tests fixed, is it a good starting point?
#6609 is in an odd situation - Mesa (which CI uses) has a bug in it that causes the test added to seg-fault, this bug is caused by resetting certain types of query pools, this has meant that that PR is not able to be merged (as it would cause everyone else's CI to fail). I was hoping that the patch would be merged soon, but that doesn't seem to be happening. Most of the other CI issues are caused by merging with trunk, and seem to be trivial.
Thanks for wanting to help! If you want to figure out how acceleration structure building works then implementing updating sometimes instead of building would be helpful too, it's probably also quite advanced though so a simpler thing to do would be general checking of code - the entire building process is quite large so it's likely that there are bugs in there somewhere. There are also #6803 and #6759 which would be nice to have implemented. General helping out is also useful, and so is testing the code using either the testing API or by writing code to use this.
Thanks for wanting to help! If you want to figure out how acceleration structure building works then implementing updating sometimes instead of building would be helpful too, it's probably also quite advanced though so a simpler thing to do would be general checking of code - the entire building process is quite large so it's likely that there are bugs in there somewhere. There are also #6803 and #6759 which would be nice to have implemented. General helping out is also useful, and so is testing the code using either the testing API or by writing code to use this.
Thanks, I'll look at the linked issues and check the acc structure building code for robustness.
Far from critical, but it would be worth considering how to support Nvidia's SER https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_ray_tracing_invocation_reorder.html.
Additionally there's two very exciting new RT features coming to Nvidia GPUs soon (No API docs yet, but should come out in the next few days iirc).
Mega geometry allows building cluster-based BVH nodes (CLAS), which can then be assembled into a BLAS via indirect commands.
Partitioned TLAS (PTLAS) allows splitting a TLAS into static/dynamic portions, for faster TLAS builds.
I've had my eye on SER, and am considering how it may help rt pipelines. I'll be on the lookout for the other two which sound very interesting.
APIs for blackwell RT stuff came out today actually:
- https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_partitioned_acceleration_structure.html
- https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_cluster_acceleration_structure.html
Turns out OMM's are actually standardized now https://docs.vulkan.org/spec/latest/chapters/VK_EXT_opacity_micromap/micromaps.html
@Vecvec another feature request :)
I've learned from https://zeux.io/2025/03/31/measuring-acceleration-structures that fp16 leads to cheaper BLAS's! Wgpu should add support for the Float16x4 (4th channel is ignored by the driver) vertex format to BlasTriangleGeometrySizeDescriptor.
another feature request
I'll add it to the list, and see when I can get to it. It will have to be a separate feature though due to metal (still) not supporting it (last I checked).
Hi, are there plans on a software backend?
Hi, are there plans on a software backend?
No, most of wgpu does not have software fallback, instead relying on WARP / llvmpipe. These do support raytracing (you should update them to the latest version, there have been many bugs) and should be good enough for testing.