Generate triangulated mesh on a device #1077
Conversation
There was a problem hiding this comment.
Is using Kokkos::Arrays important? Can/should it be replaced by some user-defined type?
If we have reason to prefer array classes over potentially more descriptive user-defined types, can you say a word to why guarding for a sufficient Kokkos version is more suitable than defining our own poor man's array class in KokkosExt::? I expect we could whip up a simplified implementation in a few lines.
| template <typename ExecutionSpace, typename MemorySpace> | ||
| void convertTriangles2VertexForm( | ||
| ExecutionSpace const &space, | ||
| Kokkos::View<Kokkos::Array<int, 3> *, MemorySpace> &triangles, |
There was a problem hiding this comment.
Did we ever agree on how to pass output views when no allocation occurs. I am not a big fan of using non-const references to denote that a view is being written into. Non-const can also be interpreted as it can be resized/realloc'd or bound to some other view.
There was a problem hiding this comment.
Did we ever agree on how to pass output views when no allocation occurs.
No, we don't decided on a guideline.
I am not a big fan of using non-const references to denote that a view is being written into.
I prefer it this way, but open to arguments. My perspective is that it is much easier to understand inputs and outputs of a function from a signature. Making everything const clouds that, and one has to dig into the function to understand what view are modified.
Non-const can also be interpreted as it can be resized/realloc'd or bound to some other view.
Indeed it can.
It can be replaced. |
|
@dalg24 I switched to using a poor man's version of Kokkos::Array to avoid dependency on Kokkos 4.3.99. I think it is easier to use that. I don't want to use custom types as I still do |
| template <typename ExecutionSpace, typename MemorySpace> | ||
| void convertTriangles2VertexForm( | ||
| ExecutionSpace const &space, | ||
| Kokkos::View<Array<int, 3> *, MemorySpace> &triangles, |
There was a problem hiding this comment.
I really don't like that your output view is now 2nd parameter followed by an input view.
There was a problem hiding this comment.
And I would still prefer if you took the view by const reference.
You could prefix the view parameters with in_ and out_
There was a problem hiding this comment.
And I would still prefer if you took the view by const reference.
I still don't understand your argument for it. What is a downside for not passing by const ref?
aprokop
force-pushed
the
device_triangulated_refinement
branch
from
11248d1
to
b4cb7ee
Compare
|
Rebased on |
To avoid using any hash tables on the device, we convert the vertex representation of a icosahedron (i.e., each triangle is a set of 3 vertices) into an edge representation (each triangle is a set of 3 edges). Edge representation is much easier to do refinement on. After all refinements are done, we convert back to a vertex representation.
Master branch generates 251,658,240 triangles in ~25 seconds, while this new approach (on A100) in less than a second.
I think it is also a generally more useful algorithm to have around whenever we need it.