LinAlg HLK: Add conversion, interpretation, signedness and saturation coverage

Goal

Provide HLK execution coverage for the legal type-conversion and interpreted-input semantics exposed by the public dx::linalg API.

Tests must distinguish numeric conversion, signed and unsigned interpretation, saturation, vector packing and floating-point rounding so third-party compiler and driver implementations cannot pass using only same-type smoke cases.

Why

LinAlg operations accept component-type enums and interpreted vectors that may not match the native DXIL scalar representation. Current coverage does not adequately distinguish signedness, saturation, packed element counts, bias interpretation or source/destination conversion behaviour.

These semantics affect CopyConvert, Convert, group-shared matrix memory operations, MatVec inputs and MatVecAdd bias values, and can fail independently from the underlying arithmetic operation. Descriptor buffer operations use the matrix component representation and are covered for layout, addressing and bounds by #8651 rather than as conversion paths here.

Required coverage

• Exercise public dx::linalg conversion and interpreted-vector APIs.
• Matrix CopyConvert:
  • cover same-type copy, widening, narrowing and supported signed/unsigned conversions;
  • cover transpose and non-transpose paths;
  • verify the source matrix remains valid and unmodified.
• Vector Convert:
  • cover native and InterpretedVector inputs;
  • verify destination vector-length calculations for packed and unpacked types;
  • distinguish signed and unsigned interpretation using values that produce observably different results.
• MatVec and MatVecAdd:
  • cover native and interpreted input vectors;
  • cover bias interpretation independently from matrix/input interpretation;
  • cover output signedness where it affects the result;
  • for native vectors whose element type differs from the matrix component type, verify that interpretation follows the native vector InputElTy; track any public-wrapper or compiler defect exposed by this case separately.
• Group-shared memory conversion:
  • cover supported matrix load, store and accumulation conversions without conflating them with layout/addressing coverage;
  • do not assign conversion semantics to descriptor load, store or accumulation operations.
• Exercise values immediately below, at and above defined saturation boundaries.
• Use exact expected results for integer, packed and uniquely specified floating-point conversions.
• Use explicit FP8 bit patterns for source encodings; require exact conversion-output bits only when the destination exactly represents the source or the specification otherwise defines a unique result.
• Prefer values with a unique specification result. Where a required case permits implementation variation, use a reviewed specification-derived permitted-result set rather than an empirically widened tolerance.
• Account for capability flags indicating emulated inputs or outputs when deriving permitted results.
• Use #8647 for applicability, #8649 for the independent oracle and #8650 for component-type selection.

Acceptance criteria

• CopyConvert covers transpose and non-transpose conversion with source preservation.
• Convert covers at least one widening, narrowing, signedness-changing and packed-length-changing path where supported.
• Signed and unsigned interpretation cases use identical source bits but produce independently verified different results.
• Saturating conversions cover both lower and upper boundaries.
• MatVec covers native and interpreted inputs.
• MatVec includes a native-vector case where InputElTy differs from the matrix component type and verifies InputElTy interpretation.
• MatVecAdd covers input and bias interpretation independently.
• Supported group-shared load/store/accumulate conversion paths have representative execution coverage.
• Descriptor load/store/accumulate paths are not treated as type-conversion operations.
• FP8 conversion-output bits are required exactly only for normatively unique results; all other accepted results come from documented specification rules.
• Floating-point expectations document rounding and any effect from emulated-input/output capability flags.
• Unsupported conversions follow #8647 and are not reported as passing tests.
• Every added case links the operation issue it advances and records remaining conversion gaps.

Initial operation mapping

• Fill/construction conversion behaviour: #8545.
• Matrix CopyConvert: #8546.
• Group-shared memory conversion: #8548, #8554 and #8562.
• Descriptor representation, addressing and bounds: #8651.
• MatVec and MatVecAdd interpretation: #8559 and #8560.
• Vector Convert: #8564.

Existing related issues

• Convert signedness #8355 remains the authority for its I64/U64 signedness case.
• Native-vector component handling #8376 and #8398.
• Packed-type traits #8400.
• Interpreted-vector Convert API #8418.
• Remaining public API feedback #8468.
• DXIL Convert validation #8509 under parent #7840.

Public references

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

Out of scope

• Invalid conversion rejection tracked under #7840.
• Fixing public API, compiler or validator defects found by the tests.
• Exhaustive operation/type combinations.
• Undefined NaN, infinity or overflow behaviour.
• Publishing private hardware conversion support.
• Inventing descriptor load/store/accumulate conversion semantics while descriptor data is defined in the matrix component representation.

Assisted-by: GitHub Copilot