Some versions of doxygen have issues with documenting `typedef`s (or the
equivalent `using`). This was causing warnings with doxygen and failing
to create some of the documentation. This fixes the problem by moving the
documentation to the classes things are defined to.
The original design of the filter base class required several specialized
base classes to control what information was pulled from the input
`DataSet` and provided to the derived class. Since the filter base class was
redesigned, the derived classes all get a `DataSet` and pull their own
information from it. Thus, most specialized filter base classes became
unnecessary and removed.
The one substantial exception was the `FilterField`. This filter base class
managed input and output arrays. This was kept separate from the base
`Filter` because not all filters need the ability to select this
information.
That said, this separation has not been particularly helpful. There are
several other features of `Filter` that does not apply to all subclasses.
Furthermore, there are several derived filters that are using `FilterField`
merely to pick a single part, like selecting a coordinate system, and
ignoring the rest of the abilities.
Thus, it makes more sense to deprecate `FilterField` and have these classes
inherit directly from `Filter`.
The `DeviceAdapter` provides an abstract interface to the accelerator
devices worklets and other algorithms run on. As such, the programmer has
less control about how the device launches each worklet. Each device
adapter has its own configuration parameters and other ways to attempt to
optimize how things are run, but these are always a universal set of
options that are applied to everything run on the device. There is no way
to specify launch parameters for a particular worklet.
To provide this information, VTK-m now supports `Hint`s to the device
adapter. The `DeviceAdapterAlgorithm::Schedule` method takes a templated
argument that is of the type `HintList`. This object contains a template
list of `Hint` types that provide suggestions on how to launch the parallel
execution. The device adapter will pick out hints that pertain to it and
adjust its launching accordingly.
These are called hints rather than, say, directives, because they don't
force the device adapter to do anything. The device adapter is free to
ignore any (and all) hints. The point is that the device adapter can take
into account the information to try to optimize for itself.
A provided hint can be tied to specific device adapters. In this way, an
worklet can further optimize itself. If multiple hints match a device
adapter, the last one in the list will be selected.
The `Worklet` base now has an internal type named `Hints` that points to a
`HintList` that is applied when the worklet is scheduled. Derived worklet
classes can provide hints by simply defining their own `Hints` type.
The scripts for the docs CI was set up to build the documentation
(doxygen and user's guide) during the `before_script` stage. This was a
hack so that different versions of the docs could post the built pages
during the `script` phase. However, this causes problems with running in
`reproduce_ci_env.py`.
Instead, move the actual building of documentation to the `script`
stage.
The breathe parser was having trouble with using `{}` inside of a
declspec for the return value. Replace this with parenthesis, which
cannot be confused with the openning of the function.
The naming convention for CI jobs is generally `stage:name` where the
`stage` matches the GitLab stage and the `name` is a description.
However, the documentation jobs broke this convention by being called
`docs:type` where `type` is `continuous`, `latest`, or `master`. This
breaks the convention because `docs` is not a stage and `type` does not
really describe the build. This fouls up things like
`reproduce_ci_env.py` that expect the first part of the name to be the
same as the stage.
This changes the names to `build:docs-continuous`, `build:docs-latest`,
and `build:docs-master`. This follows the convention of matching the
names with the stage.
Previously, if you called `Fill` on an `ArrayHandleStride`, you would get
an exception that said the feature was not supported. It turns out that
filling values is very useful in situations where, for example, you need to
initialize an array when processing an unknown type (and thus dealing with
extracted components).
This implementation of `Fill` first attempts to call `Fill` on the
contained array. This only works if the stride is set to 1. If this does
not work, then the code leverages the precompiled `ArrayCopy`. It does this
by first creating a new `ArrayHandleStride` containing the fill value and a
modulo of 1 so that value is constantly repeated. It then reconstructs an
`ArrayHandleStride` for itself with a modified size and offset to match the
start and end indices.
Referencing the `ArrayCopy` was tricky because it kept creating circular
dependencies among `ArrayHandleStride`, `ArrayExtractComponent`, and
`UnknownArrayHandle`. These dependencies were broken by having
`ArrayHandleStride` directly use the internal `ArrayCopyUnknown` function
and to use a forward declaration of `UnknownArrayHandle` rather than
including its header.
The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an
`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array.
Of these, the `Counts` array is redundant because the counts are trivially
computed by subtracting adjacent entries in the offsets array. This pattern
shows up a lot in VTK-m, and most places we have moved to removing the
counts and just using the offsets.
This change removes the `Count` array from the `Keys` object. Where the
count is needed internally, adjacent offsets are subtracted. The deprecated
`GetCounts` method is implemented by copying values into a new array.
This feature was introduced but is never used anywhere. It is up to the
worklet subclass to determine what to do with the boundaries with the
`BoundaryState` object.
In the future we may have a neighborhood worklet of compile-fixed sized
for better memory access efficiency. If that is the case, we can
reintroduce this idea. We can decide on the right implementation if that
design ever comes to pass.
