-
Notifications
You must be signed in to change notification settings - Fork 407
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
Provide Kokkos::realloc overload taking Kokkos::view_alloc() return type #5035
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have somewhere an up-to-date overload set for resize
, realloc
, and create_mirror[_view]
?
The Wiki should be up-to-date, see https://github.com/kokkos/kokkos/wiki/Kokkos::resize, https://github.com/kokkos/kokkos/wiki/Kokkos::realloc and https://github.com/kokkos/kokkos/wiki/Kokkos::create_mirror. resize and realloc at the moment can take a single |
OK so none of them seem to be taking |
OK, so let's see what possible View constructor properties are and what we want:
In my opinion, it makes sense to have an overload for the return type of |
a2fcb14
to
5442b40
Compare
Retest this please. |
Seems to work with |
dc8c513
to
2b79fa2
Compare
|
Retest this please. |
"not include a pointer!"); | ||
static_assert(!alloc_prop_input::has_memory_space, | ||
"The view constructor arguments passed to Kokkos::realloc must " | ||
"not include a memory space instance!"); | ||
|
||
const std::string label = v.label(); | ||
|
||
v = drview_type(); // Deallocate first, if the only view to allocation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a flaw in this PR, but the global Kokkos::fence()
implied by a deallocation does unfortunately undermine some of the goal of #4793.
Mentioning as much for the back-link over there as anything else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same applies for View
as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very happy to discuss that again. I'm in favor in restricting to execution spaces that can actually access the memory space.
2b79fa2
to
54ed3e3
Compare
@@ -925,6 +961,19 @@ class DualView : public ViewTraits<DataType, Arg1Type, Arg2Type, Arg3Type> { | |||
modified_flags(1) = modified_flags(0) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a behavior change in this PR that I can tell, but could @stanmoore1 or someone else familiar with DualView
semantics check that in the case where size is the same and no reallocation happens, and we do initialize only on the device instance, that the resulting modified_flags
values are sensible? It seems like a subsequent synchronization call should recognize that the re-initialized data on the device side is fresher than the stale data on the host side.
outer_view2 = inner_view; | ||
}, | ||
[&](BeginFenceEvent event) { | ||
if (event.descriptor().find("HostSpace fence") != std::string::npos) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can DynRankView
exhibit the same "Debug Only Check for Execution Error"
that the tests for DualView
and ScatterView
exclude?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test for View
has that exclusion, so I think we need it here, unless it's superfluous there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is only necessary for View since it includes an additional case.
Co-authored-by: Phil Miller <unmobile+gh@gmail.com>
7abebaf
to
8128972
Compare
Retest this please. |
Failure (OpenMP timeout) is unrelated. |
I messed up here
CI has been failing ever since the merge |
Supersedes #5027. This would allow passing a label or an execution space or other (possibly multiple) View constructor properties to
Kokkos::realloc
.We decided in #5027 to not allow passing a label at all which is implemented here.