Previously vtk-m allowed users to issue atomic loads on constant
values which is problematic for the following reasons:
- can be a source of undefined behavior
- not supported by kokkos
This issue was detected when using kokkos HIP atomic implementation
268a07bb0 remove test on large graph and sample data
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2278
- It also remove termination on bench error
- It disables passing fields in Countour to skip an error.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
932f8b82f Merge branch 'concurrent_union_find' of gitlab.kitware.com:ollielo/vtk-m into concurrent_union_find
eaff27195 minor changes on comments on findRoot()
9fef540ba minor changes on comments on findRoot()
916661e33 Merge branch 'concurrent_union_find' of gitlab.kitware.com:ollielo/vtk-m into concurrent_union_find
a036b0f98 Minor change based on code review.
9e68022ac Minor change based on code review.
1185f70bc Data Race Resolution
aed7e02da Merge branch 'concurrent_union_find' of gitlab.kitware.com:ollielo/vtk-m into concurrent_union_find
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2248
9bd6f3e6d Disable VTKM_ASSERT when using HIP
68b5edfcb VTK-m defines VTKM_EXEC / VTKM_EXEC_CONT when compiling with HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2270
d0c9fb274 Correct missing `VTKM_EXEC_CONT` in UnitTestArrayHandleExtrude
1365cfa9e Update ConnectivityExtrude to follow clangs rules on markup
09df45bb1 Update vtkm/Geometry.hxx to follow clangs rules on function markup
461616a77 Refactor some VTK-m device adapter to be alphabetical
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2268
2278fdfd9 Deprecation macro has to come before VTKM_EXEC or VTKM_EXEC_CONT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2266
Although `vtkm::internal::Variant` respected the trivially copyable
attribute of the types it contains, it was never totally trivial (i.e.
`std::is_trivial<Variant<...>>` was never true). The reason was that
`Variant` was initializing its `Index` parameter to signify that it was
not initialized. However, the fact that `Index` was initialized meant
that it was not trivially constructed.
Now, `Variant` type checks its types to see if they are all trivially
constructible. If so, it makes itself trivially constructible.
This means that `Index` may or may not be valid if `Variant` is
constructed without an argument. This in turn means that the result of
`Variant::IsValid` becomes undefined. That should be OK in practice.
`Index` will "point" to an uninitialized object, but that object is
trivially constructed anyway. However, that could cause problems if
developers used `IsValid` to determine if something is selected.
1074c0172 Commented out incomplete code creating a warning
ce0aa1cf9 Fix compile errors
edd71539c Fix compile error due to renamed includes
33a7f5610 Added missing this-> for data members
b443fb500 Added note for future reference during API refactoring
b6343c049 Applied Ken Moreland's suggested fix to avoid copy
af697e452 Use std::swap instead of manual swap
8489a69c3 Fixed missing invoker compile error
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2263
The new name reflects better what the underlying algorithm does. It also
helps prevent confusion about what types of data the locator is good
for. The old name suggested it only worked for structured grids, which
is not the case.
2e918c58d Move ColorTable mapping to its own header
38bdfec40 Move ColorTable::Sample methods to vtkm_cont
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2262
We would really like to be able to include `vtkm::cont::ColorTable` in
such a way that you don't have to compile device code (unless you are
actually compiling functions for the device). Thus, the `Map` functions
of `ColorTable` were in a special `ColorTable.hxx` that contains the
"implementation" for `ColorTable`.
That is confusing to many users. It is more clear to simply have `.h`
headers that do a specific thing. To achieve these two goals, the `Map`
functionality of `ColorTable` is separated out into its own header file.
So you don't need to be using a device compiler just to use `ColorTable`
(including `ColorTable.h`), but you do need to use a device compiler if
mapping values to colors (including `ColorTableMap.h`).
6a3ba4291 Fix warning about unused function
c6a4f9b79 Fix warning about return value
9465d2611 Adjust TransferFunction worklet to get color table as ExecObj argument
11996f133 Remove virtual methods from ColorTable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2261
Previously, the `TransferFunction` worklet required you to call
`PrepareForExecution` on the `ColorTable` and give that to the
constructor. Bad things can happen if the `ColorTable` used in the
constructor does not match the device the worklet actually gets invoked
on. Change this to make the `ColorTable` a worklet argument of type
`ExecObj`. The dispatcher will automatically call
`ColorTable::PrepareForInput` and guarantee that the devices match.
