Skip to content
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

Merged
merged 3 commits into from
Dec 23, 2023

Conversation

aprokop
Copy link
Contributor

@aprokop aprokop commented Nov 3, 2023

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.

Additional changes:

  • Swap value-index order
    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).

@aprokop aprokop added API User visible interface modifications refactoring Code reorganization labels Nov 3, 2023
@aprokop aprokop marked this pull request as ready for review December 7, 2023 15:06
@aprokop
Copy link
Contributor Author

aprokop commented Dec 7, 2023

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.

@aprokop
Copy link
Contributor Author

aprokop commented Dec 7, 2023

@dalg24 Appreciate the feedback, addressed it.

tree(execution_space,
ArborX::Details::LegacyValues<decltype(triangles), Box>{triangles});
ArborX::Details::AttachIndices<decltype(triangles)>{triangles});
Copy link
Contributor

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.

Copy link
Contributor Author

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.

src/details/ArborX_DetailsNode.hpp Show resolved Hide resolved

template <typename Value, typename Index = unsigned>
struct PairValueIndex
{
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

}
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};
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@aprokop
Copy link
Contributor Author

aprokop commented Dec 8, 2023

CUDA 11.0.3 strikes again :(

@aprokop
Copy link
Contributor Author

aprokop commented Dec 20, 2023

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}};
Copy link
Contributor

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?

Suggested change
bvh{space, ArborX::AttachIndices<decltype(primitives)>{primitives}};
bvh{space, ArborX::AttachIndices{primitives}};

same comment everywhere

Copy link
Contributor Author

@aprokop aprokop Dec 20, 2023

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.

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).
Copy link
Contributor

@dalg24 dalg24 left a 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.

@aprokop
Copy link
Contributor Author

aprokop commented Dec 22, 2023

We agreed to add Experimental::attach_indices, but keep ArborX::PairValueIndex. Will fix that.

@aprokop
Copy link
Contributor Author

aprokop commented Dec 23, 2023

All builds pass but SYCL. A bunch of SYCL tests failed like

PI CUDA ERROR:
	Value:           700
	Name:            CUDA_ERROR_ILLEGAL_ADDRESS
	Description:     an illegal memory access was encountered
	Function:        cuda_piextUSMEnqueueMemcpy
	Source Location: /root/intel-llvm-mirror/sycl/plugins/cuda/pi_cuda.cpp:5023


PI CUDA ERROR:
	Value:           700
	Name:            CUDA_ERROR_ILLEGAL_ADDRESS
	Description:     an illegal memory access was encountered
	Function:        operator()
	Source Location: /root/intel-llvm-mirror/sycl/plugins/cuda/pi_cuda.cpp:2553

terminate called after throwing an instance of 'std::runtime_error'
  what():  There was a synchronous SYCL error:
Native API failed. Native API returns: -999 (Unknown PI error) -999 (Unknown PI error)
unknown location(0): fatal error: in "half_traversal<Kokkos__Device<Kokkos__Experimental__SYCL_ Kokkos__Experimental__SYCLDeviceUSMSpace>>": signal: SIGABRT (application abort requested)
/var/jenkins/workspace/ArborX_PR-969/test/tstDetailsHalfTraversal.cpp(60): last checkpoint: "half_traversal" test entry

@aprokop
Copy link
Contributor Author

aprokop commented Dec 23, 2023

Actually, SYCL build has been broken since #973. So, it's not this PR's fault. We just had problems running anything in CI.

@aprokop aprokop merged commit 8918428 into arborx:master Dec 23, 2023
1 of 2 checks passed
@aprokop aprokop deleted the pair_index_value branch December 23, 2023 01:50
@aprokop aprokop changed the title Introduce PairValueIndex and AttachIndices Introduce PairValueIndex and Experimental::attach_indices Dec 23, 2023
This was referenced Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API User visible interface modifications refactoring Code reorganization
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants