Skip to content
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

Use device managers in allocators instead of setting device directly #796

Merged
merged 2 commits into from
Aug 6, 2022

Conversation

illuhad
Copy link
Collaborator

@illuhad illuhad commented Aug 5, 2022

It seems the CUDA and HIP allocators have invoked cudaSetDevice() and hipSetDevice() directly, which they should never do because it can invalidate the state of the hip_device_manager and cuda_device_manager, which are used to manage the active device by the rest of the runtime.

This is a terrible oversight. I don't know why these function calls are used here instead of the device managers; the files even include them but then don't use them. This seems to be a very old bug that may have been as old as when we introduced the current runtime.

There might be a case for invoking both the device_manager::activate_device() as well as cuda/hipSetDevice() directly, as this would make USM memory management functions more robust in backend interop scenarios where the user also sets device explicitly.

I believe this fixes the issues described in #770

CC @al42and

@al42and
Copy link
Contributor

al42and commented Aug 5, 2022

Can confirm, that fixes the issue I've been observing with #770 👍

@illuhad illuhad merged commit cc2e355 into develop Aug 6, 2022
@illuhad illuhad deleted the feature/use-device-manager-in-allocators branch August 6, 2022 16:26
DieGoldeneEnte pushed a commit to DieGoldeneEnte/hipSYCL that referenced this pull request Aug 8, 2022
…daptiveCpp#796)

* Use device managers in allocators instead of setting device directly

* Also set device during allocate_usm
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.

None yet

2 participants