Replace code such as `myArray.GetPortalControl().Get(0)` with
`vtkm::cont::ArrayGetValue(0, myArray)`, which will just retrieve
the single value without transferring the entire contents of
`myArray` to the host. This should prevent memory thrashing.
Also did some general style clean-ups and fixed loops that called
`GetPortalControl` in the loop body.
The Invoker is a control side object that handles the construction
of the relevant worklet dispatcher. Moving it to control makes it
obvious that it isn't an algorithm itself but a way to launch
worklets.
We previously had to mark the make_FunctionInterface function as
host/device as it could be used in either place. The ramifications
of this is that each time we launched a worklet any input parameter
had to either suppress cuda exceptions, or had to rely on the
DispatcherBase to suppress the warnings.
By making make_FunctionInterface only host callable ( as it is ),
we can remove all of our unneccesary suppression logic and better
expose real issues with code that is marked host/device but can't
be due to calling things such as std::abort
The purpose of the TestBuild infrastructure was to confirm that
VTK-m didn't have any lexical issues when it was a pure header
only project. As we now move to have more compiled components
the need for this form of testing is mitigated. Combined
with the issue of TestBuilds causing MSVC issues, we should
just remove this infrastructure.
Now that the dispatcher does its own TryExecute, filters do not need to
do that. This change requires all worklets called by filters to be able
to execute without knowing the device a priori.
For some unknown reason, on windows these header tests were producing
the following errors:
fatal error C1041: cannot open program database
There might be a better way around this, but the easiest way is to
simply remove those test builds.
