[wgpu-core] Ray tracing pipelines by Vecvec · Pull Request #10144 · gfx-rs/wgpu

Vecvec · GitHub

2 min read Original article ↗

Connections
Supersedes #9450
Closes #6760 - Should be split up once this lands

Description
Exposes the already added hal ray tracing pipelines as safe wgpu pipelines. This is a rebased version of #9450 with the hal changes removed as they were added seperately and a couple of tweaks. This means that there are some design changes in the commits. Therefore, I recommend reviewers to read commits individually up to (not including) add (unused) intersection shader index to TlasInstance and then that commit until Switch back to using a u32 instead of an enum as a single block and then individually again.

This version (unlike its predecessor) uses u32s for the intersection index, which means they can be accessed from ray queries. However, because metal has no way of retrieving them setting this above zero requires ray tracing pipelines to be enabled too.

This PR also slightly modified TlasInvalidCustomIndex to TlasInvalidCustomData and added an instance index as I was also adding it to the new error. I can split that up, but it is 2 lines.

Question 2 (Should shader binding tables (SBTs) be part of the ray tracing pipeline?) is still somewhat open, but the resolution seemed to be keep this one (and if someone needs a split, to split them then [API design is usually easier when someone knows what they need]). Aditionally this one is designed ti be somewhat easy to split due to the separate struct for the sbd.

Testing
Adds some testing

Squash or Rebase?
squash

Checklist

  • I have self-reviewed and fully understand this PR.
  • WebGPU implementations built with wgpu may be affected behaviorally.
  • Validation and feature gates are in place to confine behavioral changes.
  • Tests demonstrate the validation and altered logic works.
  • CHANGELOG.md entries for the user-facing effects of this change are present.
  • The PR is minimal, and doesn't make sense to land as multiple PRs. (see above)
  • Commits are logically scoped and individually reviewable.
  • The PR description has enough context to understand the motivation and solution implemented.