1. The code now works without CUDA_LAUNCH_BLOCKING set by using explicit
synchronizations where required.
2. The code has also been modified to use thread specific memory spaces,
which for Kokkos' Cuda backend means per thread streams.
fb130d42d Remove test for ArrayHandleCompositeVector with bad lengths
7cbf40d5b Back out of using a composite of transform arrays
7ff1a690d Support ArrayHandleCompositeVector with 1 component
5391e353a Convert ArrayHandleExtractComponent to new buffer-style array
22fac15b3 Convert ArrayHandleCompositeVector to new buffer-style array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2330
3c50a7ea4 Fix assert for pathlines. Add example from manual that was failing.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2335
As we update the `ArrayHandle`s to the new buffer style, simplify
`ArrayHandleSwizzle` by implementing it on top of
`ArrayHandleTransform`. Also, introduce some C++11 template concepts to
handle variable arguments better.
In this conversion, some features have been removed. Previously if the
swizzle dropped some components, you were still allowed to write to the
array. This would be an in place write that would only update the passed
components. This feature has been removed and if any components are
dropped, the array becomes read only. If all components are swizzled,
then the array becomes writable (through templating).
Another lost feature is that the swizzle map is no longer checked for
correctness. The array handle just assumes that the indices are correct.
It should be noted that it does not look like `ArrayHandleSwizzle` is
actually used anywhere. If it is not used by any customers, we may
want to consider deprecating the class.
The old version of `ArrayHandleCompositeVector` would check (at
construction) to make sure that all the arrays had the same length. This
check has been removed because (1) it did not always catch all problems
(such as if the input arrays change), (2) debug builds check for out-of-
range array accesses anyway, and (3) it required a lot of extra template
expansion.
Because that check has been removed, also remove the part of the
`ArrayHandleCompositeVector` test that checks this check.
When `ArrayHandleCompositeVector` has only 1 component, it is supposed
to have a special template that uses the base value type rather than a
`Vec` of that type. However, the `Storage` with the value type was
missing. I'm not sure how we weren't getting compile errors before, but
moving to the new buffer arrays seems to bring about the expected error.
The `StorageImplicit.h` header is no longer used. However, just removing
it causes compiles to fail if they include it. To make the transition
better, re-add this file, but cause a deprecation warning if it is
included.
`vtkm::[U]Int*` types depending of each platform/arch would translate to
different integer types. We cannot make a generalization with this.
A simple way to handle this is to simply use primitive types, such as
char, signed char, long..., instead of vtkm::[U]Int*. This makes sure
that every primitive type is actually instantiated.
We could potentially use this in other filters instantiation file.
This error has been reported in VTK when being build with vtkm.
