The Zip function does not work when compiling with CUDA because it
forces the parameters to be in both the control and execution (host and
device) environments.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
When fixing a problem where the disabled test had left some unused
classes, which some compilers picked up on (SHA
eae8921dc714c9bdb12058db365f890425291ea2), I used a preprocessor wrapper
to enable/disable the code (mostly to preserve history). However, I
forgot to leave the code disabled. Disable that here.
A couple of tests were failing with the Intel compiler due to
imprecision in comparing floating point values.
Also snuck in some minor documentation fixes in a comment for
FunctionInterface.
There is a test that tries to determine that the Invoke methods in
FunctionInterface do not add an unreasonable overhead. However, this
test is unreliable. Also, the most critical performance hit would be in
invoking a worklet operation, but that is now done elsewhere anyway.
The unit test for StorageBasic tested the StealArray feature and then
used the delete[] operator on the stolen array to deallocate it. For
many standard libraries the default implementation for delete[] is
the same as (or at least compatible with) std::allocator, but for
the PGI compiler they were not compatible and this resulted in a
run-time error. This change fixes the problem with the test by using
the same allocator as the StorageBasic test.
ICC can be pretty thorough about finding unused elements. In this case
it was picking up an unused method in instances of a templated class
in an anonymous namespace. It was a method that should be there due to
the nature of the class, but it happened to not be used (which was OK,
too). To get around the problem, I just added some use of that method
in another method.
It's easy to put accidently put something that is not a valid tag in a
ControlSignature or ExecutionSignature. Previously, when you did that
you got a weird error at the end of a very long template instantiation
chain that made it difficult to find the offending worklet.
This adds some type checks when the dispatcher is instantated to check
the signatures. It doesn't point directly to the signature or its
parameter, but it is much closer.
MSVC is picky about type conversions. To get it to shut up, explicitly
cast the worklet return value to the fetch value in the
WorkletInvokeFunctor. The good is that it will help with needing
explicit conversions on these return values. But that is also bad in
that it might make some unexpected conversions possible.
Instead of just checking that a dispatcher's Invoke input is an
ArrayHandle, also check that the ValueType of the ArrayHandle is
compatible with the types of the worklet operator. This is done by
adding a template argument to the ControlSignature tags that is a type
list tag that gets passed to the type check.
One fix is a simple (pointless) compiler warning about precision. The
other fix is an error in one of the test codes that did not clear out
the message string in an error message buffer like it was supposed to.
Also reduced the maximum list size to 15 (which is the current longest
single list we have). Trying to reduce the size of the generated code a
bit, which is getting a little long.
Previously, this script would create a file the same name as the desired
output, and then move it to a file with .save appended to it if the
check failed. This is problematic with parallel builds because there is
no dependency set up between the actual header file and the one being
created. Thus, it is possible for some compiles to pick up the created
file before it is moved or deleted.
Instead, just create the file with .save appended to it so that no
compile can every accidently pick it up.
This is a simple version of a dispatcher, but an important one.
Note that there is an issue brought up with UnitTestWorkletMapField in
that there needs to be better ways to specify worklet argument types.
These changes support the implementation of DispatcherBase. This class
provides the basic functionality for calling an Invoke method in the
control environment, transferring data to the execution environment,
scheduling threads in the execution environment, pulling data for each
calling of the worklet method, and actually calling the worklet.
The zip capability allows you to parameter-wise combine two
FunctionInterface objects. The result is another FunctionInterface with
each parameter a Pair containing the respective values of the two
inputs.
Being able to zip allows you to do transforms and invokes on data that
is divided among multiple function interface objects.
The Fetch class is responsible for moving data in and out of some
collection in the execution environment. The Fetch class is templated
with a pair of tags (the type of fetch and the aspect) that control the
mechanism used for the fetch.
The Transport class is responsible for moving data from the control
environment to the execution environment. (Actually, it might be more
accurate to say it gets the execution environment associated with a
given control object.) The Transport class is templated with a tag that
controls the mechanism used for the transport.
Lots of tests have to move values in and out of arrays and check them
against expected values. It is also often the case that these tests are
run on lots of different types. There is some repeated code for
generating known values for particular indices. This change unifies some
of that. This can probably also encourage making more generic tests.