This should help catch regressions that only affect a single filter. It
also allows us to set up a partitioned test that has many small blocks.
It also fixes an issue we were seeing on the dashboard where the
contour benchmark was apparently running out of resources.
Added a name option that allows the same benchmark executable to be used
in multiple benchmark tests. This allows the benchmarks to be separated.
Also added an option to pass customized arguments to the benchmark
executable to overwrite the default values.
Originally, most of the sources used constructor parameters to set the
various options of the source. Although convenient, it was difficult to
keep track of what each parameter meant. To make the code more clear,
source parameters are now set with accessor functions (e.g.
`SetPointDimensions`). Although this makes code more verbose, it helps
prevent mistakes and makes the changes more resilient to future changes.
Several revisions ago, the ability to use virtual methods in the
execution environment was deprecated. Completely remove this
functionality for the VTK-m 2.0 release.
`ExecutionWholeArray` is an archaic class in VTK-m that is a thin wrapper
around an array portal. In the early days of VTK-m, this class was used to
transfer whole arrays to the execution environment. However, now the
supported method is to use `WholeArray*` tags in the `ControlSignature` of
a worklet.
Nevertheless, the `WholeArray*` tags caused the array portal transferred to
the worklet to be wrapped inside of an `ExecutionWholeArray` class. This
is unnecessary and can cause confusion about the types of data being used.
Most code is unaffected by this change. Some code that had to work around
the issue of the portal wrapped in another class used the `GetPortal`
method which is no longer needed (for obvious reasons). One extra feature
that `ExecutionWholeArray` had was that it provided an subscript operator
(somewhat incorrectly). Thus, any use of '[..]' to index the array portal
have to be changed to use the `Get` method.
When the configure modules were first created, there were some hacks
around filters that had not yet moved to the new filter mechanism. These
can (and should) be removed.
The previous version of BenchmarkInSitu added arguments to its argv list
by using `strdup`. However, this method will leak memory, which is not
great. Replace this with a safer mechanism that will properly delete
memory at the end of the program (and satisfy any memory analyzers).
This also fixes a warning from MS about `strdup` being deprecated.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
Previous version had a hard-coded loop for updating the dataset. This change relenquishes control over to google benchmarks. Running it from the command-line will iterate each sub-benchmark a different number of iterations depending on how long each individual test takes. The number of iterations can be increased (but not controlled) by increasing the minimum time for each test. Alternatively, using the "repetitions" argument, you can control exactly how many times the benchamrks are run.
See the README for InSitu that throughly documents the arguments.
There were several tests that were disabled for hip because they either
took too long to compile or were failing. We are getting closer to
making everything work, so re-enable this part of the build.
The static datasets were wreaking havoc on order of destructors at exit and causing kokkos to throw an exception. This change dynamically allocates a dataset, copies the read/sourced data into it, and explicitly frees the data.
The enumerations in `vtkm::cont::Field::Association` were renamed in the
previous commit. The old names still exist, but are deprecated. Change
the rest of the code to use the new names.
d7b4390d1 Specify end position when filling values in Buffer
7a4cbaf10 Suggestions during review by Gunther Weber
8e4fb7ebd Suppress unhelpful nvcc warning
bacca0693 Add Fill method for non-standard Storage
9da66ff32 Prefer ArrayHandle::Fill over Algorithm::Fill
f79cf1d5f Add BitField::Fill and BitField::AllocateAndFill
926164049 Add Fill and AllocateAndFill to ArrayHandle
0cf996f41 Add ability to fill values in a Buffer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2660
The `DynamicCellSet` (and the related `DynamicCellSetBase`) are
deprecated and replaced with `UnknownCellSet` (and `UncertainCellSet`).
Thus, `UnknownCellSet` has some methods inherited from `DynamicCellSet`
but replaced with other functionality. These methods are now marked as
deprecated and their use is removed.
The `DynamicCellSet` class is now marked as deprecated (as is the header
that contains it), and all non-deprecated code is moved to its
`UnknownCellSet` replacement.
Also added a deprecation warning for the VariantArrayHandle.h header
file and deleted a couple inappropriate uses of it.