[SM6.10] Collect and Validate LinAlg PSV0 runtime data

[Ashley Coleman (V-FEXrt)]

• Collects LinAlg construction, multiply, outer-product, and accumulate-store usage
• Validates the collected LinAlg data

Fixes #7843

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

🟡 Changes recommended

Shape-reference payloads can evade module-content validation, and release-note coverage is missing.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds SM 6.10 LinAlg runtime-data collection, PSV0 serialization, validation, and coverage tests.

Changes:

• Collects LinAlg construction and operation metadata.
• Validates serialized LinAlg PSV0 records and alignment.
• Adds PSV dump tests across supported operations.

File summaries

File	Description
lib/DxilContainer/DxilContainerAssembler.cpp	Collects LinAlg runtime metadata.
lib/DxilValidation/DxilContainerValidation.cpp	Validates LinAlg PSV0 data.
tools/clang/test/DXC/dumpPSV_LinAlg.hlsl	Tests combined metadata.
tools/clang/test/DXC/dumpPSV_LinAlgAccumulate.hlsl	Tests accumulation metadata.
tools/clang/test/DXC/dumpPSV_LinAlgConstructions.hlsl	Tests construction metadata.
tools/clang/test/DXC/dumpPSV_LinAlgMatVec.hlsl	Tests matrix-vector metadata.
tools/clang/test/DXC/dumpPSV_LinAlgMatrixMultiply.hlsl	Tests matrix-multiply metadata.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Jesse Natalie (jenatali)]

One bot comment that seems "nice to have" but otherwise, LGTM.

[Joshua Batista (bob80905)]

Do we need to add a 4th loop here for threadmatrixvectormultiply?

[Ashley Coleman (V-FEXrt)]

threadmatrixvectormultiply doesn't have any shapes information to verify

DirectXShaderCompiler/include/dxc/DxilContainer/DxilPipelineStateValidation.h

Line 236 in 397ffb2

struct PSVLinAlgThreadMatrixVectorMultiply0 {

[Joshua Batista (bob80905)]

Curious: Isn't the & bitmask method better?

[Ashley Coleman (V-FEXrt)]

yeah, I wasn't super happy with the readibility of foo & 3 == 0 but the function name fixes that issue well enough to keep &

[Copilot]

🟡 Changes recommended

Unsigned LinAlg vector operations currently produce incorrect signed PSV capability records.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

Previously missed (3) — in code that hasn't changed since the last review.

lib/DxilContainer/DxilContainerAssembler.cpp:970

• Unsigned outer-product inputs are recorded as signed. HLSL's OuterProduct accepts uint16_t, uint, and uint64_t independently of the result component type, but LLVM integer types do not retain signedness and this call uses the helper's IsSigned=true default. For example, OuterProduct<ComponentType::F32>(uint4, uint4) will emit VectorInputType=I32 instead of U32, so the PSV advertises the wrong runtime capability. Signedness needs to be preserved by lowering or otherwise encoded in DXIL and supplied here.
  lib/DxilContainer/DxilContainerAssembler.cpp:1018
• Unsigned vector accumulate operations are also classified as signed because the helper's default is used after LLVM has erased integer signedness. The public InterlockedAccumulate template accepts unsigned arithmetic vectors, so an operation on uint4 produces an I32 accumulate-store record rather than U32. Preserve an explicit component type through lowering and use it here so runtime support is queried for the actual type.
  lib/DxilValidation/DxilContainerValidation.cpp:539
• When a record differs, both sides of the mismatch diagnostic are currently the same index, so the error reports equivalent PSV0 and module content even though they differ. Describe the actual and regenerated records distinctly (or print their fields) so the validation failure identifies what mismatched.

lib/DxilContainer/DxilContainerAssembler.cpp:1177

• This adds user-visible PSV0 capability data and validation for experimental Shader Model 6.10, but the PR does not update the release notes. Please add an entry under docs/ReleaseNotes.md → Upcoming Preview Release → Experimental Shader Model 6.10, or point to the related PR that will provide the shared release-note coverage.

      if (m_PSVInitInfo.PSVVersion > 3) {
        LoadLinAlgMatrixInfos();
        CollectLinAlgRuntimeInfo();

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🔵 Needs a closer look

Negative validation coverage and the required release-note entry are missing.

Review details

Suppressed comments (2)

lib/DxilValidation/DxilContainerValidation.cpp:569

• The new LinAlg PSV validation has no negative coverage: the dump tests only verify data generated by the writer, so regressions that accept a corrupted count, record, or shape-index sequence would still pass. Please add a ValidationTest-style container mutation test that alters these fields and verifies ContainerPartMatches is emitted.

  auto VerifyRecord = [&](StringRef Name, uint32_t I, const auto &Record,
                          const auto *ExpectedRecord) {
    if (ExpectedRecord && memcmp(&Record, ExpectedRecord, sizeof(Record)) != 0)
      EmitMismatchError(GetRecordName(Name, I), GetRecordBytes(Record),
                        GetRecordBytes(*ExpectedRecord));

lib/DxilContainer/DxilContainerAssembler.cpp:1178

• This introduces user-visible SM 6.10 compiler/container behavior, but the PR does not add the release note required for significant new hardware/language support. Please add a concise entry under docs/ReleaseNotes.md → ### Upcoming Release (or point to the shared release note if this is part of a tracked multi-PR effort).

      if (m_PSVInitInfo.PSVVersion > 3) {
        LoadLinAlgMatrixInfos();
        CollectLinAlgRuntimeInfo();
      }

• Files reviewed: 7/7 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Ashley Coleman (V-FEXrt)]

Unsigned outer-product inputs are recorded as signed. HLSL's OuterProduct accepts uint16_t, uint, and uint64_t independently of the result component type, but LLVM integer types do not retain signedness and this call uses the helper's IsSigned=true default. For example, OuterProductComponentType::F32(uint4, uint4) will emit VectorInputType=I32 instead of U32, so the PSV advertises the wrong runtime capability. Signedness needs to be preserved by lowering or otherwise encoded in DXIL and supplied here.

Was a suppressed comment but this is actually a pretty big deal and has a notable impact on the implementation. Fixing that is actually a quite large change that is not going to happen in this PR. I'm calling it out here for more visibility but the fix will have to come in a followup PR

[Copilot]

🔵 Needs a closer look

The user-visible SM 6.10 behavior needs release-note coverage.

Review details

Suppressed comments (1)

lib/DxilContainer/DxilContainerAssembler.cpp:1177

• This adds user-visible PSV0 metadata and validation for experimental SM 6.10, but the PR does not update the release notes. Please add an entry under Upcoming Preview Release → Experimental Shader Model 6.10 in docs/ReleaseNotes.md, or point to the related PR that will provide shared release-note coverage.

      if (m_PSVInitInfo.PSVVersion > 3) {
        LoadLinAlgMatrixInfos();
        CollectLinAlgRuntimeInfo();

• Files reviewed: 8/8 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Copilot review overview

🟡 Changes recommended

Unsigned inputs and unresolved matrix provenance can produce incorrect PSV metadata, and an unguarded opcode decode can crash validation.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Verify DXIL-op calls before decoding opcodes · New
• The new validation path has no negative validation test. The added dump tests verify writer output,…

Previously missed (2)

In code that hasn't changed since last review

Handle unresolved matrix origins in provenance analysis

lib/​DxilContainer/​DxilContainerAssembler.cpp:833

The provenance walk silently stops at any matrix value other than a phi, select, copy-convert, or direct descriptor load. A valid no-inline helper can receive a thread matrix as a function argument and perform the mat-vec operation; in that function the worklist reaches an Argument, so a caller's RowMajor or MulOptimalTranspose load is reported with Flags == 0 (which means MulOptimal-only). Please handle interprocedural/otherwise unresolved origins, or conservatively set both layout flags, and cover the no-inline case.

Preserve unsigned types when serializing outer-product inputs

lib/​DxilContainer/​DxilContainerAssembler.cpp:970

Unsigned integer outer-product inputs are serialized as signed types. LLVM integer/vector types are signless, and this call uses the helper's default IsSigned = true, while the public OuterProduct template accepts uint16_t, uint32_t, and uint64_t inputs independently of OutTy. For example, a uint4 input is therefore reported as I32 instead of U32. Preserve the input interpretation during lowering (or otherwise encode it in DXIL) and use it here.

This issue also appears on line 1017 of the same file.