ROCmSoftwarePlatform
BN FWD INFER OCL to HIP
This PR focuses on converting the Batch Norm Forward Inference Spatial and Per Activation kernels from OpenCL to HIP. This conversion is a part of the broader initiative to translate all OpenCL kernels within MIOpen, as the OpenCL backend has been deprecated.
Ensuring correctness: The PR includes a GTEST that compares the output of the OpenCL kernel with the HIP implementation. The test cases are derived from the existing batch norm forward inference kernel GTEST.
Ensuring GPU Performance parity: The GTEST also measures the minimum, maximum, mean, median, and standard deviation of the kernel execution time across five runs and records the data in a CSV file. This data is used to create graphs that illustrate the average performance improvement of the HIP implementation over OpenCL. An average performance gain greater than one is considered favorable. TODO: Collect perf metrics on a wider variety of test cases on a gfx90a, and ensure parity.
Ensuring Host side Performance parity: As the OpenCL backend support is deprecated in MIOpen, the assumption is that this decision was made while being aware of the compilation overhead of HIP kernels over OpenCL.
@sgundabo PR description is missing some important info.
Please provide:
- explanation of what is done and why
- how this have been tested for correctness
- the same Q about GPU time/performance
- is it guaranteed that the new kernels have the same or better perf than the old ones? If yes, then how this is guaranteed?
- the same Q about host-side overhead.
- we know that HIP compilation time is typically 10x longer than OCL. We must ensure that OCL->HIP transition does not lead to degradation of "initial iteration time".
/cc @CAHEK7 @junliume
the same Q about host-side overhead.
- we know that HIP compilation time is typically 10x longer than OCL. We must ensure that OCL->HIP transition does not lead to degradation of "initial iteration time".
We can't do anything with it, except deprecating HIP and get back to OCL.
It can be safely merged since it does not affect production code. I just don't want to lose this PR.
MIOpen is moving to the monorepo and old PR's need to be closed for this to happen. If needed, this PR can be re-opened in the new repo.
