Updated the DPCTLKernelArgType enum values to be aligned with C++11 types

[diptorupd]

• Have you provided a meaningful PR description?

Previously, the DPCTLKernelArgType had a mix of C99 types (long, long long, etc.) and C++ types (size_t, int8_t). After these changes the enum values have been updated to only include the C++11 integer types: [u]int[8|16|32|64]_t, float and double.

A Python enum corresponding to the libsyclinterface C++ enum was also added to make it simpler to get the types from Python. It will help numba-dpex not have to hard code magic values in its code base.

The DPCTLQueue_SubmitRange and DPCTLQueue_SubmitNdRange functions were updated to silence compiler warnings.

Unit tests were added for verifying the submission of one-dimensional range kernels each with a different kernel argument type.

NOTE: DPCTLQueue_SubmitNdRange will not be tested as part of this PR. I will be be adding those tests as part of the local accessor support as a kernel argument PR.

• Have you added a test, reproducer or referred to an issue with a reproducer?

New libsyclinterfrace unit tests to test for all possible kernel argument types, including a negative test.

• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• If this PR is a work in progress, are you opening the PR as a draft?

[github-actions]

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

[github-actions]

Array API standard conformance tests for dpctl=0.17.0dev0=py310h15de555_60 ran successfully.
Passed: 906
Failed: 0
Skipped: 94

[github-actions]

Array API standard conformance tests for dpctl=0.17.0dev0=py310h15de555_62 ran successfully.
Passed: 906
Failed: 0
Skipped: 94

[coveralls]

coverage: 87.717% (+0.3%) from 87.449%
when pulling 554541f on update/dpctl_kernelargtypes
into 786f7fc on master.

[github-actions]

Array API standard conformance tests for dpctl=0.17.0dev0=py310h15de555_62 ran successfully.
Passed: 906
Failed: 0
Skipped: 94

[github-actions]

Array API standard conformance tests for dpctl=0.17.0dev0=py310h15de555_62 ran successfully.
Passed: 906
Failed: 0
Skipped: 94

[oleksandr-pavlyk]

Probably the right way of integrating SYCL and cmake would be to use find_package(IntelSycl), but this could be done in a separate PR.

[diptorupd]

These changes are in the helper script, let us fix in separate PR. I just needed to get the helper script working once more to develop on libsyclinterface.

[oleksandr-pavlyk]

Thank you @diptorupd

It would also be useful to document in the comment how multiple SPVs are compiled into a single one.

Also, if one is on a machine without support for double type, IGC route of generation of the kernel for double won't work, how does one generate the kernel then?

[oleksandr-pavlyk]

Thank you @diptorupd

It would also be useful to document in the comment how multiple SPVs are compiled into a single one.

Also, if one is on a machine without support for double type, IGC route of generation of the kernel for double won't work, how does one generate the kernel then?

Clarifying my own misunderstanding. When C++ is compiled with default -fsycl-split-device-code value, kernel bundles are formed as per aspect required, so a kernel function would contain kernels specialized for all types but float16 and float64 and two more kernel bundles may be formed, one for float16 and one for float64.

This way, JIT-ting the generic bundle would work for all devices, regardless of the aspect supported. Hence no manual bundling of multiple SPV files is required.

The recipe to extract SPV from executable produced by DPC++ assumes IGC is available. An alternative approach is to use SYCL_DUMP_IMAGES environment variable supported by oneAPI DPC++, which would dump all offload sections of fat binary to the current working directory.

With these clarified, the PR is good to go in, although I'd still prefer if these notes were copied into the source of the test file.

[diptorupd]

Thank you @diptorupd
It would also be useful to document in the comment how multiple SPVs are compiled into a single one.
Also, if one is on a machine without support for double type, IGC route of generation of the kernel for double won't work, how does one generate the kernel then?

Clarifying my own misunderstanding. When C++ is compiled with default -fsycl-split-device-code value, kernel bundles are formed as per aspect required, so a kernel function would contain kernels specialized for all types but float16 and float64 and two more kernel bundles may be formed, one for float16 and one for float64.

This way, JIT-ting the generic bundle would work for all devices, regardless of the aspect supported. Hence no manual bundling of multiple SPV files is required.

The recipe to extract SPV from executable produced by DPC++ assumes IGC is available. An alternative approach is to use SYCL_DUMP_IMAGES environment variable supported by oneAPI DPC++, which would dump all offload sections of fat binary to the current working directory.

With these clarified, the PR is good to go in, although I'd still prefer if these notes were copied into the source of the test file.

I have updated the comment in the test file.

[oleksandr-pavlyk]

Thank you @diptorupd , LTGM!

[github-actions]

Array API standard conformance tests for dpctl=0.17.0dev0=py310h15de555_67 ran successfully.
Passed: 906
Failed: 0
Skipped: 94

[ZzEeKkAa]

Sorry for being late, but why if instance(arg, ....) still uses old style types?