mem_channel extension test plan

[AmirIpma]

Created test plan for mem_channel extension.

[gmlueck]

I have some questions for @GarveyJoe, who I think is the original author of this extension:

• The extension says there is an aspect aspect::ext_intel_mem_channel. What does this aspect mean? Can we test it somehow in this test plan?

• One of the comments above notes that it does not make sense for the extension to use the OpenCL C type cl_uint, and I agree. Can this be changed in the extension spec to either unsigned int or uint32_t?

[keryell]

Thanks.

[GarveyJoe]

The extension says there is an aspect aspect::ext_intel_mem_channel. What does this aspect mean? Can we test it somehow in this test plan?

I believe our implementation responds to the aspect query by telling you if the device does something useful with the mem_channel property as opposed to telling you whether the device supports the extension (which all our devices can trivially support as the property is a hint). I think we can remove the aspect, but I think we're internally relying on it in the runtime so we'll have to change that code to not use the aspect.

One of the comments above notes that it does not make sense for the extension to use the OpenCL C type cl_uint, and I agree. Can this be changed in the extension spec to either unsigned int or uint32_t?

Yes, uint32_t would be fine. This is a relic from when the OpenCL types were defined in the SYCL spec, but since they no longer are, this should be updated.

[bader]

@gmlueck, ping.

[gmlueck]

The test plan looks OK, so I approved it.

We should make some changes to the extension spec (and implementation), though:

• Remove use of cl_uint from the API and use uint32_t instead.
• Either deprecate or remove the ext_intel_mem_channel aspect.

@GarveyJoe is this something your team can do soon, or should we open an internal tracker for this?