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
