-
Notifications
You must be signed in to change notification settings - Fork 35
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
Introduce PairValueIndex and Experimental::attach_indices #969
Conversation
e90e620
to
30a4ded
Compare
30a4ded
to
7c8ae03
Compare
7c8ae03
to
615c70b
Compare
This used to improve performance by itself. However, I no longer see any changes after #976 was merged. So now it is purely about interface and not performance. |
@dalg24 Appreciate the feedback, addressed it. |
tree(execution_space, | ||
ArborX::Details::LegacyValues<decltype(triangles), Box>{triangles}); | ||
ArborX::Details::AttachIndices<decltype(triangles)>{triangles}); |
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.
OK but noting this still bad to advertise using private implementation details in an example.
I am not expecting you to address this in this PR.
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.
AttachIndices
should really be public. I was not sure whether to do this in this PR. If we agree on the name, I'll do it.
|
||
template <typename Value, typename Index = unsigned> | ||
struct PairValueIndex | ||
{ |
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.
Is the intent that Value
and Index
can be deduced via decltype or should we define value_type and index_type?
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.
So far, we don't have a need for either.
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.
Well yes L50 but I suppose you got to the next comment and understand now
src/details/ArborX_DetailsLegacy.hpp
Outdated
} | ||
else | ||
{ | ||
BoundingVolume bounding_volume{}; | ||
expand(bounding_volume, Access::get(_primitives, i)); | ||
return value_type{(unsigned)i, bounding_volume}; | ||
return value_type{bounding_volume, (unsigned)i}; |
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.
Wondering whether you should specify the trailing integral template parameter L29 or should we be deducing the right integral type to cast i to?
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.
Good point. It is safer to specify the template arg on L29, as this is what it was hardcoded in APIv1.
509fa76
to
f4834ce
Compare
f4834ce
to
bd275da
Compare
CUDA 11.0.3 strikes again :( |
bcf4f44
to
07b06c1
Compare
Rebased on master to solve conflicts after #970 merge. |
bvh{space, ArborX::Details::LegacyValues<decltype(primitives), Point>{ | ||
primitives}}; | ||
ArborX::PairValueIndex<Point>> | ||
bvh{space, ArborX::AttachIndices<decltype(primitives)>{primitives}}; |
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.
Any reason why you didn't rely on CTAD?
bvh{space, ArborX::AttachIndices<decltype(primitives)>{primitives}}; | |
bvh{space, ArborX::AttachIndices{primitives}}; |
same comment everywhere
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. Annoyingly, CTAD fails for CUDA 11.0.3.
07b06c1
to
68e820e
Compare
There are two use cases that are currently mixed when using LegacyValues: 1) Legacy classes use LegacyValues to pass to the new interface 2) User wants to attach indices to the passed primitives without constructing them themselves The difference is that 1) should not be exposed to a user, while 2) is intended to. With the introduction of the RangeTraits in the future, the use cases diverge: 1) will still use AccessTraits for backwards compatibility, while 2) will switch to using RangeTraits. This patch separates the two. They still share a lot of commonalities at the moment, but that will change with RangeTraits. In addition, the order is swapped between value and index in the struct. The reason being is that it is easer to align an index (likely 4-byte int) than a value (which could be a 12-byte point, 24-byte box, or whatever).
68e820e
to
bf94eb5
Compare
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 would probably prefer having an attach_indices
function template that returns a non specified type. That way template argument deduction will work and it give us more freedom.
We agreed to add |
7c76a15
to
2f317e6
Compare
All builds pass but SYCL. A bunch of SYCL tests failed like
|
Actually, SYCL build has been broken since #973. So, it's not this PR's fault. We just had problems running anything in CI. |
There are two use cases that are currently mixed when using LegacyValues:
constructing them themselves
The difference is that 1) should not be exposed to a user, while 2) is intended to.
With the introduction of the RangeTraits in the future, the use cases diverge: 1) will still use AccessTraits for backwards compatibility, while 2) will switch to using RangeTraits.
This patch separates the two. They still share a lot of commonalities at the moment, but that will change with RangeTraits.
Additional changes:
The reason being is that it is easer to align an index (likely 4-byte int) than a value (which could be a 12-byte point, 24-byte box, or whatever).