This allows you to handle just about every type of array with about 10
basic types. It allows you to ignore both the size of `Vec`s and the
actual storage of the data.
The typical use case of `ArrayHandleStride` is to flexibly point into
another array, often looking at a single component in an array. It is
typical that multiple things will be accessing the same array, and bad
things could happen as they all try to resize. There was some code to
try to figure out what the size of the original array was, but it was
fragile.
It is safer for now to disable the behavior altogether. If a use case
pops up, we can reintroduce the code.
`ArrayExtractComponent` allows you to get a component of an array.
Unlike `ArrayHandleExtractComponent`, the type you get is always the
same: an `ArrayHandleStride`. This way, you can get an array that
contains the data of an extracted component with less templating and
potentially dramatically reduce the amount of code generated (although
some runtime integer arithmetic is added).
`vtkm::VecFlat` is a wrapper around a `Vec`-like class that may be a
nested series of vectors. For example, if you run a gradient operation
on a vector field, you are probably going to get a `Vec` of `Vec`s that
looks something like `vtkm::Vec<vtkm::Vec<vtkm::Float32, 3>, 3>`. That
is fine, but what if you want to treat the result simply as a `Vec` of
size 9?
The `VecFlat` wrapper class allows you to do this. Simply place the
nested `Vec` as an argument to `VecFlat` and it will behave as a flat
`Vec` class. (In fact, `VecFlat` is a subclass of `Vec`.) The `VecFlat`
class can be copied to and from the nested `Vec` it is wrapping.
There is a `vtkm::make_VecFlat` convenience function that takes an
object and returns a `vtkm::VecFlat` wrapped around it.
7475c318b VTK-m now uses CMake's future HIP lang for Kokkos+HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2351
88b207d74 reproduce_ci_env doesn't try to do any form of EOL normalization
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2353
7811cc4b1 Add standard support for read-only storage
a6b9d5c49 Add tests for ReleaseResources of fancy arrays
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2345
f5b776b74 VTK-m Properly computes frameworks on mojave / big sur
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nick Thompson <nathompson7@protonmail.com>
Merge-request: !2352
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