VkFFT v1.3.4 release -Stable release that incorporates all the v1.3.3 bugfixes - no new functionality in this release -Tests reference: https://github.com/vincefn/pyvkfft/issues/32#issuecomment-1904238557
VkFFT v1.3.3 release (bugfix) -bugfix for tempBuffer memory management in Vulkan API -bugfix for tempBuffer stride management for multi upload even R2C algorithm
Version 1.3 update of VkFFT -Major library design change - from single header to multiple header approach, which improves structure and maintainability. Now instead of copying a single file, the user has to copy the vkFFT folder contents. -VkFFT has been rewritten to follow the multiple-level platform structure, described in the VkFFT whitepaper. All algorithms have been split into respective files, which should ease an understanding of the library design by everybody. Multiple code duplication places have been restructured and unified (mainly the read/write part of kernels and pre/post-processing). -All math operations and most variables have been abstracted to a union container approach, that can either contain numbers or variable names. Not a full compiler, but the code generated is close to machine-like. There are no math sprintf calls in the actual code generator now. More details can be found here: https://youtu.be/lHlFPqlOezo -VkFFT supports arbitrary number of dimensions now. By defining VKFFT_MAX_FFT_DIMENSIONS, it is now possible to mimic fftw guru interface. Default 4. Innermost stride is always fixed to be 1, but there can be an arbitrary number of outer strides. to achieve innermost batching, initialize N+1 dim FFT and omit the innermost one using omitDimension[0] = 1. -Enabled fp16 for all backends. -Accuracy verification of the new version can be found here: vincefn/pyvkfft#25 -The new code structure will facilitate the implementation of many new features and performance improvements, so stay tuned.
Multi-upload performance improvements + bugfixes -Improved multi-upload FFT algorithm performance in double precision on HPC GPUs -Fixed double precision sincos computation. Now it is possible to disable LUT - useLUT switched to int64_t, -1 disables LUT, 0 - auto decision, 1 forces it. It is possible to disable LUT for 4-step algorithm rotation only - useLUT_4step -Optimized swapTo3Stage4Step and switched it to direct number value from the power of 2 -Bugfixes: fixed FP64 usage in FP32 when number ending was not printed in kernels (important), fixed registerBoost incorrect writing, fixed #93
Radix 6, 8, 9, 10, 12, 14, 15, 16, 32 support + Bluestein tuning -Added support for more composite radix kenrels. Improves performance by reducing shared memory communications -Added Bluestein sequence advanced tuning: can now specify the sequence to pad to. Added default tuned values for FP32 and FP64 for Nvidia A100 and AMD MI250 for sequences up to 4096 -Improved LUT usage: do not upload the first radix, coalesced upload to shared memory for small stage requests. -Bugfixes: C2R check for big radix, matrix convolution coordinate assignment, specification of device_id in cuFFT/rocFFT scripts
DCT-I and odd-length DCT-IV support -Added support for the missing base Discrete Cosine Transforms. -Fixed DCT-IV issues in OpenCL backend -Improved coalescing logic for DCT and Bluestein's algorithm -bugfixes
Initial documentation release -Added explicit documentation that covers many questions about VkFFT and aims to provide help in using VkFFT. It is an initial version of it, so it will be expanded and improved in the future. -Added checks for passing of 0s as buffer sizes (#41) -Fixed issue #44
Performance update for Bluestein's algorithm -Improved the algorithm for determining optimal padded sequence size - up to 2x speed improvement of Bluestein's algorithm on some sequences. Bandwidth is more stable across the whole range of supported systems -Optimized the normalization by replacing it with a single multiplication instead of integer division at each stage. This solves previous CUDA/Vulkan speed discrepancies and removes ALU overutilization in Bluestein's algorithm -Small improvement for sequence batching performance -Bugfix for normalization parameter with Bluestein's algorithm -Bugfix for DCT Bluestein's algorithm
Bluestein's algorithm implementation in VkFFT -Added support for Bluestein's algorithm to cover arbitrary FFT sequences (including big primes). Optimized performance by using zeropadding and convolution merging for the lowest amount of memory transfers -Currently implemented coverage: full range of C2C (including multi-upload), single-upload R2C/C2R/R2R (2^12, 2^12, 2^12 - depending on shared memory configuration) -New configuration options: keepShaderCode - will print executed kernels as they are launched, omitDimension[3] - allows to disable specific FFT dimensions (C2C and R2R only), fixMaxRadixBluestein - allows to control the max primes used in Bluestein padding (can reduce memory usage if set higher) -New benchmarks and precision tests to check Bluestein's implementation validity -Bugfixes
Discrete Cosine Transforms - II, III and IV support -Added support for Discrete Cosine Transforms (DCT) of types II, III and IV in VkFFT. Performance is well-optimized to be on the same level as DFT transforms. Single upload only (length < 8192 in FP32 for 64KB of shared memory). DCT-IV is for even sequences only. FP32 and FP64, multidimensional systems are supported -Added option to perform calculations in FP64 precision, while storing data in FP32 (doublePrecisionFloatMemory). -OpenCL has issues with local memory synchronization in DCT-4 (Other backends work fine). -Cleaned code for management of transforms with a different logical size
Refactored benchmark scripts -Split all examples from Vulkan_FFT into separate cpp files. Should be easier to read -Added CLI for user-input system benchmarks (benchmark_vkfft, benchmark_cufft and benchmark_rocfft flags). Available options: X, Y, Z - dimensions, P - precision, B - batch, N - number of iterations, R2C -Addressed issue #29
OpenCL support in VkFFT -This update adds OpenCL backend in VkFFT (VKFFT_BACKEND 3) -OpenCL backend has similar performance compared to other backends -devices key works on all backends now -Major release
Big performance update -Solved most nonstrided shared memory conflicts with new on-fly axis swapping technique -Improved R2C/C2R performance. Will add odd sequence lengths in the next update -Improved register management for large primes -Added rocFFT benchmark and precision scripts -Added new benchmarks: 1000 - tests all 1D FP32 systems from 2 to 4096, 1001 - tests all 1D FP64 systems from 2 to 4096, 1003 - tests all 3D FP32 cube systems from 2 to 512 for VkFFT/cuFFT/rocFFT. Will update plots soon -Switched to dynamic shared memory allocation in CUDA and HIP backends -Bugfixes to strides definition and buffer layout management
Radix 11 and 13 support -VkFFT now supports sequences that are a multiple of 2s, 3s, 5s, 7s, 11s and 13s. Improved thread management -R2C optimization now produces output in the same padded layout as FFTW -Solved some of the shared memory bank conflicts for slightly better performance -It is now possible to select in which stream to run VkFFT in CUDA/HIP version
CUDA/HIP support in VkFFT -VkFFT now supports three backends - Vulkan, CUDA and HIP to cover a wider range of devices (VKFFT_BACKEND in CMakeLists). All use runtime shader/kernel generation by the means of glslang compiler/NVRTC/HIPRTC - CUDA/HIP support is in beta, some systems are not producing correct result (while Vulkan works), some extra features are not implemented yet (multiple buffer input/output, half-precision, input/output automatic type conversion, 4x register overutilization, cache shuffling, big convolutions also not tested) -QoL changes: simplified startup configuration of VkFFT - secondary parameters are default initialized to optimized values for easier use of the library (can be changed manually). Forward/inverse direction can be selected at kernel launch. Automatic temporary buffer allocation in Four-step algorithm (can be done manually) -Performance improvements: LUT reuse, improved general kernel stability and speed
Register overutilization for arbitrary sequence sizes rework -This update brings generalization of register overutilization technique for arbitrary sequences. With it enabled, bigger sequences can be done in one upload to the chip, effectively bringing shared memory size to 128KB or even 256KB. It trades occupancy for lower number of memory transfers and can be useful for high-end GPUs with high CU count. Works both for non-strided and strided axes. Tested for C2C and single upload mode, no convolutions (will be improved in the future). Enabled for power of 2 sequences by default (works for non-power of 2 sequences as well, but performance gains are not yet tested). -Switched FFT exponent sign to be conformant with FFTW. Added an option to disable normalization in inverse FFT (enabled by default).
Better Vulkan version control + lower stack usage -Vulkan API version can be specified in CMakeLists (default 1.1). Selecting 1.0 disables half-precision tests -Reduced stack usage of VkFFT by switching plans to heap allocation -Improved zeropadding performance
Radix 3 and 5 support -This big update greatly expands the amount of supported sequences. VkFFT can now work with sequences representable as a multiplication of 2, 3 and 5. Adding other radicies (7, 11... etc) requires only kernels now, as the engine is now enhanced to handle non full thread warps -Sample 14 performs precision test of VkFFT against FFTW on a set of powers 3 and 5 in single precision -Three stage Four-step FFT algorithm works with radix 3 and 5, so the range of sequencess is big -Radix 3 and 5 speed is on the level of pure powers of 2. Updated multidimensional benchmark (sample 3) shows that on modern display resolutions (like 1920x1080) VkFFT is 50%-100% faster than cuFFT -Current limits of radix 3 and 5: only even dimensions in C2R/R2C have been tested. Double precision only works in sincos polynomial approximation mode (LUT is not implemented for radix 3 and 5). Convolutions are not tested, but should work -All radix kernels are now inlined - saves on inout copying and register usage -Register overutilization and half bandwidth boost are disabled for renovations -small bugfix to the earlier commit (missing return value and zeropadding fix on Intel GPUs)
VkFFT runtime shader generation overhaul -VkFFT now creates shader collection during the FFT plan creation phase. They are compiled using glslang compiler, which is now included. This allows for many new optimizations and features, listed below. The overhead of shader generation is negligible. Precompiled shaders are no longer shipped with VkFFT. This update greatly reduces the size of codebase -All shaders now truly store information in registers - each variable is declared not as a part of an array, but as a separate entity, so the compiler has to store it in register file -This shows that array approach used before was done mostly using L1/L2 cache. Which is also really good (especially on 28KB register file Intel GPUs), so in the next update VkFFT will try to combine best of both worlds - allocate part of a sequence in register file and part as an array that will not cause cache misses. -It should also be noted that as registers don't have addresses, it is not possible to do warp shuffling (used to avoid shared memory cache misses) directly on them. Adding an additional write to an array in cache, shuffling there and writing back (while letting compiler optimize the transfers) seems to be faster than writing directly to the shared memory -Unrolled most loops, inlined most constants. VkFFT doesn't use specialization constants anymore - should be able to work on macOS through MoltenVK without tweaks now. Unrolling is done by moving loops with prints to the C code -Reworked zero padding. It now works in both directions of transform and is not only limited to 2x enlargement - you can now specify the range of sequences on each axes that are set to zero in the beginning. For example, it is possible to do zero padding from 1/4th to 3/4th on each axes. -Improved performance for >32KB of shared memory GPUs -Register overutilization is rewritten to use less registers and works in double precision as well -The code is now faster on smaller systems -Created foundation for arbitrary radix kernel support - all that is needed now are kernels codes and scheduler update to split sequences better
Precision verification in CLI -Added an option to compare VkFFT to cuFFT (if enabled) and FFTW in single, double and half precision. Launch with -vkfft and keys 11-13 -Path to FFTW can be specified in CMakeLists -Reverted TLB fix for AMD GPUs. Apparently, they can't handle more than 64-128 buffers bound. Multiple buffer input/outputs works -Added include guards and static definitions -All files under MPL 2.0 license are moved to the vkFFT folder -This version should be stable and has most of planned features, so it is released as 1.1.0
Multiple buffer input/output support. AMD TLB fix -Now VkFFT supports input/output data to be stored in multiple buffers. passed as a pointer to the array of buffers with a number of buffers. VkFFT will use memory consecutively, splitting data logically in the chunks of the smallest buffer size. This allows to use data split between different memory allocations and mitigate 4GB single allocation limit. Sample 10 shows how this works -VkFFT is now able to mitigate TLB buffer misses on big sequences. This was detrimental for AMD GPUs performance before - up to 5x performance gains for big systems there. This is done by logical split of input/output buffer in 16KB chunks if sequence spans more than 2MB. Two parameters: localPageSize and devicePageSize control these two parameters. Also combinable with multiple buffers update -Updated performance plots
Big performance improvement on small systems -restructured kernel configuration of small systems (less than warp size divided by 8 in unit-stride axis). They also achieve maximum bandwidth now -improved the system set of multidimensional benchmark to cover all possible sizes -tweaked half bandwidth technique -moved Windows executables according to https://github.com/DTolm/VkFFT/issues/14 -as usual, all reports are welcome via the E-mail or GitHub issue as they help optimizing the algorithm