Commit Graph

8 Commits

Author SHA1 Message Date
Kenneth Moreland
65c2261892 Add default constructors/destructors/assignment to ArrayHandle classes
The ArrayHandle classes all exclusively work in the control environment.
However, CUDA likes to add __device__ to constructors, destructors, and
assignment operators it automatically adds. This in turn causes warnings
about the __device__ function using host-only classes (like
boost::shared_ptr). Solve this problem by adding explicit methods for
all of these.

Implemented this by wrapping up all these default objects in a macro.
This also solved the problem of other constructors that are necessary
for array handles such as a constructor that takes the base array
handle.
2015-10-21 13:36:27 -06:00
Kenneth Moreland
7ff62d8d6b Explicitly add destructors and copy constructors to ArrayHandle classes
Under CUDA, the default constructors and destructors created are exported
as __host__ and __device__, which causes problems because they used a boost
pointer that only works on the host. The explicit copy constructors and
destructors do the same thing as the default ones except declared to only
work on the host.
2015-10-21 07:50:52 -06:00
Kenneth Moreland
882c20a2cb Support DynamicArrayHandle::CastToArrayHandle for fancy ArrayHandles
Basically, this entails adding a constructor to each fancy ArrayHandle
that accepts the base ArrayHandle with the appropriate type and storage.
2015-09-20 00:28:11 -06:00
Robert Maynard
5ec088e916 Remove IteratorType from ArrayHandlePermutation. 2015-07-14 10:11:27 -04:00
Robert Maynard
011b79ba00 Verify permutation array works with Sort and Reduce. 2015-06-19 08:44:21 -04:00
Robert Maynard
6b8e7822be The Copyright statement now has all the periods in the correct location. 2015-05-21 10:30:11 -04:00
Kenneth Moreland
1c733d4e32 Update the ArrayTransfer classes to new interface merged in
For what it's worth, the implementation of these classes simplified
quite a bit.
2015-04-30 22:01:02 -06:00
Kenneth Moreland
fe444e1267 Add ArrayHandlePermutation
Also found a problem with ArrayHandle that manifests itself with derived
types when you first do a PrepareForInput and then a PrepareForInPlace.
The ArrayHandle assumes the data is already moved to the device and
skips the in place call to the array transfer. However, this means the
transfer of the derived array handle does not have a chance to set up
for in place.

I think the appropriate solution may be to move the appropriate logic
from ArrayHandle to ArrayTransfer. I will look into that next.
2015-04-23 20:45:24 -04:00