Skip to content

[SYCL][SPEC] USM regarding to context #2721

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.

Sign up for GitHub

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

Jump to bottom
Closed
CaoZhongZ opened this issue Nov 3, 2020 · 16 comments
Closed

[SYCL][SPEC] USM regarding to context #2721

CaoZhongZ opened this issue Nov 3, 2020 · 16 comments
Assignees
@jbrodman
Labels
question Further information is requested

Comments

@CaoZhongZ
Copy link

I make statement, anything wrong please tell me.

I want to understand USM allocation regarding to "device" or "context". Consider Unified Addressing, Virtual Address Space tied to a context, consider "shared" part, real resource backing the virtual address is tied to device.

The problem is when Unified Addressing tied to multiple contexts in a single process. So the same virtual address with different context belongs to different virtual address space and are totally different entities, could point to completely different physical resources?
@bader
Copy link
Contributor

bader commented Nov 9, 2020

According to my understanding your statement is correct.
+@jbrodman to confirm.

@bader bader added the question Further information is requested label Nov 9, 2020
@jbrodman
Copy link
Contributor

jbrodman commented Nov 9, 2020

Yes.

Virtual addresses are not guaranteed to have any sort of consistency across different devices.

@CaoZhongZ
Copy link
Author

I brought up this to attention because if a unique virtual address could point to at least two different context resource, when migration happens it'll be very ugly. Conceptually, if a virtual address is not enough to distinguish different computational resource, might be huge problems lying around. Isn't it contradict Turing model a process used to hold?

@jbrodman
Copy link
Contributor

jbrodman commented Nov 10, 2020 via email

@CaoZhongZ
Copy link
Author

Users could control that? All users to do is allocate address1 from context1, allocate address2 from context2, do works. But address1 and address2 could be the same number. right?

@jbrodman
Copy link
Contributor

jbrodman commented Nov 10, 2020 via email

@keryell
Copy link
Contributor

keryell commented Nov 10, 2020

I have some issues understanding how a correct SYCL USM implementation could return the same C++ user-level address for 2 different objects.
Even if there are various back-ends and contexts, at the end they have to cooperate with the OS for not fighting for the same addresses...
At least something like Linux HMM can insure that even if behind the curtain you have actually different devices in different contexts and back-ends with different distributed physical memory pages, the illusion of a unique virtual address will hold.
In the same way as if new int and another new int are returning the same value, you are in trouble (but it is still possible with out-of-memory condition, in the case of noexcept new).

@jbrodman
Copy link
Contributor

jbrodman commented Nov 10, 2020 via email

@keryell
Copy link
Contributor

keryell commented Nov 10, 2020

While it would be possible, then it prevents use cases such as:

  • you have a lot of pointers to some objects allocated in some various slabs on various devices by C++ allocators and you cannot std::partition/std::sort/... the pointer set according to the various address ranges so you can the process them on the right devices.

So, if the application/architecture/OS/... is not short on address spaces, it seems clearer to have unique virtual address space mapping, even for non host-accessible memory. Even if we are talking about pointers here, the audience is not the Linux kernel developers... :-)

@CaoZhongZ
Copy link
Author

CaoZhongZ commented Nov 11, 2020 •
edited
Loading

Agree, we have plenty space for a clear implementation and it is then much more convenient.

Other cases like, C++ programming language required to avoid single address, two object of same type scenario. Or programmer's heuristic on pointer arithmetic, different object would have different address, etc. You could feel things will break if we don't do it right.

@KornevNikita
Copy link
Contributor

KornevNikita commented May 17, 2024 •
edited
Loading

Hi! There have been no updates for at least the last 60 days, though the ticket has assignee(s).

@jbrodman, could I ask you to take one of the following actions? :)

  • Please provide an update if you have any (or just a small comment if you don't have any yet).
  • OR mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it.
  • OR close the issue if it has been resolved.
  • OR take any other suitable action.

Thanks!

@github-actions GitHub Actions
Copy link
Contributor

Hi! There have been no updates for at least the last 60 days, though the issue has assignee(s).

@jbrodman, could you please take one of the following actions:

  • provide an update if you have any
  • unassign yourself if you're not looking / going to look into this issue
  • mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it
  • close the issue if it has been resolved
  • take any other suitable action.

Thanks!

1 similar comment
@github-actions GitHub Actions
Copy link
Contributor

Hi! There have been no updates for at least the last 60 days, though the issue has assignee(s).

@jbrodman, could you please take one of the following actions:

  • provide an update if you have any
  • unassign yourself if you're not looking / going to look into this issue
  • mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it
  • close the issue if it has been resolved
  • take any other suitable action.

Thanks!

jsji pushed a commit that referenced this issue Sep 21, 2024
@VyacheslavLevytskyy @jsji
Fix incorrect translation of calls to a builtin that returns a struct…
55ebb76 
…ure (#2722)

Fix issue #2721: Incorrect translation of calls to a builtin that returns a structure: create just one load, and account for a special case when Translator prepared a well-known pattern (store/load) for itself.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@dc1221cd83e67ef
@github-actions GitHub Actions
Copy link
Contributor

Hi! There have been no updates for at least the last 60 days, though the issue has assignee(s).

@jbrodman, could you please take one of the following actions:

  • provide an update if you have any
  • unassign yourself if you're not looking / going to look into this issue
  • mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it
  • close the issue if it has been resolved
  • take any other suitable action.

Thanks!

1 similar comment
@github-actions GitHub Actions
Copy link
Contributor

Hi! There have been no updates for at least the last 60 days, though the issue has assignee(s).

@jbrodman, could you please take one of the following actions:

  • provide an update if you have any
  • unassign yourself if you're not looking / going to look into this issue
  • mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it
  • close the issue if it has been resolved
  • take any other suitable action.

Thanks!

@AlexeySachkov
Copy link
Contributor

Considering that USM is now a core part of SYCL 2020, any remaining questions about it should be discussed in KhronosGroup/SYCL-Docs repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jbrodman jbrodman

Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@bader @keryell @jbrodman @CaoZhongZ @AlexeySachkov @KornevNikita