Enable tests for externally-managed work areas by expanding hipfft_params

[regan-amd]

Summary: changes suggested to enable coverage for features relevant to externally-managed work areas with hipFFT.

Details

1. In general, hipFFT should assume/require a pointer to an array of $N_\text{GPU}$ size_t values where $N_\text{GPU}$ is the number of GPU devices being used, when it comes to the size_t* workSize arguments of its various APIs. Some implementation changes may be required for multi-gpu usage as only one of those values is written anyways on AMD platforms currently unless I missed something; full testing cannot be done at the moment due to a missing API in my understanding, though.
   Anyhow, this point likely motivated some gymnastics currently present within hipfft_params that makes the base class member variable workbuffersize irrelevant/unused/possibly misleading in some cases. I suggest to no longer declare workbuffersize in the base class to let derived classes consistently unroll their own logic, free of that "constraint". This also triggers some required changes for the fft_params::work_buffer_alloc_failure exception, in turn.
2. The base class is expanded with a member enum variable identifying whether the encapsulated plan is allowed to "auto-allocate" its work area(s) or not; the possible values are basically "on", "off", and "default". For rocfft_params, "default:=off" whereas "default:=on" for hipfft_params.
3. The hipfft_param class is expanded with a static std::vector<gpubuf> externally_managed_workareas; class member that is meant to be used by its instances if they're required to create plans without auto-allocation. externally_managed_workareas exists independently of any of the hipfft_params instance. Any instance instructed to create plans without auto-allocate will use the member(s) of externally_managed_workareas (after reallocating them if they're too small for their needs) and provide them as work areas to the created plans.
   If any plan creation is found to fail due to a failing device allocation at any point, the specific hipfft_params instance will clear externally_managed_workareas and attempt the plan creation again before reporting the failure (or not), given that externally_managed_workareas may contain buffers that are not needed or too large for the instance.
4. I'm suggesting some implementation changes to hipFFT to prevent it from allocating more buffer(s) if a simple work buffer size or size estimate is queried.

Please let me know if hipfft_params is supposed to be thread-safe as more care would be required w.r.t. externally_managed_workareas in that case.

[malcolmroberts]

This seems like it's going to affect performance tests, which is also a target for hipfft_params.

[regan-amd]

AFAIK, the suggested changes should not modify the overall behavior of this class for configurations that could be tested prior (at least not w.r.t. the allocations of work areas). With the suggested changes, any previously-testable configuration remains testable, and their (newly-introduced) member auto_allocate is then fft_auto_allocation_default (note: fft_auto_allocation_on behaves equivalently in case of hipfft_params). In such cases, this specific member function would always return false and the logic flow of create_plan is globally unchanged (work areas are automatically allocated by hipfft at plan generation).

For newly-enabled configurations of hipfft_params though (i.e., cases with auto_allocate set to fft_auto_allocation_off), note that the additions to create_plan will still fully set the required work areas (see set_externally_managed_work_areas) before returning. The changes do not rely on the backend library (e.g., rocfft) allocating its own work area(s) at plan execution if they were not provided with some prior.

Therefore, I do not expect a significant change in measured performance, in either case. I verified with a few various sizes on a gfx1201 (single-process, single-GPU cases), using hipfft-bench on this branch and develop. Please let me know if there is a specific size you'd want me to look into.

[malcolmroberts]

Does this affect a performance test?

[regan-amd]

Does this affect a performance test?

I don't think it does.

[malcolmroberts]

This isn't really an error; we just haven't implemented it yet. Normally, one would just skip the test using gtest's mechanism, but we can't do that here because it's in the fft params level.

[regan-amd]

Thank you. I introduced a dedicated base-class-defined unimplemented_exception along with the corresponding logic in the accuracy test in 517f101: let me know if that's more acceptable o you, or not.

Note: thinking about it, I don't think the (current) lack implementation support warrants an exception to be thrown by validate_fields, so I removed it therefrom.