You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
spencerpatty
changed the title
Consider avoiding references for SYCL objects
[oneMKL] Consider avoiding references for SYCL objects
Mar 27, 2024
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:
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?
The text was updated successfully, but these errors were encountered: