microsoft / microsoft/DirectXShaderCompiler
LinAlg HLK: Add Thread, Wave and ThreadGroup execution coverage
@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::linalgAPI. Exclude scope-independent operations such asMatrixQueryAccumulatorLayout(#8555). - Exercise the public
dx::linalgAPI 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::InterlockedAccumulateusing 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
- HLSL proposal 0035: Linear Algebra Matrix
- D3D12 Linear Algebra Runtime Feature Support
- Parent tracker #7841
- Capability handling #8647
- Dimension coverage #8648
- Independent oracle #8649
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.