Fix an infinite recursion where the wrong overload was called
The intension was that if Camera::Zoom was called with a Float64, it
would call the Float32 version. However, I made a type where it called
itself. The latest version of XCode called me out on this infinite
recursion.
I think this is the equivalent of the compiler calling me a dumb-ass.
See merge request !483
The intension was that if Camera::Zoom was called with a Float64, it
would call the Float32 version. However, I made a type where it called
itself. The latest version of XCode called me out on this infinite
recursion.
I think this is the equivalent of the compiler calling me a dumb-ass.
a4012c16 Rmoving throw from worklet that prevents rendering from compiling with CUDA
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Matt Larsen <mlarsen@cs.uoregon.edu>
Merge-request: !481
063b349a Setup the examples to find vtkm components quietly.
e52f7628 VTKm config module now properly support the QUIET flag.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !479
Instead of having two separate implementations of MarchingCubes, we have
a single implementation in worklet, and filter uses that.
That does mean that the version in worklet has been updated to support
merging of duplicate point coordinates.
45ada6b5 Rework ArrayHandleCuda to make it stop generate warnings
4ca6ce2a nvcc doesn't have troubles with boost shared_ptr optimizations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !473
When finding the VTKm package, it is important to load components that
support the devices you want to use. However, there is no indication of
what does and does not get loaded. In some circumstances, it simply says
that VTKm_FOUND is not true but not why. Add some status messages of
whether each component gets loaded or not.
Add extra documentation to VTKmConfig.cmake
Add a note about the VTKm_COMPILE_OPTIONS. Also make an easy to read
list of available components.
See merge request !468
Re-disable warnings on CUDA builds for MSVC
In an earlier commit, we took out the "-w" flag for CUDA builds, which
disables all compiler warnings. The original reason for disabling
warnings was an errant warning about unused functions. It was taken out
because the visual studio compiler complains when this flag overrides
another warning flag (such as /W3).
Although the visual studio compiler was not complaining about unused
functions, we were getting lots of other warnings. These warnings did
not seem to actually come from the visual studio compiler. They probably
come from whatever CUDA uses for a device compiler. But it is unclear
how to specifically target these warnings.
So, the easiest solution is to add the "-w" flag back. To get around the
other warning, we now (hopefully temporarily) remove warning flags from
CMAKE_CXX_FLAGS to prevent the conflicting flags.
See merge request !467
In an earlier commit, we took out the "-w" flag for CUDA builds, which
disables all compiler warnings. The original reason for disabling
warnings was an errant warning about unused functions. It was taken out
because the visual studio compiler complains when this flag overrides
another warning flag (such as /W3).
Although the visual studio compiler was not complaining about unused
functions, we were getting lots of other warnings. These warnings did
not seem to actually come from the visual studio compiler. They probably
come from whatever CUDA uses for a device compiler. But it is unclear
how to specifically target these warnings.
So, the easiest solution is to add the "-w" flag back. To get around the
other warning, we now (hopefully temporarily) remove warning flags from
CMAKE_CXX_FLAGS to prevent the conflicting flags.
I don't know why, but under some circumstances when compiling with CUDA
and Visual Studio, the compiler was giving syntax errors when the
IteratorFromArrayPortal was using the typename keyword to reference a
type in its superclass. Get around the problem by looking directly in
the superclass.
The VTKM_ASSUME macro uses some of the definitions defined in
Configure.h, but it never included that file. So unless that file
happened to be included before Assume.h, VTKM_ASSUME could be declared
incorrectly.
Actually added the include to Assert.h, which Assume.h includes.
The VTKM_SUPPRESS_EXEC_WARNINGS should go before the template keyword,
but on a couple of methods in FunctionInterfaceDetailPre.h.in it was
after the template keyword.
Add pragmas to disable warnings 4244 and 4800 on Visual Studio when
compiling third party libraries. This gets around some warnings inside
the thrust library.
The build automatically sets some macros when building CUDA files. Some
of the CUDA sources were setting the same macros, which was causing
warnings. Change the code to be more careful about setting preprocessor
macros.
To detect what CUDA hardware is native, a simple CUDA program is
compiled. However, CMake was not necessarily pointing to the correct
source file, so the compile was failing.
This change makes sure that VTKm_CMAKE_MODULE_PATH is properly set and
uses that variable to find the source file.
Because the CUDA builds were experiencing some warnings about unused
functions, a -w flag was added to our nvcc flags. This effectively
turned off the warning (which was part of -Wall). But on Visual Studio
this added flag was causing a warning of its own because it overwrote
the /W3 flag. So turn this off for Visual Studio.
I don't think Visual Studio gives this warning anyway. If it does, we
can add a specific flat to suppress that warning.
When doing parallel builds with CUDA's nvcc on windows, you often get
errors about multiple programs trying to write to a pdb file at once. To
get around this, add the /FS flag on windows for the CUDA compiler.
Make sure tests for many devices are using requested devices
There are several tests in the cont directory that are in header files so
that they can be recompiled for different devices. Make sure that the
tests are exclusively using the device being tested by making the error
device adapter the default.
If any part of the test tries to use the default device (which could be
different than the one being tested), a compile error will occur. Several
of these compile errors are fixed in this commit.
See merge request !463
16f3f8ca VTKm_LOAD_COMPONENTS_COMMANDS now works with CMake version older than 3.3
b0d35919 VTKMConfig.cmake now properly sets VTKm_PACKAGE_IN_BUILD
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !462
There are several tests in the cont directory that are in header files so
that they can be recompiled for different devices. Make sure that the
tests are exclusively using the device being tested by making the error
device adapter the default.
If any part of the test tries to use the default device (which could be
different than the one being tested), a compile error will occur. Several
of these compile errors are fixed in this commit.
