Xilinx / Xilinx/XRT

OpenCL kernels keep reference count of their arguments until they are released

Open
#4,677 7 comments 2 reactions 1 assignee View on GitHub

@stsoe is already working on this.

Since Jul 7, 2021.

Dominant language
C++
Stars
686
Forks
549
Avg merge
2d 4h
Merged PRs (30d)
70

Description

When a buffer is created using the OpenCL API, its reference count is set to 1. Upon invocation of clSetKernelArg(kernel, index, buffer) function, the buffer's reference count is incremented. However upon completion of the kernel execution task, the reference count is not decremented. A call to clReleaseMemObject(buffer) won't actually release the buffer since its reference count will not be zero.

Also Khronos states the following under 'Notes' section:

"Implementations shall not allow cl_kernel objects to hold reference counts to cl_kernel arguments, because no mechanism is provided for the user to tell the kernel to release that ownership right. If the kernel holds ownership rights on kernel args, that would make it impossible for the user to tell with certainty when he may safely release user allocated resources associated with OpenCL objects such as the cl_mem backing store used with CL_MEM_USE_HOST_PTR."

Finally, an example case that produces a CL_OUT_OF_RESOURCES error:

  1. PLRAM of 2MB available
  2. Allocate buffer A (2MB) in PLRAM
  3. Invoke and await execution of OpenCL kernel using the buffer allocated in (2)
  4. Release buffer A
  5. Allocate buffer B of size <= 2MB in PLRAM -- (CL_OUT_OF_RESOURCES)

[ Tested with many XRT versions including 2.9.0 ]

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.