abstracted out particles into an execution object and a factory that populates said execution object based on its state. removed the facotries dependance on a device adaptor.
Rather than require all ExecutionObjectFactoryBase classes to declare a
templated ExecObjectType type, get the type of the execution object
directly from the result of the PrepareForExecution method.
before it was wall prepareforexecution(device) creating an execution object but invoke calls this function now through the transport tag so we just need to give it the factory object not the execution object
updating the transport execution object test to use the factory to create an execution object based on the templated device and chaged the trasport tag to call the prepareForExectuion(Device) method to create the execution object.
In order to make the change from the current way execution obejcts are utilized to the new proposed executionObjectFactory process type checks now has to look for the new execution object factory class to check against.
36ae705e Suppress maybe-uninitialized warnings from VecTraitsTests
5bc9ecef Add a vtkm::Vec<T,N> fast path for CopyInto a vec of the same type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1176
f025c218 Suppress conversion warning inside Cell Interpolate code
822d4c61 Marching Cubes test doesn't abuse fall through case statements
dac7ab98 Correct a bad memcpy in ColorTable that gcc 7 found
c6726644 Reformat some test code to stop gcc 7.3 from segfaulting.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Merge-request: !1175
When converting integer fields the interpolate code generates lots
of warnings that we are promoting into floating point space.
The quickest solution is to suppress these conversion warnings
all together for all interpolation functions.
Somehow deducing the parameters to a static function was causing
gcc to segfault and crash. Changed around the code to use a free
function and everything works properly
The usage of uint was causing problems with CUDA + MSVC2015 as
type was not defined. Instead we use vtkm::Id as that was the expect
type to be passed to the task
adcabb03 VTK-m Vec<> constructors are now more conservative.
6267deb6 CellDerivativeFor3DCell has a better version for Vec of Vec fields.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1170
This allows for easier host side logic when determining grid and block
sizes, and allows for a smaller library side by moving some logic
into compiled in functions.
When you have a Vec<Vec<float,3>> it was possible to incorrectly correct
it with the contents of a Vec<double,3>. An example of this is:
using Vec3d = vtkm::Vec<double, 3>;
using Vec3f = vtkm::Vec<float, 3>;
using Vec3x3f = vtkm::Vec<Vec3f, 3>;
Vec3d x(0.0, 1.0, 2.0);
Vec3x3f b(x); // becomes [[0,0,0],[1,1,1],[2,2,2]]
Vec3x3f c(x, x, x); // becomes [[0,1,2],[0,1,2],[0,1,2]]
Vec3x3f d(Vec3f(0.0f,1.0f,2.0f)) //becomes [[0,0,0],[1,1,1],[2,2,2]]
So the solution we have chosen is to disallow the construction of objects such
as b. This still allows the free implicit cast to go from double to float.
So while `Vec3x3 b = x is supported by vtk-m, it produces very incorrect results.
Previously we would compute a 3x3 matrix where each element was a Vec. Using
the jacobain of a single component is sufficient so by using that we safe 2 to
3 times the memory space.
Additionally by moving to doing the derivative as a per component algorithm
we work around the issues found in bug
https://gitlab.kitware.com/vtk/vtk-m/issues/221. In effect when trying to
construct a Vec of Vec from a component of a different floating type e.g.:
Vec3d x(0.0, 1.0, 2.0);
Vec3f a = x;
Vec3x3f b = x;
Vec3x3f c(x, x, x);
Generates bad values vectors such as b which look like:
b: [[0,0,0],[1,1,1],[2,2,2]]
c: [[0,1,2],[0,1,2],[0,1,2]]
Previously, when a Worklet needed a scatter, the scatter object was
stored in the Worklet object. That was problematic because that means
the Scatter, which is a control object, was shoved into the execution
environment.
To prevent that, move the Scatter into the Dispatcher object. The
worklet still declares a ScatterType alias, but no longer has a
GetScatter method. Instead, the Dispatcher now takes a Scatter object in
its constructor. If using the default scatter (ScatterIdentity), the
default constructor is used. If using another type of Scatter that
requires data to set up its state, then the caller of the worklet needs
to provide that to the dispatcher. For convenience, worklets are
encouraged to have a MakeScatter method to help construct a proper
scatter object.
d393468e Add any OpenGL link targets to test builds
8b9c0f50 Re-add non testable files to test build sources
ffd98463 Load correct file extension in header test build
7c5f44a6 Fix warnings about no symbols
289a4bc1 Differentiate between header files with different extensions
9571c9b5 Fix vtkm_add_header_build_test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1160
dc6e7d1a Make all Vec types consistently mark methods as inline
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1168
4b9a8143 Correct 'may be used uninitialized in this function' warnings in wavelets
ebf96077 Correct casting warnings found inside vtkm_rendering
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1167
7c7b1ed5 Make sure when compiling CUDA code we suppress unknown pragma
b7e63718 Correct issues found be enabling more CUDA warnings.
4ca2522c VTK-m when building CUDA code in debug now checks for more warnings
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1164
