ae23f180 Refactor ArrayRange to do as little as possible inside TryExecute
12b5aac0 Leverage try_executes perfect forwarding in ArrayRange
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1085
9bf14b78 Correct warnings inside worklet::Clip when making array handles
1b6d67e0 Always defer to the serial allocator when allocating basic storage
bf2b4169 Refactor vtk-m ArrayHandle to use mutable over const_cast
705528bf vtk-m ArrayHandle + basic storage has an optimized PrepareForDevice method
22f9ae3d vtk-m ArrayHandle + basic holds control data by StorageBasicBase
b1d0060d Make Storage and ArrayHandle export for the same value types.
d0a68d32 Refactor vtk-m storage basic to generate less code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1084
1dabda42 Bug fix for max threads in radix sort
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1087
There was a bug where if you included an empty range into another range,
the range suddenly became infinite. This is because empty ranges have
the max at -infinity and the min at infinity. If you just include the
endpoints independently (which is what include does), then the min gets
-infinity and the max gets infinity. This gets a check to make sure that
empty ranges are ignored.
By hard coding the PrepareForDevice to know about all the different VTK-m
devices, we can have a single base class do the execution allocation, and not
have that logic repeated in each child class.
Added check for long double arrays, use TBB parallel_sort
Added radix sort instantiations for char16_t, char32_t, and
wchar_t. std::is_arithmetic<T> will evaluate to true for these
types.
Removed VTKM_CONT_EXPORT in DeviceAdapterAlgorithmTBB.h to try
and fix dll related error on Windows.
1. Add a 'FastVec' class that copies input vector types to an efficient
Vec type on the stack. Specializations avoid copies of already efficient
types.
2. Update 'WorldCoordinatesToParametricCoordinates' functions to utilize the
'FastVec' class. This should improve performance when the passed in
vectors are of slow types like 'vtkm::VecFromPortalPermute'.
3. Since most input Vec types will convert to the same 'FastVec' type this
also reduces the code generations. Some code refactoring was required for
this.
22ea5833 iVTK-m CUDA backend doesn't use thrust::cuda::pointer any more.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Allison Vacanti <allison.vacanti@kitware.com>
Merge-request: !1076
A recent merge request corrected several spelling errors in VTK-m.
One such correction was in the git-gitlab-sync script in the
Utilities/GitSetup directory. This commit reverts the change in
this specific file for two reasons.
1. The changed introduced a \' inside a single quote string (to
correct cant to can't). However, single quotes in shell scripts
do not allow you to escape characters like that, and thus this
causes an error when running the script.
2. This script actually comes from a separate repository
(https://gitlab.kitware.com/utils/gitsetup) that we occasionally
syncronize with. To prevent confusion, we should minimize the
divergence between this repository and that one. If someone wants
to make this change, it should really be made in the GitSetup
repository.
When the implementation for the cell derivative functions was made, the
special cases for creating the Jacobian for wedge and pyramid cell
shapes was not working. Instead, it just used the hexahedra case for a
degenerate cell. This fixes the issues with the special cases.
There were multiple issues to be fixed. There were some complaints
by the compiler about types. There was a mistake in the pyramid table.
But the biggest issue was a problem with macro expansions. It was
the classic tale of forgetting that you have to encase parameters
in parenthesis to make sure that operator precedence comes out as
expected.
