Previously each device adapter only had a unique string name. This was
not the best when it came to developing data structures to track the status
of a given device at runtime.
This adds in a unique numeric identifier to each device adapter. This will
allow classes to easily create bitmasks / lookup tables for the validity of
devices.
When writing multiple backend code users of vtkm need to use the
DeviceAdapterTraits classes, so therefore we should move them to vtkm::cont
to signify this.
Array transforms can now be created with an inverse functor, allowing for
casts back into the native array type. As a result, array transforms with
both a functor and inverse functor defined can perform read and write
operations. As an example, ArrayHandleCast now supports this operation. The
original implementation of ArrayHandleCast (i.e. read only) has been renamed
'ArrayHandleCastForInput'.
This now allows for even more efficient construction of uniform point
coordinates when running under the 3d scheduler, since we don't need to go
from 3d index to flat index to 3d index, instead we stay in 3d index
9a8809f9 Add CellSetPermutation which allows custom iteration over a cell set.
66f6db5a IsWriteableArrayHandle now can tell if an array handle can be written too
20f3fb50 Update VertexClustering to use vtkm::cont::CellSetSingleType.
154896b7 Extend the test for DataSetSingleType.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !228
Even when using implicit index's the ConnectivityExplicit would generate
the code to compute the IndexOffsets, which would than fail to compile as
the ArrayHandle would only support read operations. This fixes that issue.
98885186 Fix CopyInto tests that use different DeviceAdapterTag
69b2ad2a Add unit tests for CopyInto function
2c55b15c Add additional control logic for CopyInto function
20c1a048 CopyInto function for ArrayHandles
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !202
Xcode 7 warnings
The XCode 7 compiler has a new warning for unused typedefs. The Boost code we use has some instances where this warning gets issued. Suppress these warnings.
See merge request !199
This is to be used in place of BOOST_STATIC_ASSERT so that we can
control its implementation.
The implementation is designed to fix the issue where the latest XCode
clang compiler gives a warning about a unused typedefs when the boost
static assert is used within a function. (This warning also happens when
using the C++11 static_assert keyword.) You can suppress this warning
with _Pragma commands, but _Pragma commands inside a block is not
supported in GCC. The implementation of VTKM_STATIC_ASSERT handles all
current cases.
ArrayHandles in DAX have a CopyInto function which allows the user to copy an array handle's data into a compatible STL type iterator. Originally this was fairly straight forward to implement since array handles in DAX are templated on the DeviceAdapterTag. In contrast, VTKm array handles use a polymorphic ArrayHandleExecutionManager under the hood allowing a single array handle to interface with multiple devices at runtime. To achieve this virtual functions are used. This makes implementing the CopyInto function difficult since it is templated on the IteratorType and virtual functions cannot be templated.
To work around this, I've implemented a concrete templated CopyInto function in the class derived from ArrayHandleExecutionManagerBase. In the ArrayHandle class, CopyInto dynamically casts the base class into the derived class, then calls the CopyInto function defined in the derived class.
The drawback to this approach is that, should the user define their own class that inherits from ArrayHandleExectionManagerBase, they are not forced to implement the CopyInto function, unlike the other virtual functions.
fd685210 Always install all device headers even when device isn't enabled.
b1663b24 Add an example of using multiple backends from a single translation unit.
fc0ff69d Methods with try/catch need to be host only.
4d635d64 DeviceAdapter Tags now always exist, and contain if the device is valid.
cf32b430 Teach Configure.h to store if TBB and CUDA are enabled.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !198
Previously it was really hard to verify if a device adapter was valid. Since
you would have to check for the existence of the tag. Now the tag always
exists, but instead you query the traits of the DeviceAdapter to see if
it is a valid adapter.
This makes compiling with multiple backends alot easier.
The boost assert macros seem to have an issue where they define an
unused typedef. This is causing the XCode 7 compiler to issue a warning.
Since the offending code is in a macro, the warning is identified with
the VTK-m header even though the code is in boost. To get around this,
wrap all uses of the boost assert that is causing the warning in the
third party pre/post macros to disable the warning.
The idea of the PointCoordinate classes was to make it easier to define
new special types of point coordinate arrays. But ultimately you have to
create an array handle type, and the CoordinateSystem class pretty much
handles everything else for you. Thus, these classes where being used
nowhere.
My version of the PGI compiler was having problems with using
IteratorFromArrayPortal with STL algorithms. I traced the problem to
iterator_facade checking to see if the reference type we gave it was
a real reference (e.g. T&). It is not, iterator_facade downgraded the
iterator trait to a simple input iterator tag even though I declared
it with a random access traversal. I don't know what the reference type
has to do with random access, but in any case the value object is
designed to behave like a reference in that when you assign to it
the value gets propagated to the array. To tell boost this is the case,
I made a specialization of boost::is_reference that declares the
value type as a reference.
I'm not sure why it failed for me but not elsewhere. It might be that
this version of the PGI compiler is using "old-style" iterator traits
whereas other were using newer style that matches better the boost
iterator traits that iterator_facade is actually using.
Clean up CellSet
Underneath the CellSet implementation is a set of supporting classes that manage the actual structure in both the control and execution environments. However, the implementation of these classes was a bit confusing and inconsistent. The following changes are made:
* Most significantly, there is no longer any Connectivity classes in the control environment. This functionality has been wrapped up into the CellSet classes, which is more consistent and easier to understand. (There was a definite distinction between CellSet and Connectivity, but it was subtle and difficult to understand.) This also means that edits to CellSets happen to CellSets directly.
* The set of classes for structured and explicit cell sets match. There is different functionality within, but the class naming and meaning are consistent.
* Make the class names more consistent with the rest of VTK-m class names. Specifically classes like ExplicitConnectivity become ConnectivityExplicit. Also, the words regular and structured were being used interchangeably. Now, always use structured except when dealing specifically with grids of regular spacing.
* The connectivity classes were using the nomenclature "From" and "To" to specify topological elements of links. The same concept in worklet classes were using the nomenclature "Src" and "Dest." For consistency, all references are changed to "From" and "To".
* Unlike explicit cell sets, structured cell sets have functionality shared between control and execution environments. Rather than duplicate it or create unique exposed classes, have a shared internal implementation in vtkm::internal.
See merge request !117
(Re-) Add a helper structure that holds the connectivity information for
a particular topology connection (e.g. from points to cells) to make it
easier to manage connections in multiple different directions in
CellSetExplicit.
Unlike the previous version of connectivity, this structure is
considered "internal" and not exposed through the API so that
CellSetExplicit can better manage the data. Also, many of the helper
methods remain in CellSetExplicit since they were specific for point-to-
Also, CellSetExplicit has a mechanism to take an arbitrary pair of
TopologyElementTags and get the appropriate connectivity. This should
simplify adding connections in the future.
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.
DynamicCellSet
Add a ```DynamicCellSet``` class to use in place of raw pointers or boost ```smart_ptr```s to make managing the anonymous class and casting easier.
See merge request !103
Previously, IteratorFromArrayPortal was declaring its difference_type
to be vtkm::Id. Although this is allowed, there is code that assumes
that iterators have a difference_type that is ptrdiff_t or something
similar. This change makes the difference_type the default for the
boost iterator facade, which should be the type other code that\
neglects to check expects.
The DynamicCellSet will be used in place of the pointer to a CellSet
in a DataSet. This will prevent us from having to cast it all the time
and also remove reliance on boost smart_ptr.
Correct type for the output portal in DeviceAdapterAlgorithmGeneral::UpperBounds
It looks like the type here was accidently written as a `ArrayHandle<T, COut>` when it should (I think) be `ArrayHandle<vtkm::Id, COut>`. I 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 if I recall correctly and couldn't cast to the vtkm::Id
type. This should fix that by using the correct type for the output
portal.
See merge request !75
