mirror of
https://github.com/ROCm/composable_kernel.git
synced 2026-03-21 15:47:38 +00:00
e6e7dc2910
This pull request builds on #3267 by proving the "validation" infrastructure, the means to compare a set of `Outputs`. The design of the validation infrastructure is relatively straight forward: - Each SIGNATURE should come with a `validate()` implementation, which should be implemented in a similar way that the other functions/types from `testing.hpp` are implemented. - `validate()` returns a `ValidationReport`, which is a structure that keeps all relevant information about comparing the tensors from two `Outputs`. Note that crucially, `validate()` should not do any reporting by itself. Rather, glue logic should be implemented by the user to turn `ValidationReport` into a relevant error message. - You can see this clue code for CK-Builder itself in `testing_utils.hpp`, its `MatchesReference()`. This functionality is relatively barebones right now, it will be expanded upon in a different PR to keep the scope of this one down. The comparison is done on the GPU (using an atomic for now), to keep tests relatively quick. Some notable items from this PR: - To help compare the tensors and with writing tests, I've written a generic function `tensor_foreach` which invokes a callback on every element of a tensor. - For that it was useful that the `TensorDescriptor` has a rank which is known at compile-time, so I've changed the implementation of `TensorDescriptor` for that. I felt like it was a better approach than keeping it dynamic, for multiple reasons: - This is C++ and we should use static typing where possible and useful. This way, we don't have to implement runtime assertions about the tensor rank. - We know already know the rank of tensors statically, as it can be derived from the SIGNATURE. - It simpifies the implementation of `tensor_foreach` and other comparison code. - There are a lot of new tests for validating the validation implementation, validating validation validation tests (Only 3 recursive levels though...). For a few of those functions, I felt like it would be useful to expose them to the user. - Doc comments everywhere.
49 lines
1.6 KiB
C++
49 lines
1.6 KiB
C++
// Copyright (c) Advanced Micro Devices, Inc., or its affiliates.
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
#include <gtest/gtest.h>
|
|
|
|
#include "testing_utils.hpp"
|
|
|
|
using ck_tile::test::inlineDiff;
|
|
|
|
TEST(InlineDiff, simpleColorDiff)
|
|
{
|
|
std::string str1{"hello"};
|
|
std::string str2{"hello"};
|
|
std::string str3{"world"};
|
|
|
|
// some easy tests
|
|
// you can veryfy the ungodly strings are meaningful by running echo -e "<string>"
|
|
EXPECT_THAT(inlineDiff(str1, str2, true), "hello");
|
|
EXPECT_THAT(inlineDiff(str1, str3, true),
|
|
"[\x1B[36mwor\x1B[0m|\x1B[35mhel\x1B[0m]l[\x1B[36md\x1B[0m|\x1B[35mo\x1B[0m]");
|
|
}
|
|
|
|
TEST(InlineDiff, noColorDiff)
|
|
{
|
|
std::string str1{"hello"};
|
|
std::string str2{"hello"};
|
|
std::string str3{"world"};
|
|
|
|
// some easy tests without color
|
|
EXPECT_THAT(inlineDiff(str1, str2, false), "hello");
|
|
EXPECT_THAT(inlineDiff(str1, str3, false), "[wor|hel]l[d|o]");
|
|
}
|
|
|
|
TEST(InlineDiff, complexColorDiff)
|
|
{
|
|
|
|
// now something more interesting
|
|
std::string str4{"this part has changed, this part has been left out, this part, this part has "
|
|
"an extra letter"};
|
|
std::string str5{
|
|
"this part has degeahc, this part has, this part added, this part has ana extra letter"};
|
|
|
|
EXPECT_THAT(
|
|
inlineDiff(str5, str4, true),
|
|
"this part has [\x1B[36mchanged\x1B[0m|\x1B[35mdegeahc\x1B[0m], this part has[\x1B[36m "
|
|
"been left out\x1B[0m|\x1B[35m\x1B[0m], this part[\x1B[36m\x1B[0m|\x1B[35m added\x1B[0m], "
|
|
"this part has an[\x1B[36m\x1B[0m|\x1B[35ma\x1B[0m] extra letter");
|
|
};
|