ArrayPortalFromIterators uses the GetIteratorBegin method signature.
This makes all the custom ArrayPortals have the same syntax,
which is nice when writing new backends.
See merge request !48
Remove dead code for converting zip handles to iterators for cuda.
This code isn't needed anymore as the new iterator facade handles this use case properly.
See merge request !45
Correct undefined behavior that was causing scan test failures.
We need call PrepareForInput on the input argument before invoking a function.
The order of execution of parameters of a function is undefined, so we need to
make sure input is called before output, or else in-place use case breaks.
See merge request !44
We need call PrepareForInput on the input argument before invoking a function.
The order of execution of parameters of a function is undefined, so we need to
make sure input is called before output, or else in-place use case breaks.
Add NewInstance method to DynamicArrayHandle.
Per Sujin's recent request on the VTK-m mailing list, here is an implementation of NewInstance added to DynamicArrayHandle.
See merge request !43
Properly initialize vtkm::Pair, and remove the TypeTrait for it.
vtkm::Pair can hold vtkm::Vec so we need to call the proper constructor
for vtkm::Vec.
Now that vtkm::TypeTraits don't error out on unknown types, we don't need
the weird specialization for vtkm::Pair.
See merge request !39
vtkm::Pair can hold vtkm::Vec so we need to call the proper constructor
for vtkm::Vec.
Now that vtkm::TypeTraits don't error out on unknown types, we don't need
the weird specialization for vtkm::Pair.
We need to remove this overload to simplify the constructors, and to
allow code such as vtkm::Vec<float,3> f(0). Which when you have both
overloads is ambiguous.
Fix ReduceByKey general algorithm to work with parallel ScanInclusive
Also using bit representation for states. This is using an advanced algorithm, and the fix has very little change from the current implementation.
See merge request !35
Fancy Arrays as input to Device Algorithms
Currently working on the general approach to get ArrayHandleZip/Permutation to be handled by all device adapter algorithms.
See merge request !32
Instead of having a single specialization for sort and zip handles,
we know handle any fancy handles being passed to the cuda device adapter.
This was done by reworking how we represent fancy iterators inside thrust,
and instead of using a transform iterator + counting iterator we just use
a iterator_facade.
