Add support for raw_kernel_arg extension

[sommerlukas]

Add support for the DPC++ SYCL extension raw_kernel_arg that allows to pass a binary blob as kernel arguments.

This is for example useful if the kernel uses a struct as kernel parameter, but is loaded from SPIR-V and the argument type is unknown for set_arg.

The implementation follows #1984.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• 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?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?
• If this PR is a work in progress, are you opening the PR as a draft?

[coveralls]

coverage: 86.307% (-0.07%) from 86.379%
when pulling 3017074 on sommerlukas:raw-kernel-arg
into 67317b0 on IntelPython:master.

[AlexanderKalistratov]

RawKernelArgDataTy doesn't owns bytes which rises a lot of questions.
Who's owning bytes?
Who's responsible for deleting bytes?
How long do we need to keep bytes alive?

It is probably better to make RawKernelArgDataTy to own bytes and allocate and copy data on construction of RawKernelArgDataTy.

[sommerlukas]

I had considered having RawKernelArgDataTy own the money and copy on construction. My reasoning to not do that was that the current approach allows the modification of the data in the time between construction of the raw kernel arg and the kernel launch. If you prefer to have raw kernel arg own the data, I can change that, no problem.

[ndgrigorian]

I think I favor copying as well, especially because, while the overload from an object exposing buffer is pretty unambiguous (though the GC is a concern), the nbytes and pointer constructor or using the C API directly have a lot of ownership concerns.

[AlexanderKalistratov]

Could you please use unique_ptr here?

auto RawKernelArg = std::make_unique(new RawKernelArgData{bytes, count});
rka = wrap<RawKernelArgData>(RawKernelArg.release());

[sommerlukas]

I'm not sure I understand the advantage here. We're still allocating with new and we're immediately releasing the unique_ptr in the second line. Is there any benefit of this, e.g., exception handling?

[sommerlukas]

It also deviates from the code style used in the rest of libsyclinterface, e.g., here.

[ndgrigorian]

Yes, biggest advantage would be not having to delete it in case an exception is caught.

If an exception did occur here, we would need delete rka below in the catch block.