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
A question I wasn't able to answer using the spec is whether clSetKernelArg with (e.g.) a buffer will increase the reference count of the buffer and/or keep the buffer alive while it is set as an argument. The spec for clSetKernelArg doesn't seem to say much.
Perhaps the most informative section I found was the glossary entry on reference counts, which isn't very precise, but seems to require life support to enable in-flight operations to complete:
Implementations may also modify the reference count, e.g. to track attached objects or to ensure correct operation of in-progress or scheduled activities. The object becomes inaccessible to host code when the number of release operations performed matches the number of retain operations plus the allocation of the object. At this point the reference count may be zero but this is not guaranteed.
This has an impact on users of the interface, as it determines for what length of time they need to keep buffers alive. (just from set-arg to enqueue, or until kernel completion)
Empirically, PyOpenCL releases early, but has never had buffer life time issues until I tried the same thing with SVM. A "straw poll" of the reference counts (allowing for the fact that those might not be the full story) among implementations using this script yielded:
With respect to the question of "whether implementations keep buffers alive while it is set as kernel argument", I asked a similar question in #45 and the consensus was that:
buffers need to be kept alive by the implementation while executing a kernel accessing them
there is no need that the user-visible reference count be updated, i.e. the object management can be done in a different way which is not transparent to the user.
Thanks for the response! I agree that your summary of the consensus is supported by the spec. One area is not fully clear to me though: Is there any lifetime implication to simply setting the kernel argument? I suspect that the answer is no. (supported at least by looking at the implementation in pocl) If such a relationship were implied, this would of course affect the period after kernel enqueue as well, resulting in buffers potentially living much longer than needed.
I'll conclude that no such lifetime relationship is implied and close this. If anyone disagrees, I would of course be curious to hear about it.
A question I wasn't able to answer using the spec is whether
clSetKernelArg
with (e.g.) a buffer will increase the reference count of the buffer and/or keep the buffer alive while it is set as an argument. The spec forclSetKernelArg
doesn't seem to say much.Perhaps the most informative section I found was the glossary entry on reference counts, which isn't very precise, but seems to require life support to enable in-flight operations to complete:
This has an impact on users of the interface, as it determines for what length of time they need to keep buffers alive. (just from set-arg to enqueue, or until kernel completion)
Empirically, PyOpenCL releases early, but has never had buffer life time issues until I tried the same thing with SVM. A "straw poll" of the reference counts (allowing for the fact that those might not be the full story) among implementations using this script yielded:
x-ref: inducer/pyopencl#450
cc @matthiasdiener
The text was updated successfully, but these errors were encountered: