windows.h was only being included for MSVC, while in UnitTestTimer.cxx, the
Windows function Sleep was being called after check for _WIN32. This was
causing compilation failure in MINGW.
Fixes#122
6d6b5991 Support reading VTK files with empty title
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !725
5355a432 Remove unnecessary library dependencies
6fdc7eb8 Add Field::GetRange and CoordinateSystem::GetBounds to library
c16236ce Use ArrayRangeCompute without specifying a device
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !710
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.
Following what was done with ArrayRangeCompute, the GetRange and
GetBounds methods are embedded into the vtkm_cont library for the most
common type lists.
Also, and probably more importantly, the device adapter is no longer one
of the arguments for either of these methods. It is no longer needed as
ArrayRangeCompute no longer needs it.
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.
There were some issues for device adapter algorithms (like scan and
reduce) for empty arrays or arrays of size 1. This adds tests for these
short arrays to the device adapter algorithm tests and fixes these
problems.
The basic storage has an implicit invariant that if the size of the
storage is 0 then the array is a null pointer. That invariant was broken
if the array was allocated and then Shrink or Allocate was called with
0. In that case, the array remained allocated by the size was set to 0.
This fixes the problem by making sure a Shrink(0) actually does an
Allocate(0) (to clear out the data) and that the basic storage always
frees its memory when allocating a 0 sized array.
d5dfb1f6 Restore ArrayRangeCompute to using a single Reduce call.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !719
8d5f4eb6 Expose the normal array's name in the MarchingCubes filter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !713
Since we don't have explicit template instantiations for CellSetExplicit
and CellSetSingleType we need to mark them as being exported from all
libraries.
18c4190d Update classes using RuntimeDeviceTracker
200928ef Add a global RuntimeDeviceTracker
a3573117 Compile RuntimeDeviceTracker.cxx with CUDA when appropriate
814b2db1 Add the implementation of RuntimeDeviceTracker to cont library
b9d3206e Move RuntimeDeviceTracker to vtkm::cont
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !707
7e34f861 Append newline to ArrayHandle summaries.
6f417a38 Add type information to array summaries and cast/call errors.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !705
The clip worklet will change the number of points in the result
set by adding points at the clip boundaries. The filter was updating
the clipped scalar array to reflect the new points, but not the actual
coordinate array.
This patch will cause the clip filter's result dataset to contain the
correct number of points and no longer automatically map the scalar
array onto the output, since this is easily done via the filter API.
