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>
934f085e0 Build diy as a library
f0a37ac6a Merge branch 'upstream-diy' into diy-mpi-nompi
7687aabf8 diy 2020-06-05 (b62915aa)
6ca2b9f87 Point to new version of Diy
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2123
Previously, the vtkm_unit_tests CMake function added a "NONE" argument
to the test when no device was specified. However, the correct thing to
do is to add no argument. Fixed this so that strict parsing of the test
arguments works.
Consumers of VTK-m when enabling of dropping of unused functions
will see VTK-m functions dropped. Previously this didn't happen
as VTK-m didn't build object files with the correct flags for this.
By allowing the linker to remove unused symbols we see a significant
saving the file size of VTK-m tests, examples, and benchmarks.
An OpenMP build of the tests and benchmarks goes from 168MB to
141MB which is roughly a 16% filesize reduction.
Initially I had presumed that these changes would increase link times.
But in measurements the total wall time for compilation of VTK-m has
stayed about the same ( seeing a decrease of 1.5% ). Presumably the
increased computation is offset by the reduction in file writing.
Instead of having to be called for each target you can now
pass multiple targets at once. Do note that if you pass multiple
targets you will need to pass all the sources from those targets
that need to be 'device' compiled.
This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`requires_static_builds` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`cuda_architecture_flags` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
978650b06 FindMPI works with CMake 3.8's separate_arguments
1f99fbc35 FindMPI will now work when CUDA is disabled and CMake <= 3.11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !1787
This was causing issues for downstream users of VTK-m as it exposed
a bug in CM ( cmake#17952 ) where it was evaluating against the set of
enabled languages instead of possible languages.
When both examples and tests are on, there are a few tests created that
will install VTK-m and build the example against the install to make
sure that all expected components are installed. Since it requires the
full compile of a VTK-m application (and some VTK-m applications can
take a while to compile), increase the timeout for these tests.
The timeout is currently set to 10 minutes (600 seconds).
