[wgpu-hal] Blas compaction

[Vecvec]

Connections
Hal part of #6609

Description
Allows for BLASes to be compacted in wgpu-hal

Testing
No testing, but the successful tests in #6609 tested this API.

Checklist

• Run cargo fmt.
• Run cargo clippy.
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[nical]

LGTM. I suspect that it would be better to have fewer/larger query pools in the vulkan backend, but we can cross that bridge if it shows up in profiles.

[Vecvec]

LGTM. I suspect that it would be better to have fewer/larger query pools in the vulkan backend, but we can cross that bridge if it shows up in profiles.

@JMS55 mentioned this on matrix too, but I'd need to look at the specifics (and how expensive they were). For mesa at least this is 8 bytes read back from the acceleration structure so I would be surprised if this is the main bottleneck (especially since my current plan is to combine this in a build command which is not very fast itself),

[nical]

It's not the cost of the copy as much as the driver overhead of managing a lot of tiny pools (and maybe the per-pool memory overhead). The recommendation is generally to group things into large-ish pools but to be honest I don't know how impactful it is.

[Vecvec]

I think I'll add it to

wgpu/wgpu-core/src/ray_tracing.rs

Lines 1 to 8 in 9770409

	// Ray tracing
	// Major missing optimizations (no api surface changes needed):
	// - use custom tracker to track build state
	// - no forced rebuilt (build mode deduction)
	// - lazy instance buffer allocation
	// - maybe share scratch and instance staging buffer allocation
	// - partial instance buffer uploads (api surface already designed with this in mind)
	// - ([non performance] extract function in build (rust function extraction with guards is a pain))

when doing wgpu-core compaction.

[JMS55]

Yeah this is something we can stress test once I start the actual RT work in Bevy and have something to measure.