Add ability to specialize worklet for device

This adds an ExecutionSignature tag named Device that passes the DeviceAdapterTag as an argument to the worklet's operator(). This allows worklets to specialize their code based on the device.

This merge request has been queued for testing. Test results may be viewed on:

• CDash (master)
• Buildbot (master) (only visible from inside Kitware)

Branch-at-master: 68a0afb3

Errors:

• commit 68a0afb3 is not allowed because the following files are not formatted according to the 'clang-format-3.8' check: vtkm/internal/Invocation.h, vtkm/worklet/internal/DispatcherBase.h, vtkm/worklet/testing/UnitTestWorkletMapFieldExecArg.cxx. Post a comment ending in the line Do: reformat to rewrite the MR source branch automatically.

Please rewrite commits to fix the errors listed above (adding fixup commits will not resolve the errors) and force-push the branch again to update the merge request.

mentioned in issue #362 (closed)

Do: reformat

This topic has been reformatted and pushed; please fetch from the source repository and reset your local branch to continue with further development on the reformatted commits.

added 1 commit

• b8bff820 - Add ability to specialize worklet for device

Compare with previous version

This merge request has been queued for testing. Test results may be viewed on:

• CDash (master)
• Buildbot (master) (only visible from inside Kitware)

Branch-at-master: b8bff820

added 27 commits

• b8bff820...e787d52a - 26 commits from branch vtk:master
• 4e34feec - Add ability to specialize worklet for device

Compare with previous version

This merge request has been queued for testing. Test results may be viewed on:

• CDash (master)
• Buildbot (master) (only visible from inside Kitware)

Branch-at-master: 4e34feec

@sujin.philip Would you like to review this code?

@kmorel, this looks good to me. I am just unsure about the inclusion of ArrayHandle.h in ArrayHandle.hxx and ArrayHandleBasicImpl.hxx. Could you tell me why those changes are required?

ArrayHandle.h was always included from ArrayHandle.hxx. Including ArrayHandle.h won't work otherwise since the implementation of many of the methods is in ArrayHandle.hxx.

What is new is including ArrayHandle.hxx from ArrayHandle.h. The only reason why I added this (much like many of the other .hxx files) is so that my IDE doesn't flip out when it loads the .hxx file. The include guards prevent recursive inclusion. It does not have any actual effect on the compilation as nothing includes ArrayHandle.h before ArrayHandle.hxx.

I didn't actually make any changes to ArrayHandleBasicImpl.hxx. I did add that include to ArrayHandleBasicImpl.cxx. I don't recall exactly why I added that. (I might have been struggling with getting the include guards right at one point.) At any rate, it makes sense for ArrayHandleBasicImpl.cxx to include ArrayHandle.h, and since it is a .cxx file that is not included from anywhere, it shouldn't affect any other translation units.

+1

Do: merge

mentioned in commit 04254dbd

merged