THe IncrementBy2 test type previously allowed any subtype including
floating point numbers. The meaning of this is actually a little unclear
and the feature was causing implicit type conversion warnings that were
hard to template out. The utility of of templating this class is dubious
in the first place, so class is now a fixed type.
I'm a little unsure whether we should keep this test class at all. It's
math operations are ad hoc and it could be difficult to determine if a
problem is caused by an actual problem or just bad math operators.
Fix compile warnings that come up with the flags
-Wconversion -Wno-sign-conversion
This catches several instances (mostly in the testing framework) where
types are implicitly converted. I expect these changes to fix some of
the warnings we are seeing in MSVC.
I was going to add these flags to the list of extra warning flags, but
unfortunately the Thrust library has several warnings of these types,
and I don't know a good way to turn on the warnings for our code but
turn them off for Thrust.
The UnitTestArrayHandlePermutation test was failing when compiled with
icc. I believe the issue is that the icc optimization takes some
liberties when computing literal floating point values versus computing
them at run time that makes the two slightly different. I changed all
the applicable comparisons in this test from using the == operator to
using the test_equal function, which adds a tolerance to the comparison.
I expect this to fix the test failure.
There are often instances where one wants to make an assert check in a
method that can run in either the control or execution environment. This
is rather difficult in general for the execution environment, but with
this change you can place the VTKM_ASSERT_CONT macro in such a method,
and it should compile even under CUDA. It works by removing the macro if
compiling for a CUDA device.
Per a discussion with Robert Maynard, we no longer have plans to bind
textures or use texture objects. Instead, we are now using the __ldg
command to load from global memory inside the execution portal, which
gives us most of the benefits of textures, but doesn't incur any
bookkeeping.
Previously ArrayTransfer and ArrayManagerExecution received a reference
to a Storage class in their constructor and held the reference as an
ivar. In retrospect, this is just asking for trouble. First, it is way
too easy to pass by value when you mean to pass by reference. Second, if
there ever is a bug where the Storage goes out of scope before the
classes holding a reference, it is that much harder to debug.
This includes changing methods like LoadDataForInput to PrepareForInput.
It also changed the interface a bit to save a reference to the storage
object. (Maybe it would be better to save a pointer?) These changes also
extend up to the ArrayManagerExecution class, so it can effect device
adapter implementations.
This API change effects both ArrayTransfer and ArrayManagerExecution.
This is in preparation for a future change to make the API more
consistent with ArrayHandle.
The UserPortal in ArrayHandle was used to copy a pointer the user
created into an ArrayHandle to use in VTK-m algorithms. However, this is
only really valid for a basic storage, so the functionality has been
moved there, and you have to construct an ArrayHandle with a storage
instead of an array portal.
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.
The number of values in the array handle portal was screwy and the
GetNumberOfValues method was flat out wrong (thanks to Rob Maynard for
pointing that out). This is fixed.
Also fixed a subtle but nasty typing problem in the Storage's
GetPortalConst method.
Our approach of using the underlying allocator inside thrust was a bad approach,
for some reason it fails to properly allocate uint8's or int8's on the correct
boundaries. I expect that this logic is somewhere else in the code and
instead we should use thrust::system::cuda::vector which does this properly.
Add an Allocate method in ArrayHandle that basically forwards the
alllocate request to the storage object. This allows some measure of
control of the array from the control side. You can allocate the array
and set values (by getting the control array portal) if you so desire.
Previously when ReleaseResourcesExecution was called, the method blindly
deleted the execution array regardless of whether there was a valid copy
in the control environment. This could potentially lose data. What if
someone wanted to conserve memory on the device by clearing the array of
an output array?
There is also now an internal method that blindly deletes the array.
This is good for internal functions that are doing something to
invalidate the execution data anyway.
Fixed a problem where ArrayHandle would cause a crash if you tried to
get the control portal on an uninitialized array (it was supposed to
throw an exception).
Also changed some methods in ArrayHandle so that they work resonably
without error when used with an uninitialized array. Specifically, the
aforementioned behavior was changed to "allocate" an array of size 0
(that is, call Allocate(0) on the storage object) to return an empty
array portal rather than throw an error. Although this use of
ArrayHandle can be considered erroneous, it is convenient the get an
empty array portal when dealing with a potentially unallocated array
rather than create a special condition.
The namespaces need to be different for each test, or else only the first
implementation of the function will be used for all tests that call that
function.
Also updated the test to verify that we can count starting from a non zero
number.
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
