[LinAlg] Clarification needed in the Vector Matrix type combinations section
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- markdown
- Domain
- documentation
Research direction
Start in d3d/D3D12LinearAlgebraRuntimeFeatureSupport.md at the Vector-Matrix Operations section, then compare its table with the cooperative vector minimum support set and the linked linalg conversion proposal. Clarify whether the Vector column describes the HLSL-facing type or the implementation's input interpretation, and document when conversion may be required.
Written by the indexing model from the issue text.
Description
In the spec’s Vector-Matrix Operations section, it is unclear what the Vector column represents. As written, it appears to list the HLSL-facing vector type, but for Matrix x Vector Mul/MulAdd support, it seems more important to tabulate the types or interpretations that the operation actually supports natively, or via implementation-provided emulation.
In its current form, the table may imply direct support for the listed type even when a conversion step is required, and that conversion is not explicitly called out.
For comparison, the cooperative vector minimum support set used two separate columns: Input Type and Input Interpretation. That distinction was useful because Input Type described the HLSL type presented by the programmer, while Input Interpretation described the type actually consumed by the implementation, including cases where the implementation handled conversion to a non-native representation.
This section seems closer in meaning to Input Interpretation than to Input Type. It would also help to explicitly note in the surrounding commentary when support for a listed case may require an implicit conversion rather than reflecting native operand support in the multiply operation itself
- Dominant language
- HTML
- Stars
- 856
- Forks
- 181
- Avg merge
- 1m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
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.
More from microsoft/DirectX-Specs
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
microsoft/DirectX-Specs#244 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/DirectX-Specs#235 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
microsoft/DirectX-Specs#193 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
microsoft/DirectX-Specs#240 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
microsoft/DirectX-Specs#234 · 3 comments ·
All issues in microsoft/DirectX-Specs
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Ecosystem: ClawMetry — the Qwen Code reader is now free and open source (follow-up to #9294 / #9338) Opencategory/integration priority/P3 scope/documentation status/ready-for-human type/feature-request
Difficulty 1/5 Under an hour Newbie friendliness 84/100