Ray Queries

[Vecvec]

Connections
Works towards #1040

Description
This PR provides BLASes (bottom level acceleration structures), TLASes (top level acceleration structures), TLAS instances (which contain BLASes and data, like transforms, about them), TLAS packages (which contain vectors of TLAS instances).

Testing
Running tests & examples included in PR

This a updated version of #3631 and is intended to replace it.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • n/a --target wasm32-unknown-unknown
  • n/a --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.
• More tests & examples.
• More docs

Later (follow-up PR)

• Acceleration structure compaction.
• Procedural geometry.
• as_hal methods

[cwfitzgerald]

Chatted with the other maintainers, and two main things to do before we can land, then we're good to land with follow up testing for any naga stuff.

Both of these things I can take on:

• More testing; some validation testing would be nice to make sure common error patterns are easily caught.
• The validation should be refactored away from storing mutable state on the TLAS/BLAS itself and move to a tracker-like way of validating state. We've learned from experience with the texture initialization code that having state inside the resources itself is an area that is ripe for bugs and we want to move towards validation where information all "flows" from command encoder into the queue. This is a lot easier to get right and to keep right. Even if the validation as it stands today is correct, we're very liable to break it in the future, by accident. I'm not sure if you wrote the valdiation for this or someone else did, but I can do this conversion, just wanted you to know what my plan was.

[Vecvec]

I'm fine to work on some of the testing, I assume common errors are thing like:

• Invalid vertex format
• Mismatched index buffers
• ect.

[Vecvec]

After using advanced debugging (putting an eprintln! at the end of the test) :) I've discovered that the second set of vulkan validation errors are happening at the end of the test. Shouldn't all encoders have been reset by the wgpu validation errors generated in queue submit?

[Vecvec]

It seems like command buffers might be leaking if a validation error is generated

[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] CommandEncoder::drop Id(1,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::command] Drop CommandBuffer with 'TLAS 1' label <--- command buffer freed here
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] Device::create_shader_module -> Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] Device::create_compute_pipeline -> Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] Device::create_bind_group -> Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] BindGroupLayout::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] Device::create_command_encoder -> Id(1,2)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::queue] Queue::submit Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] CommandBuffer::drop Id(1,2)
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] CommandEncoder::drop Id(1,2)
[2024-09-26T08:58:50Z INFO  wgpu_core::command] Drop CommandBuffer with '' label
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] BindGroup::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::binding_model] Destroy raw BindGroup with '' label
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] ComputePipeline::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::pipeline] Destroy raw ComputePipeline with '' label
[2024-09-26T08:58:50Z INFO  wgpu_core::binding_model] Destroy raw PipelineLayout with '' label
[2024-09-26T08:58:50Z INFO  wgpu_core::binding_model] Destroy raw BindGroupLayout with '' label
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] ShaderModule::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::pipeline] Destroy raw ShaderModule with 'shader.wgsl' label
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] CommandEncoder::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::command] Drop CommandBuffer with 'BLAS 1' label
[2024-09-26T08:58:50Z INFO  wgpu_core::device::global] Buffer::drop Id(0,1)
[2024-09-26T08:58:50Z INFO  wgpu_core::resource] Destroy raw Tlas with 'TLAS' label
[2024-09-26T08:58:50Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-vkDestroyAccelerationStructureKHR-accelerationStructure-02442 (0xaf03fd73)]
    	Validation Error: [ VUID-vkDestroyAccelerationStructureKHR-accelerationStructure-02442 ] | MessageID = 0xaf03fd73 | vkDestroyAccelerationStructureKHR():  can't be called on VkAccelerationStructureKHR 0xcad092000000000d[TLAS] that is currently in use by VkCommandBuffer 0x7f8b0de60af0[TLAS 1]. The Vulkan spec states: All submitted commands that refer to accelerationStructure must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.290.0/linux/1.3-extensions/vkspec.html#VUID-vkDestroyAccelerationStructureKHR-accelerationStructure-02442) 
               ^--- vulkan validation error about command buffer being still active

I'll see if I can create a memory leak repro (without acceleration structures). Never mind, remembered command encoders get reused.

Edit: wondering if #6323 might be related

[Vecvec]

The validation should be refactored away from storing mutable state on the TLAS/BLAS itself and move to a tracker-like way of validating state.

@cwfitzgerald what would this be like (would there be a FastHashMap<TrackerIndex, Option<NonZeroU64>>?)