VkFFT VS GLSL

Hello, I am the creator of the VkFFT - GPU Fast Fourier Transform library for Vulkan/CUDA/HIP/OpenCL/Level Zero and Metal. In the latest update, I have added support for quad-precision double-double emulation for FFT calculation on most modern GPUs. I understand that modern ML is going in the opposite low-precision direction, but I still think that it may be useful to have this functionality at least for some prototyping and development of concepts.

Not quite what I asked for, but close enough for now...

https://github.com/DTolm/VkFFT/discussions/126

Source - I have made a somewhat functional programming-like FFT library (https://github.com/DTolm/VkFFT/tree/develop) which also operates on abstract data containers. Maybe it can be interesting to you from the algorithmic point of view.

VkFFT is a use-case I've heard of where Vulkan-Compute is faster than its Cuda and OpenCL counter-part: https://github.com/DTolm/VkFFT

Hello, I am the creator of the VkFFT - GPU Fast Fourier Transform library for Vulkan/CUDA/HIP/OpenCL and Level Zero. In the latest update, I have added support for Apple Metal API, which will allow VkFFT to run natively on modern Apple SoC. I have tested it on MacBook Pro with an M1 Pro 8c CPU/14c GPU SoC single precision on 1D batched FFT test of all systems from 2 to 4096. Achieved bandwidth is calculated as 2*system size divided by the time taken per FFT - minimum memory that has to be transferred between DRAM and GPU:

Another possible project to look at is https://github.com/DTolm/VkFFT

You're looking for this repo

You have access to physical (u64) global memory pointers through buffer_reference in GLSL, note you should be using buffer_reference2

On April 27, 2023 the Vulkan® Ray Tracing TSG released the VK_KHR_ray_tracing_position_fetch extension, which exposes the ability to fetch vertex positions from an acceleration structure hit when tracing rays. The SPIR-V SPV_KHR_ray_tracing_position_fetch and GLSL GL_EXT_ray_tracing_position_fetch extensions have also been released to provide SPIR-V and GLSL support for this functionality.

You can also have general extensions that are only supported on some hardware, for instance NVIDIA supports all of these extensions on OpenGL that add support for Vulkan's thread subgroup operations while AMD only supports these extensions and a few others that add support for similar features to the extension that NVIDIA supports, but with way more restrictions.

GL_NV_ray_tracing is a vendor extension, but it does exist.

According to this document, one should be able to extract those values through

The reports of my death are greatly exaggerated

https://github.com/KhronosGroup/GLSL/blob/master/extensions/...

I don't think there's away. For Vulkan, there's GL_EXT_nonuniform_qualifier which allows you to index with gl_InstanceIndex but AFAIK it's not available for OpenGL.

AMD hardware works a little differently, and for that you have to write a waterfall loop with subgroup instructions to get the correct behavior (since GL_EXT_nonuniform_qualifier doesn't exist in OpenGL GLSL). The loop might look like this (you would use it the same way as NonUniformEXT in Vulkan GLSL).