Consequently, you can end up with something like the following psuedocode:
myStridesFwd = {1, 4};
myStridesBwd = {1, 8};
rocfft_plan_description_set_data_layout(myPlanDesc, myStridesFwd, myStridesBwd);
// A plan generated with this would print that its input strides were {1, 4} and output strides were {1, 8}
// Now reuse the plan for the backward DFT, swapping inputs and outputs.
rocfft_plan_description_set_data_layout(myPlanDesc, myStridesBwd, myStridesFwd);
// A plan generated with this would should print that its input strides were {1, 8} and output strides were {1, 4}
// However, a plan generated with this would still print (incorrectly) that its input strides were {1, 4} and output strides were {1, 8}
// Internally the strides would be inStride = {1, 4, 1, 8} and outStride = {1, 8, 1, 4}
Operating System
Ubuntu 22.04
CPU
i9-12900K
GPU
AMD Instinct MI210, AMD Radeon Pro W6800
ROCm Version
ROCm 6.1.0, ROCm 6.0.0
ROCm Component
rocFFT
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
Problem Description
When reusing a plan description, the input and output stride vectors not reinitialized.
This is because the new strides are simply appended to the back of the inStride / outStride vector at https://github.com/ROCm/rocFFT/blob/b9926b55ee877db3d901e364135c8341b623c3cd/library/src/plan.cpp#L372 - the vector must be resized to zero first!
Consequently, you can end up with something like the following psuedocode:
Operating System
Ubuntu 22.04
CPU
i9-12900K
GPU
AMD Instinct MI210, AMD Radeon Pro W6800
ROCm Version
ROCm 6.1.0, ROCm 6.0.0
ROCm Component
rocFFT
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response