Decouple evolution of OpenCL C

[AnastasiaStulova]

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

[bashbaug]

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!

[AnastasiaStulova]

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.

[bashbaug]

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?

[AnastasiaStulova]

it seems sufficient. So what would be the format of the returned string: "OpenCL C 3.0, OpenCL C 2.0, etc"?

[bashbaug]

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.

[bashbaug]

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!

[alycm]

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.