[kpet]

No description provided.

[kpet]

This PR currently captures the working draft for the coming cl_khr_cooperative_matrix extension. The OpenCL working group is still making minor changes to the specification. We decided to continue doing this in public so we could engage with a wider set of stakeholders. Feedback welcome!

[MrSidims]

Suggested change

	For *OpTypeCooperativeMatrixMulAddKHR*, the operands must match a supported
	For *OpCooperativeMatrixMulAddKHR*, the operands must match a supported

[tvvikram]

Should these be OpTypeInt xx 1 to indicate signedness?

[svenvh]

Probably not, as the OpenCL SPIR-V Environment Specification Section 4 "Validation Rules" says:

For all OpTypeInt integer type-declaration instructions:

• Signedness must be 0, indicating no signedness semantics.

[tvvikram]

Got it, thanks!

[svenvh]

...variant_khr should go after ...component_type_khr as the former (a struct type) contains elements of the latter, and the wrong order breaks the generated header. I'd suggest putting the struct type after the cl_uint types, like so:

Suggested change

	<type name="cl_device_cooperative_matrix_variant_khr"/>
	<type name="cl_device_cooperative_matrix_component_type_khr"/>
	<type name="cl_device_cooperative_matrix_info_khr"/>
	<type name="cl_device_cooperative_matrix_component_type_khr"/>
	<type name="cl_device_cooperative_matrix_info_khr"/>
	<type name="cl_device_cooperative_matrix_variant_khr"/>

[anun333]

Feedback on floating-point accumulation, for this draft and the OpenCL C companion (#1627).

SPV_KHR_cooperative_matrix leaves two things to the client API: "The order of the operations is implementation-dependent" and "The internal precision of floating-point operations is defined by the client API". The environment section in this PR does not define the internal precision, and #1627 adds to section 7.4 that coop_mat_mulAdd "performs its operations in an implementation-dependent order and internal precision". So for a floating-point variant an application cannot tell what accuracy it gets, or whether two devices, or two runs on one device, give the same result. (Integer variants are already fully defined.)

A small suggestion while cl_device_cooperative_matrix_variant_khr is still a draft: add a bitfield member that reports the accumulation behaviour of each variant, for example:

• CL_DEVICE_COOPERATIVE_MATRIX_ACCUMULATION_EXACT_KHR: each element of the result is the exact value of the dot product plus the element of C, rounded once to the result type (round to nearest, ties to even). Results are then the same on every device that reports it, whatever order the hardware uses internally.
• CL_DEVICE_COOPERATIVE_MATRIX_ACCUMULATION_REPEATABLE_KHR: the same inputs give the same result on this device on every execution.

A device that sets neither flag loses nothing, and the query needs no hardware. Libraries can use it to choose an algorithm or state an error bound, and applications that need repeatable results (regression tests, safety cases) can check for it instead of finding out by testing. RISC-V's matrix extension draft (Zvvm, in architecture review) takes a similar line: each implementation must disclose its accumulation parameters. Adding a member now avoids a separate query once the struct has shipped.

AI tool usage: written with the assistance of Claude Code; the quotations are from the specifications and drafts linked.