It is very easy to cause ODR violations with DeviceAdapterTagCuda.
If you include that header from a C++ file and a CUDA file inside
the same program we an ODR violation. The reasons is that the C++
versions will say the tag is invalid, and the CUDA will say the
tag is valid.
The solution to this is that any compilation unit that includes
DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled
must be invoked by the cuda compiler.
When you install pyexpander with pip under python 3, the executable
script is now named expander3.py instead of expander.py. Support using
either file.
We now have a couple of the examples also being built against
the installed version of VTK-m as a test. This allow us to verify
that VTK-m installs and can be found properly.
0581b368f Fix issues with importing installed vtkm::cuda after refactor.
ed4374b05 diy 2019-03-13 (e8e68c7c)
b85dcf229 Add more vtkm_cont compilation units to device_sources.
9014de0eb Suppress new host/device warnings for cuda 10.1.
04a464cc4 Update cuda detection to create vtkm::cuda as an interface library.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1582
Previously we didn't realize that the cmake_install.cmake files
would properly walk the entire install tree. Therefore we would try
to find each one manually and invoke it. This caused problems with
dirty continuous build directories, and was actually unneeded as
just including the root cmake_install.cmake is sufficient.
In certain circumstances (currently, when logging is enabled), VTK-m
libraries depend on the threading library. However, when the VTK-m
package was included from an external project, it did not automatically
find the threads package. This change makes the Threads library loaded
when the VTK-m package is found.
The purpose of the TestBuild infrastructure was to confirm that
VTK-m didn't have any lexical issues when it was a pure header
only project. As we now move to have more compiled components
the need for this form of testing is mitigated. Combined
with the issue of TestBuilds causing MSVC issues, we should
just remove this infrastructure.
Also
- Renamed vtkm::cont::make_DeviceAdapterIdFromName to just overload
make_DeviceAdapterId.
- Refactored CMake logic for unit tests
- Since we're now querying the device tracker for the names, they
cannot be all caps.
- Updated usages of InitLogging to use Initialize instead.
- Added changelog.
VTK-m has been updated to replace old per device worklet testing executables with a device
dependent shared library so that it's able to accept a device adapter
at runtime.
Meanwhile, it updates the testing infrastructure APIs. vtkm::cont::testing::Run
function would call ForceDevice when needed and if users need the device
adapter info at runtime, RunOnDevice function would pass the adapter into the functor.
Optional Parser is bumped from 1.3 to 1.7.
The FindTBB modules that come with packages such as OSPRay don't
provide TBB_LIBRARY_RELEASE but instead only provide TBB_LIBRARY.
If TBB_LIBRARY_RELEASE isn't found, and TBB_LIBRARY is we will use
that as the release library
Fixes issue #276.
OpenMP tests when run in parallel exhibit negative scaling as we
have N openMP processes each spawning N threads. We speculate that
this causes excessive context switching and swapping and reduces
performance.
9861cdecb Use CMake to automatically set policies to NEW.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Allison Vacanti <allison.vacanti@kitware.com>
Merge-request: !1270
CMake 3.12 introduces a ...<max> syntax in the version given to
cmake_minimum_required to automatically set policies to NEW up
to that version. Use it to avoid listing policies explicitly.