microsoft / microsoft/DirectXShaderCompiler

LinAlg HLK: Add Thread, Wave and ThreadGroup execution coverage

Open
#8,652 0 comments 0 reactions 1 assignee View on GitHub

@JoeCitizen is already working on this.

Since Jul 22, 2026.

Dominant language
C++
Stars
3.7k
Forks
900
Avg merge
2d 11h
Merged PRs (30d)
44

Description

Goal

Provide end-to-end HLK execution coverage for every LinAlg matrix scope permitted by the public dx::linalg API: Thread, Wave and ThreadGroup.

Tests must exercise the compiler and driver execution model for each scope, including lane distribution, group participation, synchronisation and scope-specific capability limits.

Why

Current coverage is concentrated on Wave-scope matrices, with limited Thread-scope MatVec and OuterProduct tests and no ThreadGroup execution coverage. A smoke test in one scope does not prove that the same operation family works in another scope because matrix representation, supported dimensions, group size, memory use and driver lowering differ.

Required coverage

  • Map each scope-sensitive operation issue to every scope exposed by the current public dx::linalg API. Exclude scope-independent operations such as MatrixQueryAccumulatorLayout (#8555).
  • Exercise the public dx::linalg API for all scope-level tests.
  • Thread scope:
    • cover MatVec, MatVecAdd, OuterProduct and applicable accumulation paths;
    • verify per-thread inputs and outputs remain independent across multiple threads.
  • Wave scope:
    • cover matrix construction, element access, load/store, conversion and matrix arithmetic;
    • exercise more than one supported Wave size where the capability API permits it;
    • verify lane-distributed Length/GetCoordinate/Get/Set behaviour;
    • cover public group-shared Matrix::InterlockedAccumulate using Wave-scope accumulator matrices, including contention from multiple Waves within one thread group where supported.
  • ThreadGroup scope:
    • add a complete load or construction, arithmetic and store/readback chain;
    • select supported group sizes using #8647 only where the corresponding operation query exposes group size;
    • for other legal ThreadGroup operations, do not invent a group-size applicability result;
    • do not require ThreadGroup-scope group-shared matrix accumulation while proposal 0035 and the public header disagree;
    • exercise matrices spanning multiple Waves where supported;
    • include required group-shared memory and synchronisation without relying on undefined ordering.
  • Dispatch more than one Wave or thread group where practical to expose indexing and cross-group contamination.
  • Use #8648 for dimensions and #8649 for independent expected values.

Acceptance criteria

  • Every operation issue documents each legal scope and its current execution coverage.
  • Thread scope has end-to-end public-API coverage for MatVec, MatVecAdd and OuterProduct.
  • Wave scope covers construction, memory, element access, conversion and matrix arithmetic families.
  • At least one ThreadGroup test performs a complete matrix operation chain and readback.
  • More than one supported Wave size is exercised for Wave operations where available.
  • ThreadGroup tests use a capability-supported group size and explicitly perform required synchronisation.
  • Multi-thread, multi-Wave or multi-group cases prove outputs do not alias or leak between execution units.
  • A scope or group size is classified as unsupported only when the relevant public query represents that axis and returns an unsupported result; otherwise legal public-API cases execute.
  • Group-shared matrix accumulation uses the public Wave-scope API; no direct-builtin ThreadGroup exception is required.
  • Scope-independent #8555 is excluded from the scope-coverage matrix.
  • Expected outputs are independently derived and diagnostics identify scope, Wave/group size and failing operation.
  • Existing scope-specific smoke coverage remains intact.

Initial operation mapping

  • Scope-sensitive construction, memory, element and conversion operations: #8545 through #8554, excluding scope-independent #8555.
  • Wave and ThreadGroup matrix arithmetic: #8556 through #8558.
  • Thread MatVec and MatVecAdd: #8559 and #8560.
  • Descriptor accumulation across its legal public scopes, Wave-scope group-shared accumulation, and Thread vector accumulation: #8561, #8562 and #8565.
  • Thread OuterProduct: #8563.
  • Scope-independent accumulator-layout query: #8555, tracked outside this issue's coverage matrix.

Existing validation work

Invalid scope/use combinations remain under the DXIL validation hierarchy #7840, including #8506. This issue covers legal runtime execution only.

Public references

Out of scope

  • Invalid scope validation tracked under #7840.
  • Exhaustive component-type and dimension combinations.
  • Performance benchmarking or comparing vendor implementations.
  • Publishing private device, driver or scheduling information.
  • Direct-builtin ThreadGroup-scope group-shared matrix accumulation while the proposal and public header disagree.

Assisted-by: GitHub Copilot

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.