Support for binding arrays of RT acceleration structures

[kvark]

Connections
Description
In addition to samplers, buffers, and images, we need to support TLAS in binding arrays.

Testing
Included.

Squash or Rebase?

Rebase.

Checklist

• Run cargo fmt.
• Run taplo format.
• 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.

[JMS55]

I'm curious, are you planning to use more than one TLAS?

[kvark]

@JMS55 yes, exactly.
Imagine a Gaussian point cloud expressed as a TLAS with millions of instances of a single BLAS that has a triangular approximation of a mesh - https://gaussiantracer.github.io/
Now, this is a single cloud. What if you want to have a scene composited from multiple clouds? One way would be to merge all points into a single cloud on GPU every frame. But a more interesting path would be to have a TLAS at the higher level, and it would resolve to a specific cloud, which has it's own TLAS. Like a nested traversal.
AFAIK, Metal supported nested acceleration structures from day 1 instead of having a distinct TLAS thing.

[Vecvec]

Thank you for adding this into wgpu as well as naga! I think that bind groups containing binding arrays of acceleration structures should have a new limit like all the other resources. It would also be nice to mention this in the ray tracing API docs.

[Vecvec]

Because binding arrays do not validate out of bounds indexing, this should probably be listed as experimental.

[kvark]

@Vecvec thank you for reviewing!
Falling under the existing max_binding_array_elements_per_shader_stage would be most consistent with the current implementation. Unless increasing the scope of this limit would actually hurt the value, which I don't think it does.

Because binding arrays do not validate out of bounds indexing, this should probably be listed as experimental.

I don't see other non-uniform indexing declared as experimental, e.g. STORAGE_TEXTURE_ARRAY_NON_UNIFORM_INDEXING, so I believe the current state of PR is most consistent.

[Vecvec]

Falling under the existing max_binding_array_elements_per_shader_stage would be most consistent with the current implementation. Unless increasing the scope of this limit would actually hurt the value, which I don't think it does.

Sorry, for some reason I though that the default for normal acceleration structures (16) was significantly lower than others and therefore the same might be the case for the bindless version. If it doesn't hurt this value then it should probably just be integrated into the same limit.

I don't see other non-uniform indexing declared as experimental

They were added before experimental features were a concept, see #8619.

[kvark]

Small comparison on the limits:

• acceleration structures: 16 (like you stated)
• images: 40
• storage buffers: 155

So, indeed the inclusion of acceleration structures would lower the bounds if the feature is enabled. Not a good thing.
At the same time, there is already a big difference between this limit for different object types... I've added a new limit for the acceleration structures, but we may need to also separate the buffer limit from the image limit there in another PR.

They were added before experimental features were a concept, see #8619.

Can we defer to the moment where this issue will be implemented to convert them in bulk?

[Vecvec]

For most of the API it isn't really my design choices, so @cwfitzgerald probably has final say on most of this.

Can we defer to the moment where this issue will be implemented to convert them in bulk?

I'm perfectly happy to defer the change.

Small comparison on the limits

This is very confusing, I thought the update after bind limits had a significantly higher limit (50,000) vs 'normal' limits. That said, they do seem to be much lower for acceleration structures even for the limits higher than that, so I think it would be safer.