Encountered this causing a compilation error when trying to run some
benchmarks with FloatDefault input and values since it was using the
wrong type for some iterators iirc and couldn't cast to the vtkm::Id
type. This should fix that by using the correct type for the output
portal.
Unlike most compilers, MSVC will give conversion warnings when
implicitly converting a 32-bit int to a 32-bit float because the
mantissa can potentially drop some of the lower order bits of large
ints. Use static casts to (hopefully) remove the warnings.
For some reason when optimization was on with the Intel compiler it
was removing the loop in some instances of the templated MatrixTranspose
function. I inserted an empty assembly statement that prevents the
compiler from removing the loop but does not add any actual code. That
seems to fix the problem.
Some compilers, particularly icc, do strange things to literals during
optimization that makes them slightly different. This change was originally
to fix a testing issue with the icc build. It is not actually fixing the
problem, but I am leaving in the change because it is good practice.
Specifically a conversion operator was not being used in the StringInt
class of UnitTestArrayHandleCounting. Because it was in an anonymous
namespace that could not be used outside of the file, ICC warned about
it. Rather than remove the method, which could cause confusion later,
gave the namespace a name so the compiler assumes that the class could
potentially be used somewhere else.
Robert Maynard pointed out that the unary operator- I added to Vec could
lead to undesirable behavior for vectors of unsigned integer types. This
changed makes the definition of operator- conditional on the component
type being either a signed integer or a float type.
I also added some more actual testing of the new operator.
Previously, the templated Vec classes had overloaded multiply operators
to allow it to be multiplied by any basic type (float, double, int,
long, char, etc.). This was there to make it easier to multiply a vector
by a scalar without having to jump through introspection hoops for the
component types. However, using them almost always resulted in a
conversion warning on some type of compiler, so I think it is easier
just to remove them.
Some fixes to VertexClustering
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
See merge request !64
When mixing precision, it is possible for the computation to pick a grid
size greater than the requested number of dimensions. This change
ensures that you never get more dimensions than requested. (Thanks to
Chun-Ming Chen for the fix.)
The test now behaves the same way as it did before the last change.
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
Implement a way to pass a portal to worklet as a parameter.
This is built ontop of the ExecutionObjectBase work, and is designed to show
other developers how they can create custom objects that are shared among
all worklets, but are passed as parameters to the worklet.
See merge request !60
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.
Math
Adds a set of portable math functions, most of which are "expected" to be available and are typically useful. They include things like trigonometry (sin, cos, tan, etc.), floating point information (nan, finite, etc), and min/max.
See merge request !58
This is built ontop of the ExecutionObjectBase work, and is designed to show
other developers how they can create custom objects that are shared among
all worklets, but are passed as parameters to the worklet.
Also fix some issues that caused the compile to fail when trying to
run some of the math functions on a CUDA device. In particular, CUDA
is picky about using a global const on a device when the const type is
not one of the basic C types.
By mistake the cuda texture memory load code was not being used, so correct
that issue and allow loading of vtkm::Vec and primitive types. Currently
the only issue is loading int8/int16 uint8/uint16 through texture memory.
