[SYCL] Support sycl_khr_default_context - #15645

sycl-cts: KhronosGroup/SYCL-CTS#960

This patch is intended to be merged only when there are sycl-cts tests and the ratified khr extension.

It looks like those tests are for the oneAPI extension ext_oneapi_get_default_context not for the KHR extension khr_get_default_context. We should have tests for the KHR extension.

It looks like those tests are for the oneAPI extension ext_oneapi_get_default_context not for the KHR extension khr_get_default_context. We should have tests for the KHR extension.

@gmlueck as far as I understand you said that there is no sense to have sycl_ext_oneapi_default_context tests and we should add sycl_khr_oneapi_default_context instead. I thought Michael will update his PR to reflect it. Am I wrong? @0x12CC

@gmlueck as far as I understand you said that there is no sense to have sycl_ext_oneapi_default_context tests and we should add sycl_khr_oneapi_default_context instead. I thought Michael will update his PR to reflect it. Am I wrong? @0x12CC

Oh, I see. If @0x12CC is going to update KhronosGroup/SYCL-CTS#960, then everything is good.

Sorry, I missed this discussion earlier. I've updated KhronosGroup/SYCL-CTS#960 to test the KHR extension instead.

@KornevNikita now that KhronosGroup/SYCL-CTS#960 is updated, is there some way for you to check that the changes in this PR pass those tests? The Khronos SYCL WG is waiting for us to say that we have an implementation that passes those tests. Once we can say that, I think we can move forward with finalizing the KHR specification.

@gmlueck is it enough to say "yes, we can pass them" or we need some result available online?

@gmlueck is it enough to say "yes, we can pass them" or we need some result available online?

I think the WG will trust us, so I think it is sufficient to say "yes, we pass them". Of course, we really should run the tests to make sure that they do pass.

@gmlueck okay, then I'll check that and provide an update.

@gmlueck yes, we can pass new tests with this patch.

@gmlueck the spec change was merged, now this also can be merged, right?

@gmlueck the spec change was merged, now this also can be merged, right?

The spec wasn't ratified yet. That will happen (probably) in the middle of January. It's very unlikely that the spec will change between now and the middle of January, so it's probably safe to merge this PR. However, there is still a chance that it might change. Is it difficult to keep the PR open until the spec is officially ratified?

@gmlueck the spec change was merged, now this also can be merged, right?

The spec wasn't ratified yet. That will happen (probably) in the middle of January. It's very unlikely that the spec will change between now and the middle of January, so it's probably safe to merge this PR. However, there is still a chance that it might change. Is it difficult to keep the PR open until the spec is officially ratified?

Of course, I just wanted to check how the process works.

@KseniyaTikhomirova could you please take a look?

what will happen with ext_oneapi_get_default_context then? Will it be deprecated?

Good question. I think that deprecating it is the right way to go, but we need to double-check that it doesn't provide anything extra besides what we have in the khr counterpart and still want to maintain.

@KseniyaTikhomirova @AlexeySachkov could you please merge?

@KornevNikita I do not have privileges to merge.
@intel/llvm-gatekeepers could you please merge this PR?

what will happen with ext_oneapi_get_default_context then? Will it be deprecated?

Good question. I think that deprecating it is the right way to go, but we need to double-check that it doesn't provide anything extra besides what we have in the khr counterpart and still want to maintain.

I also agree that we should deprecate the oneapi version. The oneapi version doesn't have any "extra" functionality beyond the KHR version.

I've created a draft PR to deprecate it: #17135