Skip to content

[HLSL] LinAlg HLK: Add tolerance and ULP comparison modes to the matrix oracle #8729

Description

Goal

Extend MatrixResultOracle in LinAlgTests.cpp beyond bit-exact comparison, so operations whose results the specification does not pin down uniquely can be verified without either weakening the test or enumerating an impractical number of candidate matrices.

Why

The oracle's three modes — Exact, PermittedResults and Excluded — all compare encoded component bits exactly. PermittedResults expresses "the spec permits this result or that result" as an enumerated set of complete candidate matrices; it is not a tolerance band.

That is correct and deliberate for the cases covered today, where every value is exactly representable in its component type and bit-exactness is both stronger than a tolerance and reproducible across implementations. It does not extend to operations where the specification leaves a range: matrix multiply accumulation order over a large K, conversion rounding, and results produced through the optimal layouts. Enumerating candidates there is not viable.

The harness already has the vocabulary for this. ValidationType::Epsilon and ValidationType::Ulp in HlslTestDataTypes.h are used by the pre-existing verifyFloatBuffer and verifyHalfBuffer paths in this same file. The oracle should adopt those rather than introduce a fourth comparison vocabulary.

Required work

  • Add tolerance-based and ULP-based comparison to MatrixResultOracle, reusing ValidationType and the existing doValuesMatch overloads.
  • Keep Exact the default; a case must opt in to a looser comparison and state why.
  • Require that any tolerance is derived from the specification or from an independent error analysis, and record that derivation at the call site.
  • Report the worst observed deviation on failure, not just the first mismatch.

Acceptance criteria

  • At least one operation whose result the spec does not uniquely determine is covered with a justified tolerance.
  • No existing case is relaxed from Exact as part of this work.
  • Tolerances are traceable to a public specification statement or a written derivation; none is fitted to an implementation's observed output.

Blocked on

Nothing, but it should land with the first case that genuinely needs it so the tolerance is chosen against a real result rather than guessed.

Public references

Out of scope

  • Relaxing any currently exact expectation.
  • Templating the oracle, and the checked-arithmetic redesign (tracked separately).

Assisted-by: GitHub Copilot

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions