[rocm-libraries] ROCm/rocm-libraries#5722 (commit 55febd2)

[CK Tile] Stream-K gtest Code Gen

## Motivation

Stream-K was using the tile engine infrastructure for smoke tests.
However, tile engine creates a different target per kernel instance,
which has resulted in scalability issues when used in the context of
unit tests. To avoid burdens on cmake configuration and build time, we
have opted to remove our Stream-K tile engine tests. Instead, we use
pure gtests with code gen to generate repetitive .cpp files.

**Note: This appears to change a lot of files because many files are
removed since they are now generated at build time.**

## Technical Details
We originally used Tile Engine to facilitate code gen for unit tests
since we found that pure gtests required the addition of many repetitive
.cpp files of the following form:
```cpp
#include "test_gemm_streamk_common_includes.hpp"

template <typename Tuple>
class TestCkTileStreamKBf8 : public TestCkTileStreamK<Tuple>
{
};

#define TEST_SUITE_NAME TestCkTileStreamKBf8

TYPED_TEST_SUITE(TestCkTileStreamKBf8, KernelTypesStreamKBf8);

#include "test_gemm_streamk_atomic_cases.inc"

#undef TEST_SUITE_NAME

```
Due to issues encountered with tile engine, we instead use pure gtests
to generate the repetitive .cpp files. The code generator parses
`KernelTypesStreamK*` type aliases from the types header using a
two-phase approach:
1. At **configure time**, CMake runs the Python script with
`--list_files` to extract the type alias names from the header
(test_gemm_streamk_types.hpp) and compute the list of .cpp file paths
that will be generated. This lets CMake know the exact set of source
files for each target.
2. At **build time**, `add_custom_command` runs the script again with
`--gen_files` to actually emit the .cpp files into the build directory,
triggered only when the types header or generator script changes.

With these changes, we've removed all Stream-K tile engine tests. There
are now 5 targets for Stream-K GEMM tests:
1. test_ck_tile_streamk_atomic_smoke: smoke tests for Atomic reduction
strategy (pipeline: compv3)
2. test_ck_tile_streamk_linear_smoke: smoke tests for Linear reduction
strategy (pipeline: compv3)
3. test_ck_tile_streamk_tree_smoke: smoke tests for Tree reduction
strategy (pipeline: compv3)
4. test_ck_tile_streamk_pipelines_smoke: smoke tests (smaller set) for
pipelines other than compv3
- Since Stream-K can be thought of as a wrapper around universal GEMM,
we don't need to extensively test each pipeline. So, we opt to run a few
tests for different pipelines. Currently, this just consists of the mem
pipeline, but compv4 is coming soon.
5. test_ck_tile_streamk_extended: extended tests

## Test Plan

I have tests the gtests locally on gfx90a, gfx942, and gfx950.

## Test Result

All local tests pass.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

test/ck_tile/gemm_streamk_tile_engine/README.md

@@ -1,64 +0,0 @@
-# Stream-K GEMM Tile Engine Unit Tests
-
-## How It Works
-
-This unit test system integrates **tile_engine's kernel generation** into automated testing:
-
-1. **Uses tile_engine scripts directly**: Same Python scripts that generate tile_engine kernels
-2. **JSON-based configuration**: Define test parameters in JSON files (like tile_engine)
-3. **Build-time generation**: CMake calls tile_engine scripts to generate kernel headers
-4. **Individual test executables**: Each kernel configuration becomes a separate test
-5. **Tile_engine verification**: Uses exact same error thresholds and validation as tile_engine
-
-## Tile Engine Integration
-
-```
-JSON Config → tile_engine Python scripts → Generated Headers → Test Executables
-```
-
-- **`--list_kernels`**: Get available kernel configurations from JSON
-- **`--gen_individual`**: Generate all kernel headers in parallel during CMake configuration
-- **`--gen_single`**: Generate individual kernel header for each configuration  
-- **Same verification**: Uses tile_engine's adaptive error thresholds and reference calculations
-- **Same patterns**: Follows tile_engine's tensor initialization, stride calculation, and kernel launching
-
-### Config-Specific Test Parameters
-
-Each test configuration can specify optimized problem sizes in its JSON file:
-- **`test_params.problem_sizes`**: Array of `{m, n, k, split_k}` configurations
-- **CMake extraction**: `extract_test_params.py` generates config-specific test parameter files
-- **Build integration**: Each test target uses parameters appropriate for its kernel configuration
-- **Optimized testing**: Different configs test different problem sizes that showcase their strengths
-
-
-The key idea: **Unit tests that use tile_engine's exact kernel generation and verification methodology** instead of creating separate test infrastructure.
-
-## Test Configurations
-Test configs are generated during the Generation Phase. They are stored under the build directory at test/ck_tile/gemm_streamk_tile_engine/configs. The Compute Unit (CU) count of the device is required to generate the configs. If the Generation Phase occurs on a machine without a GPU or does not contain same GPU architecture on which you will run the tests, you can manually set the CU count using the `CU_COUNT` option:
-```bash
-# Assuming you are at the root of the repo
-cd build
-../script/cmake-ck-dev.sh .. gfx90a  -G Ninja -DCU_COUNT=100
-```
-You can reference the public whitepaper for your specific GPU to get the appropriate CU count. 
-If no `CU_COUNT` option is given and no HIP device is found, then the default value of 100 CUs will be used to determine the problem sizes tested.
-
-### 1. **Smoke Tests**
-- **Purpose**: Basic functionality validation for fp16/bf16/fp8/bf8 data types
-- **Config**: 256x256x32 (for bf16/fp16) or 128x128x32 (for bf8/fp8), warp 2x2x1, warp_tile 32x32x16  
-- **Traits**: compv3 pipeline only
-- **Coverage**: All 4 layouts (rcr, rrr, ccr, crr)
-
-## Data Type Support
-- ✅ **fp16, bf16, fp8, bf8**: Fully supported - all layouts (rcr, rrr, ccr, crr)
-- ❌ **fp64**: Not supported (hardware MFMA limitation)
-- ⏳ **fp32, pk-int4-t**: Not yet supported by gemm_instance_builder (will be added later)
-
-## Test Result Behavior
-
-Tests automatically handle unsupported configurations through runtime validation:
-- **PASSED**: Kernel executed correctly with results within error thresholds ✅
-- **SKIPPED**: Kernel validation returned "Arguments not supported" (expected for certain problem sizes/configurations) ⚠️
-- **FAILED**: Actual error or incorrect computation results ❌
-
-When a kernel's `IsSupportedArgument()` check fails (e.g., due to vector alignment requirements, dimension constraints, or padding limitations), the test is automatically skipped rather than failed. This allows comprehensive testing across various problem sizes while gracefully handling configurations that don't meet specific kernel requirements.