[svenvh]

Add tests for the cl_khr_cooperative_matrix extension.

The extension defines various operations on cooperative matrix types. The list of tested operations is in cooperative_matrix.def. Each entry in that .def file results in a subtest.

Each subtest will iterate over all supported variants reported by the runtime and test each variant. An individual variant can be run using the --variant command line option.

This CTS suite generates textual SPIR-V and uses spirv-tools to assemble the textual SPIR-V into a SPIR-V binary.

[bashbaug]

Asking as a review comment for better threading.

I am interested in this kind of SPIR-V tools integration for general-purpose SPIR-V testing via generated SPIR-V files vs. the current SPIR-V testing using pre-written .spvasm files. Especially for cases where testing iterates over a combination of source and destination types, it's much more maintainable to generate each test case on-the-fly rather than commit tens (or more) different files.

My questions are specifically:

1. Are we happy with this general approach? Are we OK adding a built dependency on SPIR-V tools for general-purpose SPIR-V testing? Do we want to support building SPIR-V testing (specifically, test_spirv_new) without support for SPIR-V tools, or are we OK requiring SPIR-V tools for SPIR-V testing?
2. If so, are we OK separating out the SPIR-V tools integration into a separate PR? Is there anything we would want to change in the process?

Note that (2) is not needed if we can get this PR merged soon, but there hasn't been a lot of activity on it lately, so it will take some concerted effort and/or risk taking to get it merged in the near future.

[bashbaug]

Somewhat related: We might want to revisit #2527 if we proceed with SPIR-V tools integration, especially if we add a build dependency on SPIR-V tools for test_spirv_new but not for the entire CTS. With access to SPIR-V tools, we could generate SPIR-V modules for the SPIR-V extensions, extended instruction sets, and capabilities returned by SPIR-V queries, but we'd want to do that testing as part of test_spirv_new and not as part of test_api (where the SPIR-V query testing is currently).

[svenvh]

I'm happy to factor the SPIR-V tools integration out into a separate PR. I always felt that's a substantial change warranting a dedicated PR anyway. As part of that, I can migrate an existing spirv_new test as a proof-of-concept, so that folks can test the new dependency in their environments without needing a cooperative matrix implementation.

[bashbaug]

Awesome! If you don't mind factoring out the SPIR-V tools integration into a separate PR, I'll definitely take you up on the offer. I would be interested in using this functionality soon, though, so I don't mind doing this myself if it's going to be some time. Just let me know - thanks!

[svenvh]

Here's an initial attempt: #2782
It might take a few iterations to get it working on CI, so I've created it as a draft for now.

[rjodinchr]

Thanks for the updates! I found a few remaining issues, notably an out-of-bounds Workgroup array size (and missing alignment decoration) in copy_workgroup, signed 64-bit integer overflow UB in the mul bounds calculation and Matrix::fill, and a leftover typo in opencl_conformance_tests_full.csv.