The list defining the common storage types was defined in
DefaultTypes.h.in. The problem was that derived default types could not
just add their own type. They had to redefine the whole list.
Instead, move the list to StorageList.h. Also updated
DefaultTypesVTK.h.in to use this list when using XGC. This enables
ArrayHandleSOA for this case.
968c66f94 add TODO to update kokkos initialize
18d7827db update vtkm test arguments
5fa8734bb update vtkm initialize flags to have 'vtkm' prefix and deprecate old flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2456
Deprecate `VirtualObjectHandle` and all other classes that are used to
implement objects with virtual methods in the execution environment.
Additionally, the code is updated so that if the
`VTKm_NO_DEPRECATED_VIRTUAL` flag is set none of the code is compiled at
all. This opens us up to opportunities that do not work with virtual
methods such as backends that do not support virtual methods and dynamic
libraries for CUDA.
The both the underlying `UnknownArrayHandle` and `ArrayHandleVirtual`
handle `ArrayHandleCast` specially. This caused problems when passing an
`ArrayHandleCast` to `VariantArrayHandle::AsVirtual`. Solve the problem
by stripping out the cast storage tags and letting these classes handle
it internally.
It's annoying to have to fix a problem in a method of a deprecated class
that returns another class that is deprecated for a different reason. No
one should really be running this.
`UnknownArrayHandle` treats a `ArrayHandleCast` and
`ArrayHandleMultiplexer` special. When you put one of these arrays in an
`UnknownArrayHandle`, it takes the original array out and stores it. If
you try to take an array of that type out, it will again do the proper
conversion.
The only problem is that if you use `IsType`, the result can be
unexpected. This is what happened with `CastAndCall`, which was using
`IsType` internally. Changed that to `CanConvert` to properly get the
array handle out.
`VaraintArrayHandle` has been replaced by `UnknownArrayHandle` and
`UncertainArrayHandle`. Officially make it deprecated and point users to
the new implementations.
Using this internal class is a bit tricky because it requires a pointer
to a C array that is expected to contain portals. Both the C array and
the portals must be defined for the expected device. This is already
handled by the associated Storage. Assuming all of this holds, make sure
the `ArrayPortalRecombineVec` is trivially copyable. This is a
requirement for passing objects to the execution environment.
`vtkm::cont::Error` inherits from `std::exception`. As such, it has a
special `what` string that reports an error message in a standard way.
This is particularly useful when a `vtkm::cont::Error` exception remains
uncaught because the system will print the `what` string before
crashing.
Unfortunately, the `what` string was only being set in the `Error`
constructor that took a message. That is a problem for subclasses like
`ErrorCuda` that used the default constructor and then used
`SetMessage`. The `what` string did not get set in this case.
Change the behavior to capture the stack trace in the default
constructor and update the `what` string if a subclass uses
`SetMessage`.
563e23aac Fix unintended cast in TBB Reduce's return value
a7100c845 Do not assume CUDA reduce operator is unary
f3a6931f6 Fix casting issues in TBB functors
cc5b9a016 Add casts to FunctorsGeneral.h
d9c988b20 Allow for different types in basic type operators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2431
The `Reduce` algorithm is sometimes used to convert an input type to a
different output type. For example, you can compute the min and max at
the same time by making the output of the binary functor a pair of the
input type. However, for this to work with the CUDA algorithm, you have
to be able to also convert the input type to the output type. This was
previously done by treating the binary operator as also a unary
operator. That's fine for custom operators, but if you are using
something like `thrust::plus`, it has no unary operation. (Why would
it?)
So, detect whether the operator has a unary operation. If it does, use
it to cast from the input portal to the output type. If it does not,
just use `static_cast`. Thus, the operator only has to have the unary
operation if `static_cast` does not work.
If you are using the classes in `FunctorsGeneral.h`, you specify both
the result type and the type of the operands. Presumably you are already
comfortable with any type conversions. So let them keep.
The basic type operators in `Types.h` (i.e. `vtkm::Add`,
`vtkm::Subtract`, `vtkm::Multiply` and `vtkm::Divide`) required the same
type for both arguments. This caused problems when used with `Reduce`
and the initial value type did not match exactly.
Use some tricks from `BinaryOperators.h` to be flexible about using
different types.
`std::is_trivial` is part of the C++14 specification. However, we have
encountered multiple compilers that purport to implement C++14 but do
not implement `std::is_trivial` and the like checks correctly.
To avoid such issues, only use `std::is_trivial` on compilers that we
have tested to support it.
662998f19 Remove make_ImplicitFunctionFunctor functions
27cc99acb Add documentation for Multiplexer and General implicit functions
6a445ebcf Do not return a reference from ImplicitFunction::PrepareForExecution
b0fcab5d7 Do not capture references to execution objects
096e7457c Fix CUDA issues
8c6623736 Suppress deprecation warnings in deprecated class
a6725b3ac Remove use of deprecated ImplicitFunctions with virtual methods
180d11e7f Add ImplicitFunctionGeneral
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2413
