The maximum recursion that could happen was 1 call in, but compilers had
trouble determining that. Split this into 2 non-recursive functions so
the compiler can easily determine the stack depth.
This is only set while compiling device code, and is useful
for code that needs different implementations on devices (e.g.
they call CUDA device intrinsics, etc).
This commit adds several geometric constructs to vtk-m
in the `vtkm/Geometry.h` header. They may be used from
both the execution and control environments.
We also add methods to perform projection and Gram-Schmidt
orthonormalization to `vtkm/VectorAnalysis.h`.
See `docs/changelog/geometry.md` included in this commit
for more information.
Previously FloatPointReturnType would always be double for types that
are not float, which caused Int8/Int16 types to promote to double instead
of float.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
Unary operations on scalars and vectors will return vtkm::Float64 for
integral input types and vtkm::Float64 input types. Unary operations will
return vtkm::Float32 for vtkm::Float32 input vectors and scalars.
Changed return types for all scalar and vector unary math operations
to return vtkm::FloatDefault instead of input type. vtkm::Float64 will
be returned when the input is vtkm::Float64.
Modified the vector magnitude worklet to accept VecAll instead
of Vec3 and return Scalar. Modified the Magnitude() and Sqrt() functions
to return FloatDefault for all inputs except for Float64.
Perhaps we should modify other functions in Math.h and VectorAnalysis.h to
return float types for intergral arguments instead of integral types?
Literals that are used to represent the bits of certain floating point
numbers (e.g. VTKM_NAN_BITS_64) are placed into unsigned integers before
converted to floating points. We ran into an example where the compiler
complained that a literal (specifically VTKM_NEG_INF_BITS_64) was
declared signed and was negative but then placed in an unsigned (64-bit)
integer. This should fix the problem by making the literal itself
unsigned.
The math nonfinite check functions (like IsNan) were calling the std
equivalent function. This is fine for most architectures, but is not
available for devices under CUDA. Instead, call the CUDA version of
these functions when compiling with CUDA.
This fixes an issue that became apparent once we added CUDA error code
checking.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
We had a report that vtkm::Min/Max was significantly slower than other
products. This was traced back to the fact that these functions were not
completely inlining because they were calling fmin or fmax, and that
resulted in an actual C library call. It turns out using the templated
functions in the std namespace is faster.
This change has the VTK-m min/max functions use the std version in
almost all circumstances. The one exception (so far) is that fmin and
fmax are used for CUDA devices since the std functions are not declared
to run on the device and the nvcc compiler treats these functions
special.
On one of my compile platforms, GCC was giving conversion warnings from
any boost include that was not wrapped in pragmas to disable conversion
warnings. To make things easier and more robust, I created a pair of
macros, VTKM_BOOST_PRE_INCLUDE and VTKM_BOOST_POST_INCLUDE, that should
be wrapped around any #include of a boost header file.
The VTKM_MSVC is just defined if using MSVC. It is not set to any value.
There was a reference in Math.h that assumed it was set to true, which
it was not. This simple change should fix that.