[spirv] Make ray queries safer

[Vecvec]

Connections
Vulkan side of #6761

Description
With every ray query, creates an extra variable that gets passed around with it that tracks the functions that have been called on it in spirv. HLSL still has UB so I haven't updated the spec. This doesn't track them through function calls, as right now passing ray queries as function arguments is not allowed (might be a metal requirement?).

I have also added emitting debug printf as an option if initialization fails as it could fairly difficult to debug.

Testing
Adds a test that calls the ray queries with invalid values (including NaN and Infinity)

Squash or Rebase? Squash, each of the commits don't really make sense on their own.

Checklist

• Run cargo fmt.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[cwfitzgerald]

Suggested change

	// TODO: Is double calling this invalid? Can't find anything to suggest so.
	// Can't find anything to suggest that calling this twice is invalid.

Also what is "this" finished traversal?

[Vecvec]

Sorry, I should have been more clear on this. "this" is the function (or spir-v OP technically)

[cwfitzgerald]

Some small things, but broadly good. Honestly this is enough code that I'm really relying on tests to validate this is okay, so most of my comments are about trying to make sure that tests are covering as much as is possible.

[cwfitzgerald]

Thought: Would it be better to split this file up into validation/non-validation?

[Vecvec]

From what I remember, I think that most of this is validation. IMO, it could be more useful to add helper functions for instructions like equal, logical ands, ect. (it takes 8 lines where only the last three really matter).

[Vecvec]

It could be worth adding a module for helpers functions in manually written spirv (which ray-tracing seems to be the largest user).

[Copilot]

Pull Request Overview

This pull request adds runtime tracking for ray query initialization and usage to prevent undefined behavior (UB) on SPIR-V backends (Vulkan). The main changes include:

• Added ray_query_initialization_tracking flag to track ray query state through initialization and proceed calls
• Implemented validation to ensure ray queries are used correctly (initialized before use, proceed called, etc.)
• Added test cases demonstrating invalid ray query usage patterns
• Currently only implemented for Vulkan/SPIR-V backend (noted as not yet implemented for DX12 and Metal)

Reviewed Changes

Copilot reviewed 17 out of 24 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
wgpu-types/src/lib.rs	Added ray_query_initialization_tracking field to ShaderRuntimeChecks struct
wgpu-hal/src/vulkan/device.rs	Integrated tracking flag into Vulkan backend shader compilation
wgpu-hal/src/vulkan/adapter.rs	Added debug print support and tracking initialization
wgpu-hal/src/dx12/device.rs	Added comment noting tracking not yet implemented for DX12
tests/tests/wgpu-gpu/ray_tracing/shader.wgsl	Added test shader with invalid ray query usage patterns
tests/tests/wgpu-gpu/ray_tracing/shader.rs	Added test case for invalid ray query validation
naga/src/back/spv/*	Implemented SPIR-V code generation for ray query tracking with helper functions
naga/tests/in/wgsl/ray-query-no-init-tracking.*	Added test files for ray query without tracking

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The panic message 'Must have multiple booleans!' could be more descriptive about why this assertion failed and what the caller should do. Consider: 'write_less_than_2_true requires at least 2 boolean values, but received {}'.

Suggested change

	assert!(bools.len() > 1, "Must have multiple booleans!");
	assert!(
	bools.len() > 1,
	"write_less_than_2_true requires at least 2 boolean values, but received {}",
	bools.len()
	);

[Vecvec]

TBH, this assert probably could be downgraded to a debug assert, its just making sure I've written my code properly

[cwfitzgerald]

Feel free to take or leave any of ^ if it's useful.

[Vecvec]

I forgot to note, https://docs.vulkan.org/spec/latest/appendices/spirvenv.html#VUID-RuntimeSpirv-OpRayQueryGenerateIntersectionKHR-06353 isn't rejected. However, we can't just validate the inputted value to this range because OpRayQueryGetIntersectionTKHR is UB if there is not yet another committed intersection (i.e its the first thing the traversal has processed). The equivalent is defined on HLSL as the maximum t value (Note: DXC directly translates from one to the other, which I think is a bug).