Merge group related improvements for convolution operations

[zsotakal]

A collection of several depthwise convolution related improvements.

Proposed changes

The list of todos came from the investigation of 2d convolution performance on fp32 data input. It turns out CK has limited support for merged group convolutions. The purpose of this PR is to add some of the missing functionality.

• Added merged groups implementation for backward data convolution in 2d and 3d.
• Added new instances for fp32 bit fwd convolution with merge group sizes 2 and 4
• Added missing instances for fp32 wrw convolution
• Added tuned instances bwd data convolution

Checklist

Please put an x into the boxes that apply. You can also fill these out after creating the PR. If you're not sure, please don't hesitate to ask.

• I have added tests relevant to the introduced functionality, and the unit tests are passing locally
• I have added the test to REGRESSION_TESTS list defined at the top of CMakeLists.txt in tests/CMakeLists.txt, IF the test takes more than 30 seconds to run.
• I have added inline documentation which enables the maintainers with understanding the motivation
• I have removed the stale documentation which is no longer relevant after this pull request
• (If this change is user-facing) I have added release notes which provide the end users with a brief summary of the improvement from this pull request
• I have run clang-format on all changed files
• Any dependent changes have been merged

Discussion

If this is a relatively large or complex change, feel free to start a discussion by explaining why you chose the solution you did and what alternatives you considered

[kabrahamAMD]

Is there a way to avoid duplication with the struct above? Afaik, these functions are only used in two places, so I would recommend to always call the MG variant and to have a defalut value (and ignore the GStep return value) to avoid duplicating the rest of the logic

[zsotakal]

I did the unification for the generator helper function which was a low hanging fruit. With the structure I am not sure if its a good idea. It can be generalized but since the dimensions don't match it is slightly more complicated. For the time being I would leave it like this since I don't see the long term strategy with it. If this is the new method a more general infrastructure will be needed to support all convolution varaints, if that is not the case having this dirty variant seems fine to me.

@bartekxk do you have an opinion in this?

[illsilin]

Hi @zsotakal, have you coordinated these changes with the MIOpen team? It looks like they are breaking the MIOpen tests in TheRock CI, which is specifically meant to ensure we don't break the cross-library integration.

[ammallya]

Imported to ROCm/rocm-libraries