Add support for PhysicalStorageBuffer

[jwollen]

Summary

This adds support for SPV_KHR_physical_storage_buffer and the PhysicalStorageBuffer64 addressing model and expands support for physical pointers.

Includes

• Allow instructions to explicitly specify StorageClasses #236

Motivation

Allow taking advantage of physical buffer addresses (VK_KHR_buffer_device_address) for more flexible bindless storage buffer access.

While physical pointers are largely optional with increasing support for bindless storage buffers,
fully descriptor-less storage buffers remain very ergonomic, especially in pure compute and ray-tracing shaders.

This allows, for example:

struct Node {
    next: PhysicalPtr<T>,
    payload: f32,
}

#[spirv(fragment)]
fn main(
    #[push_constant] root_node: &PhysicalPtr<Node>,
    out: &mut f32,
) {
    unsafe {
        let mut next_node = *root_node;
        while let Some(node) = next_node.as_ref() {
            *out = *out + node.payload;
            next_node = node.next.as_ref();
        }
    }
}

Implementation steps

• Allow expressing explicit storage classes
• Enable PhysicalStorageBuffer64 when PhysicalStorageBufferAddresses is supported
• Support pointer casts
  • Enable u64 as *mut T and vice versa
  • Defer pointer-cast errors until after storage class inferrnce
• Aligned
  • Generate Aligned operands for all memory operations
  • Add a SPIR-T pass to strip alignment from non-physical operations
  • Allow memory operands in qptr store/load lowering/lifting
• Add RestrictedPointer if/where necessary
• Ensure raw pointer ops are correct or disallowed
• Add spirv_std utilities for working with physical pointers
  • Add a PhysicalPtr<T> type that wraps physical addresses. /bikeshed
  • Parity with *mut

Prior work

• [Migrated] OpConvertUToPtr support #119: As noted the qptr route is the most flexible and custom constraints for each instruction don't scale. For example supporting OpBitcast would be hard to model with custom constraints.

Open questions

• How safe/unsafe should the API be? Technically all interface variables are aliased.
• Should pointers be 64-bit? #238

[LegNeato]

Turns out I am porting a shader that needs this too!

[axelkar]

While physical pointers are largely optional with increasing support for bindless storage buffers

Are physical pointers more performant than using descriptor indexing? Are they similar to 32-bit handles used for bindless in DirectX? Sorry for asking here, but I haven't found documentation on them.

[jwollen]

Turns out I am porting a shader that needs this too!

Will pick it up again soon!

Are physical pointers more performant than using descriptor indexing? Are they similar to 32-bit handles used for bindless in DirectX? Sorry for asking here, but I haven't found documentation on them.

There is no direct equivalent in DX (yet?). Buffer device addresses/physical storage buffer pointers are literally 64-bit pointers to GPU memory. That means, compared to descriptors

• you can do pointer arithmetics on them
• you can store them directly in buffers (instead of descriptor indices), saving an indirection into descriptor sets/heaps
• you therefore don't need to manage descriptors for them
• they are smaller (storage buffer descriptors are at least 16 bytes in all implementations)

They behave a little different and might take different data paths, so the question performance is not trivial. But in general they should be superior.