uxlfoundation / oneAPI-spec

oneAPI Specification source files
https://spec.oneapi.com
Other
182 stars 102 forks source link

[oneMKL] Consider avoiding references for SYCL objects #524

Open Rbiessy opened 3 months ago

Rbiessy commented 3 months ago

In the update for the sparse specification PR we have been discussing with @spencerpatty and @gajanan-choudhary that we should not take SYCL buffers by reference.

From the SYCL specification:

Buffers are reference-counted. When a buffer value is constructed from another buffer, the two values reference the same buffer and a reference count is incremented. When a buffer value is destroyed, the reference count is decremented. Only when there are no more buffer values that reference a specific buffer is the actual buffer destroyed and the buffer destruction behavior defined below is followed.

Taking the buffer by reference adds a constraint for the user as they have to keep them alive themselves while the SYCL specification suggests that this should not be needed. This makes it harder to use the buffer interface.

For the new sparse specification, it so happens that we can take buffers by value and still support the MKL backends that take buffers by reference by storing buffers in handle types (which is already needed for cuSPARSE and rocSPARSE backends). I don't think this can be easily done for all the domains today.

A similar logic applies to the SYCL queue which could be given as value, although in practice this is less of an issue for the user in my experience. This cannot easily be done in oneMKL interface without first changing the MKL backends however.

Are there specific reasons for using references for SYCL queues and buffers? If not, would it make sense to remove the queue and buffer references from the close-source MKL libraries and then from oneMKL interface? Is it acceptable for the sparse domain to not take buffers by reference even if that means losing some consistency?