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
```
- It explicitly instantiate its concrete templates to
the supported types.
- It disables implicit template instantations for the
the supported types.
- Also fix small typo in Contour impl include guards
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.
1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.
To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.
Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.
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>
Generally, fields that have a WHOLE_MESH association might be valid even
if the structure of the mesh changes. Thus, it makes sense for filters
to pass this data pretty much all the time.
Also cleaned up some code and comments to make the relationship between
`MapFieldOntoOutput` and `DoMapField` more clear.
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.