Open AnastasiaStulova opened 4 years ago
I think this issue involves the OpenCL C version beyond OpenCL C 3.0, so it's not clear to me what is "must fix" in the OpenCL 3.0 spec. Is this mostly to ensure we don't paint ourselves into a corner and unintentionally prevent decoupling the OpenCL C version from the OpenCL API version?
To be clear, I'm fine having this issue, I just don't think it should be tagged "OpenCL 3 Must Fix" without knowing what it is that we must fix.
FWIW, I think we have an existence proof already of a decoupled OpenCL C version in that the OpenCL 2.1 and 2.2 APIs did not include an updated version of OpenCL C and continued to support OpenCL C 2.0. So, as long as we're equally confident we can revise the OpenCL C version ahead of the OpenCL API version - say by adding OpenCL C 3.0.X or OpenCL C 3.1 - there may be nothing to do here?
Thanks!
I think I was more thinking along the lines of adding some query mechanisms to check what versions of a language are supported. It could allow an implementation to support any future OpenCL C versions independently and unlocks separate evolution of the kernel language.
I think I was more thinking along the lines of adding some query mechanisms to check what versions of a language are supported.
I think we have this in OpenCL 3.0 - see CL_DEVICE_OPENCL_C_ALL_VERSIONS. Is this sufficient, or is more needed?
it seems sufficient. So what would be the format of the returned string: "OpenCL C 3.0, OpenCL C 2.0, etc"?
it seems sufficient. So what would be the format of the returned string: "OpenCL C 3.0, OpenCL C 2.0, etc"?
Great, that's good to hear.
The OpenCL 3.0 query returns an array of cl_name_version
structures. So, if an implementation supported say OpenCL C 1.0, OpenCL C 1.1, OpenCL C 1.2, and OpenCL C 3.0 (but not OpenCL C 2.0), it would return four structures, one for each supported OpenCL C version.
I have a sample demonstrating this query that I will try to publish soon.
The sample demonstrating this query can be found here:
https://github.com/bashbaug/SimpleOpenCLSamples/blob/master/samples/00_newqueries/main.cpp#L348
This is the output I am getting when I run this sample using a local build with OpenCL 3.0 support enabled:
$ ./newqueries
[snip]
Platform:
Name: Intel(R) OpenCL HD Graphics
Vendor: Intel(R) Corporation
Driver Version: OpenCL 3.0
Platform Numeric Version: 3.0.0
[snip]
Device[0]:
Type: GPU
Name: Intel(R) Gen9 HD Graphics NEO
Vendor: Intel(R) Corporation
Device Version: OpenCL 3.0 NEO
OpenCL C Version: OpenCL C 3.0
Driver Version: 20.25.0
Device Numeric Version: 3.0.0
OpenCL C (version): OpenCL C (1.0.0)
OpenCL C (version): OpenCL C (1.1.0)
OpenCL C (version): OpenCL C (1.2.0)
OpenCL C (version): OpenCL C (2.0.0)
OpenCL C (version): OpenCL C (3.0.0)
[snip]
Done.
Thanks!
It seems like there is nothing more to do here for OpenCL 3.0 specifically, but still open questions for the future, I'll move this to the maintenance project.
We need to provide mechanisms for evolving OpenCL C independently.
I guess it should be ok to allow sources compiled with OpenCL 2.0 in OpenCL 3.0 driver? I guess the checking of device supporting the features should be done manually? Could we also allow future standards (i.e. > 3.0) in OpenCL 3.0 drivers? This would be valuable to unlock the evolution of OpenCL C independently.
Note: This was discussed on OpenCL WG call on Jun 23