Many of the fancy `ArrayHandle`s are read-only and therefore connot
really create write portals. Likewise, many `ArrayHandle`s (both read-
only and read/write) have no way to resize themselves. In this case,
implementing the `CreateWritePortal` and `ResizeBuffers` methods in the
`Storage` class was troublesome. Mostly they just threw an exception,
but they also sometimes had to deal with cases where the behavior was
allowed.
To simplify code for developers, this introduces a pair of macros:
`VTKM_STORAGE_NO_RESIZE` and `VTKM_STORAGE_NO_WRITE_PORTAL`. These can
be declared in a `Storage` implementation when the storage has no viable
way to resize itself and create a write portal, respectively.
Having boilerplate code for these methods also helps work around
expected behavior for `ResizeBuffers`. `ResizeBuffers` should silently
work when resizing to the same size. Also `ResizeBuffers` should behave
well when resizing to 0 as that is what `ReleaseResources` does.
The `ReleaseResources` method should work for all arrays (even if it
effectively does not do anything). However, the implementation of
`ReleaseResources` is generally to call `Allocate` with 0. Several fancy
arrays balk at this because it is resizing a read-only array. There
should be an exception for this.
This class was used indirectly by the old `ArrayHandle`, through
`ArrayHandleTransfer`, to move data to and from a device. This
functionality has been replaced in the new `ArrayHandle`s through the
`Buffer` class (which can be compiled into libraries rather than make
every translation unit compile their own template).
This commit removes `ArrayManagerExecution` and all the implementations
that the device adapters were required to make. None of this code was in
any use anymore.
`ArrayTransfer` is used with the old `ArrayHandle` style to move data
between host and device. The new version of `ArrayHandle` does not use
`ArrayTransfer` at all because this functionality is wrapped in `Buffer`
(where it can exist in a precompiled library).
Once all the old `ArrayHandle` classes are gone, this class will be
removed completely. Although all the remaining `ArrayHandle` classes
provide their own versions of `ArrayTransfer`, they still need the
prototype to be defined to specialize. Thus, the guts of the default
`ArrayTransfer` are removed and replaced with a compile error if you try
to compile it.
78aa463da Fix compile error when template parameter shadows superclass
905b5a02b Call PrepareForControl to get transform for undefined device
650e416cc Convert ArrayHandleTransform to new buffer-style-array
76880dd8c Enable ExecutionObjectBase::PrepareForExecution for DeviceAdapterId
b0146b1e4 Fix issue with CreateBuffers function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2341
I'm too lazy to look up the C++ spec, but it seems like template
parameter names would shadow the same names from a superclass.
Apparently that is not the case for Visual Studio. The `Storage` for the
cast array inherits from the `Storage` of the transform array. The
latter declares a private type named `SourceStorage`, and that is being
used instead of the former's `SourceStorage` template parameter. You
then get an error for accessing a private member that you did not want
in the first place.
Fix the problem by changing the name of the template parameter.
a10d7be0b Revert back from ResizeVector to Allocate but setting vtkm::CopyFlag::On
76dcacc09 Revert from Allocate to ResizeVector, but initialize with 0 instead of NO_SUCH_ELEMENT
774d8df37 Renamed ResizeIndexVector to ResizeVector and fixed bad resize call
94697e0e0 Fix unused variable warnings when logging is disabled
25bacf928 Removed return statement that is never reached
635510de0 Make device tracker named variable
58515c2e2 Use ScopedRuntimeDeviceTracker to enforce the device rather than setting it explicitly
bda234c6e Use CopySubRange to ensure arrays are not being shrunk
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2279