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.
It is common to write template code that needs to operate across both
scalar and vector values. To facilitate code like this we are required
to provide these common operators.
Add in the vtkm namespace an assert macro (technically VTKM_ASSERT) that
basically replicates the functionality of the POSIX assert macro. This
form of assert is set to replace the separate control/exection asserts.
It has been decided that an assert that throws an exception instead of
terminating the program is not all that great of a feature and it causes
some limitations on how it is used. The next commit will remove the
other forms of VTK-m assert.
Scatter in worklets
Add the functionality to perform a scatter operation from input to output in a worklet invocation. This allows you to, for example, specify a variable amount of outputs generated for each input.
See merge request !221
This has been requested on the mailing list to make it easier to
interpolate integer vectors.
There are a couple of downsides to this addition. First, it implicitly
casts doubles back to whatever the vector type is, which can cause a
loss of precision. Second, it makes it more likely to get overload
errors when multiplying with Vec. In particular, the operator to cast
Vec of size 1 to the component class had to be removed.
These changes are basically to support some upcoming changes to
ArrayHandleZip. The major additions are an implementation of VecTraits
for Pair and an overloaded << operator to ostream for Pair.
I also had to declare the operator<< for Pair to be in Types.h. Under
some circumstances the operator has to either be declared before the
template is declared or declared in the vtkm namespace. (The reasons are
described at <http://clang.llvm.org/compatibility.html#dep_lookup> but I
still don't understand.) I tried adding it to the vtkm namespace, but
that caused several of the other operator<< to fail. Since there is no
way to guarantee that Pair.h is declared before, say, ArrayHandle.h, I
moved the implementation to Types.h.
Since I was moving operator<< to Types.h, I went ahead and moved the
TypeTraits and VecTraits to their respective headers. Since Pair is
declared (but not implemented) in Types.h, these templated classes can
be implemented without including Pair.h.
The recently added pragma to suppress warnings about unused local
typedefs caused lots of dashboard failures because many GCC and clang
compiler do not have this warning so did not recognized the pragma to
suppress it. Now only use the pragma on clang compilers with a large
enough version.
I also discovered that the check for VTKM_CLANG was wrong (at least for
the most modern versions of XCode). Fixed that as well as some uses of
VTKM_CLANG that were wrong.
In the special case where you are loading the point coordinates for a
structured grid in a point to cell map (an important use case), create a
VecRectilinearPointCoordinates rather than build a Vec of the values.
This will activate the cell specalizations in previous commits.
These changes also added some flat-to-logical index conversion and vice
versa in ConnectivityStructuredInternals. This change also fixed a bug
in getting cells attached to points in 2D grids. (Actually, technically
someone else fixed it and checked it in first. The changes were merged
during a rebase.)
I also added a specalization to Vec for 1D that implicitly converts
between the 1D Vec and the component. This can be convenient when
templating on the Vec length.
The PrintSummary for CoordinateSystem went in an infinite loop. It was
supposed to call PrintSummary of its superclass (Field), but instead it
called itself.
The PrintSummary for Field only worked for fields of type vtkm::Float32.
To make it work for all array types, I added a PrintSummary method to
DynamicArrayHandle, and Field calls that without trying to cast to a
static type.
Some changes to the Vec class and VecTraits in anticipation of creating
Vec-like objects. The following changes are made:
* Add GetNumberOfComponents to Vec, which returns NUM_COMPONENTS.
* Likewise, all VecTraits have a GetNumberOfComponents method.
* The ToVec method in VecTraits is changed to CopyInto so that it can be
used when the length of the Vec-like is not known. CopyInto is also
added to Vec.
* VecTraits has a typedef named IsSizeStatic which is set to
VecTraitsTagSizeStatic when the number of components is known at compile
time and VecTraitsTagSizeVariable when the number of components is not
known until runtime.
C and C++ has a funny feature where operations on small integers (char
and short) actually promote the result to a 32 bit integer. Most often
in our code the result is pushed back to the same type, and picky compilers
can then give a warning about an implicit type conversion (that we
inevitably don't care about). Here are a lot of changes to suppress
the warnings.
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.
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.
We need to remove this overload to simplify the constructors, and to
allow code such as vtkm::Vec<float,3> f(0). Which when you have both
overloads is ambiguous.
When multiplying integer values of a width less than an integer c++ actually
converts up to an integer implicitly. So we silence the warnings that the
result of the multiply could be larger than the original type. If people want
to do multiplies on int8/16 they better know what they are doing.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
Since we want our code to generally handle data of different precision
(for example either float or double) expand the types in our list types
to include multiple precision.
There are multiple reasons for this name change:
* The name Tuple conflicts with the boost::Tuple class, which as a
different interface and feature set. This gets confusing, especially
since VTK-m uses boost quite a bit.
* The use of this class is usually (although not always) as a
mathematical vector.
* The vtkm::Scalar and vtkm::Vector* classes are going to go away soon
to better support multiple base data type widths. Having this
abbriviated name will hopefully make the code a bit nicer when these
types have to be explicitly specified.
Also modified the implementation a bit to consolidate some of the code.
In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).
Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
We made this change a while ago to help with completion in IDEs.
(Completion was matching a bunch of wrapper macros that were almost
never used anywhere.) Most of the changes are in comments, but there are
a few bad macro definitions.
Using alignment on basic types when vtkm only targetted Linux/BSD/OSX was
'okay' because of how the alignment operators worked, but potential was going
to cause issues in the long run if we failed to detect the correct size and the
compiler was than forced to not use intrinsics.
Now with adding windows support we have run into another problem. Basically
using an alignment operator on a typedef means that the type must never
be passed by value, but must always be passed by reference. The reason for
this is that passing by value doesn't respect alignment requirements, and
can cause very subtle errors or crashes.
A really good read for people more interested in these problems:
http://eigen.tuxfamily.org/dox/group__TopicPassingByValue.htmlhttp://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Alignement.html
