04f020ae6 Update Field to use new ArrayRangeCompute features
2a41428fe Add implementation of ArrayRangeCompute for UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2409
This is a fancy array that takes an array of offsets and converts it to
an array of the number of components for each packed entry.
This replaces the use of `ArrayHandleDecorator` in `CellSetExplicit`.
The two implementation should do the same thing, but the new
`ArrayHandleOffsetsToNumComponents` should be less complex for
compilers.
Reduces the amount of code that has to be generated. Also improves the
number of arrays supported and has better support for deprecated
versions of `GetRange`.
CUDA architecture has a limited amount of memory available for
constants. The CUDA compiler uses this space to hold constants for some
optimizations. However, for large kernels, the number of constants
needed might be larger than the constant space available. For these
conditions, you have to disable this form of optimization with the `-
Xptxas --disable-optimizer-constants` flags.
Currently, the only file that seems to have this issue is the test for
the Lagrangian filter. Someone should take a closer look to see if this
filter in particular is making unnecessarily large worklet/kernel. (In
particular, why does the Lagrangian filter have a larger kernel than the
streamline and stream surface filters?)
If this occurance happens more often, we might need to add some ways to
configure it in the build.
There was some compile errors with CUDA and the CellLocatorGeneral.
Apparently it added enough to the CUDA kernel to cause issues with
constant memory.
`CellLocatorChooser` allows you to select a cell locator at compile
time. Unlike `CellLocatorGeneral`, you have to deduce what cell set
types you might have, but you don't have to have a large switch
statement in the middle of your worklet.
There appears to be a bug in GCC where if you mixed C++ attributes like
`[[deprecated]]` with GNU attributes like `__attribute__(())`, you will
get a compile error. This can be a problem when using attributes to both
set the export (i.e. visibility) of an item and deprecating the same
item.
This problem has been encountered before. Commit
34b0bba84207a89e8fddfe62e7a1ff30b1b53a18 fixed the problem by using
`[[gnu::visibility()]]` instead of `__attribute__()` in the export
macros. This works fine for export macros defined by VTK-m headers such
as `VTKM_ALWAYS_EXPORT`. Unfortunately, we have little control over the
export macros that CMake automatically creates. Rather than rewrite the
CMake export code, we go the other way and use `__attribute__()` for all
exports _and_ the depreciated attribute.
Deprecated the `CellLocator` class and made all methods of the
other `CellLocator` classes non-virtual. General locators can
still use the `CellLocatorGeneral` class, but this class now
only works with a predefined set of locators. (The functionality
to provide a function to select a locator has been removed.)
0797359c5 Make ExecutionWholeArray objects not depend on device type
0bee74438 Support DeviceAdapterId in deprecated ArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nick Thompson <nathompson7@protonmail.com>
Merge-request: !2405
With recent changes to `Arrayhandle`, the type for the associated array
portal is now the same across all devices. This means that almost all
exec objects no longer need to be specialized on the device types. Thus,
clean up the whole array exec objects to no longer need to be templated
on device.
The original `ArrayHandle` design had the `PrepareFor*` methods
templated on the device adapter tag. This is no longer necessary (at
least for any existing `ArrayHandle`), so support calling `PrepareFor*`
with a `DeviceAdapterId` that is resolved at runtime.
With recent changes to `ArrayHandle`, the type for the associated array
portal is now the same across all devices. This means that almost all
exec objects no longer need to be specialized on the device types. Thus,
clean up the locator exec objects to no longer need to be templated on
device.
05fc1747e Make deprecated tags more descriptive
b92566cdd Convert `std::endl` to `'\n'`
b8b958a98 Get rid of CellSetStructured.hxx
f4bc3002b Fix compiler error with `constexpr` method
4d8f05bae Update CellSetExtrude to not specify exec types by device
3962e73b0 Fix issues with class specialization
c55d15f39 Deprecate ArrayHandle::ExecutionTypes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2401
e4241aa53 Make matrix unit tests less verbose.
bba3d29c2 Remove UB from Matrix.h, and replace by quiet NaNs.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2402
One of the MSVC builds was giving template resolution problems for one
of the methods declared non-inline for no discernable reason. It sounds
like a compiler bug. Rather than try to work around the issue, just
move the declaration inline.
In fact, all the methods are really small (only 1 or 2 lines). Just
delete the .hxx file and simplify things.
The `GetMaxNumberOfNeighbours` of the `MeshStructure*` classes was
declared `constexpr`. This was causing some compiler errors.
I think the problem is actually a bug with GCC (https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=66297). Whether it is a compiler bug or not,
there does not seem to be a large value to declaring this method
`constexpr`, so I just removed the keyword.
Somewhere during this edit I removed a header file that didn't strictly
need to be there. This caused me to have to add
```cpp
```
in several places in the code.
The newer version of `ArrayHandle` no longer supports different types of
portals for different devices. Thus, the `ReadPortalType` and
`WritePortalType` are sufficient for all types of portals across all
devices.
This significantly simplifies supporting execution objects on devices,
and thus this change also includes many changes to various execution
objects to remove their dependence on the device adapter tag.
Some (but not all) versions of visual studio seem to have a bug that
causes a syntax error when using the deprecated attribute in a templated
constructor.
The actual code for AtomicArrayExecutionObject does not need to be
specialized by the device. The functionality is implemented by calling
the vtkm::Atomic* methods, which are properly implemented on each
device.
Unfortunately, there is no way to specify when copying `RecombineVec`s
whether we wish to allow precision loss in conversions. Because
sometimes we need them, disable the warnings.
It used to be the case where you needed to call `ResetTypes` on a
`VariantArrayHandle` before using `ArrayCopy` to limit the types it gets
compiled for. However, there is now a general form for
`UnknownArrayHandle`, so `ResetTypes` no longer does anything useful in
this case. Remove the use of that.
Rather than copy every type to every other type, only copy for the same
base type or copy to/from FloatDefault. This should reduce the amount of
code generated by a lot.
This reduces the size of the .o for ArrayCopy.cxx on my mac from
21MB to 7.7MB.
Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and
copies them for (almost) any `ArrayHandle` type.
The code uses `CastAndCallWithExtractedArray` to reduce the total number
of copy conditions to about 100, which are all precompiled into the
library. On a debug build on my mac, this creates a .o file of 21MB.
That's not great, but not terrible. Hopefully, this can be used to
consolidate copy implementations elsewhere.
The circular dependency came from UnknownArrayHandle.h needing
VTKmDefaultTypes.h, which needed all the cell set types. Some of those
cell sets used ArrayCopy in templated functions. Changed those functions
to directly deep copy the ArrayHandle.
This provides the ability to convert an array handle of an unknown value
type to an array handle that has `vtkm::FloatDefault` as its base
component type. Thus subsequently lets you pull the components as
`vtkm::FloatDefault` without having to worry about type conflicts.
There was an error that caused deprecation warnings in VTK-m to be
suppressed, which meant that many uses of deprecated features went
unnoticed. This fixes those deprecation warnings.
The majority of the warnings were caused by the use of the deprecated
`Cast`, `CopyTo`, and `ResetTypes` methods of `UnknownArrayHandle` (or
`VariantArrayHandle`). Both `Cast` and `CopyTo` have been subsumed by
`AsArrayHandle` (to make the functionality more clear). `ResetTypes` now
requires a second template argument to define the storage types to try.
Also fixed some issues with `SerializableField` being deprecated.
This class is no longer necessary because `Field` can now be directly
serialized.
Field.h had a runaway deprecation suppression where the pragmas to
suppress deprecation warnings were turned on but not properly turned
off. This caused deprecation warnings to be turned off for anything
including Field.h (directly or indirectly), and consequently lots of use
of deprecated features went unnoticed.
There are several places in the ray casting library that require
operating on a field that we know is a scalar field. Previously, these
were all independently cast to an uncertain array of the limited types.
Rather than have independent calls everywere, make a consolidated
function that does the same operation for everyone.
This fixes an issue with using a deprecated version of a method. It also
makes it possible to quickly change types in the future.
081f8aaea reformat if statements, add comments on the HDF5 macros
31aa46706 Merge branch 'master' into hdf5_image_io
e65c0713b move #include of hdf5.h into .cxx files
ff0b8fd0b changed to CMake files based on Robert's feedback
ca0ce4de7 Merge branch 'master' into hdf5_image_io
23a95f864 exclude header files from install check when it is not enabled
d81f08eed correct copyright mesage
fb6c9afe7 uncomment ubuntu1805_cuda image
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2371
MSVC tends to give deprecation warnings in templated methods that are
used with deprecated classes rather than where the deprecated thing was
declared. That makes it annoyingly hard to supress them to implement
support of deprecated items.
The `VariantArrayHandle` will soon be deprecated for its replacement of
`UnknownArrayHandle`. Thus, `Field` and related classes should start
using the new `UnknownArrayHandle`.
The compile error happened from incompatible code changes between !2349
and !2374. The former removed the ability to use non-`Vec` values in
`ArrayHandleSOA`. The latter tried to create such an `ArrayHandle`
inside a template function that was called with the SOA storage.
cecd81d5d Add types appropriate for Ascent
865855ea0 Add changelog for making ArrayHandleSOA a default array
50ff9c22a Add support of `ArrayHandleSOA` as a default storage type
bc09a9cd1 Add precompiled versions of `ArrayRangeCompute` for `ArrayHandleSOA`
77f9ae653 Support `ArrayHandleSOA` only for `Vec` value types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2349
3228752b2 Fix error message when using deprecated storage
5ef4e7eee Make new style of ArrayHandle the expected style
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2375
`ArrayHandleCounting` only works with values that support basic
arithmetic. The concept of counting makes little sense for types that
are not well defined for addition and multiplication like `bool`,
`string` and other custom types.
`RecombineVec` is the class used as the value type for
`ArrayHandleRecombineVec`. It is a `Vec`-like object, but has several
limitations (including arithmetic operators like `+` won't work).
Arithmetic assignment operators are useful so you don't have to create
impossible intermediate values.
Previously, the arithmetic assignment operators (`+=`, `-=`, `*=`, `/=`)
on `VecBaseCommon` only accepted another subclass of `VecBaseCommon`.
Changed the operators to accept any type.
The benefit of this change is that the assignment operator of classes
that inherit from `VecBaseCommon` can now work with `Vec`-like classes
that do not inherit from `VecBaseCommon`. I think the only real downside
is that the template could match other classes that would lead to
invalid comparisons. But such use would lead to a compile error anyway.
The difference is that instead of getting an error that no overloaded
version of the operator is available, you will get an error inside the
code of the operator.
The base C types have several "duplicate" types that the compiler
considers different even though the byte representation is the same. For
example, `char` and `signed char` have the same meaning but are treated
as different types. Likewise, 'long', 'int', and 'long long' are all
different types even though 'long' is the same as either 'int' or 'long
long'.
When pulling extracted components from `UnknownArrayHandle`, there is
little value for creating multiple code paths for types like `char` and
`signed char`. Instead, allow implicit conversion among these types.
When using the old style of storage, you need to declare it as the old
style so that a bridge to the new style can be built in. You get a
compile error message if this is not done. The previous message gave the
wrong instructions.
What was previously declared as `ArrayHandleNewStyle` is now just the
implementation of `ArrayHandle`. The old implementation of `ArrayHandle`
has been moved to `ArrayHandleDeprecated`, and `ArrayHandle`s still
using this implementation must declare `VTKM_ARRAY_HANDLE_DEPRECATED` to
use it.
Some of the special `ArrayHandle`s require specialized versions of
`vtkm::exec::arg::Fetch`. The specializations were not put in the
respective vtkm/exec/arg/Fetch*.h header files because the definition of
the `ArrayHandle`s was not available there. The implementation was in
the ArrayHandle*.h files, but it is hard to find the specialization
there.
Instead, make a secondary header file in vtkm/exec/arg that implements
the Fetch specialization and include it from the ArrayHandle*.h file.
That way, the basic Fetch does not have to include odd `ArrayHandle`
types but the `Fetch` implemenations are still all located together.
This method was originally deprecated to avoid confusion with the
indexing of the components in `ExtractComponent`. However, there might
be good reason to want to know the non-flat number of components, so
maybe getting rid of it is not a great idea. Unmark the method as
deprecated, at least for now.
Previously, `ArrayHandleSOA` worked with any value type that supported
`VecTraits`. That means that `ArrayHandleSOA` worked with scalar types
like `Float32`. However, for scalar types, the behavior is essentially
the same as `ArrayHandleBasic`, but with lots of extra templating and
code generation.
Although there is nothing _wrong_ with allowing `ArrayHandleSOA` holding
a scalar, there is no real reason to either (other than likely template
convenience). Generally, there is nothing wrong with supporting it, but
if you want to support `ArrayHandleSOA` in places where types are not
known (e.g. `Field`), then templating tends to iterate over the cross of
all supported types with all supported storage. That means such code
will automatically generate a bunch of code for `ArrayHandleSOA` with
scalars even if there is no reason for those code paths.
So, we can just disable the use of `ArrayHandleSOA` with scalars to
allow us to use `ArrayHandleSOA` as a default storage without creating
all these useless code paths.
`ArrayHandleRecombineVec` is used when calling
`ExtractArrayFromComponents` from `UnkownArrayHandle`. It needs special
handling with the `Fetch` for an output array.
This method allows you to extract an `ArrayHandle` from
`UnknownArrayHandle` when you only know the base component type.
Also removed the `Read/WritePortalForBaseComponentType` method
from `UnknownArrayHandle`. This functionality is subsumed by
`ExtractArrayFromComponents`.
The primary purpose of `ArrayHandleRecombineVec` is to take arrays
returned from `ArrayExtractComponent` and recombine them again into a
single `ArrayHandle` that has `Vec` values.
The previous implementation of test_equal_ArrayHandles was several
templates that had to be resolved by any test that used them, which
could be costly for unknown array types. Simplify this a bit by moving
the implementation of testing unknown arrays into a library.
Another advantage of the new implementation is that is handles more
cases. Thus, you should not need to `ResetTypes` on the unknown/
uncertain arrays.
Some of the `test_equal` functions return a `TestEqualResult`
instead of a `bool` to capture more information about what
the error was. Unfortunately, using this was awkward because
you couldn't just call the `test_equal_*` inside of a
`VTKM_TEST_ASSERT`. Rather, you would have to do the comparison
and then check it.
This change adds an overload to `VTKM_TEST_ASSERT` that specifically
takes a `TestEqualResult`, checks its condition, and prints out
the contained messages. Thus, your command can just look like
`VTKM_TEST_ASSERT(test_equal_ArrayHandles(...));` and it will
provide the additional information.
These helper functions were in vtkm::cont::testing, but that made them
hard to discover (and I personally kept forgetting about them). Move
them to the top namespace so that IDE of test_equal will helpfully
remind us of these other test functions.
Recent merge requests !2354 and !2356 both edited ArrayHandleView. Git
successfully merged the changes, but the changes were still incompatible
with each other, causing an unexpected compile error on master. This
fixes the issue.
`VecFlat` has a casting operator to cast itself to the nested version of
the `Vec`. However, for a simple `Vec` type, the superclass of `VecFlat`
is the same type as the "nested" `Vec` type (which was flat to begin
with). This meant that the casting operator was never used because it
casted to the same type as the object being cast from. Most compilers
silently ignored this, but some gave a warning that the casting operator
would never be used because of this condition.
Fix the problem by having a different implemention of `VecFlat` when
applied to a `Vec` that is already flat.
Previously, the `MapFieldMergeAverage` and `MapFieldPermutation` helper
function had to iterate over every possible type and create a separate
code path. This change uses the new extract component functionality to
create separate code paths only for different component types. This both
requires less code (the common filter library dropped from 66MB to 42MB
on my Mac) and covers more cases (such as `Vec`s larger than 4
components).
To make the implementation easier, `UnknownArrayHandle` now can create a
new `UnknownArrayHandle` of the same `ValueType` but with the basic
storage (so you can work with read-only storage) and the ability to
allocate the unknown array.
This allows you to handle just about every type of array with about 10
basic types. It allows you to ignore both the size of `Vec`s and the
actual storage of the data.
The typical use case of `ArrayHandleStride` is to flexibly point into
another array, often looking at a single component in an array. It is
typical that multiple things will be accessing the same array, and bad
things could happen as they all try to resize. There was some code to
try to figure out what the size of the original array was, but it was
fragile.
It is safer for now to disable the behavior altogether. If a use case
pops up, we can reintroduce the code.
`ArrayExtractComponent` allows you to get a component of an array.
Unlike `ArrayHandleExtractComponent`, the type you get is always the
same: an `ArrayHandleStride`. This way, you can get an array that
contains the data of an extracted component with less templating and
potentially dramatically reduce the amount of code generated (although
some runtime integer arithmetic is added).
`vtkm::VecFlat` is a wrapper around a `Vec`-like class that may be a
nested series of vectors. For example, if you run a gradient operation
on a vector field, you are probably going to get a `Vec` of `Vec`s that
looks something like `vtkm::Vec<vtkm::Vec<vtkm::Float32, 3>, 3>`. That
is fine, but what if you want to treat the result simply as a `Vec` of
size 9?
The `VecFlat` wrapper class allows you to do this. Simply place the
nested `Vec` as an argument to `VecFlat` and it will behave as a flat
`Vec` class. (In fact, `VecFlat` is a subclass of `Vec`.) The `VecFlat`
class can be copied to and from the nested `Vec` it is wrapping.
There is a `vtkm::make_VecFlat` convenience function that takes an
object and returns a `vtkm::VecFlat` wrapped around it.
7475c318b VTK-m now uses CMake's future HIP lang for Kokkos+HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2351
7811cc4b1 Add standard support for read-only storage
a6b9d5c49 Add tests for ReleaseResources of fancy arrays
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2345
Many of the fancy `ArrayHandle`s are read-only and therefore connot
really create write portals. Likewise, many `ArrayHandle`s (both read-
only and read/write) have no way to resize themselves. In this case,
implementing the `CreateWritePortal` and `ResizeBuffers` methods in the
`Storage` class was troublesome. Mostly they just threw an exception,
but they also sometimes had to deal with cases where the behavior was
allowed.
To simplify code for developers, this introduces a pair of macros:
`VTKM_STORAGE_NO_RESIZE` and `VTKM_STORAGE_NO_WRITE_PORTAL`. These can
be declared in a `Storage` implementation when the storage has no viable
way to resize itself and create a write portal, respectively.
Having boilerplate code for these methods also helps work around
expected behavior for `ResizeBuffers`. `ResizeBuffers` should silently
work when resizing to the same size. Also `ResizeBuffers` should behave
well when resizing to 0 as that is what `ReleaseResources` does.
The `ReleaseResources` method should work for all arrays (even if it
effectively does not do anything). However, the implementation of
`ReleaseResources` is generally to call `Allocate` with 0. Several fancy
arrays balk at this because it is resizing a read-only array. There
should be an exception for this.
This class was used indirectly by the old `ArrayHandle`, through
`ArrayHandleTransfer`, to move data to and from a device. This
functionality has been replaced in the new `ArrayHandle`s through the
`Buffer` class (which can be compiled into libraries rather than make
every translation unit compile their own template).
This commit removes `ArrayManagerExecution` and all the implementations
that the device adapters were required to make. None of this code was in
any use anymore.
`ArrayTransfer` is used with the old `ArrayHandle` style to move data
between host and device. The new version of `ArrayHandle` does not use
`ArrayTransfer` at all because this functionality is wrapped in `Buffer`
(where it can exist in a precompiled library).
Once all the old `ArrayHandle` classes are gone, this class will be
removed completely. Although all the remaining `ArrayHandle` classes
provide their own versions of `ArrayTransfer`, they still need the
prototype to be defined to specialize. Thus, the guts of the default
`ArrayTransfer` are removed and replaced with a compile error if you try
to compile it.
78aa463da Fix compile error when template parameter shadows superclass
905b5a02b Call PrepareForControl to get transform for undefined device
650e416cc Convert ArrayHandleTransform to new buffer-style-array
76880dd8c Enable ExecutionObjectBase::PrepareForExecution for DeviceAdapterId
b0146b1e4 Fix issue with CreateBuffers function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2341
I'm too lazy to look up the C++ spec, but it seems like template
parameter names would shadow the same names from a superclass.
Apparently that is not the case for Visual Studio. The `Storage` for the
cast array inherits from the `Storage` of the transform array. The
latter declares a private type named `SourceStorage`, and that is being
used instead of the former's `SourceStorage` template parameter. You
then get an error for accessing a private member that you did not want
in the first place.
Fix the problem by changing the name of the template parameter.
