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
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
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.
A relatively new convention is to use `DeviceAdapterTagUndefined` when
referring to the host. When getting the transform functor for the
control, detect when the device is undefined and call
`PrepareForControl` instead of `PrepareForExecution` with the undefined
device.
Previously, the implementation of `ExecutionObjectBase` required you to
call `PrepareForExecution` with a specific `DeviceAdapterTag`. If you
passed in a `DeviceAdapterId`, which is the superclass of all device
adapter tags, you would get a compile error.
As we move to the new `ArrayHandle` style, it is more common to handle a
straight `DeviceAdapterId` without templating. Perhaps there will be a
time when the templated version is removed.
1fb4c0499 Rename ArrayHandle::FakeBuffer to BufferAsStorageWrapper
05fea4d17 Bridge old-style ArrayHandle to new-style
62c509520 Save host portal for ArrayHandleVirtual in array instead of portal
bc3a7d8e2 Restore composite of transform in UnitTestParticleDensity.cxx
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2339
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.
1. The code now works without CUDA_LAUNCH_BLOCKING set by using explicit
synchronizations where required.
2. The code has also been modified to use thread specific memory spaces,
which for Kokkos' Cuda backend means per thread streams.
fb130d42d Remove test for ArrayHandleCompositeVector with bad lengths
7cbf40d5b Back out of using a composite of transform arrays
7ff1a690d Support ArrayHandleCompositeVector with 1 component
5391e353a Convert ArrayHandleExtractComponent to new buffer-style array
22fac15b3 Convert ArrayHandleCompositeVector to new buffer-style array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2330
As we update the `ArrayHandle`s to the new buffer style, simplify
`ArrayHandleSwizzle` by implementing it on top of
`ArrayHandleTransform`. Also, introduce some C++11 template concepts to
handle variable arguments better.
In this conversion, some features have been removed. Previously if the
swizzle dropped some components, you were still allowed to write to the
array. This would be an in place write that would only update the passed
components. This feature has been removed and if any components are
dropped, the array becomes read only. If all components are swizzled,
then the array becomes writable (through templating).
Another lost feature is that the swizzle map is no longer checked for
correctness. The array handle just assumes that the indices are correct.
It should be noted that it does not look like `ArrayHandleSwizzle` is
actually used anywhere. If it is not used by any customers, we may
want to consider deprecating the class.
The old version of `ArrayHandleCompositeVector` would check (at
construction) to make sure that all the arrays had the same length. This
check has been removed because (1) it did not always catch all problems
(such as if the input arrays change), (2) debug builds check for out-of-
range array accesses anyway, and (3) it required a lot of extra template
expansion.
Because that check has been removed, also remove the part of the
`ArrayHandleCompositeVector` test that checks this check.
When `ArrayHandleCompositeVector` has only 1 component, it is supposed
to have a special template that uses the base value type rather than a
`Vec` of that type. However, the `Storage` with the value type was
missing. I'm not sure how we weren't getting compile errors before, but
moving to the new buffer arrays seems to bring about the expected error.
The `StorageImplicit.h` header is no longer used. However, just removing
it causes compiles to fail if they include it. To make the transition
better, re-add this file, but cause a deprecation warning if it is
included.
It should be noted that a break in backward compatibility is introduced.
The implementation class passed to `ArrayHandleDecorator` changed the
specification of `AllocateSourceArrays`. Thus, decorators that were
previously allocatable now no longer will be until that method is
updated to the new form.
A large portion of the VTK-m filters are now compiled into the
vtkm_filter library. These pre-built filters now don't include
the respective hxx file to remove the amount of template
instantiation users do.
To verify that this removal reduces compiler memory ( and maybe time)
I profiled the compiler while it building filter tests in debug mode.
Here is a selection of results:
```
CleanGrid 10.25s => 9.01s, 901MB => 795MB
ExternalFaces 13.40s => 5.96s, 1122MB => 744MB
ExtractStructured 4.69s => 4.75s, 492MB => 492MB
GradientExplicit 22.97s => 5.88s, 1296MB => 740MB
```
The array given to `ArrayHandleGroupVec` should really have a number of
values that divides evenly among the `Vec`s. Previously, if this was not
the case, an error exception was thrown. These changes allow this
condition. Extra components are dropped and a warning is logged.
Most `ArrayHandle` implementations must create an
`std::vector<vtkm::cont::internal::Buffer>` object. It is most helpful
to create it in the constructor when initializing the superclass (so the
superclass does not have to create it's own). Added a `CreateBuffers`
convenience function to make it easy to build these vectors.
