Clarify Unified Addressing#1005
Conversation
Unified Addressing should only be within a single context (and the host).
Satisfy reflow
| The unified address space encompasses the host and all devices in a given SYCL | ||
| <<context>>. | ||
| Note that this does not require addresses in the unified address space to be | ||
| accessible on all devices, just that pointer values will be consistent. |
There was a problem hiding this comment.
I've always found this section to be unclear, so maybe we can take this as an opportunity to clarify it. Looking closely at three of the four sentences in this section:
- The first sentence defines "Unified Addressing" as "use a unified address space". That seems like an unhelpful circular definition.
- The second sentence says that "pointer values [...] refer to the same location in memory". It's not clear to me what this means. Isn't this always the case for pointer values? The value of a pointer is the address of a memory location. How could a pointer refer to a different location in memory if its value doesn't change?
- The fourth sentence says that "pointer values will be consistent". What does "consistent" mean here?
Are we trying to say the following?
- The address of any USM buffer is different from all non-USM memory addresses on the host.
- The address of any USM host memory buffer allocated from context C has an address that is different from all other USM host memory buffers (regardless of context), different from all USM shared memory buffers (regardless of context), and different from all USM device memory buffers allocated from context C.
- The address of any USM shared memory buffer allocated from context C has an address that is different from all other USM shared memory buffers (regardless of context), different from all USM host memory buffers (regardless of context), and different from all USM device memory buffers allocated from context C.
- The address of any USM device memory buffer allocated from context C has an address that is different from all other USM device memory buffers allocated from context C, different from all USM host memory buffers (regardless of context), and different from all USM shared memory buffers (regardless of context).
Tagging @bashbaug because the SYCL definition of "unified addressing" should match OpenCL.
There was a problem hiding this comment.
I think I would agree with these statements.
However, I'm not sure I like the term "USM buffer". Since a "buffer" is overloaded in SYCL-speak (buffer/accessors) this seems confusing and I couldn't find any other reference to the term in the spec. I think if we need this term we should define it in this section first, but at the end of the day USM gives you pointers, so can we reword it in terms of pointers without losing clarity? Perhaps we could spell it out in terms of "pointer returned by a SYCL malloc_X function", if that's what we mean?
There was a problem hiding this comment.
Perhaps we could spell it out in terms of "pointer returned by a SYCL malloc_X function", if that's what we mean?
Yes, that's what I mean. If we're being pedantic, you can also get a USM pointer from the usm_allocator. Perhaps we need to define a term "USM pointer" to mean a pointer returned from any of the USM allocation functions.
|
Perhaps this section of the C++ spec could be extended to USM buffers within SYCL contexts, but not across different contexts. |
I think that section of the C++ spec is mostly talking about nested objects. How do you think it could be extended to clarify our situation? FWIW, I considered writing my proposed text in terms of C++ object addresses, but I changed it to refer to USM buffer addresses instead. I did this because the memory returned from the USM allocation routines is raw memory that does not contain any C++ objects. |
|
It says that except in the mentioned cases
Maybe a better place to extend is here but again this refers to objects rather than memory as you say. |
3 participants
Unified Addressing should only be within a single context (and the host).