This is done through a new version of ApplyPolicy. This version takes
a type of the array as its first template argument, which must be
specified.
This requires having a list of potential storage to try. It will use
that to construct an ArrayHandleMultiplexer containing all potential
types. This list of storages comes from the policy. A StorageList
item was added to the policy.
Types are automatically converted. So if you ask for a vtkm::Float64 and
field contains a vtkm::Float32, it will the array wrapped in an
ArrayHandleCast to give the expected type.
I ran into a bug with GCC 4.8 where if you use the alignas keyword
with a number declared with a constexpr, it gives an error about
the expression not being a constant expression (even though it
is). A workaround to the issue is to wrap the alianas in a class
templated by the size you want to align with. GCC does not
complain when you use a constexpr with a template parameter, and
it is happy to use that template parameter in the alignas
expression.
Workaround found here:
https://stackoverflow.com/questions/29879609/g-complains-constexpr-function-is-not-a-constant-expression
The `From` and `To` nomenclature for topology mapping has been confusing for
both users and developers, especially at lower levels where the intention of
mapping attributes from one element to another is easily conflated with the
concept of mapping indices (which maps in the exact opposite direction).
These identifiers have been renamed to `VisitTopology` and `IncidentTopology`
to clarify the direction of the mapping. The order in which these template
parameters are specified for `WorkletMapTopology` have also been reversed,
since eventually there may be more than one `IncidentTopology`, and having
`IncidentTopology` at the end will allow us to replace it with a variadic
template parameter pack in the future.
Other implementation details supporting these worklets, include `Fetch` tags,
`Connectivity` classes, and methods on the various `CellSet` classes (such as
`PrepareForInput` have also reversed their template arguments. These will need
to be cautiously updated.
The convenience implementations of `WorkletMapTopology` have been renamed for
clarity as follows:
```
WorkletMapPointToCell --> WorkletVisitCellsWithPoints
WorkletMapCellToPoint --> WorkletVisitPointsWithCells
```
The `ControlSignature` tags have been renamed as follows:
```
FieldInTo --> FieldInVisit
FieldInFrom --> FieldInMap
FromCount --> IncidentElementCount
FromIndices --> IncidentElementIndices
```
Although it is mostly C++11 compliant, GCC 4.8 does not have an
implementation of std::aligned_union. We cannot drop this compiler, so
provide our own implementation in that case.
Previously, templates were used in the implementation of CastAndCall to
find the type and call the underlying function. The templates checked
one type at a time.
However, compilers were not always great at optimizing a 15-call deep
stack with an if statement at each one. Instead, use a case statement in
a single function block. This requires providing separate code for each
number of types. Currently, up to 20 are created (with pyexpander). If
there are more than that, then the template recurses.
Currently, ListTags are implemented by having a subtype name list set to
a brigand::list. However, there is always a chance this will change. To
make things more explicit, create a vtkm::internal::ListTagToBrigandList
to make it clear what the resulting type should be (and provide some
potential future-proofing).
Also add a convenient vtkm::ListTagApply that allows you to easily
instantiate a template with the list of types in a ListTag.
vtkm::internal::Variant is a simplified version of C++17's std::variant
or boost's variant. It is a template that takes a list of types. The
Variant may be set to any one of those types. A CastAndCall allows you
to call a functor with the appropriately cast type.
how did any of this work?
match other CellSet file layouts.
???
compile in CUDA.
unit tests.
also only serial.
make error message accurate
Well, this compiles and works now.
Did it ever?
use CellShapeTagGeneric
UnitTest matches previous changes.
whoops
Fix linking problems.
Need the same interface
as other ThreadIndices.
add filter test
okay, let's try duplicating CellSetStructure.
okay
inching...
change to wedge in CellSetListTag
Means changing these to support it.
switch back to wedge from generic
compiles and runs
remove ExtrudedType
need vtkm_worklet
vtkm_worklet needs to be included
fix segment count for wedge specialization
need to actually save the index
for the other constructor.
specialize on Explicit
clean up warning
angled brackets not quotes.
formatting
All C++11 compilers support _Pragma to insert pragmas inline into code
and within macros. All compilers, that is, except for visual studio
because Microsoft has to be contrarian and make life miserable for all
programmers. Instead, you have to use __pragma with visual studio.
It is very easy to cause ODR violations with DeviceAdapterTagCuda.
If you include that header from a C++ file and a CUDA file inside
the same program we an ODR violation. The reasons is that the C++
versions will say the tag is invalid, and the CUDA will say the
tag is valid.
The solution to this is that any compilation unit that includes
DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled
must be invoked by the cuda compiler.
We previously had to mark the make_FunctionInterface function as
host/device as it could be used in either place. The ramifications
of this is that each time we launched a worklet any input parameter
had to either suppress cuda exceptions, or had to rely on the
DispatcherBase to suppress the warnings.
By making make_FunctionInterface only host callable ( as it is ),
we can remove all of our unneccesary suppression logic and better
expose real issues with code that is marked host/device but can't
be due to calling things such as std::abort
This adds an ExecutionSignature tag named Device that passes the
DeviceAdapterTag as an argument to the worklet's operator(). This allows
worklets to specialize their code based on the device.
Mask objects allow you to specify which output values should be
generated when a worklet is run. That is, the Mask allows you to skip
the invocation of a worklet for any number of outputs.
Declaring operator= as const seems a little weird because we are
changing the value. But remember that ArrayPortalReference is only a
reference class. The reference itself does not change, just the thing
that it is referencing. So declaring as const is correct and necessary
so that you can set the value of a reference returned from a function
(which is a right hand side value).
The ArrayPortalValueReference is supposed to behave just like the value
it encapsulates and does so by automatically converting to the base type
when necessary. However, when it is possible to convert that to
something else, it is possible to get errors about ambiguous overloads.
To avoid these, add specialized versions of the operators to specify
which ones should be used.
Also consolidated the CUDA version of an ArrayPortalValueReference to the
standard one. The two implementations were equivalent and we would like
changes to apply to both.
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).
`vtkm::cont::testing` now initializes with logging enabled and support
for device being passed on the command line, `vtkm::testing` only
enables logging.
Adds a variable `GlobalPointIndexStart` to `CellSetStructured`.
Adding this to the cell-set, instead of the coordinate system, enables this
feature for different types of datasets like uniform grid, rectilinear, etc.,
with this one change.
The extents can be computed using `GlobalPointIndexStart` and `PointDimensions`.
In theory if you requested negative indices's or generated a structure
with invalid point sizes the result of some operations would be
in an invalid state. Gave the compiler hints that this states
can't occur.
