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.
There is still a test for the deprecated functionality (for now). The
deprecated test only happens if deprecated virtuals are still compiled,
and warnings are suppressed for this part of the code.
The `ImplicitFunction` classes are now trivial classes that can be
passed among host and devices. Because of this, we now need to know the
type of the `ImplicitFunction` in order to use it.
The old functionality still exists (when virtual methods are still being
compiled), but will give deprecation warnings. It is also not possible
to get a pointer from `ImplicitFunctionHandle` and cast it back to the
original data type (because the type changed). This is a weird testing
feature that makes little sense in practice.
Also unsupported in the deprecated classes is the ability to change
the object and have those changes reflected in the handle. This is
unfortunate, but it would have been difficult to implement this
feature that is going away and only appears to be used in some of
the tests.
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
ebb265ce0 Add missing VTKM_EXEC_CONT declarations to functor
10ea36bb9 Pick one approach of using array handle decorator for contour tree
585f0ccb1 Two versions for replacing array transform with array decorator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2412
1822792b8 Support deprecated behavior of point locator pointers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2411
`PointLocator`s have changed from being virtual objects to being trivial
objects. Part of this change means that when a worklet gets the
execution object for a point locator, it gets the actual object (or a
reference to it) instead of a pointer to an object. This means that the
new code uses the `.` operator to access the locator's features instead
of the `->` operator.
To support code still using the deprecated functionality, added a
specific `->` operator to the locator execution object to make it behave
as if it were a pointer. However, this operator is marked deprecated to
warn the user that they should modify their code to use the `.` instead.
04f020ae6 Update Field to use new ArrayRangeCompute features
2a41428fe Add implementation of ArrayRangeCompute for UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2409
This is a fancy array that takes an array of offsets and converts it to
an array of the number of components for each packed entry.
This replaces the use of `ArrayHandleDecorator` in `CellSetExplicit`.
The two implementation should do the same thing, but the new
`ArrayHandleOffsetsToNumComponents` should be less complex for
compilers.
Reduces the amount of code that has to be generated. Also improves the
number of arrays supported and has better support for deprecated
versions of `GetRange`.
047d79672 Fix CUDA compilation error with Lagrangian filter
aec9890e9 Remove check for CellLocator.h in SourceInInstall test
2399741a9 Change Probe filter to use CellLocatorChooser
e61c54f87 Add CellLocatorChooser
23c823d4b Fix compile errors and warnings related to new CellLocator structure
47429a316 Fix export issues with CellLocatorBase
8922f600e Use GNU attributes for deprecated
0a5f5d55c Remove virtual methods from cell locators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2271
CUDA architecture has a limited amount of memory available for
constants. The CUDA compiler uses this space to hold constants for some
optimizations. However, for large kernels, the number of constants
needed might be larger than the constant space available. For these
conditions, you have to disable this form of optimization with the `-
Xptxas --disable-optimizer-constants` flags.
Currently, the only file that seems to have this issue is the test for
the Lagrangian filter. Someone should take a closer look to see if this
filter in particular is making unnecessarily large worklet/kernel. (In
particular, why does the Lagrangian filter have a larger kernel than the
streamline and stream surface filters?)
If this occurance happens more often, we might need to add some ways to
configure it in the build.
There was some compile errors with CUDA and the CellLocatorGeneral.
Apparently it added enough to the CUDA kernel to cause issues with
constant memory.
`CellLocatorChooser` allows you to select a cell locator at compile
time. Unlike `CellLocatorGeneral`, you have to deduce what cell set
types you might have, but you don't have to have a large switch
statement in the middle of your worklet.
There appears to be a bug in GCC where if you mixed C++ attributes like
`[[deprecated]]` with GNU attributes like `__attribute__(())`, you will
get a compile error. This can be a problem when using attributes to both
set the export (i.e. visibility) of an item and deprecating the same
item.
This problem has been encountered before. Commit
34b0bba84207a89e8fddfe62e7a1ff30b1b53a18 fixed the problem by using
`[[gnu::visibility()]]` instead of `__attribute__()` in the export
macros. This works fine for export macros defined by VTK-m headers such
as `VTKM_ALWAYS_EXPORT`. Unfortunately, we have little control over the
export macros that CMake automatically creates. Rather than rewrite the
CMake export code, we go the other way and use `__attribute__()` for all
exports _and_ the depreciated attribute.
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.)
0797359c5 Make ExecutionWholeArray objects not depend on device type
0bee74438 Support DeviceAdapterId in deprecated ArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nick Thompson <nathompson7@protonmail.com>
Merge-request: !2405
With recent changes to `Arrayhandle`, the type for the associated array
portal is now the same across all devices. This means that almost all
exec objects no longer need to be specialized on the device types. Thus,
clean up the whole array exec objects to no longer need to be templated
on device.
The original `ArrayHandle` design had the `PrepareFor*` methods
templated on the device adapter tag. This is no longer necessary (at
least for any existing `ArrayHandle`), so support calling `PrepareFor*`
with a `DeviceAdapterId` that is resolved at runtime.
c62e38bab Make locator exec objects not depend on device type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nick Thompson <nathompson7@protonmail.com>
Merge-request: !2404
With recent changes to `ArrayHandle`, the type for the associated array
portal is now the same across all devices. This means that almost all
exec objects no longer need to be specialized on the device types. Thus,
clean up the locator exec objects to no longer need to be templated on
device.
05fc1747e Make deprecated tags more descriptive
b92566cdd Convert `std::endl` to `'\n'`
b8b958a98 Get rid of CellSetStructured.hxx
f4bc3002b Fix compiler error with `constexpr` method
4d8f05bae Update CellSetExtrude to not specify exec types by device
3962e73b0 Fix issues with class specialization
c55d15f39 Deprecate ArrayHandle::ExecutionTypes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2401
e4241aa53 Make matrix unit tests less verbose.
bba3d29c2 Remove UB from Matrix.h, and replace by quiet NaNs.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2402
One of the MSVC builds was giving template resolution problems for one
of the methods declared non-inline for no discernable reason. It sounds
like a compiler bug. Rather than try to work around the issue, just
move the declaration inline.
In fact, all the methods are really small (only 1 or 2 lines). Just
delete the .hxx file and simplify things.
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.