75cb53d3a Reset ArrayPortalToken when Detach is called
53c17a687 Release locks in ArrayHandleVirtual control portals
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1982
When `ArrayPortalToken::Detach` was called, the contained `Token` was
detached, but `ArrayPortal` being wrapped might also be holding its own
portal that it is decorating. To ensure that any dependent portals are
also detached, `ArrayPortalToken::Detach` resets itself.
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.
424dfbaf5 Add call to UpdateSeedResoltuion() to set output dataset resolution.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1981
This commit changes how CoordinateSystemTransforms write their result.
Before theoy would write their result in a DataSet in which the new
Coords where stored in a field with the name of:
- cylindricalCoordinateSystemTransform
- sphericalCoordinateSystemTransform
Now, they write their results as a DataSet in which its first Coords
are the transformed Coords. Previous Coordinates are appended
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
This commit also:
- Removes a corner case not longer used at ArrayPortalGroupVecVariable::get
- Changes doc regarding the number of offset elements in the input
array handler of ConvertNumComponentsToOffsets.
- Updates invokation of make_ArrayGroupVectVariable in multiple files
- Adds its corresponding changelog entry
1f1688483 Initial infrastructure to allow WorkletMapField to have 3D scheduling
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1938
e5a6f2d4b Make ArrayPortalWrapper more tolerant of host objects
8569359e1 Add threads library to vtkm_cont
69c03d902 Fix deadlock in rendering
14c3d90ac Fix race condition in UnitTestToken
9b876df96 Remove PortalType from ArrayHandleImplicitTraits
188d1c567 Correct "invalid" portal in ArrayHandleTransform
ec34cb56c Use new ways to get array portal in control environment
8ddde979f ArrayPortalToIterators gets custom iterator from ArrayPortalToken
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1953
The ArrayPortalWrapper is used for both execution and control portals.
When it was wrapped around a control portal that does not work on CUDA
devices, we were getting ugly warnings even though the intention was
only to use it in the control environment.
With the new thread safety/token code, the vtkm_cont library now relies
on the pthreads library (or whatever threads library is used by std on
the system). Make sure this library gets added to vtkm_cont.
Apparently when future::get returns, it is not the case that all
resources of the future are cleaned up (only that the calling function
has returned). Do not rely on this resource cleanup for the test to
pass.
The type for PortalType was declared before the class from which the
type came from. Normally this was not a big deal since the template was
resolved later, but nvcc seemed to have a problem with it.
For an ArrayHandleTransform with no inverse functor, it really
only supports read-only portals. Thus, the non-const portal
for the execution environment was set to some unused control
portal. That was causing problems with CUDA, so make the
non-const portal valid (although without a Set).
Because ArrayPortalToken does not have an IteratorType,
ArrayPortalToIterators assumed it had to wrap it in an
IteratorFromArrayPortal object. Now it uses PortalSupportsIterators
(from ArrayPortalHelpers.h) to determine whether the iterators are
there. This does work with ArrayPortalToken.
To get a portal to access ArrayHandle values in the control
environment, you now use the ReadPortal and WritePortal methods.
The portals returned are wrapped in an ArrayPortalToken object
so that the data between the portal and the ArrayHandle are
guaranteed to be consistent.
This fixes an issue where moving a Token object left the original Token
in an invalid state because the poiner to the internals was NULL. Rather
than allocate a new one, just make the Token work correctly if the
internals are NULL.
It is questionable whether there is a point to having a token object
when transfering a virtual object to a device (since there is a handle
object that is managing it anyway). Back out of passing the token all
the way down unless there is an actual need for that.
Marked the old versions of PrepareFor* that do not use tokens as
deprecated and moved all of the code to use the new versions that
require a token. This makes the scope of the execution object more
explicit so that it will be kept while in use and can potentially be
reclaimed afterward.
When a single `ArrayHandle` is given to multiple arguments of a worklet
dispatch, the `PrepareFor*` methods will be called multiple times with
the same token. If one of them is a `PrepareForInPlace` or
`PrepareForOutput`, then the two requests will deadlock. To prevent
this, allow the `PrepareFor*` to happen if the same token was used
previously.
The old version of ExecutionObject (that only takes a device) is still
supported, but you will get a deprecated warning if that is what is
defined.
Supporing this also included sending vtkm::cont::Token through the
vtkm::cont::arg::Transport mechanism, which was a change that propogated
through a lot of code.
Duplicated the new versions of PrepareFor* methods from the basic
ArrayHandle that take a token in addition to the other arguments. The
ArrayHandle attaches itself to the token and will not allow operaitons
that make the returned portal invalid until the token goes out of scope.
Later the old versions will be deprecated.
Added new versions of PrepareFor* methods that take a token in addition
to the other arguments. The ArrayHandle attaches itself to the token and
will not allow operations that make the returned portal invalid until
the token goes out of scope.
Later the old versions will be deprecated.
47249ee3c Merge branch 'master' into oruebel/vtk-m-cleanup/contourtreeaugmented
392854ee3 Replace C-tyle casts with C++ style
230ef15e4 Fix layout of array definition in unit test
712ae1063 Fix memory bug in contour tree unit test
4501afb24 Iprove array style in test
3f9988253 Remove completed TODO items
45e9684d9 Improve layout of arrays in unit test
0a897aa94 Improve layout of arrays in unit test
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1972
ba030da1d remove confusing parts of the README example code
8dcd02422 fix README.md code example
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1959
