-
Notifications
You must be signed in to change notification settings - Fork 68
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
Does "local_accessor" really have common reference semantics? #552
Comments
I did not yet run your test case, but my expectation that AdaptiveCpp honors the reference semantics in that case. So I believe that common reference semantics are implementable here. What AdaptiveCpp does is that it manages a single local memory allocation for all local accessors, and the local accessor only stores offsets into that memory. So when you copy an accessor, only the offset is copied, but the offset is still applied to the same local memory allocation. EDIT: Yes, works with AdaptiveCpp
|
Implement work group memory extension: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_work_group_memory.asciidoc Two notes: - Free function kernel support for work group memory argument will be added in a future PR. - When the assignment operator is called in host code, the assigned to work group memory object does not actually correspond to the same underlying memory as the one that was assigned from contradicting the spec. See KhronosGroup/SYCL-Docs#552 for a similar problem with `local_accessor`
We state in section 4.5.2 that
local_accessor
has common reference semantics, which means that a copy of alocal_accessor
object:If that were true, I would expect two
local_accessor
objects that are copies to reference the same underlying local memory. This is not how DPC++ behaves currently, and I wonder if we really intended this to be the case. Consider the following test:When the
local_accessor
object is copied in host code (command group scope), the test fails:However, when the
local_accessor
object is copied inside the kernel, the test passes:When you understand the implementation, this behavior makes sense. Each local accessor kernel argument creates its own unique SLM pointer inside the kernel, thus the test fails when the copy happens on the host. However, inside the kernel, the copy just copies the underlying SLM pointer, so the copies alias the same memory. Thus, the test passes when the copy happens inside the kernel.
However, the spec doesn't say this is the expected behavior. Furthermore, this behavior likely seems bizarre to someone who does not understand the implementation.
It would be tempting to sidestep the issue and just delete the copy constructor and copy assignment operator from
local_accessor
. However, I fear that existing applications may passlocal_accessor
by value to function calls, and this wouldn't work if we delete these.Note that there is no similar issue with regular
accessor
. When you copy anaccessor
object on the host, the copy points to the same buffer, and the common reference semantics are upheld.The text was updated successfully, but these errors were encountered: