Skip to content

Conversation

@V-FEXrt
Copy link
Collaborator

@V-FEXrt V-FEXrt commented Dec 31, 2025

Introduces dx.types.MatrixRef as a legal DXIL type without using it anywhere. This doesn't expose the type to higher levels yet so it's not possible to write a meaningful test for the PR. The very next PR in the stack will have tests that emit the type and test this code path.

The DXIL ops that operate over the MatrixRef type have been updated to use the new type

include/dxc/DXIL/DxilInstructions.h is entirely generated code and all the case updates to lib/DXIL/DxilOperations.cpp is generated code.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 31, 2025

✅ With the latest revision this PR passed the Python code formatter.

Copy link
Collaborator

@bob80905 bob80905 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood that this type can't be emitted yet, though I wonder if there are IR-level validation tests that can test the new type.

// Operand indexes
enum OperandIdx {
arg_matrixRef = 1,
arg_matrix = 1,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand you've changed the underlying type from i32 to matrixref, a new dxil type.
But why should these names change from matrixref to matrix?
Wouldn't it be better to leave the function/variable names as is, they are accurate no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No real technical reason, just a style sense/gut feeling I guess?

the signature @dx.op.createMatrix(MatrixRef matrix) looks nicer to me than @dx.op.createMatrix(MatrixRef matrixRef) must I'm happy to revert if anyone strongly disagrees

@V-FEXrt
Copy link
Collaborator Author

V-FEXrt commented Dec 31, 2025

I wonder if there are IR-level validation tests that can test the new type.

Yeah, I was thinking about this too. I could hand write some DXIL IR with the type in it but since that's the final output what do I do after that? Maybe I could pass the IR into the DXIL Validator but that's not actually going to test any of the code changes in this PR which doesn't feel all that useful either especially when the very next commit has all the tests needed to hit this functionality properly.

If its useful to see those tests early they are available at c689b9a

Honestly I still see this PR as another "pre-reserve stuff for the actual work to come" type of PR but its getting to the fuzzy parts and I'd fully understand if someone disagreed with that claim

Copy link
Collaborator

@bob80905 bob80905 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

3 participants