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

[Vecvec]

@cwfitzgerald I've been thinking about the issue you are having with llvmpipe, it seems to be that the scratch buffer's device address is not properly aligned, that sounds to me like it's a wgpu-hal issue not a wgpu-core issue. To help check whether it is as I think, could you try the hal ray-traced-triangle?

edit: comment is

When running on llvmpipe on windows, I get some validation errors (and a segfault, probably related) on all the example tests.
Validation Error: Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710 ] Object 0: handle = 0x27d00c65740, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x63ff8904 | vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (2735913731904) must be a multiple of minAccelerationStructureScratchOffsetAlignment (128). The Vulkan spec states: For each element of pInfos, its scratchData.deviceAddress member must be a multiple of VkPhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment (https://vulkan.lunarg.com/doc/view/1.3.290.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710
Seems we're not minding minAccelerationStructureScratchOffsetAlignment?

[cwfitzgerald]

Good idea - I can also debug this a bit to see what's going on.

[Vecvec]

Hmm... this line (

wgpu/wgpu-hal/src/vulkan/device.rs

Lines 918 to 925 in 859dd88

	| crate::BufferUses::BOTTOM_LEVEL_ACCELERATION_STRUCTURE_INPUT,
	) {
	16
	} else {
	req.alignment
	} - 1;
	let block = unsafe {

) has no mention of scratch buffer usage, could you also try hard-coding it to

let alignment_mask = if desc.usage.intersects(
            crate::BufferUses::TOP_LEVEL_ACCELERATION_STRUCTURE_INPUT
                | crate::BufferUses::BOTTOM_LEVEL_ACCELERATION_STRUCTURE_INPUT,
        ) {
            16
        } else if desc.usage.contains(crate::BufferUses::ACCELERATION_STRUCTURE_SCRATCH) {
            128
        } else {
            req.alignment
        } - 1;

[cwfitzgerald]

I'm fairly certain that this is actually a lavapipe bug. Even if we properly manage the alignment, the resulting buffer device address pointer is not actually aligned as much as the memory is.

This seems to be technically allowed for the spec, but it's probably just a spec oversight. I'm going to put together a bug report tomorrow and file it against Mesa to see what they say.

[Vecvec]

I'm fairly certain that this is actually a lavapipe bug

that would explain why I couldn't repro this even though I have the same minAccelerationStructureScratchOffsetAlignment as mesa.

[cwfitzgerald]

Filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/11940

[cwfitzgerald]

Looking good - I'm going to do a documentation and formatting pass, then check in with the other maintainers tomorrow, but I'm expecting to get this in by the end of the week!