Skip to content

[SYCL] piDeviceRelease resource leak fix #2668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

cperkinsintel
Copy link
Contributor

piDeviceRetain/piDeviceRelease fix.
There is a dependency loop between device_impl and platform_impl, each holding a shared pointer to the other, preventing their destruction. Here device_impl is modified to use a weak_ptr to the platform_impl, but this means the device must track the plugin as well, as it needs it during its destruction (when the weak_ptr will be dangling).
Once device_impl destructor runs, piDeviceRelease is called.

Signed-off-by: Chris Perkins [email protected]

…nd platform_impl, each holding a shared pointer to the other, preventing their destruction. Here device_impl is modified to use a weak_ptr to the platform_impl, but this means the device must track the plugin as well, as it needs it during its destruction (when the weak_ptr<platform> will be dangling).

Signed-off-by: Chris Perkins <[email protected]>
@cperkinsintel cperkinsintel requested a review from a team as a code owner October 22, 2020 04:21
@@ -101,7 +104,10 @@ cl_device_id device_impl::get() const {
}

platform device_impl::get_platform() const {
return createSyclObjFromImpl<platform>(MPlatform);
if (PlatformImplPtr Platform = MPlatform.lock())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not very clear what should be done if a platform is released before a device bound to this platform.
Can we do vice versa - device has a shared_ptr to platform, platform has a weak_ptr to device?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try it.
The platform has multiple owners "higher up", like the context and the GlobalHandler. So it isn't affected if the device has a weak_ptr to it. But I'm less certain for the devices. I think the platform might be the primary owner, so if it's a weak pointer, then the device might be released before the platform is done with it. Also, the code has a clear chain of ownership now: context->platform->device, it seems unwise to meddle with it.

I would prefer that instead of returning just platform() in the else case, that we throw an exception - because no one should be asking for the platform after it has been released. However, that would be an ABI change, and I wanted to avoid anything controversial.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this PR to draft, and opened a new one here: #2671

@cperkinsintel cperkinsintel marked this pull request as draft October 22, 2020 18:37
@cperkinsintel cperkinsintel deleted the cperkins-device-resource-leak branch October 27, 2020 15:41
iclsrc pushed a commit that referenced this pull request Aug 15, 2024
OpenCL spec supports atomic_float/atomic_double type for
atomic_compare_exchange* functions. However, value and return type in
OpAtomicCompareExchange in SPIR-V spec must be integer type.
Therefore, in OCLToSPIRV translation we need to translate floating-point
type to corresponding integer variant that has the same type size.
Floating-point value is bitcasted so that bits remain the same.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@e5544014fba77d3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants