LinAlg HLK: Add component-type and value-domain coverage

Goal

Expand LinAlg HLK execution coverage across selected component types and value domains for each public operation category that advertises support, using the public dx::linalg API and the independent host oracle tracked by #8649.

Coverage should prove type interpretation and arithmetic semantics without attempting every operation/type/value combination.

Why

Current ExecutionTests are concentrated on F16 with limited F32 and I32 coverage. That leaves signedness, unsigned types, narrow integer formats, packed representations, FP8 formats, conversion boundaries and mixed input/accumulator combinations largely untested.

A third-party compiler or driver may support an operation for one type combination but mishandle another, so capability-gated type coverage is required for useful conformance testing.

Required coverage

• Cover supported signed and unsigned integer component types.
• Distinguish matrix-construction/component-representation support from operation-specific support; do not infer multiplication, MatVec, OuterProduct or atomic support from a different query category.
• Record the exact #8647 query category and type inputs that gate each case.
• Keep component selection and representative values in this issue; numeric conversion, interpretation and signedness pairings remain owned by #8653.
• Cover supported F16 and F32 paths, including mixed input and accumulator types where permitted.
• Add capability-gated coverage for I8/U8 packed representations and FP8 E4M3FN/E5M2.
• Track I64/U64/F64 as deferred until the public runtime capability contract and certification requirements expose a testable support rule.
• Exercise representative defined value classes:
  • zero, one and negative one where representable;
  • signed and unsigned boundaries;
  • values immediately around conversion and saturation boundaries;
  • finite floating-point values around precision or rounding boundaries;
  • explicit bit-exact FP8 source encodings and packed representations.
• Cover compatible matrix input and accumulator type combinations for multiplication operations.
• Exercise native and InterpretedVector inputs for MatVec and Convert where applicable.
• Prefer floating values whose expected results are normatively unique. For required precision-boundary cases, consume the specification-derived permitted-result model from #8649, including emulated-input/output flags.
• Avoid undefined overflow, NaN or infinity behaviour unless the public specification defines the expected result.
• Use #8647 for capability handling and #8649 for input encoding and expected values.

Acceptance criteria

• Every component type selected for this HLK tranche and advertised by a relevant public operation query is represented by at least one supported execution path.
• Every type case records the operation-specific capability query that permitted execution.
• Signed and unsigned integer behaviour is distinguished by values that would produce different results if interpreted incorrectly.
• At least one narrow or packed integer case is covered where supported.
• Both FP8 formats have bit-exact source-encoding coverage where supported; output bits are exact only for uniquely specified results and otherwise use #8649's documented permitted-result model.
• F16 and F32 arithmetic use exact expectations where normative and specification-derived permitted results where implementation variation is allowed.
• Mixed input/accumulator combinations are covered for matrix multiplication where advertised.
• MatVec and Convert exercise interpreted-vector paths as well as native vectors where the public API permits them.
• Unsupported component combinations follow #8647 and are not reported as passing tests.
• I64/U64/F64 coverage is either implemented against a public capability rule or explicitly remains deferred with a public rationale.
• Each added case references the operation issue it advances and records the remaining type gaps.

Existing related issues

• Convert signedness #8355.
• Packed-type trait handling #8400.
• Input vector component restrictions #8398.
• Component-enum handling for native vectors #8376.
• DXIL component validation under #7840 and completed issue #8494.

Public references

• HLSL proposal 0035: LinAlg component types
• D3D12 Linear Algebra Runtime Feature Support
• Parent tracker #7841
• Capability handling #8647
• Independent oracle #8649

Out of scope

• A full Cartesian product of operations, types and values.
• Invalid-component rejection tracked under #7840.
• Fixing public API or validator defects discovered by the tests.
• Requiring 64-bit types before a public runtime support contract exists.
• Publishing private hardware support tables.
• Duplicating conversion, interpretation and signedness semantics owned by #8653.
• Treating support reported for one operation category as proof that another category supports the same component type.

Assisted-by: GitHub Copilot