Previously, the `Allocate` method of `ArrayHandle` was _not_ declared as
`const`. Likewise, the methods that depended on `Allocate`, namely
`ReleaseResources` and `PrepareForOutput` were also not declared `const`.
The main consequence of this was that if an `ArrayHandle` were passed as a
constant reference argument to a method (e.g. `const ArrayHandle<T>& arg`),
then the array could not be reallocated.
This seems right at first blush. However, we have changed these methods to
be `const` so that you can in fact reallocate the `ArrayHandle`. This is
because the `ArrayHandle` is in principle a pointer to an array pointer.
Such a structure in C will allow you to change the pointer to the array,
and so in this context it makes sense for `ArrayHandle` to support that as
well.
Although this distinction will certainly be confusing to users, we think
this change is correct for a variety of reasons.
1. This change makes the behavior of `ArrayHandle` consistent with the
behavior of `UnknownArrayHandle`. The latter needed this behavior to
allow `ArrayHandle`s to be passed as output arguments to methods that
get automatically converted to `UnknownArrayHandle`.
2. Before this change, a `const ArrayHandle&` was still multible is many
way. In particular, it was possible to change the data in the array
even if the array could not be resized. You could still call things
like `WritePortal` and `PrepareForInOut`. The fact that you could
change it for some things and not others was confusing. The fact that
you could call `PrepareForInOut` but not `PrepareForOutput` was doubly
confusing.
3. Passing a value by constant reference should be the same, from the
calling code's perspective, as passing by value. Although the function
can change an argument passed by value, that change is not propogated
back to the calling code. However, in the case of `ArrayHandle`,
calling by value would allow the array to be reallocated from the
calling side whereas a constant reference would prevent that. This
change makes the two behaviors consistent.
4. The supposed assurance that the `ArrayHandle` would not be reallocated
was easy to break even accidentally. If the `ArrayHandle` was assigned
to another `ArrayHandle` (for example as a class' member or wrapped
inside of an `UnknownArrayHandle`), then the array was free to be
reallocated.
Added the following form of `ArrayCopy`:
```cpp
VTKM_CONT_EXPORT void ArrayCopy(
const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination);
```
Note that the destination array is a constant reference. This is
actually OK because you can change the contents of an
`UnknownArrayHandle` (as long as you don't change the array being
referenced). The main motivation for this change is to allow you to call
this form of `ArrayCopy` while passing in a `ArrayHandle` as the second
argument. C++ will automatically make the conversion, but the function
has to accept a const reference for it to be passed correctly.
Note that there is still a form of `ArrayCopy` that accepts a non-const
reference to the destination array. The two arrays behave the same
except for one difference. For the non-const version, if the
`UnknownArrayHandle` does not already point to an array (i.e. is not
valid), a new array will be created and placed in the destination
object. However, because this cannot be done for a const reference, an
exception is thrown instead.
835467753 Fix link issue with discarded section
42acb9a66 Properly check whether ArrayHandleRecombineVec is on device
c17a5569f Do not try to use ArrayGetValue on arrays of non-basic types
9ca0cd1f6 Report array type when UnknownArrayHandle::ExtractComponent fails
e1ac918bc Compile ArrayGetValues implementation in library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2551
By default, the `FilterDataSet` class will iterate over all fields and
use `CastAndCall` on each one to call the subclass' mapping function
with the appropriate array type.
This only works if the array is of a known type. If it is not
`CastAndCall` throws an exception. However, having the entire filter
exception out just because one field cannot be converted does not make
sense. Instead, catch the exception, log a warning, and drop the field.
The reason why we did not support shared libraries when CUDA compiles
were on is that virtual methods require a special linking step to pull
together all virtual methods that might be called. I other words, you
cannot call a virtual CUDA method defined inside a library. This
requirement goes away when virtuals are removed.
Also removed the necessity of using seprable compilation with cuda.
Again, this is only needed when a CUDA function is defined in one
translation unit and used in another. Now we can enforce that all
translation units define their own CUDA functions.
Also, suppress warnings in cuda/internal/ExecutionPolicy.h
This is where we call the thrust algorithms. There must be some loop
where it, on some code path, calls back a host function. This must be in
an execution path that never happens. The thrust version has its own
suppress, but that does not seem to actually suppress the warning (it
just means that the warning does not tell you where the actual call is).
Get around the problem by suppressing the warnings in VTK-m.
Co-authored-by: Kenneth Moreland <morelandkd@ornl.gov>
Co-authored-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
0855de1b4 Collect the get methods for `Field` in the header definition
47371bb5e Add ability to convert fields to known types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2558
`RuntimeDeviceConfiguration` is supposed to log a warning if a specific
device returns a non-success status other than simply an invalid option.
However, the condition was wrong and warnings never happened.
In VTK-m we have a constant tension between minimizing the number of
types we have to compile for (to reduce compile times and library size)
and maximizing the number of types that our filters support.
Unfortunately, if you don't compile a filter for a specific array type
(value type and storage), trying to run that filter will simply fail.
To compromise between the two, added methods to `DataSet` and `Field`
that will automatically convert the data in the `Field` arrays to a type
that VTK-m will understand. Although this will cause an extra data copy,
it will at least prevent the program from failing, and thus make it more
feasible to reduce types.
The `MeshQuality` filter only worked with `CellSetExplicit<>`. However,
`MeshQuality` should also work with `CellSetSingleType`. Fix
`MeshQuality` to work with both.
The handling of cell sets was actually worse than that. After forcing
the type to `CellSetExplicit<>`, it then applied a policy that converted
the types back to all possible cell sets. Thus, the filter made lots of
code paths that were impossible to follow.
In one of the dashboards, we got a link error about one of the
UnknownArrayHandle internal methods being discarded and then used. Add
an explicit `__attribute__((used))` modifier to prevent this from
happening.
The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from
the `UnknownArrayHandle` was on a device. Seems right, but it is
actually operating on an `ArrayHandleRecombineVec`. This is a special
array that mostly behaves like other `ArrayHandle`s, but because it has
variable vec size, it breaks some `ArrayHandle` conventions.
One of the iffy things it has to do is stick the dependent `Buffer`
objects into the metadata of its own `Buffer` rather than list them in
the `Buffer` list. This means that `ArrayHandle` cannot properly check
them to see where they are located. Instead, it just sees that the one
`Buffer` it has is empty.
A recent change to `IsOnDevice` made it return true for any device if
the `Buffer` is empty. So previously this was broken in that it reported
that the array was not on any device. That changed to report that it was
on all devices, even inactive ones. So the code went from not
efficiently copying to throwing an exception.
This has been fixed by pulling one of the dependent arrays and checking
that one.
Previously, all of the `ArrayGetValues` implementations were templated
functions that had to be built. That meant that any code using them had
to be compiled with a device compiler and create special code for it.
This change uses an `UnknownArrayHandle` to encapsulate the
`ArrayHandle` and call a per-compiled library function. This means that
the code only has to be compiled once.
3feff3689 Save device choice on spawned control threads
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2543
Having UnknownArrayHandle.h include DefaultTypes.h is problematic,
because that header includes lots of other classes like cell sets.
Keeping these from in turn depending back on UnknownArrayHandle.h is
difficult. So this dependancy is broken.
Added features with reporting types with `UnknownArrayHandle`. First,
added a method named `GetArrayTypeName` that returns a string containing
the type of the contained array. There were already methods
`GetValueType` and `GetStorageType`, but this provides a convenience to
get the whole name in one go.
Also improved the reporting when an `AsArrayHandle` call failed. Before,
the thrown method just reported that the `UnknownArrayHandle` could not
be converted to the given type. Now, it also reports the type actually
held by the `UnknownArrayHandle` so the user can better understand why
the conversion failed.
VTK-m contains a helpful method named `vtkm::cont::TypeToString` that
either takes a type as a template argument or a `std::type_info` object
and returns a human-readable string for that type.
The standard C++ library has an alternate for `std::type_info` named
`std::type_index`, which has the added ability to be used in a container
like `set` or `map`. The `TypeToString` overloads have been extended to
also accept a `std::type_info` and report the name of the type stored in
it (rather than the name of `type_info` itself).
39054e644 Add corner case unit test.
0a3fd2629 Add test file for corner case.
4b0896bd8 Fix for corner case in particle advection.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abhishek Yenpure <abhishek@uoregon.edu>
Merge-request: !2545
Since we have (hopefully) gotten rid of all unbounded recursion and
calls to function pointers or virtual methods, the CUDA compiler should
be able to statically determine the size of the stack needed. Thus, we
shouldn't need `ScopedCudaStackSize` at all.
However, there is one odd case where using it seems to be necessary. It
is unclear why, but that is an issue for another day.
The implementation of the search in the k-d tree is problematic because
it uses unbounded recursion. This is a problem for GPU devices, which
have very short stacks set by how many calls the compiler determines.
This is fixable, but the fix is not trivial.
This class is not used anywhere in VTK-m other than a trivial test.
Thus, I am just deprecating the class. I am also deleting the test, so
the code is not run anymore.
The maximum recursion that could happen was 1 call in, but compilers had
trouble determining that. Split this into 2 non-recursive functions so
the compiler can easily determine the stack depth.
The `RuntimeDeviceTracker` is a thread-local variable that monitors the
devices to use separately on each thread. This is an important feature
to allow different threads to control different devices.
When a tracker is created on a new thread, it was simply reset, which
makes sense. However, the reset does not take into account the device
selected by `vtkm::cont::Initialize`. This means that if VTK-m was used
in a different thread than it was initialized, it would ignore the
`--vtkm-device` parameter.
To get around this problem, keep track of the `RuntimeDeviceTracker` on
the "main" thread. When a `RuntimeDeviceTracker` is created on a new
thread, it copies the state from that tracker.
It is sometimes the case that you want to copy the state of one
`RuntimeDeviceTracker` to another. This is particularly the case when
creating threads in the control environment. Each thread has its own
copy of `RuntimeDeviceTracker`, so when you spawn a thread you probably
want to copy the state of the tracker from the calling thread.
This method is a remenant of when `ArrayHandle` could only store data on
one device at a time. It is now capable of storing data on any number of
devices (as well as the host), so asking for "the" device no longer
makes sense. Thus, this method is deprecated in favor of
`ArrayHandle::IsOnDevice`.
This deprecation leads to fixing some older functionality that still
assumed data could only be on one device at a time.
Fixes#592.
There were several places in the code that had to check the type of an
`UnknownArrayHandle` and conditionally get or copy that array. This code
is simplified by using `ArrayCopyShallowIfPossible`.
Often times you have an array of an unknown type (likely from a data set),
and you need it to be of a particular type (or can make a reasonable but
uncertain assumption about it being a particular type). You really just
want a shallow copy (a reference in a concrete `ArrayHandle`) if that is
possible.
`ArrayCopyShallowIfPossible` pulls an array of a specific type from an
`UnknownArrayHandle`. If the type is compatible, it will perform a shallow
copy. If it is not possible, a deep copy is performed to get it to the
correct type.
Fixes#572.
ca86402f9 Provide additional debug info in case contour tree hangs
48d91b99f Throw exception if merge tree gets stuck in a loop
c7ea03ee2 Throw exception if contour tree gets stuck in a loop
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2420
If the camera is not a 3D camera, then it might be the case that the
calling code has not set the bounds in the Z direction. Allow this to
happen as long as you are not using a 3D camera.
The divide by zero happened when mapping a surface to a depth buffer.
Some rays terminated at the origin, which is a singularity in the
project matrix.
This might be indicative of a larger problem. Rays really shouldn't
terminate before the near plane.
There were apparently some fields copy/pasted from the 3D version were
not used in the 2D version (probably because they had no meaning). In
one case, one was erroneously normalized, and could cause a floating
point exception.
When computing the cost for splitting, if a regions was empty you would
get a floating point error when multiplying the (invalid) region bound
(inf or -inf) with the number of points (0). It would then check for NaN
costs and reset that. This worked but caused a floating point exception,
which is problematic for some users.
Instead, check for empty regions before computing the cost and reset the
cost that way.
Singular matrices cannot be LUP factorized, so this condition is
detected and returned in a `valid` flag. However, when the detection
happened, the rest of the computation continued to happen. This could
lead to floating point exceptions, which some applications do not like.
So, when an invalid array is detected, return immediately.
Some functions are supposed to behave correctly when given a NaN. This
might only be valid if floation point exceptions are not trapped, so
disable trapping for these tests.
Some simulations trap floating point exceptions to ensure that their
code is working correctly, and we want VTK-m to work correctly in their
code. To check this, we want to turn on floating point exception
trapping in our test code. This is very implementation-specific, so for
now we are just turning it on for GCC. This will at least alert a
problem on some of the dashboards.
1. Use cudaPerThreadStream instead of the default streams
2. Since there have been changes to ArrayHandle code, the API to create
ArrayHandle from a device pointer has changed.
8d7cf2c85 Support all Allocate flags in UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2522
f878ba8da Move the check for 0 inputs. With mpi, 0 input is ok for a rank.
4b2dbfbad Remove unused header.
b08082472 Clean up the code a bit.
c4341adfe update cmakelists.txt. The merge somehow missed this..
90bed8d0c refactor particle adv-based filters and make a temporal particle adv filter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2515
`UnknownArrayHandle` supported an `Allocate` method to change
the size of the underlying array without knowing its type.
However, it did not give all the features of `ArrayHandle`'s
allocate. Namely, you could not specify that the data should
be preserved and you could not provide a `Token` object. This
change adds these (optional) parameters.
TBB 2020 introduced a new class called `task_group`. TBB 2021 removed
the old class `task` as its functionality was replaced by `task_group`.
Our parallel radix sort for TBB was implemented using `task`s, so change
it to use `task_group` (which actually cleans up the code a bit).
The code in `vtkm/cont/Testing.h` now requires a library, which is not
built if testing is not built. Thus, the benchmarking code was giving a
compile error if benchmarking was on but testing was off.
Change the benchmarking to not rely on anything in the Testing
framework. This means using classes in `vtkm/source` instead of
`MakeTestData`. Also avoid using the `TestValue` defined for the tests.
(In one case, we have a simple replacement.) Also had to fix a problem
with a header file not defining everything it needed to compile.
Years ago we discovered a problem with TBB's parallel sort, which we
patch in our local repo and submitted a change to TBB, which has been
accepted.
The code to decide whether to use our parallel_sort patch does not work
with the latest versions of TBB because it requires including a header
that changed names to get the TBB version.
We no longer support any TBB version with this bug, so just remove the
patch from VTK-m.
57f516811 Support reading Global and Pedigree ids
a01e4335d Support reading new format cells
d7b2fec44 Fix reading of string arrays
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2490
The list defining the common storage types was defined in
DefaultTypes.h.in. The problem was that derived default types could not
just add their own type. They had to redefine the whole list.
Instead, move the list to StorageList.h. Also updated
DefaultTypesVTK.h.in to use this list when using XGC. This enables
ArrayHandleSOA for this case.
968c66f94 add TODO to update kokkos initialize
18d7827db update vtkm test arguments
5fa8734bb update vtkm initialize flags to have 'vtkm' prefix and deprecate old flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2456
Deprecate `VirtualObjectHandle` and all other classes that are used to
implement objects with virtual methods in the execution environment.
Additionally, the code is updated so that if the
`VTKm_NO_DEPRECATED_VIRTUAL` flag is set none of the code is compiled at
all. This opens us up to opportunities that do not work with virtual
methods such as backends that do not support virtual methods and dynamic
libraries for CUDA.
Although technically supported, this version of the visual studio likes
to put the warnings where templates are defined (rather than
instantiated). That makes it impossible to suppress a warning when, for
example, when a deprecated class is legitmately used in an std template
to implement other deprecated functionality.
To prevent this, disable deprecations on MSVC compilers before 2019. I
doubt any developers are using this compiler anywhere but the dashboard,
and the warnings should legitimately appear elsewhere.
Virtual methods were used in the `MeshConnectivity` classes for the
internal ray casting system. However, using virtual methods in the
execution environment is being deprecated.
This change replaces the virtual object with an object containing a
`Variant`. The `Variant` holds one of the supported mesh connectivities
and selects the correct one at runtime rather than jumping into a
virtual method.
ff4ad96ef Do not print extra information on Kokkos and CUDA.
321571fab Make sure operator precedence is correct over macro invocation.
94a32bf64 Improve code in response to review.
568c0b5d2 Small formatting changes.
a8e25da0a Add __func__ to unit test metadata printed on failure.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@acm.org>
Merge-request: !2469
The both the underlying `UnknownArrayHandle` and `ArrayHandleVirtual`
handle `ArrayHandleCast` specially. This caused problems when passing an
`ArrayHandleCast` to `VariantArrayHandle::AsVirtual`. Solve the problem
by stripping out the cast storage tags and letting these classes handle
it internally.
It's annoying to have to fix a problem in a method of a deprecated class
that returns another class that is deprecated for a different reason. No
one should really be running this.
`UnknownArrayHandle` treats a `ArrayHandleCast` and
`ArrayHandleMultiplexer` special. When you put one of these arrays in an
`UnknownArrayHandle`, it takes the original array out and stores it. If
you try to take an array of that type out, it will again do the proper
conversion.
The only problem is that if you use `IsType`, the result can be
unexpected. This is what happened with `CastAndCall`, which was using
`IsType` internally. Changed that to `CanConvert` to properly get the
array handle out.
`VaraintArrayHandle` has been replaced by `UnknownArrayHandle` and
`UncertainArrayHandle`. Officially make it deprecated and point users to
the new implementations.
1c9ae402b Deprecate vtkm/BinarySearch.h, it is unused and similar to LowerBound
26d9ecb39 split vtkm/Algorithms.h into UpperBound.h, LowerBound.h, and BinarySearch.h
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@acm.org>
Merge-request: !2455
When the dispatcher does it's "transport" phase, it returns an
"execution object", but this object is held in the control environment
(on the host) although it may point to resources in the execution
environment (on the device). For this object to get from host to device,
it must be trivially copyable. If it is not, compile and/or runtime
errors could occur. So force this condition with a static assert.
Using this internal class is a bit tricky because it requires a pointer
to a C array that is expected to contain portals. Both the C array and
the portals must be defined for the expected device. This is already
handled by the associated Storage. Assuming all of this holds, make sure
the `ArrayPortalRecombineVec` is trivially copyable. This is a
requirement for passing objects to the execution environment.
6921b5cc3 Minor style changes in UnitTestVariant
6ccb32d27 Slight comment changes
647bc94fe Reduce the number of lines required to implement Variant::CastAndCall
991eeba9f Reduce the number of lines required to implement VariantUnion
7607736ef Reduce the number of lines required to implement AllTrivially*
9816c422b Add padding to Grid struct in CellLocatorTwoLevel
e480fd7a2 Support copying a Variant to itself
d2d9ba332 Make connectivity structures trivially copyable
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2444
a683a8802 add support for removing annotations and remove from regression tests
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !2433
There appears to be a bug in CUDA 9.2 where if you have a class that
contains a struct that itself has to have padding in the middle for
alignment purposes and you then put that class in a union with other
classes, it seems like that padding can cause problems with other
objects in the union.
It always worked to trivially copy these classes, but the compiler did
not think so because copy constructors were defined. Change these
constructors to be default so that the compler can properly check
triviality.
For some reason some versions of the CUDA compiler would return true for
`is_trivially_copyable` on a `VariantUnion` even when the types of the
union caused the copy constructor to get deleted.
Solve the problem by using `AllTriviallyCopyable` instead of directly
caling `is_trivially_copyable` on the union.
Nvcc was having troubles resolving the return type of the overloaded
function to get a value out of a `VariantUnion`. Replace the
implementation with a class with specializations. This is more verbose,
but easier on the compiler.
Create a `VaraintUnion` that is an actual C++ `union` to store the data
in a `Variant`.
You may be asking yourself, why not just use an `std::aligned_union`
rather than a real union type? That was our first implementation, but
the problem is that the `std::aligned_union` reference needs to be
recast to the actual type. Typically you would do that with
`reinterpret_cast`. However, doing that leads to undefined behavior. The
C++ compiler assumes that 2 pointers of different types point to
different memory (even if it is clear that they are set to the same
address). That means optimizers can remove code because it "knows" that
data in one type cannot affect data in another type. To safely change
the type of an `std::aligned_union`, you really have to do an
`std::memcpy`. This is problematic for types that cannot be trivially
copied. Another problem is that we found that device compilers do not
optimize the memcpy as well as most CPU compilers. Likely, memcpy is
used much less frequently on GPU devices.
`vtkm::cont::Error` inherits from `std::exception`. As such, it has a
special `what` string that reports an error message in a standard way.
This is particularly useful when a `vtkm::cont::Error` exception remains
uncaught because the system will print the `what` string before
crashing.
Unfortunately, the `what` string was only being set in the `Error`
constructor that took a message. That is a problem for subclasses like
`ErrorCuda` that used the default constructor and then used
`SetMessage`. The `what` string did not get set in this case.
Change the behavior to capture the stack trace in the default
constructor and update the `what` string if a subclass uses
`SetMessage`.
Although it makes sense to assume a pointer is `volatile` when doing an
atomic operation, the arguments to the `atomicCAS` overloads take
regular pointers. The overload resolution can fail if you use the
`volatile` keyword.
