Remove APIv1 shortcuts #1182
Remove APIv1 shortcuts #1182
Conversation
aprokop
added
refactoring
aprokop
force-pushed
the
apiv1_v2
branch
2 times, most recently
from
ce5eb55
to
6f50471
Compare
| @@ -178,6 +151,18 @@ KOKKOS_FUNCTION | |||
| typename Details::AccessValues<Values, PrimitivesTag>::memory_space, | |||
| typename Details::AccessValues<Values, PrimitivesTag>::value_type>; | |||
|
|
|||
| template <typename ExecutionSpace, typename Values, typename IndexableGetter> | |||
There was a problem hiding this comment.
Enable if ExecutionSpace is indeed an execution space {?)
There was a problem hiding this comment.
I see your point. I think it is out of scope for this PR. Rather, we would need to do that for all our deduction guides, both BVH and BruteForce. Or just wait for concepts.
A common user pattern is that they want to get the indices of the positive search results, like we've been doing in our original version, and possibly execute a callback on those results. As such, the hierarchy's value type would need to be |
|
I updated the PR to do only the part where we eliminate the APIv1 shortcuts but do no provide global |
| ArborX::BoundingVolumeHierarchy bvh{ | ||
| space, ArborX::Experimental::attach_indices(primitives)}; | ||
| ArborX::BoundingVolumeHierarchy bvh{space, primitives, indexable_getter}; |
There was a problem hiding this comment.
I really don't see a good way to write this without Iota.
|
Because |
Get out of business trying to guess user intentions. Make a user explicitly state what their desire is.
Experimental::IotaBVHandBruteForcethat returnView<int>for views based onPairValueIndex<Geometry,int>IotaUsing an
Iotainstead ofPairValueIndexdoes have a performance penalty, up to 40% in some cases. On Frontier,Ultimately, I think, we would need to document it properly and provide performance suggestions for a user.