9855db096 Add test for array and datas that are cleaned up after finalize
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2801
We have been noticing occasional failures of UnitTestTimer on the
dashboard for CUDA devices. The timer seems to be recording less time
than is actually elapsed.
The problem might be that the CUDA timer actually inserts fences to the
CUDA stream rather than record the current time. Thus, the actual time
might start after some pending operations complete.
To attempt to match the UnitTestTimer measurements closer to wall-clock
time, add a synchronize before starting the timer.
a0a270b42 CI: update DEVELOPER_DIR to conform to standard
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !2815
f598656d5 Enable reallocation of ArrayHandleBasic with moved std::vector
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2811
Previously, the number of buffers held by an `ArrayHandle` had to be
determined statically at compile time by the storage. Most of the time
this is fine. However, there are some exceptions where the number of
buffers need to be selected at runtime. For example, the
`ArrayHandleRecombineVec` does not specify the number of components it
uses, and it needed a hack where it stored buffers in the metadata of
another buffer, which is bad.
This change allows the number of buffers to vary at runtime (at least at
construction). The buffers were already managed in a `std::vector`. It
now no longer forces the vector to be a specific size.
`GetNumberOfBuffers` was removed from the `Storage`. Instead, if the
number of buffers was not specified at construction, an allocation of
size 0 is done to create default buffers.
The biggest change is to the interface of the storage object methods,
which now take `std::vector` instead of pointers to `Buffer` objects.
This adds a little hastle in having to copy subsets of this `vector`
when a storage object has multiple sub-arrays. But it does simplify some
of the templating.
It is possible to create an `ArrayHandleBasic` from a `std::vector`. It
is possible to move the `vector` into the `ArrayHandle` such that the
`ArrayHandle` takes over the memory. When you do this, the `ArrayHandle`
should be able to resize the data if necessary. However, this was not
working.
There were actually 3 problems that were colluding to lead to this
incorrect behavior.
1. The `Buffer` object was not allowing the reallocation of pinned data.
Pinned data means that the `Buffer`'s memory is pointing to some user
data that should stay where it is. Instead, the `Buffer` should attempt
to reallocate the pinned data using its registered realloc method. This
registered realloc method should be the think to throw the exception if
reallocation is not supported. (Technically, the memory doesn't really
need to be pinned since the data is moved and the user no longer has
direct access to it. But for implementation reasons, moved `vector` data
is pinned.)
2. The `InvalidRealloc` function was not properly throwing an exception.
This was not noticed since `Buffer` was inappropriately throwing an
exception for it.
3. The reallocation method `StdVectorReallocater` had a bad assert that
crashed the program during reallocation.
nvcc is giving me lots of annoying warnings about unused functions.
Typically, this warning is given when a function declared as static or
in an anonymous namespace is never used. The "functions" in question are
not really functions. They are templated methods (in a class in an
anonymous namespace).
Specificaly, I'm getting errors like this:
```
/.../vtkm/cont/testing/UnitTestArrayHandleDecorator.cxx(96): warning #177-D: function "<unnamed>::DecoratorTests::InvertibleDecorImpl::CreateFunctor(PortalTs&&...) const [with PortalTs=<vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleCounting<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleConstant<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandle<vtkm::Int8, vtkm::cont::StorageTagBasic>>>]" was declared but never referenced
```
That said, these warnings appear to be an annoying but harmless bug in
nvcc. This warning is in error because
1. The method in question is _definitely_ being used.
2. I'm pretty sure this warning should not be given for a templated
method even if it was never used. SFINAE alone should be enough
justification to allow this to exist without warning.
The easiest way around the spurious error is to declare these structures
in a namespace with a name.
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
The `UnitTestAlgorithm` test was running several device algorithms, but
it was not checking the results of any of them. (In fact, it was not
even setting values in the input arrays.) So, it verified that the
execution did not crash, but did not verify correctness.
Add checks to the results to make sure this executed correctly. (Part of
the reason for this change was a warning that popped up because a result
value was never used.)
8ae353ec0 Fix CUDA Architecture for CI with old CMake
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2807
The configuration for CI changed to using the newer CMake option
`CMAKE_CUDA_ARCHITECTURES` for turing builds instead of the now
depreciated `VTKm_CUDA_Architecture` setting. However, this new
setting only works for newer versions of CMake, and some of the
CI docker images still have older versions of CMake.
This happened to work on the CI because the CI was run on
machines that had the right CUDA device installed (I guess), but
did not work with the `reproduce_ci_env.py` utility. Fix this
by checking the CMake version first.
The legacy VTK file reader for unstructured grids had a bug when reading
cells of type voxel. VTK-m does not support the voxel cell type in
unstructured grids (i.e. explicit cell sets), so it has to convert them to
hexahedron cells. A bug in the reader was mangling the cell array index
during this conversion.
It is the case that arrays might be deallocated from a device after the
device is closed. This can happen, for example, when an `ArrayHandle` is
declared globally. It gets constructed before VTK-m is initialized. This
is OK as long as you do not otherwise use it until VTK-m is initialized.
However, if you use that `ArrayHandle` to move data to a device and that
data is left on the device when the object closes, then the
`ArrayHandle` will be left holding a reference to invalid device memory
once the device is shut down. This can cause problems when the
`ArrayHandle` destructs itself and attempts to release this memory.
The VTK-m devices should gracefully handle deallocations that happen
after device shutdown.
`UnknownArrayHandle` compares `std::type_index` objects to check whether a
requested type is the same as that held in the array handle. However, it is
possible that different translation units can create different but
equivalent `std::type_info`/`std::type_index` objects. In this case, the
`==` operator might return false for two equivalent types. This can happen
on OSX.
To get around this problem, `UnknownArrayHandle` now does a more extensive
check for `std::type_info` object. It first uses the `==` operator to
compare them (as before), which usually works but can possibly return
`false` when the correct result is `true`. To check for this case, it then
compares the name for the two types and returns `true` iff the two names
are the same.
There was a bug where if you attempted to copy a variant that was not
valid (i.e. did not hold an object), a seg fault could happen. This has
been changed to set the target variant to also be invalid.
6e5ad1a32 Add changelog for splitting MeshQuality filter
7f96fce77 Move MeshQualityAspectGamma to its own filter
c3fcc9464 Move MeshQualityAspectRatio to its own filter
5288afa5d Move MeshQualityCondition to its own filter
86c0e1a96 Move MeshQualityDiagonalRatio to its own filter
0adf88fbd Move MeshQualityDimension to its own filter
cb119cf23 Move MeshQualityJacobian to its own filter
2431d4fef Move MeshQualityMaxAngle to its own filter
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2792
