Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions adoc/chapters/programming_interface.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -11174,10 +11174,12 @@ include::{code_dir}/usm_device.cpp[lines=4..-1]

=== Unified addressing

Unified Addressing guarantees that all devices will use a unified address space.
Unified Addressing guarantees that all devices in a given SYCL <<context>> will
use a unified address space.
Pointer values in the unified address space will always refer to the same
location in memory.
The unified address space encompasses the host and one or more devices.
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.


Expand Down
Loading