9ea11440e Do not require `VecTraits` for `UnknownArrayHandle` components
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2778
Originally `MakeTestDataSet.h` was header-only code. This was changed to
put its functionality into a library. The obvious library to put it in
was `vtkm_cont_testing`.
The problem is that there is some external code that is (unadvisably)
adding this header to their own code. This code ends up breaking because
it needed to include `vtkm_cont_testing`, which was not needed before.
As a workaround, there was a CMake interface link that caused external
code linking in `vtkm_cont` to also link in `vtkm_cont_testing`. This
works OK, but creates something of a circular dependency. CMake itself
has no problem with this, because `vtkm_cont` did not itself depend on
`vtkm_cont_testing`; only things that linked to `vtkm_cont` also had to
link to `vtkm_cont_testing`.
Unfortunately, some Ascent CMake script was trying to trace down
dependencies and ran into an infinite loop. So this solution was not so
great for them.
Get around the problem by just adding the `MakeTestDataSet` code
directly to `vtkm_cont` (for now).
Whan an `UnknownArrayHandler` is constructed from an `ArrayHandle`, it uses
the `VecTraits` of the component type to construct its internal functions.
This meant that you could not put an `ArrayHandle` with a component type
that did not have `VecTraits` into an `UnknownArrayHandle`.
`UnknownArrayHandle` now no longer needs the components of its arrays to
have `VecTraits`. If the component type of the array does not have
`VecTraits`, it treats the components as if they are a scalar type.
849106762 remove include CellDeepCopy
4108febd3 remove #include functional
daaac78f1 minor changes based on code review
aecdd7705 Update vtkm/filter/resampling/testing/CMakeLists.txt
38000ed6d Use ALL_BACKENDS for unit test
ab09f77b7 migrate Probe filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2771
`UnitTestDispatcherBase` previously used arrays from `std::vector` to
test dispatching data to worklets. This only works for devices that have
unified memory with the host.
Change the test to use `vtkm::cont::internal::Buffer` objects and
properly copy data to/from the device for devices that have separate
memory spaces.
There were several tests that were disabled for hip because they either
took too long to compile or were failing. We are getting closer to
making everything work, so re-enable this part of the build.
The scalar field difference along x, y, and z should be divided by the
spacing not multiplied. This was causing some test failures in VTK and
ParaView when overriding the default contour filter with `vtkmContour`.
When `PointTransform` was converted to the new filter structure, some of
the methods that were moved from .hxx to .cxx (and therefore compiled in
a library) were still marked as `inline`. This caused the compiler to
not compile the function into the library if it was not used. Fix the
problem by removing the `inline` modifier to the method implementations.
The scalar field difference along x, y, and z should be divided by the
spacing not multiplied. This was causing some test failures in VTK and
ParaView when overriding the default contour filter with `vtkmContour`.
Previously, the mesh parameters used for the `ParticleDensity` filters
had to be provided in the constructor. However, this is different than
most other filters in VTK-m. It also can be more error prone as it is
easy to mix up unnamed arguments.
Add methods to `ParticleDensityBase` to allow setting/getting parameters
like `Dimensions` and `Bounds` to make it more clear what the values
mean.
The deprecated class `vtkm::filter::MeshQuality` contained a private
method that was referenced in its inlined constructor. The problem was
that this private method was compiled in the `vtkm_filter_mesh_info`
library but not properly exported. Fix this by adding an export to the
class.
e6b37f7a4 Remove deprecated use of old unscoped enums in FieldToColors
f37cc7657 Use scoped enum for FieldToColors modes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2734
The current implementation of the AMD HIP compiler adds default compiler
flags to attempt to inline everything possible. This is wrecking havoc
with the `Variant::CastAndCall` function, whose implementation has one
or more large switch statements with each case calling a different
potentially inline function. In some parts of the VTK-m code, this is
dragging the compilation on for days as it tries to resolve a
`Variant::CastAndCall` within a `Variant::CastAndCall`. This will
probably need to be addressed in the compiler, but meanwhile we will
force the inlining to be turned off for the function called by
`Variant::CastAndCall`. It is unclear if this will result in some extra
runtime overhead, but the change is worth it to get reasonable compile
times.
Thanks to Nick Curtis for tracking this down and providing the solution.
The previous implementation of `Variant`'s `CastAndCall` generated a
switch statement with 20 cases (plus a default) regardless of how many
types were handled by the `Variant` (with the excess doing nothing
useful). This reduced the amount of code, but caused the compiler to
have to build many more instructions (and optimize for them). This in
turn lead to large compile times and unnecessary large libraries/
executables.
This change makes a different function to use for `CastAndCall` so that
the number of cases in the switch matches exactly the number of types in
the `Variant`'s union.
Because the size of VariantImplDetail.h was getting large, I also
reduced the maximum expansions for the code. This does not seem to
negatively affect compile time, and I doubt it will have an noticible
difference in running time (when in release mode).
I also modified some other parts of this code to match the expansion
without making unnecessary defaults.
For the templated methods that we are precompiling instances for, do not
put their implementation inside of the class declaration. The problem is
that if you define a method inside of a class, it is implicitly inline.
If it is inline, a compiler might choose to compile it even if an
external symbol exists.
It appears that some compilers treat template instances different than
calling a template. For example, if you have
```cpp
template <typename T, typename U>
void Foo(T t, U u);
template <typename T>
void Foo(T t, int u);
template void Foo(int t, int u);
```
that some compilers will complain that the instance is ambiguous because
it matches both versions of Foo even though the second one is the one
that is called (unless you specifically declare template parameters).
This is what happend with the gradient instances. Fix the problem by
wrapping the "ambiguous" cases to be called by a simple, single
templated function.
When the gradient filter was moved over to the new filter structure, it
lost its instantiations. This is a problem because the gradient filter,
which compresses a lot of the code into single worklet calls for
efficiency, is one of the longest to compile filters.
This commit restores the instantiations with the updated instantiation
functionality. This breaks up the code into many translation units that
can be compiled simultaneously and thus not hold up the entire compile
on one process.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.
