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 initial implementation of `MergePartitionedDataSet` would grow each
array as it was generated. As each partition was revisited, the arrays
being merged would be reallocated and data appended to the end. Although
this works, it is slower than necessary. Each reallocation has to copy
the previously saved data into the newly allocated memory space.
This new implementation first counts how big each array should be and
then copies data from each partition into the appropriate location of
each dataset.
Also changed the templating of how fields are copied so that all field
types are supported, not just those in the common types.
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.
`UnknownCellSet` is an updated replacement for `DynamicCellSet`. The
next step in the replacement is to change `DataSet` to use the new
class.
Also replaced `DynamicCellSet` with `UnknownCellSet` in a few
places where `DynamicCellSet.h` was not directly included (and
therefore now no longer included at all). This change would have
to be made at some point anyway.
To avoid having to use a device compiler every time you wish to use
`ArrayGetValue`, the actual implementation is compiled into the `vtkm_cont`
library. To allow this to work for all the templated versions of
`ArrayHandle`, the implementation uses the extract component features of
`UnknownArrayHandle`. This works for most common arrays, but not all
arrays.
For arrays that cannot be directly represented by an `ArrayHandleStride`,
the fallback is bad. The entire array has to be pulled to the host and then
copied serially to a basic array.
For `ArrayGetValue`, this is just silly. So, for arrays that cannot be
simply represented by `ArrayHandleStride`, make a fallback that just uses
`ReadPortal` to get the data. Often this is not the most efficient method,
but it is better than the current alternative.
We have been doing a better job at hiding device code (and moving code
into libraries). Smoke out source that no longer needs to be compiled by
device compilers.
The `test_equal_images` function has been expanded to supply the
generated image in a `Canvas` or a `DataSet` in addition to a `View`.
Much of the templating code has been removed from `test_equal_images`
and most of the code has moved into the `vtkm_rendering_testing`
library.
The previous functions that enabled the render regression tests were
heavily templated, which required every test using rendering to
recompile the entire rendering system being used. Changed the interface
to not rely on templating so that the RenderTest method can be moved
into a library.
Also moved the options into a struct where they can be better managed.
The render testing functions tended to have lots of arguments that were
difficult to manage. Instead, created a single `struct` that holds all
the potential options. That way when someone specifies on option, it is
clear what option is being set.
The tests that used rendering and image comparison were named
`RegressionTest*`. However, this name is not very descriptive as all the
tests are regression tests. These have all been renamed to be
`RenderTest*` to more clearly indicate that they are tests that use
rendering as part of the test.
Previously, all methods in the `vtkm::cont::testing::Testing` class were
inlined in the header file. This makes sense for the methods that are
templated, but not so much for methods that are not templated.
Although this change provides minimal improvements with compile times
and object sizes (maybe). But the real benefit is that some of these
methods declare static objects. When declared in inlined functions, a
different object will be created for each translation unit. This can
lead to unexpected behavior when multiple versions of a supposed
singleton static object exist.
The `Permutations` array was created using floating point numbers. But
integers were put into it and then used when taken out of it. Simplified
everything by simply making the value type of `Permutations` as
`vtkm::Id`.
