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.
`VaraintArrayHandle` has been replaced by `UnknownArrayHandle` and
`UncertainArrayHandle`. Officially make it deprecated and point users to
the new implementations.
When the dispatcher does it's "transport" phase, it returns an
"execution object", but this object is held in the control environment
(on the host) although it may point to resources in the execution
environment (on the device). For this object to get from host to device,
it must be trivially copyable. If it is not, compile and/or runtime
errors could occur. So force this condition with a static assert.
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
It is possible for a transport to return a reference to an object.
At some point, however, the object has to be potentially copied
to a different memory space to be used in the execution environment.
This was getting fouled up because the reference type was being
captured. Instead, remove any references from the object.
The GCC 7 compiler on summit was failing to compile all of the
code. The problematic parts involved using lambda functions.
I think the problem is that the compiler has a bug where it
has a problem resolving the type of variables captured by
reference. The problem seems similar to this bug reported
to Kokkos:
https://github.com/kokkos/kokkos-kernels/issues/349
Solved the problem by removing the lambdas with either a
named method or just inline code.
I suspect the problem arose (without anyone's knowledge) with
MR !2331, which moved VTK-m to C++14. This GCC error seems to
happen with C++14 but not C++11. (The features of lambdas changed
between these two versions of C++.)
Unfortunately, this introduces a backward-incompatible change with the
filters that use ImplicitFunctions. Before, they would get an
ImplicitFunctionHandle. This class is deprecated, and there is no easy
way to get back the actual type of implicit function stored in it.
7a14ea0ef Use Float64 instead of FloatDefault in TreeCompiler
96424c833 Fix bad ordering of args for CountLinkComponentsIn2DSlice in IsNecessary
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2414
There was some compile errors with CUDA and the CellLocatorGeneral.
Apparently it added enough to the CUDA kernel to cause issues with
constant memory.
Deprecated the `CellLocator` class and made all methods of the
other `CellLocator` classes non-virtual. General locators can
still use the `CellLocatorGeneral` class, but this class now
only works with a predefined set of locators. (The functionality
to provide a function to select a locator has been removed.)
The `GetMaxNumberOfNeighbours` of the `MeshStructure*` classes was
declared `constexpr`. This was causing some compiler errors.
I think the problem is actually a bug with GCC (https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=66297). Whether it is a compiler bug or not,
there does not seem to be a large value to declaring this method
`constexpr`, so I just removed the keyword.
Somewhere during this edit I removed a header file that didn't strictly
need to be there. This caused me to have to add
```cpp
```
in several places in the code.
The newer version of `ArrayHandle` no longer supports different types of
portals for different devices. Thus, the `ReadPortalType` and
`WritePortalType` are sufficient for all types of portals across all
devices.
This significantly simplifies supporting execution objects on devices,
and thus this change also includes many changes to various execution
objects to remove their dependence on the device adapter tag.
It used to be the case where you needed to call `ResetTypes` on a
`VariantArrayHandle` before using `ArrayCopy` to limit the types it gets
compiled for. However, there is now a general form for
`UnknownArrayHandle`, so `ResetTypes` no longer does anything useful in
this case. Remove the use of that.
The circular dependency came from UnknownArrayHandle.h needing
VTKmDefaultTypes.h, which needed all the cell set types. Some of those
cell sets used ArrayCopy in templated functions. Changed those functions
to directly deep copy the ArrayHandle.
There was an error that caused deprecation warnings in VTK-m to be
suppressed, which meant that many uses of deprecated features went
unnoticed. This fixes those deprecation warnings.
The majority of the warnings were caused by the use of the deprecated
`Cast`, `CopyTo`, and `ResetTypes` methods of `UnknownArrayHandle` (or
`VariantArrayHandle`). Both `Cast` and `CopyTo` have been subsumed by
`AsArrayHandle` (to make the functionality more clear). `ResetTypes` now
requires a second template argument to define the storage types to try.
Also fixed some issues with `SerializableField` being deprecated.
This class is no longer necessary because `Field` can now be directly
serialized.
The `VariantArrayHandle` will soon be deprecated for its replacement of
`UnknownArrayHandle`. Thus, `Field` and related classes should start
using the new `UnknownArrayHandle`.
cecd81d5d Add types appropriate for Ascent
865855ea0 Add changelog for making ArrayHandleSOA a default array
50ff9c22a Add support of `ArrayHandleSOA` as a default storage type
bc09a9cd1 Add precompiled versions of `ArrayRangeCompute` for `ArrayHandleSOA`
77f9ae653 Support `ArrayHandleSOA` only for `Vec` value types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2349
