Added a name option that allows the same benchmark executable to be used
in multiple benchmark tests. This allows the benchmarks to be separated.
Also added an option to pass customized arguments to the benchmark
executable to overwrite the default values.
73cb38d86 Output complete list of libraries for external Makefiles
d87316fbf Create a list of all modules being built
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nicole Marsaglia <marsaglia1@llnl.gov>
Merge-request: !2901
Several revisions ago, the ability to use virtual methods in the
execution environment was deprecated. Completely remove this
functionality for the VTK-m 2.0 release.
When the configure modules were first created, there were some hacks
around filters that had not yet moved to the new filter mechanism. These
can (and should) be removed.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
This commit reflects the changes of VTK-m API/ABI release plans in
which we attempt ABI compatibility in patch releases.
- It also sets the version/soname for diy thirdparty module lib
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
A compiler or linker may give an error if a .cxx file is empty (that is,
declares no symbols). This can happen if an instantiation declaration
gets removed during the compile either through preprocessor macros or
SFINAE.
To protect against this, declare a simple integer with a unique symbol
in each instantiation file. The overhead is very small and will prevent
compile/link errors.
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.
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>
