This means that we not only setup the runtime device tracker
to force the intended device, it also means making sure
the default device is the error device.
The previous implementation of DeviceAdapterRuntimeDetector caused
multiple differing definitions of the same class to exist and
was causing the runtime device tracker to report CUDA as disabled
when it actually was enabled.
The ODR was caused by having a default implementation for
DeviceAdapterRuntimeDetector and a specific specialization for
CUDA. If a library had both CUDA and C++ sources it would pick up
both implementations and would have undefined behavior. In general
it would think the CUDA backend was disabled.
To avoid this kind of situation in the future I have reworked VTK-m
so that each device adapter must implement DeviceAdapterRuntimeDetector
for that device.
While making changes to how execution objects work, we had agreed to
name the base object ExecutionObjectBase instead of its original name of
ExecutionObjectFactoryBase. Somehow that change did not make it through.
571556d9 CUDA's RuntimeDeviceTracker and Timer are now built as part of vtkm_cont
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1196
This is done to not only reduce the amount of code that users need
to generate but to reduce the amount of errors when using
the RuntimeDeviceTracker. If the runtime device tracker is initially
used in a library by a c++ file it will never properly detect the
cuda backend. By moving the code into vtkm_cont we can make sure
this problem doesn't occur.
0da55730 Fix scaling of x/y field of views
39b347db Fix raytrace using wrong fov with standard camera
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1185
Numerous worklets of ContourTreeUniform generate optimizations that
presume no vtkm::Id overflow. This assumption is correct, and the
related warning about this optimization can be safely ignored.
21b80a5d UnitTestImageConnectivity now uses size_t to index to std::vector
44382300 Make sure all tests use the .cxx extension.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Merge-request: !1190
The logic inside DataSetBuilderUniform has some tricky logic but for all
cases the dimensions are correct. We just initialize the variable to make
the compiler stop warning.
Prevously, the x field of view was computed by scaling the y field of
view by the aspect ratio of the canvas. However, this is wrong because
the field of view angles do not scale linearly with the aspect ratio.
Fix this issue by using trig functions to convert the angle to distance,
scale the distance, and then convert back to angle.
The raytracing code has its own version of camera that maintains two
field of view (fov) parameters: one for the x direction and one for the
y. The standard vtkm::rendering::Camera contains only one fov. As is
consistent with OpenGL's gluPerspective and VTK's camera, the fov is
specified in the y direction. However, the raytracing code was
incorrectly using it in the x direction. That caused it to do a weird
rescaling when the aspect ratio was not 1.
737ea7e1 Suppress maybe-uninitialized warnings for gcc 4+
7ac4ae15 Marching Cubes test doesn't abuse fall through case statements
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1182
The maybe uninitialized warnings condition logic wasn't correct the
first time, and needed to be extended for gcc4+. This locally has
resolved the problems the first try didn't solve.
Some worklets Run() method accidentally used the default device adapter
which should be avoided. Instead they should use a passed in device
adapter so that we support multiple device adapters in the same
binary/executable.
Previously vtkm_find_gl was only usable when rendering was enabled.
This is problematic as examples would use vtkm_find_gl even if
they didn't use vtkm rendering library.
abstracted out execution objects for both tetrahedralize and triangulate and removed the device template requirement from the execution object factory for both classes
cleaned up a logic error texture2d and cleaned how the constructor for execution object was being called. Also, went and cleaned up how the execution object was being created for particle to align it with the same method for creating the execution object.
