The `vtkm_add_target_information` CMake function has a `DEVICE_SOURCES`
option that allows you to list which sources need to be compiled with a
device compiler. Added some hints to the documentation about which
source code needs to be listed in `DEVICE_SOURCES`.
Some of the unit tests for serial and kokkos are disable for hipcc to
properly compile.
VTKM_MATH_ASSERT and VTKM_TEST_ASSERT fail to compile with HIP in
execution environment so they are disabled with building with HIP.
Kokkos::finalize is causing error so it is temporarily disabled.
When VTKm is used inside another CMAKE project the instatitations will
include its filers with the relative path from the top lever of the
parent project instead of the top level of the VTKm project. This commit
resolves that.
The reason why we did not support shared libraries when CUDA compiles
were on is that virtual methods require a special linking step to pull
together all virtual methods that might be called. I other words, you
cannot call a virtual CUDA method defined inside a library. This
requirement goes away when virtuals are removed.
Also removed the necessity of using seprable compilation with cuda.
Again, this is only needed when a CUDA function is defined in one
translation unit and used in another. Now we can enforce that all
translation units define their own CUDA functions.
Also, suppress warnings in cuda/internal/ExecutionPolicy.h
This is where we call the thrust algorithms. There must be some loop
where it, on some code path, calls back a host function. This must be in
an execution path that never happens. The thrust version has its own
suppress, but that does not seem to actually suppress the warning (it
just means that the warning does not tell you where the actual call is).
Get around the problem by suppressing the warnings in VTK-m.
Co-authored-by: Kenneth Moreland <morelandkd@ornl.gov>
Co-authored-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
These were previously suppressed because they are unavoidable when
calling virtual methods. But we no longer support virtual methods on
devices (it is deprecated).
These warnings can still happen if you have unbounded recursion. But we
would like to avoid unbounded recursion, so we would like to see these
warnings.
Also turned on other nvlink warnings, which include when a recursive
function call means that the compiler cannot figure out the full
stack depth.
Sourcing the file installed on dragnipur is causing a CMake error. I
don't know if it is an install error or a problem with FindTBB.cmake,
but this should get around the problem by just using the "old" method
for finding TBB.
The latest version of TBB changes the include directory where the
version is stored, so the old version of FindTBB.cmake would fail
because it could not open this file. This issue has already been fixed
by the FindTBB.cmake in VTK, so pull the latest version of that.
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
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
The previous implementation of test_equal_ArrayHandles was several
templates that had to be resolved by any test that used them, which
could be costly for unknown array types. Simplify this a bit by moving
the implementation of testing unknown arrays into a library.
Another advantage of the new implementation is that is handles more
cases. Thus, you should not need to `ResetTypes` on the unknown/
uncertain arrays.
7475c318b VTK-m now uses CMake's future HIP lang for Kokkos+HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2351
Virtual methods are being deprecated, so remove their use from the
ColorTable classes. Instead of using a virtual method to look up a value
in the ColorTable, we essentially use a switch statement. This change
also simplified the code quite a bit.
The execution object used to use pointers to handle the virtual objects.
That is no longer necessary, so a simple `vtkm::exec::ColorTable` is
returned for execution objects. (Note that this `ColorTable` contains
pointers that are specific for the particular device.) This is a non-
backward compabible change. However, the only place (outside of the
`ColorTable` implementation itself) was a single worklet for converting
scalars to colors (`vtkm::worklet::colorconversion::TransferFunction`).
This is unlikely to affect anyone.
I also "fixed" some names in enum structs. There has been some
inconsistencies in VTK-m on whether items in an enum struct are
capitolized or camel case. We seem to moving toward camel case, so
deprecate some old names.
If `VTKm_NO_DEPRECATED_VIRTUAL` is on, then these classes are not
installed. Thus, add exceptions for these files to avoid test failures.
We could get fancier by only checking if `VTKm_NO_DEPRECATED_VIRTUAL` is
off, but that seems heavy-handed to make a regression test for something
that will go away.
These exceptions should be removed once the files are removed.
There is a limitation in Windows builds using VS2019 where libraries cannot be
bigger than 4GiB. This is normally not an issue but in `VTKm` due to its strong
template usage libraries can reach that size.
The `VTKm` filter library is can easily reach that size and it will halt the
build
This MR tries to avoid reaching those sizes for now by splitting the filter
library into four smaller libraries.
The proposal scheme is:
It splits vtkm-filter into:
- vtkm-common, Classes that are dependencies of other filter libs.
- vtkm-contour, Contour class and its instantiations.
- vtkm-contour, Gradient class and its instantiations.
- vtkm-extra, Classes other than Contour or Gradient that are
not dependencies.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
