[opencl plugins] If no out of order queue support, then temporary queues get created that never get deleted. #11156
Comments
This is due to an issue with dpc++ where it can leave temporary queues unreleased. This can then have the effect on the closing down of the device. This is resolved by registering and deregistering the queues on creation and deletion and then releasing any queues which still have an external reference when `atexit` is called. This should be reviewed when intel/llvm#11156 is fixed.
This is due to an issue with dpc++ where it can leave temporary queues unreleased. This can then have the effect on the closing down of the device. This is resolved by registering and deregistering the queues on creation and deletion and then releasing any queues which still have an external reference when `atexit` is called. This should be reviewed when intel/llvm#11156 is fixed.
This is due to an issue with dpc++ where it can leave temporary queues unreleased. This can then have the effect on the closing down of the device. This is resolved by registering and deregistering the queues on creation and deletion and then releasing any queues which still have an external reference when `atexit` is called. This should be reviewed when intel/llvm#11156 is fixed.
This is due to an issue with dpc++ where it can leave temporary queues unreleased. This can then have the effect on the closing down of the device. This is resolved by registering and deregistering the queues on creation and deletion and then releasing any queues which still have an external reference when `atexit` is called. This should be reviewed when intel/llvm#11156 is fixed.
This is due to an issue with dpc++ where it can leave temporary queues unreleased. This can then have the effect on the closing down of the device. This is resolved by registering and deregistering the queues on creation and deletion and then releasing any queues which still have an external reference when `atexit` is called. This required an additional device mutex to avoid threading issues. This should be reviewed when intel/llvm#11156 is fixed.
|
This is a major issue for us, is there any idea when it might be addressed? |
|
I don't have level zero as a route to testing the oneapi construction kit, and I'm not sure how to repeat this any other way. |
|
Potentially this might be a memory leak in the runtime as well. |
|
To be clear, I haven't been able to show this since the UR change over, since it didn't have the out of order aspect written, but the thought seemed to be that the failure was elsewhere. (If we do claim we support out of order, then I don't believe the temporary queues are created). |
|
I can confirm I still see this even with the yet to be merged https://github.com/oneapi-src/unified-runtime/pull/975/files (which means that a lot of tests pass). |
|
I'm guessing this won't be looked at before the final oneapi release? |
Out-of-order queues impose additional restrictions on user code and grant additional freedom to the implementation, including the freedom to continue to execute in order. Therefore, we can trivially support out-of-order queues by removing the code that is specifically there to reject them, and continuing to run them in order. DPC++ aims to support OpenCL implementations that lack out of order execution support, but it does so by creating temporary queues that appear to not get released (intel/llvm#11156). By claiming out of order execution support, we avoid leaks, and the specification for CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE only permits out-of-order execution, it does not and in general cannot mandate it, so this should be a valid minimal implementation. In order to ease testing, this is optional for now, but enabled by default. -DCA_ENABLE_OUT_OF_ORDER_EXEC_MODE=OFF can be used to restore the prior behavior. * CMakeLists.txt: add CA_ENABLE_OUT_OF_ORDER_EXEC_MODE option. * config.h.in: report the CA_ENABLE_OUT_OF_ORDER_EXEC_MODE option. * _cl_command_queue::create: tolerate CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE and pass it along to _cl_command_queue, provided CA_ENABLE_OUT_OF_ORDER_EXEC_MODE is enabled. * cl::EnqueueWaitForEvents: tolerate CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE and ignore it, provided CA_ENABLE_OUT_OF_ORDER_EXEC_MODE is enabled. Tests for unsupported properties are updated to test CL_QUEUE_ON_DEVICE rather than CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE.
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days. |
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days. |
Describe the bug
The OpenCL plugin support for dpc++ tries to create a queue with the property CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE.
If this fails (such as in the oneAPI Construction Kit), then it may create temporary queues to enforce dependencies.
It never deletes these temporary queues.
To Reproduce
In detail:
Use the following script, it assumes that we already have LD_LIBRARY_PATH and PATH set up correctly for dpc++
Please describe the steps to reproduce the behavior:
This shows four piextQueueCreate and one piQueueRelease
Environment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: