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.354% (-0.06%) from 86.41%
when pulling 5fb74e6 on sommerlukas:raw-kernel-arg
into 3e74087 on IntelPython:master.

[AlexanderKalistratov]

auto RawArg = unwrap<RawKernelArgData>(Ref);
delete[] RawArg->bytes;
delete RawArg;

[sommerlukas]

I changed the approach slightly to hold the data in a std::vector inside RawKernelArgDataTy, because delete[] RawArg->bytes gave a warning about incomplete delete.

[AlexanderKalistratov]

Sorry. I've misled you in my previous comment about unique_ptr. To make it work it should be something like this:

        auto rawData =
            std::unique_ptr<unsigned char[]>(new unsigned char[count]);
        std::memcpy(rawData.get(), bytes, count);
        auto RawKernelArg = std::unique_ptr<RawKernelArgData>(
            new RawKernelArgData{rawData.get(), count});
        rka = wrap<RawKernelArgData>(RawKernelArg.get());
        RawKernelArg.release();
        rawData.release();

Otherwise rawData would leak if new RawKernelArgData{rawData.release(), count} throws.

[sommerlukas]

I changed the approach slightly to hold the data in a std::vector inside RawKernelArgDataTy.

[AlexanderKalistratov]

@sommerlukas this is a good idea, but I'm not sure about this. As far as I understand this part of API should be C-api, so we can't use c++ classes and/or constructors/destructors.
But I'm not sure about it.
Let's ask @ndgrigorian

[sommerlukas]

My understanding was that only the interface of libsyclinterface needs to be C-like. We use std::vector in other parts of libsyclinterface, e.g., here.

But happy to wait for confirmation from @ndgrigorian.

[AlexanderKalistratov]

std::vector is used indeed. The same as std::unique_ptr. But it is in .cpp file. Not in header file which actually has .h extension and not .hpp and extern "C" declaration (https://github.com/IntelPython/dpctl/pull/2038/files#diff-bc26687692ae358c908d9587e3abdfab35454bc0fcab36f47cf59af185e6b5fdR40)

[ndgrigorian]

@AlexanderKalistratov is correct, and this is the reason why the dpctl-typed opaque pointers for std::vectors exist (i.e., DPCTLDeviceVector, etc.)

We could add another of such types for this implementation though.

[ndgrigorian]

@sommerlukas
Master now has a fix for nightly build, so please merge or rebase on master so the tests run on nightly compiler

[ndgrigorian]

These seem to be causing the test failures

[ndgrigorian]

Unfortunately, the use of copying and cstring also brought about another problem, namely, that this is now a class with a constructor under extern "C" linkage.

Builds fail but also, it won't be constructible from C with this constructor due to name-mangling issues.

[sommerlukas]

Thanks for the feedback @ndgrigorian @AlexanderKalistratov!

After taking a look at how the opaque pointers for other std::vector work, I've changed the approach: I've removed RawKernelArgDataTy entirely, so that the opaque pointer (DPCTLSyclRawKernelArgRef) now directly points to std::vector<unsigned char>. That way, we can avoid defining a struct with std::vector in the header, so the offending includes of <vector> and <cstring> are now removed.