The precompiled `ArrayRangeCompute` function was not following proper fast
paths for special arrays. For example, when computing the range of an
`ArrayHandleUniformPointCoordinates`, the ranges should be taken from the
origin and spacing of the special array. However, the precompiled version
was calling the generic range computation, which was doing an unnecessary
reduction over the entire array. These fast paths have been fixed.
These mistakes in the code were caused by quirks in how templated method
overloading works. To prevent this mistake from happening again in the
precompiled `ArrayRangeCompute` function and elsewhere, all templated forms
of `ArrayRangeCompute` have been deprecated. Most will call
`ArrayRangeCompute` with no issues. For those that need the templated
version, `ArrayRangeComputeTemplate` replaces the old templated
`ArrayRangeCompute`. There is exactly one templated declaration of
`ArrayRangeComputeTemplate` that uses a class, `ArrayRangeComputeImpl`,
with partial specialization to ensure the correct form is used.
267ee49cb docker: update kokkos hip image
67bf9a966 docker: update kokkos hip image
50d4ab5cc CMake: VTKm_ENABLE_KOKKOS_THRUST to depend on Kokkos with CUDA or HIP enabled
0604f314a Fix for building SERIAL unit tests with KOKKOS_HIP/CUDA enabled
802bf80b0 CI: Add rocthrust installation step
fda475d5b Rework Thrust CMake options
e6f63a807 Adding CMake tweaks to turn off thrust algorithms if thrust is not detected.
5a72275ed Rewrite sorting specialization using std::enable_if_t
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2926
`vtkm::cont::DataSet` is a dynamic object that can hold cell sets and
fields of many different types, none of which are known until runtime. This
causes a problem with serialization, which has to know what type to compile
the serialization for, particularly when unserializing the type at the
receiving end. The original implementation "solved" the problem by creating
a secondary wrapper object that was templated on types of field arrays and
cell sets that might be serialized. This is not a great solution as it
punts the problem to algorithm developers.
This problem has been completely solved for fields, as it is possible to
serialize most types of arrays without knowing their type now. You still
need to iterate over every possible `CellSet` type, but there are not that
many `CellSet`s that are practically encountered. Thus, there is now a
direct implementation of `Serialization` for `DataSet` that covers all the
data types you are likely to encounter.
The old `SerializableDataSet` has been deprecated. In the unlikely event an
algorithm needs to transfer a non-standard type of `CellSet` (such as a
permuted cell set), it can use the replacement `DataSetWithCellSetTypes`,
which just specifies the cell set types.
The `UnknownArrayHandle` has been updated to allow
`ArrayHandleRuntimeVec` to work interchangeably with basic
`ArrayHandle`. If an `ArrayHandleRuntimeVec` is put into an
`UnknownArrayHandle`, it can be later retrieved as an `ArrayHandleBasic`
as long as the base component type matches and it has the correct amount
of components. This means that an array can be created as an
`ArrayHandleRuntimeVec` and be used with any filters or most other
features designed to operate on basic `ArrayHandle`s. Likewise, an array
added as a basic `ArrayHandle` can be retrieved in an
`ArrayHandleRuntimeVec`. This makes it easier to pull arrays from VTK-m
and place them in external structures (such as `vtkDataArray`).
