Clarifications to SPV_KHR_cooperative_matrix

kpet commented 10 months ago

Change the description of 'Memory Operand' operands to load/store instructions to make it clear that multiple words can be used (in line with the language used for OpLoad/OpStore).
Require all instructions that have a cooperative matrix object as an operand or produce a cooperative matrix object result only be executed in uniform control flow within the scope of the matrix type.
Require the constituent provided to OpCompositeConstruct to be the same for all invocations in the scope of the cooperative matrix.
Require the operands to arithmetic and conversion instructions operating on cooperative matrix objects to be the same for all invocations within the scope of the cooperative matrix.
Clarify when Stride and Memory Operand operands can be provided.
Clarify when referring to cooperative matrix types or objects/values of that type in the description of conversion instructions.

Fixes #208 Fixes #211

kpet commented 10 months ago

Here's a first attempt at addressing the outstanding clarification requests on SPV_KHR_cooperative_matrix (cc @alan-baker, @jeffbolznv).

kpet commented 10 months ago

@alan-baker @jeffbolznv I've updated the PR to reflect the discussions at the F2F. PTAL.

kpet commented 9 months ago

@alan-baker I'm guessing you're referring to these rules:

All the operands to this instruction must be dynamically uniform within the 'Scope' of the cooperative matrix.

I think the intent is clear from this wording but we may be able to improve the language. How about the following:

All the operands to this instruction must be dynamically uniform within every instance of the 'Scope' of the cooperative matrix.

kpet commented 9 months ago

@alan-baker I've made the change. This should now be ready to go.

bashbaug commented 9 months ago

Merging as discussed in the December 6th teleconference.

KhronosGroup / SPIRV-Registry