What was previously declared as `ArrayHandleNewStyle` is now just the
implementation of `ArrayHandle`. The old implementation of `ArrayHandle`
has been moved to `ArrayHandleDeprecated`, and `ArrayHandle`s still
using this implementation must declare `VTKM_ARRAY_HANDLE_DEPRECATED` to
use it.
The new-style `ArrayHandle` uses `Buffer` objects to manage data. Thus,
when one is decorating the other, it expects to find the `Buffer`
objects, which the old-style `ArrayHandle`s do not have. To make the two
work together, fake buffers in the old-style arrays.
The buffers in old-style arrays are empty, but have metadata that points
back to the `ArrayHandle.
Previously, when you got a host/control portal from
`ArrayHandleVirtual`, you got a version of an `ArrayPortal` that manged
its own reference to the virtual structure that was implementing the
portal. This was not done for device/execution portals because those
objects could not do the appropriate resource management from the
execution environment.
Rather than releasing the host object to the portal, keep the host
object managed by `StorageVirtual`. This allows the control and
execution portals to be the same type, which we will need to be friendly
with new array objects.
As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.
1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.
To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.
Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.
As a general C++ "rule of three," if one of a copy constructor, copy
assignment, or destructor is defined, all three should be defined. Some
compilers issue warnings if this rule of three is violated.
It is sometimes the case that we define a destructor simply because it
is only valid in the control environment. When doing so, add
implementations for copy constructor and assignment as well.
This fixes an issue where getting a `ReadPortal` or a `WritePortal` from
an `ArrayHandleVirtual` could cause a deadlock from a held token even if
the returned portal was detached or destroyed.
The problem was that `ArrayHandleVirtual` was keeping a reference to the
`ArrayPortal` from the concrete array. This was because the returned
`ArrayPortalRef`, which was designed to work on both control and
execution environments, had no good way to destroy the portal. This
meant that the `ArrayHandleVirtual` was caching a copy of the concrete
array's portal. This was not a great idea before because the array could
get invalidated. It is worse now because it keeps the concrete array
locked.
Fixed the problem by subclassing `vtkm::ArrayPortalRef` to make a
control-specific version that will delete the concrete portal on its own
destruction.
Previously, ArrayHandleVirtual was using the default Transfer object.
This was problematic because it would copy/allocate things in the
execution environment independently from the array that it was wrapped
around. This caused several negative effects, particularly for CUDA
devices. First, if the data were already on the device (or the array is
implicit), a second copy of the data would be made. Second, the copy to
the device is likely less efficient. Third (and worst of all), the data
did not always get pulled back to the original array correctly.
This commit also contains instantiations of ArrayHandleVirtual and its
components for the most common types.
If an ArrayHandleVirtual is constructed without an underlying concrete
array handle, then the Storage<T, StorageTagVirtual> holds a
StorageVirtual pointer that is null. Generally, a null
ArrayHandleVirtual cannot do much, but its operations should still be
correct. There were a few places where the Storage would blindly try to
use its StorageVirtual pointer without checking it first. This adds some
conditions that should correct the behavior when StorageVirtual is null.
Previously, ArrayHandleVirtual was defined as a specialization of
ArrayHandle with the virtual storage tag. This was because the storage
object was polymorphic and needed to be handled special. These changes
moved the existing storage definition to an internal class, and then
managed the pointer to that implementation class in a Storage object
that can be managed like any other storage object.
Also moved the implementation of StorageAny into the implementation of
the internal storage object.
