GPGPU programming

[carlostling]

Hi,

Is this project suitable for writing compute shaders? I'm working on evaluating Rust for HPC and I'm currently looking for the best tools available for GPGPU programming in Rust.

[hrydgard]

Yes, you can write compute shaders with rust-gpu.

[Cazadorro]

aren't important features like warp intrinsics, GPU pointers (physicalDeviceAddress64, variable pointers) and atomics/memory scope semantics missing? I can't seem to find the feature list anymore.

[hrydgard]

Some features are missing indeed, doesn't mean it can't be used to write compute shaders (with some limitations then, of course).

[charles-r-earp]

aren't important features like warp intrinsics, GPU pointers (physicalDeviceAddress64, variable pointers) and atomics/memory scope semantics missing? I can't seem to find the feature list anymore.

Seems like all of these are present, other than physicalDeviceAdress64. AFAIK this is a OpenCL thing and isn't widely supported enough via Vulkan to be of much use. I think rust-gpu uses logical addressing for a vulkan target, so maybe that could be an option?

Warps correspond to "subgroups", so you have #[spirv(subgroup_size)] and so on. But this can be fetched from the client api as well.

[Cazadorro]

@charles-r-earp I couldn't remember the exact name of the addressing model, it's PhysicalStorageBuffer64, I got mixed up with that, the generic name of the extension that enables it (PhysicalStorageBufferAddresses ), the naming of the Vulkan extension (VK_KHR_buffer_device_address ), and the naming of buffer_reference (the name of the GLSL extension) . buffer device address is both essential for bindless and 100% required for raytracing (you can find it in the first page of the nvidia vulkan RT tutorial for peat sake), it is widely used. This is not a niche feature, nor a OpenCL feature, opencl has a different set of physical address features that do not include physical device address64, because it's model is physical by default, hence why Physical32 and Physical64 exist in the Addresses capability, and not under the PhysicalStorageBufferAddresses capability. Please read see the spec. Dismissing these features is harmful to the wider community. See this

id	Addressing Model	Enabling Capabilities
0	Logical
1	Physical32 Indicates a 32-bit module, where the address width is equal to 32 bits.	Addresses
2	Physical64 Indicates a 64-bit module, where the address width is equal to 64 bits.	Addresses
5348	PhysicalStorageBuffer64 Indicates that pointers with a storage class of PhysicalStorageBuffer are physical pointer types with an address width of 64 bits, while pointers to all other storage classes are logical.	PhysicalStorageBufferAddresses Missing before version 1.5. Also see extensions: SPV_EXT_physical_storage_buffer, SPV_KHR_physical_storage_buffer
5348	PhysicalStorageBuffer64EXT	PhysicalStorageBufferAddresses Missing before version 1.5.Also see extension: SPV_EXT_physical_storage_buffer

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_buffer_device_address.html
https://gpuopen-librariesandsdks.github.io/VulkanMemoryAllocator/html/enabling_buffer_device_address.html
https://github.com/KhronosGroup/GLSL/blob/master/extensions/ext/GLSL_EXT_buffer_reference.txt
PhysicalStorageBufferAddresses
https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#PhysicalStorageBufferAddresses
https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/vulkan-buffer-device-address
https://community.khronos.org/t/cant-get-a-buffer-reference-to-point-to-the-right-thing/108227
https://developer.nvidia.com/blog/improved-glsl-syntax-vulkans-descriptorset-indexing/

It's been an extension in 1.2, core in 1.3, and available on virtually all desktop GPUs. It's brought up in virtually every vulkan survey and conference. Again, this is not a niche feature. You cannot do certain things with out physical addresses.

I think rust-gpu uses logical addressing for a vulkan target, so maybe that could be an option?

No, This is actually part of the problem.

Warps correspond to "subgroups", so you have #[spirv(subgroup_size)] and so on. But this can be fetched from the client api as well.

It's not a matter of being able to know that subgroups exist, but to be able to use operations that utilize them. I don't know, for example, whether or not Rust GPU supports subgroup operations . With out subgroup operations, some algorithms, such as bandwidth limited stream compaction/prefix sum become impossible , a fundamental GPGPU algorithm, required in things like texel coherence based algorithms, for example, types of photon mapping and non hardware RT indirect lighting calculations, ie doing things per texel. It also hinders histogram calculation to not have access to subgroup operations

My understanding now is that Rust-GPU has inline-spirv, which should in theory allow escape hatches to use some of these features, but due to the lack of clarity on the current feature parity, I've not tried this my self, nor do I understand how far this extends.

[charles-r-earp]

It looks like I was wrong about PhysicalStorageBuffer64. It looks like it is a feature of Vulkan 1.2.

I did a quick test to see if this works (via rspirv / vulkano / spirv-tools), and adding the PhysicalStorageBufferAddresses allows casting a u64 to a pointer, and this can then be used to store a value. The pointer can be acquired through DeviceBufferAdress.

; SPIR-V
; Version: 1.5
; Generator: rspirv
; Bound: 11
OpCapability PhysicalStorageBufferAddresses
OpCapability VulkanMemoryModel
OpCapability Int64
OpMemoryModel PhysicalStorageBuffer64 Vulkan
OpEntryPoint GLCompute %8 "main"
OpExecutionMode %8 LocalSize 1 1 1
%1 = OpTypeInt 32 0
%2 = OpTypeInt 64 0
%3 = OpTypePointer PhysicalStorageBuffer %1
%4 = OpConstant  %1  1
%5 = OpConstant  %2  12886999040
%6 = OpTypeVoid
%7 = OpTypeFunction %6
%8 = OpFunction  %6  DontInline|Const %7
%9 = OpLabel
%10 = OpConvertUToPtr  %3  %5
OpStore %10 %4 Aligned 4
OpReturn
OpFunctionEnd

Caveats, this more or less requires Int64, because the pointer will be 64 bits. It appears that you can cast a u32 to a pointer, but there are platforms that do not support u64 but do have more than 4G of memory, so it wouldn't work on those. But this appears to be mobile chips.

As it stands rust-gpu uses logical addressing for Vulkan, but this could be changed, by adding a method to SpirvBuilder, or if PhysicalStorageBufferAddresses is enabled. I don't know if that is enough to get this working, considering it appears to have been overlooked so Vulkan = logical was assumed.

As for subgroup operations, yes this can be done with assembly like https://github.com/EmbarkStudios/rust-gpu/blob/main/examples/shaders/reduce/src/lib.rs.