73c05c10 Suppressions of __host__ warnings shouldn't trigger internal compile errors
5100e559 Suppress warnings about calling __host__ functions from CUDA 9.0
282c515e Suppress warnings about calling __host__ functions from CUDA 8.0
5dfdc830 Cuda will also print error/warning pragma values now.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1150
3211c150 add support to run test with MPI.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1148
faf916f1 Fix condition on which to get the TBB version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1140
`vtkm_unit_tests` now supports an MPI option that can be used to add
test that run with MPI. Adding `UnitTestFieldRangeGlobalCompute` to test
global ranges for fields.
a37a3f39 Examples that use glu functions now properly link to OpenGL::GLU
a44ad273 Make sure Rendering example doesn't conflict with rendering testing name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Merge-request: !1147
CUDA currently doesn't support building for `compute_` and having compiled
in virtuals ( using separable compilation ). So we need to transition everything
over to `sm_`
The FindTBB.cmake module gets the TBB version by reading and grepping
one of the header files. Before doing so, it checks to see if the
version variable already exists. The problem was it was checking
TBB_VERSION, which was never created. Worse, other build systems might
set this for us (for example, the ParaView superbuild). Correct this by
making sure both TBB_VERSION_MAJOR and TBB_VERSION_MINOR are set.
Previously there was a special build for the template source files
(.hxx) that installed them but did not create the test builds (because
they cannot be built outside of their enclosing .h file). It also added
an entry into the IDE that let them show up on the file list. However,
because they were not explicitly built as part of something actually
compiled, they did not have an compile options associated with them.
This caused confusion in some IDEs where it could not find the header
files it included, which made it more frustrating to edit them.
Due to limitations in the CUDA MSBuild support and how CMake stores the language
of a source file, we had to change VTK-m over to using generated .cu files
to signal when we want CUDA compilation.
The location of VTKmCheckPyexpander.cmake was originally set to $
{CMAKE_SOURCE_DIR}/CMake. This is correct with respect to the VTK-m
install, but incorrect if VTK-m is being included as a module in another
project (like VTK). Change the location to ${VTKm_CMAKE_MODULE_PATH},
which should be correct in every case.
A ParaView user noted that the determine version script (which is
essentially the same for ParaView and VTK-m) incorrectly used the
results of git describe when the source actually came from a tarball
distribution that was placed in another git archive. (The SHA was
incorrectly taken from the enclosing git project.) See the ParaView bug
for more details on the report:
https://gitlab.kitware.com/paraview/paraview/issues/17761
This fix simply checks to make sure the the source directory has the
.git subdirectory expected in all git projects.
There are still some warnings left:
* Some text in markdown files are incorrectly picked up as
doxygen commands
* ArrayPortalTransform weirdly inherits from a specialized
version of itself. It's technically correct C++ code, but
gives doxygen fits.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
When used as a submodule, redefining LIBRARY_OUTPUT_PATH and
EXECUTABLE_OUTPUT_PATH fails since the CMake default variables from the
containing project already exist.
CMake has several default build types, but if nothing is specified when
configuring your project it defaults to an empty string and no optimization
flags are used.
It will now default to using a debug build if the source directory is a git
clone, or a release build if not. Additionally when using ccmake or cmake-gui
this will provide a nice list of possible options for CMAKE_BUILD_TYPE.
when adding target_include_directories for the rendering library. I believe this happens because cmake determines that the variable VTKm_OPENGL_INCLUDE_DIRECTORIES is dependent on OPENGL_INCLUDE_DIRS( which is NOTFOUND). This causes cmake to raise an error even when VTKm_OPENGL_INCLUDE_DIRECTORIES is set to "".
In the FindTBB module, add the directory of the TBB includes and the
directory of the base tbb library to the list of paths to search for
TBB includes and libs, respectively. The reason is that TBB has its
initial includes and libraries and then has its support libraries.
Rather than enter entire paths 9 separate times, this allows you to
select the include directory once and one TBB library and the rest will
be automatically populated.
The vtkm_library macro was making all VTK-m libraries depend on all
other VTK-m libraries previously defined. This potentially creates
unnecessary linking. Instead, only depend on the backend libraries (like
TBB) and libraries explicitly given.
Most uses of ArrayRangeCompute just want to get the range of the data
and probably don't have a particular device in mind. Thus, it is better
to use a TryExecute internally use whatever devices are available.
Note that when using TryExecute, the calling code is expected to be able
to support all devices. That might not always be the case. Thus, I am
experimenting a bit with how we incorporate this in a library. The
advantage of having the code compiled in a library is that you only have
to compile it once and the calling code does not need to worry about
CUDA, etc.
However, because ArrayRangeCompute is templated, we can only pre-compile
some subset of array handle types. The most common are compiled into the
code (matching all the predefined ArrayHandles as well as some special
cases). If the code wants to use some other type, it has to include
ArrayRangeCompute.hxx. The only place where this is necessary is a test
that intentially trys to find the range on an uncommon type.
If array portals were to support virtual methods, then we should be able
to modify this code so that we could precompile for all array handle
types.
The RuntimeDeviceTracker.cxx contains a library method that queries the
CUDA device, which only works if compiled as a CUDA source file.
This set up will allow code that is not compiled with CUDA use a
RuntimeDeviceTracker with other code that does use CUDA.
fc68362d Build benchmarks even when testing is not enabled.
31e20859 Fix typo.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !696
Previously if you constructed an array handle without allocating it, you
would get an error if you tried to use the array as input. This
conflicted with some recent changes to accept empty vectors.
Now when you try to use an unallocated ArrayHandle as input (calling
PrepareForInput or PrepareForInPlace), it internally calls Allocate(0)
(to establish internal state) and sets up a valid execution ArrayPortal
of size 0.
Class that need to be passed across dynamic library boundaries such as
DynamicArrayHandle need to be properly export. One of 'tricks' of this
is that templated classes such as PolymorphicArrayHandleContainer need
the Type and Storage types to have public visibility.
This makes sure that all vtkm storage tags have public visibility so
in the future we can transfer dynamic array handles across libraries.
During a round of resolving compile issues on the dashboard, the test
builds were disabled, but never re-enabled. This change re-enables the
test builds.