If a global static array is declared with VTKM_EXEC_CONSTANT and the code
is compiled by nvcc (for multibackend code) then the array is only accesible
on the GPU. If for some reason a worklet fails on the cuda backend and it is
re-executed on any of the CPU backends, it will continue to fail.
We couldn't find a simple way to declare the array once and have it available
on both CPU and GPU. The approach we are using here is to declare the arrays
as static inside some "Get" function which is marked as VTKM_EXEC_CONT.
f6e18ac4 Remove IntegerSequence.h as we don't need it in vtk-m anymore
7f762204 Redesign the Dispatcher to not need FunctionInterface to convert dynamic types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1010
203205a1 TryExecute RuntimeDeviceTracker can't be a const ref anymore.
dfb9cc62 Allow users to pass multiple arguments to TryExecute
5384305d Update tests and a single worklet to verify new CastAndCall works
2ff14a81 Allow users to pass multiple arguments to CastAndCall
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1005
Previously we allowed a const ref as we would make a copy, this only works
as it relies on RuntimeDeviceTracker implementing state through a shared_ptr.
Instead if we require modifiable types only we can make TryExecute more
efficient and clearer on what it does.
5f1db422 Add option to use default symbol visiblity for VTK-m libraries.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1004
dd25c5c2 DynamicCellSet CastAndCall refactored to use the new vtkm::ForEach
c9f1d192 DynamicArrayHandle CastAndCall refactored to use the new vtkm::ForEach
68381d9f Rework TryExecute to leverage perfect forwarding.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1003
VTK doesn't hide symbols for static builds, which results in linker
errors for VTK targets that link with VTK-m. This option allows VTK-m
to match VTK's behavior.
By using perfect forwarding we can reduce not only the amount of TryExecute
signatures, but we can enable the ability to pass temporary functors to
TryExecute.
At the same time we have optimized TryExecute by moving the string generation
code into a single function that is compiled into the vtkm_cont library.
The end result is that the vtkm_rendering library size has been reduced from
12MB to 11MB, and we shave off about 5% of our build time.
Rather than requiring all the arguments to be placed as member variables to
the functor you can now pass extra arguments that will be added to the functor
call signature.
So for example:
vtkm::ForEach(functor, vtkm::TypeListTagCommon(), double{42.0}, int{42});
will be converted into:
functor(vtkm::Int32, double, int)
functor(vtkm::Int64, double, int)
functor(vtkm::Float32, double, int)
functor(vtkm::Float64, double, int)
...
b3a7c697 MarchingCubes: Now is able to run on Uint8/Int8 types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !995
The speed improvement fix regressed support for non scalar types, this
correct that issue.
The issue was found while trying to bump the VTK-m version inside VTK.
f6ead29c Removing a debug variable that was causing cuda to crash
565e69c5 Merge branch 'master' into visit_changes
81afcb62 further removing debug statements
a3bf1b26 Merge branch 'master' of https://gitlab.kitware.com/mclarsen/vtk-m into visit_changes
fdd5d1c8 removing debug statements
e60e330c Merge branch 'connectivity_tracer_additions' into visit_changes
2cb26b2d something
0bea9ce9 tracking path lengths if present
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !992
e49f27a3 Remove all uses of VTKM_OVERRIDE at instead just use override.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !993
32148cdb A first pass at improving the compile time of MarchingCubes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <mlarsen@cs.uoregon.edu>
Merge-request: !989