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'.
The first CUDA worklet test requires way more time because of the overhead to
allow the driver to convert the kernel code from virtual arch to actual arch.
Like the ability to specify the vectorization level, users of CMake can
now specify what GPU architectures they want to build for. Most users
should just use the default 'native'.
* Support a REQUIRED flag that only gives an error if that flag is given.
* Move common configuration required for all devices (such as boost) to a
special device named Base.
* Make CUDA always capitalized to be consistent with the other CMake
variables.
* Rather than call include_directories, set a variable named
VTKm_INCLUDE_DIRS. This is consistent with how most CMake packages work.
* Make a CMake variable named VTKm_LIBRARIES containing all the
libraries the configured devices need.
* Automatically configure supported devices when loading the VTK-m
package in CMake.
There were a couple of files checked into the git repository with DOS
line endings. Most git implementations really expect there to be Unix
line endings and should do the appropriate conversions as necessary.
This commit should change the line endings to the appropriate Unix endings.
fd685210 Always install all device headers even when device isn't enabled.
b1663b24 Add an example of using multiple backends from a single translation unit.
fc0ff69d Methods with try/catch need to be host only.
4d635d64 DeviceAdapter Tags now always exist, and contain if the device is valid.
cf32b430 Teach Configure.h to store if TBB and CUDA are enabled.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !198
Starting in OSX 10.9, apple has deprecated the glut.h provided header
so we need to figure out how we want to do window management on OSX. I expect
the way forward is to require the developer to install openGLUT.
By default visual studio limits the number of sections in an object file
to 2^16 which isn't enough when creating some of our tests. So we enable
/bigobj which increases that number to 2^32.
When a new file is added to VTK-m, the copyright statement should go at
the top of the file. The copyright contains a date. What should that date
be? I usually set the date to the current year so older files will have
an older copyright whereas newer files will have a newer one. The check
copyright script needs to be flexible on the date.
There was an error in the script that was copied over from Dax. It was
checking for the year 2011, the start of the Dax project, and replacing
that in the text. VTK-m started in 2014, so the script really needs to
check for that year instead.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
Previously, this script would create a file the same name as the desired
output, and then move it to a file with .save appended to it if the
check failed. This is problematic with parallel builds because there is
no dependency set up between the actual header file and the one being
created. Thus, it is possible for some compiles to pick up the created
file before it is moved or deleted.
Instead, just create the file with .save appended to it so that no
compile can every accidently pick it up.
The previous behavior of the pyexpander check (in
VTKmCheckPyexpander.cmake) was to generate the file in the binary
directory and then remove it from there iff the check failed. This
caused two problems. The first is that if the check failed then the file
was deleted and there was no file to copy to the source as the
instructions suggested. The second is that if the check succeeded the
build would then use the files in the build directory rather than the
source directory, and if the programmer accidently modified the binary
files (because, for example, if a build error occured there), the
configure system would not catch that.
This change in behavior was that if the check failed, the file is
renamed to have a .save extension so that the file remains and can be
easily copied back to the source directory if that is appropriate. If
the check succeeds, the generated file is removed and a file with the
extension .check is touched. That .check file is used as a make target
to signal that the test has been performed.
The SystemInformation test always passes. It prints out the contents of
various configuration parameters. The intention is to capture this
information in dashboard reports. That way if a change causes a
dashboard failure and a developer does not have access to the dashboard,
she can look at the output of this test to see the configuration of the
build and that machine.
The CMake template for the source file that contains the main function for
tests uses functions that MSVC considers unsafe. We want to check for these
conditions but have no control over the CMake-generated test code (which
looks right anyway). This disables the warning specifically for those
source files but nothing else.
Although we cannot expect every developer to have pyexpander, for those
that do the build will automatically run it and check the expanded file
in the source code. If they match, a descriptive error is given.
We don't automatically update the file because subtle problems might
occur. It is better to alert a developer to fix the problem properly.
