Skip to content

Queues in DPPL queue manager should share contexts when appropriate #53

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
oleksandr-pavlyk opened this issue Sep 21, 2020 · 4 comments
Closed
Milestone

Comments

@oleksandr-pavlyk
Copy link
Contributor

DPPL creates queues in the queue manager using explicit queue(const device &syclDevice) signature constructor.

Although I do not have an explicit spec reference, I was told that this would create "new instance of sycl context for every constructor call".

To ensure that SYCL runtime facilitates data traffic between compatible devices, associated queues should be created using the same context which is associated with the widest set of compatible devices on the same SYCL platform.

This is an issue to ensure that this is being doing in the DPPL queue manager.

@fschlimb

@fschlimb
Copy link

This also implies that data structures-backed by USM require special handling when they are passed between different SYCL contexts. SYCL USM grants unified access within a context but not necessarily within an application.
It is probably ok to start with supporting a single context and handle cross-context issues later.

@diptorupd
Copy link
Contributor

@oleksandr-pavlyk @fschlimb Please review the new way to create the queues in PR 93.

The thing I do not yet understand is why DPC++ spawns a huge number of TBB threads when we call the context constructor that accepts a vector of devices for OpenCL. For Level-0 the issue happens even with the context constructor with a single device. The following warning gets printed out:

TBB Warning: The number of workers is currently limited to 7. The request for 31 workers is ignored. Further requests for more workers will be silently ignored until the limit changes.

@diptorupd
Copy link
Contributor

@oleksandr-pavlyk can we close this after #93 is merged.

@diptorupd diptorupd added this to the beta10 milestone Oct 5, 2020
@oleksandr-pavlyk
Copy link
Contributor Author

Yes, certainly.

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

No branches or pull requests

3 participants