Support external workspace and workspace size query in DFT domain about onemkl

[Rbiessy]

Thank you for the issue. We'll start working on this in the coming weeks.

[hjabird]

I'm looking at this at the moment. A challenging aspect is providing pre-commit estimates of workspace size. This is because rocFFT (and perhaps other future backends) do not support workspace estimates, only exact workspace requirements after committing.

• What is the usecase for pre-commit workspace estimates?
  • Do we need pre-commit estimates at all?
• Do these estimates need to be conservative?

Thanks!

[zhiweij1]

Hi @hjabird , I noticed that https://github.com/ROCmSoftwarePlatform/hipFFT/blob/ef5eb0d5facf9d997b00bb0b94c8e37791b72ce4/library/src/amd_detail/hipfft.cpp#L1150 uses hipfftGetSize1d to implement hipfftEstimate1d which is the migrated result of cufftEstimate1d with HIPFIY.

It just queries the actual workspace size after creating a plan and destroys the plan before return.

[hjabird]

Hi @zhiweij1, that is an option, but creating a plan just to query workspace size is an expensive thing to do. Especially if you then create that exact same plan once again on commit!

At the moment I don't understand the scenario in which you use an estimate instead of committing a descriptor and getting the exact workspace requirement from that. In such a scenario, does the estimate need to be conservative (if not, we could introduce some kind of heuristic for rocFFT's workspace requirements, or just return 0)?

The specification may be a better place to continue this discussion. I've created a spec issue oneapi-src/oneAPI-spec#508 and also a draft PR in the spec oneapi-src/oneAPI-spec#509

[hjabird]

@zhiweij1 I've had some feedback on the above linked PR. It would be great to have your feedback too, especially since it doesn't include the estimation feature right now. It doesn't included this feature since I'm not sure how it would be used (and so what to specify), as stated in my above comment.

[zhiweij1]

Hi @hjabird, the oneapi-src/oneAPI-spec#509 LGTM.

[hjabird]

As a timeline on this:

• I believe above spec PR needs to be discussed by the Math SIG before it can be merged. I hope this can take place in early December, but obviously it is subject to availablity, scheduling, holidays in the US, etc.
• I've already started work on adding support for the above spec to oneMKL, but it won't make sense to until the spec is merged.

So long as no problems or delays are encountered, hopefully external workspaces will be added in early December. I'll try to keep this issue updated.

[hjabird]

Happy new year!: both the spec and implementation are now merged!