LinAlg HLK: Add atomic accumulation collision and concurrency coverage

Goal

Provide HLK execution coverage for the public dx::linalg::InterlockedAccumulate matrix and vector APIs under both non-colliding and contended execution.

Tests must detect lost updates, incorrect addressing, unsupported destination handling and scope-specific synchronisation defects in third-party compiler and driver implementations.

Why

Current accumulation tests provide basic operation coverage but do not prove atomic behaviour under contention. A driver can produce correct results when each invocation writes a unique destination while still losing or corrupting updates when multiple threads, Waves or thread groups accumulate to the same location.

Descriptor and group-shared destinations also expose different capability and scope rules.

Required coverage

• Exercise the public matrix and vector InterlockedAccumulate APIs.
• Matrix accumulate to descriptor:
  • cover unique destinations as a non-collision baseline;
  • cover multiple invocations accumulating to the same destination;
  • cover contention within a Wave, across Waves and across thread groups where supported.
• Matrix accumulate to group-shared memory:
  • use Wave-scope matrix objects through the current public dx::linalg API; multiple Waves may contend within one thread group, but ThreadGroup-scope matrix accumulation is not an HLK requirement until the proposal and public header agree;
  • cover unique and shared destinations within a thread group;
  • use explicit synchronisation before readback;
  • exercise more than one Wave per group where supported.
• Vector accumulate to descriptor:
  • cover unique destinations and shared destinations;
  • distinguish vector element addressing from matrix addressing.
• Begin from both zero and non-zero destination values to prove additive rather than replacement behaviour.
• Use exact integer inputs where supported to detect every lost update.
• For floating-point paths, choose initial values, increments and invocation counts for which every legal atomic ordering and every precision mode permitted by the advertised capability flags produces the same representable result. If no useful order-invariant oracle exists, defer that permutation rather than accepting an empirical tolerance.
• Select destination kind and component types using the atomic support reported through #8647.
• Use guard regions and bounds cases from #8651 without duplicating that issue's addressing matrix.
• Use #8649 for independent expected totals and diagnostics.

Acceptance criteria

• Descriptor matrix accumulation has both collision and non-collision cases.
• Group-shared matrix accumulation has both collision and non-collision cases where supported.
• Vector descriptor accumulation has both collision and non-collision cases.
• At least one collision case spans multiple Waves or thread groups for descriptor memory.
• At least one group-shared collision case spans multiple Waves in one group where supported.
• Exact integer cases detect any lost or duplicated update.
• Every floating-point collision case documents why all legal accumulation orders and permitted precision modes produce the same expected result; no implementation-tuned tolerance is used.
• Group-shared matrix accumulation uses the public Wave-scope API and may span multiple Waves within one thread group.
• ThreadGroup-scope group-shared matrix accumulation is not required while it lacks a consistent public API contract.
• Tests cover zero and non-zero initial destination values.
• Unsupported destination/type combinations follow #8647 rather than being reported as passing tests.
• Failure logs include destination kind, scope, invocation count, initial value, expected total and actual total.

Operation mapping

• MatrixAccumulateToDescriptor #8561.
• MatrixAccumulateToMemory #8562.
• VectorAccumulateToDescriptor #8565.

Existing validation work

Argument, scope, layout, alignment and groupshared-type validation remain under #7840, including #8505, #8507, #8635, #8636 and #8645. Runtime bounds and guard-region coverage remain under #8651.

Public references

• HLSL proposal 0035: Linear Algebra Matrix
• D3D12 Linear Algebra Runtime Feature Support
• Parent tracker #7841
• Capability handling #8647
• Independent oracle #8649
• Memory addressing and bounds #8651
• Scope coverage #8652

Out of scope

• Atomic performance benchmarking.
• Requiring a specific execution order where the specification does not define one.
• Invalid-operation validation tracked under #7840.
• Exhaustive type, shape and contention-count combinations.
• Publishing private hardware atomic capabilities.
• Direct-builtin ThreadGroup-scope group-shared matrix accumulation while proposal 0035 and the public dx::linalg header disagree.

Assisted-by: GitHub Copilot