The test build file did not actually define any symbols, so the linker
might give a warning about it not being used in the library. Define some
unique symbol so that the linker will not complain.
If you tried to create test builds of a header.h and header.hxx, you
would get an error about building two files with the same name (tried to
build header.cxx for both of them). Fixed this by adding the original
extension name to the source file name.
The CMake configuration stopped creating any of the test builds. There
were a couple of errors introduced into this function that needed to be
fixed.
First, the condition on whether the testing should be skipped got
reversed. It was trying to create test build files for all the headers
that were not supposed to be built instead of the ones that were.
Second, the list of source files to build was not created correctly. The
set command that stored the name of the source file got removed, and so
nothing was being added to the list. I restored the variable and used
that consistently for the source file name.
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.
Change the OpenGL configuration to require GLEW as most of the OpenGL
code actually requires GLEW (or will as soon as the VBO branch gets
merged in).
Also removed some stray find_package commands and rearranged the
configuration to use the vtkm_configure_component_* commands instead.
Recently VTK-m was changed to require C++11. The internal builds set
properties to require C++11, but these never make it to the
configuration for projects that use the VTK-m package (i.e. not declared
in VTKmConfig.cmake).
This change adds a new CMake target, vtkm, which is an interface. It
does not point to an actual library, but it allows code that links it in
to have the appropriate compile flags.
The previous attempt at using caching to prevent duplicate commands, failed
when you tried to build VTK-m itself and had examples turned on. Now we
just don't add the std=c++11 option if it already exists.
This makes the name more consistent with the names of the other VTK-m
CMake options.
Also changed the default to be ON. I do not see a big downside to
compiling the rendering library most of the time.
When you called find_package multiple times with VTK-m components such as CUDA
would continuously append to variables, causing a variable to have the same
parameter listed multiple times.
Properly cache the results of CUDA native detection.
I found some issues when using VTK-m from inside VTK. The issues where
that on reconfigures the device architectures flags where dropped by the
caching mechanism.
See merge request !555
I found some issues when using VTK-m from inside VTK. The issues where
that on reconfigures the device architectures flags where dropped by the
caching mechanism.
123bc8b6 Add a configuration error if OSMesa was not found
0a61085d Do not load OpenGL libraries if OSMesa already loaded
640e92c7 Add VTKm_ENABLE_OSMESA option
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !548
It is standard now in CMake to make the CMake configuration variables
(like those specifying paths to files for a library) are marked as
advanced. Otherwise, the CMake configuration gets overwhelmed by lots of
parameters that are either found automatically or only need to be set
once.
The test builds are created by making some library targets for libraries
with nothing useful. (The intention is to test a build of the code, not
use the built code.) To prevent linking issues, each test build defines
a function named Test_Build_For_<headername>.
However, when BUILD_SHARED_LIBS was on for windows, it never actually
exported anything because dlls need a __declspec(dllexport) on it. Thus,
nothing was exported from the library, and that could cause issues with
the build system (e.g. https://public.kitware.com/Bug/view.php?
id=15885). To get around the issue, always compile the test build
libraries as static.
Rendering library
Pull the majority of the implementation of the rendering
package into a library for better compile performance.
See merge request !527
Always load "Base" component in find_package
A big part of the VTK-m find_package configuration is a set of
components that load different parts of VTK-m's configuration. If you
load none of the components, you do not actually get enough to compile
any part of VTK-m, which is confusing. To get around this, always load
the "Base" component.
See merge request !541
The target_compile_options expects the arguments to be in a CMake list.
However, the variables used to hold CMake lists are space separated to
be just put in a command line. Thus, call separate_arguments on the
string before using it.
We moved to using the more modern signature of target_link_libraries,
but on some platforms this causes a configuration error. The issue is
that cuda_add_library internally uses target_link_libraries with the old
signature, and CMake does not allow us to use both signatures on the
same target.
Currently, the only library created is for the rendering package. If
VTKm_BUILD_RENDERING is off, then no libraries are created. If no
libraries are created, then there is nothing that declares a VTKmTargets
export. If there is nothing that creates a VTKmTargets export, the
export command fails.
Aaarg!!!! I can't even find a way to query whether an export is valid
(in the same way you can query whether a target exists). I added a
global variable that recorded whether vtkm_library added a library
(where things are added to the VTKmTargets export). The export command
is called if any libraries were created, a stub is created and installed
otherwise.
A recent change to the rendering library has a source code in the
internal subdirectory references from the rendering directory. This
makes sense as we want all the components (whether externally visible or
not) to be in the same library. However this broke the SourceInBuild
tests as the source code was technically not referenced from the
CMakeLists.txt in the same directory.
Anticipating that this could be a common occurance, I modified the test
to also check the CMakeLists.txt in the parent directory.
When things in the rendering library need to execute things in parallel
(outside of another rendering library like OpenGL) it should run it on
available parallel devices. This means using TryExecute to attempt on
whatever devices may be available. It also means that some of the
sources must be compiled with CUDA's nvcc. To enable this, made a code
wrapping mechanism to compile within a .cu file.
I have noticed at least on my windows machine that source code that uses
the rendering package is taking a long time to compile. The rendering
library does not rely much on templates and more on virtual methods.
Thus, it is a good candidate for moving to a library so that it need be
compiled only once.
This sets up the configure scripts to create the library. There is also
a simple port of one class to the library. More will follow.
A big part of the VTK-m find_package configuration is a set of
components that load different parts of VTK-m's configuration. If you
load none of the components, you do not actually get enough to compile
any part of VTK-m, which is confusing. To get around this, always load
the "Base" component.
Often times packages are loaded multiple times simply to resolve
dependencies. This can mean the same status is given multiple times
(particularly when a component does not load). This change reduces that
a bit by making sure the messages from the VTK-m configuration only
happen once.
The configuration for OpenGL can change depending on whether OSMesa is
used, so make sure OSMesa is always configured first so that the
"correct" OpenGL is used.
1. Change set_property(...) to target_* commands
2. Remove explcit adding of CMAKE_CXX_FLAGS_WARN_EXTRA as compile option
3. Add /bigobj option to VTKm_COMPILE_OPTIONS under MSVC
The UnitTestMapperGLFW test was coded to run in an interactive mode,
which was problematic when simply running the test. If no one was there
to exit the interactive window, the test would time out. This change
adds a "batch" mode that is on when run by ctest. The batch mode runs
through all configurations and exits.
The VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
There were a couple of places where the configure scripts did not add
either includes to VTKm_INCLUDE_DIRS or libraries to VTKm_LIBRARIES.
The biggest offender was when the examples used find_package to load the
VTK-m configuration it needed. find_package cleared out the includes and
libraries, but it did not clear out the VTKm_<COMPONENT>_FOUND
variables. Normally, these variables would not be set before
find_package is called, but in this case the examples were called after
some partial configuration. I got around this issue by clearing out all
the *_FOUND variables in VTKmConfig.cmake.
a6609311 Silence auto_ptr deprecation warnings with older boosts ( < 1.61 )
6d38f44d Update ListTag and DispatcherBase to leverage C++11 features.
ea0d84a8 Remove VTK-m Variadic defines and replace them with a single CXX11 define
77121d18 Add support to VTK-m to build with C++11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !475
This fixes a issue where when CUDA is enabled and VTKm_CUDA_Architecture is
set to native, we would run nvcc each time somebody explicitly enabled the
CUDA component ( each example ).
In an earlier commit, we took out the "-w" flag for CUDA builds, which
disables all compiler warnings. The original reason for disabling
warnings was an errant warning about unused functions. It was taken out
because the visual studio compiler complains when this flag overrides
another warning flag (such as /W3).
Although the visual studio compiler was not complaining about unused
functions, we were getting lots of other warnings. These warnings did
not seem to actually come from the visual studio compiler. They probably
come from whatever CUDA uses for a device compiler. But it is unclear
how to specifically target these warnings.
So, the easiest solution is to add the "-w" flag back. To get around the
other warning, we now (hopefully temporarily) remove warning flags from
CMAKE_CXX_FLAGS to prevent the conflicting flags.
To detect what CUDA hardware is native, a simple CUDA program is
compiled. However, CMake was not necessarily pointing to the correct
source file, so the compile was failing.
This change makes sure that VTKm_CMAKE_MODULE_PATH is properly set and
uses that variable to find the source file.
Because the CUDA builds were experiencing some warnings about unused
functions, a -w flag was added to our nvcc flags. This effectively
turned off the warning (which was part of -Wall). But on Visual Studio
this added flag was causing a warning of its own because it overwrote
the /W3 flag. So turn this off for Visual Studio.
I don't think Visual Studio gives this warning anyway. If it does, we
can add a specific flat to suppress that warning.
When doing parallel builds with CUDA's nvcc on windows, you often get
errors about multiple programs trying to write to a pdb file at once. To
get around this, add the /FS flag on windows for the CUDA compiler.
Have VTK-m eat its own dog food when it comes to its configuration. Load
the same configuration for building VTK-m as would be loaded (more or
less) when using find_package(VTKm) in an external project.
This includes adding lots more components to the packages so that all the
setup (e.g. OpenGL, TBB, etc.) can be set up correctly. It is also a
significant change to how these components are declared. The component
configuration is simplified a bit and unified in a single file.
This is a little tricky since they don't seem to have considered that
you will have files in both the source and build directory or that the
file locations will not match exactly with the install locations.
On Unix-based systems, you can directly execute a script and the system
will automatically run it through its associated interpreter. However,
on Windows this does not work. You just get an error about the script,
which is just a text file, being an invalid executable.
This was an issue when running pyexpander. Now, Python is called
directly for pyexpander.
Without a working directory specified, the executable will be output
to what-ever working directory cmake-gui was launched from. In most cases when
CMake is the 'system' version, this is a directory that you don't have write
access to.
The benchmarking header files were not listed. Not a huge deal since
these files do not need to be installed, but they should be listed
anyway. Changed the vtkm_save_benchmarks CMake macro to be able to list
headers.
Also moved everything from BenchmarkDeviceAdapter.h to
BenchmarkDeviceAdapter.cxx. Since this code shouldn't need to be
included by anything except this benchmark, there is no need to have it
in a header file. Plus, the build changes would mean that any change in
the header (where most of the source was) could cause all code in this
directory to recompile. I do not want to set that precedent.
The test is a simple CMake script that finds all files in the build
directory with certain extensions (.h, .cxx, etc.) and makes sure that
the filename is listed somewhere in the CMakeLists.txt file of the same
directory. If the filename is listed in the CMakeLists.txt file, then
there is a good chance it is being addressed by the build.
This should help catch when header files are not being installed. It also
should help verify that test builds are being done on all files. It will
also highlight dead source files.
780cef61 Bump up the CUDA timeout as some of our Maxwell machines are timing out.
e5c3f9c4 Solve reduce by key bugs with cuda 7.5 + maxwell hardware.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !411
I like to have all the source files used in VTK-m to be explicitly
declared as source files in CMake so that when CMake builds a project file
for an IDE, all the source files are shown and monitored by the IDE. This
makes working with the files much easier.
3eec5e86 ICC: disable vectorization as both ivdep and simd generate bad code.
f021e4a5 Make the default for vectorization be none.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !368
A default of 'native' has the concern that people using vtk-m might by
default generate non portable binaries or libraries and will become
very hard to track down why this happens. So do enable vectorization we
default to 'none'.
