VTK-m has a deprecation method that supports API changes in minor
releases. When an API change is made, the old API is marked with the
VTKM_DEPRECATED macro. If code attempts to use the old API, it still
works, but the compiler issues a warning that the thing is deprecated
and where to find the new API.
We have recently run into an issue when the API changes have a header
file renamed or moved. We still keep the old header file with the old
API, so code including that file will still work. However, sometimes
code expected the contents of that header file without directly
including that header file. In these cases, the code could get an error
about missing classes.
As an example, consider the change from `DynamicCellSet` to
`UnknownCellSet`/`UncertainCellSet`. The deprecated `DynamicCellSet` is
still around. But there is a lot of code that did not directly include
DynamicCellSet.h. This header file was necessarily included by
DataSet.h. Now, when this code uses `vtkm::cont::DynamicCellSet`, you
get a confusing error that the class does not exist. Backward
compatibility broken.
In response to this, we should be more careful about where we put the
deprecated API. Instead of containing the deprecated API, moved headers
should be empty except for a warning and an inclusion of the new header
file. The deprecated API should be moved to the new header file. For
example, in the case of `DynamicCellSet`, the implementation for the
deprecated `DynamicCellSet` is moved to UnknownCellSet.h, which is
included by anything that was including DynamicCellSet.h before.
A large portion of the VTK-m filters are now compiled into the
vtkm_filter library. These pre-built filters now don't include
the respective hxx file to remove the amount of template
instantiation users do.
To verify that this removal reduces compiler memory ( and maybe time)
I profiled the compiler while it building filter tests in debug mode.
Here is a selection of results:
```
CleanGrid 10.25s => 9.01s, 901MB => 795MB
ExternalFaces 13.40s => 5.96s, 1122MB => 744MB
ExtractStructured 4.69s => 4.75s, 492MB => 492MB
GradientExplicit 22.97s => 5.88s, 1296MB => 740MB
```
There is a limitation in Windows builds using VS2019 where libraries cannot be
bigger than 4GiB. This is normally not an issue but in `VTKm` due to its strong
template usage libraries can reach that size.
The `VTKm` filter library is can easily reach that size and it will halt the
build
This MR tries to avoid reaching those sizes for now by splitting the filter
library into four smaller libraries.
The proposal scheme is:
It splits vtkm-filter into:
- vtkm-common, Classes that are dependencies of other filter libs.
- vtkm-contour, Contour class and its instantiations.
- vtkm-contour, Gradient class and its instantiations.
- vtkm-extra, Classes other than Contour or Gradient that are
not dependencies.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
The version of `Filter::Execute` that takes a policy as an argument is now
deprecated. Filters are now able to specify their own fields and types,
which is often why you want to customize the policy for an execution. The
other reason is that you are compiling VTK-m into some other source that
uses a particular types of storage. However, there is now a mechanism in
the CMake configuration to allow you to provide a header that customizes
the "default" types used in filters. This is a much more convenient way to
compile filters for specific types.
One thing that filters were not able to do was to customize what cell sets
they allowed using. This allows filters to self-select what types of cell
sets they support (beyond simply just structured or unstructured). To
support this, the lists `SupportedCellSets`, `SupportedStructuredCellSets`,
and `SupportedUnstructuredCellSets` have been added to `Filter`. When you
apply a policy to a cell set, you now have to also provide the filter.
VTK-m now provides the following filters with the default policy
as part of the vtkm_filter library:
- CellAverage
- CleanGrid
- ClipWithField
- ClipWithImplicitFunction
- Contour
- ExternalFaces
- ExtractStructured
- PointAverage
- Threshold
- VectorMagnitude
By building these as a library we hope to provide faster compile
times for consumers of VTK-m when using common configurations.
Now that the dispatcher does its own TryExecute, filters do not need to
do that. This change requires all worklets called by filters to be able
to execute without knowing the device a priori.
This commit removes `vtkm::filter::Result`. All methods that used
`vtkm::filter::Result` simply change to use `vtkm::cont::Dataset` instead.
The utility API on `Result` that was used to add fields to the resulting
dataset is now available via `vtkm::filter::internal::CreateResult`.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
