Marked the old versions of PrepareFor* that do not use tokens as
deprecated and moved all of the code to use the new versions that
require a token. This makes the scope of the execution object more
explicit so that it will be kept while in use and can potentially be
reclaimed afterward.
When a single `ArrayHandle` is given to multiple arguments of a worklet
dispatch, the `PrepareFor*` methods will be called multiple times with
the same token. If one of them is a `PrepareForInPlace` or
`PrepareForOutput`, then the two requests will deadlock. To prevent
this, allow the `PrepareFor*` to happen if the same token was used
previously.
The old version of ExecutionObject (that only takes a device) is still
supported, but you will get a deprecated warning if that is what is
defined.
Supporing this also included sending vtkm::cont::Token through the
vtkm::cont::arg::Transport mechanism, which was a change that propogated
through a lot of code.
Duplicated the new versions of PrepareFor* methods from the basic
ArrayHandle that take a token in addition to the other arguments. The
ArrayHandle attaches itself to the token and will not allow operaitons
that make the returned portal invalid until the token goes out of scope.
Later the old versions will be deprecated.
Added new versions of PrepareFor* methods that take a token in addition
to the other arguments. The ArrayHandle attaches itself to the token and
will not allow operations that make the returned portal invalid until
the token goes out of scope.
Later the old versions will be deprecated.
e68b283e8 Delete commented, unused class variables
4d358e5b2 Remove coordinates from class member variable list
e6647efaf Fix condition to populate coordinate variables
2e2a847f5 Change Lagrangian output format to structured grid
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1945
f7709a8db Mark deprecated superclasses of WorkletMapTopology with VTKM_DEPRECATED
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1955
1f61c500e Remove non-atomic ops from BitField unit test.
5565848d9 Use a dynamic strategy for openmp 1D scheduling.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1925
The nvcc compiler under visual studio seems to give the error `attribute
does not apply to any entity` when you try to use the `[[deprecated]]`
attribute. So disable for this compiler configuration.
b9516c116 Correct CellSetStructured compile failures
00235874d Suppress more warning types from thirdparty includes
a52af2d13 Correct double to float warning in CellAspectFrobeniusMetric
cf5ebfb16 Suppress warning about extension use, since all compilers support it
27739660b Add missing constructors/assignment operators
123f8b01a Mark virtual destructors as override where applicable
54118dfca Use noexcept instead of throw() as it was deprecated in c++11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1943
Having a custom assignment operator means that the compiler
isn't required to generate the implicit copy constructor.
This makes sure they are constructed.
The `std::conditional` utility is very convenient, but it unfortunately
means that the compiler has to evaluate both the true and false types
even though one is guaranteed to be thrown out. This is problematic
because it requires the compiler to do a lot more work then necessary.
It is especially dumb when introducing the conditionals to reduce the
number of cases being evaluated, as was much of the case in List.h.
Eg:
```
vtkm::Float32 -> F32
vtkm::Int64 -> I64
vtkm::Vec< vtkm::Float32, 3 > -> Vec3f_32
vtkm::Vec< vtkm::Pair< vtkm::Int32, vtkm::Float64 > -> Vec<Pair<I32, F64>>
```
This makes the benchmark names a lot shorter to keep rows tabular
results on
a single line.
Also discovered that many C++ compilers have trouble giving warnings
for partial specialization of classes marked as deprecated. Fix
the problem by instead deprecating the items in the class.
These extra operations caused the pointer to go out of bound and
then back in, but some compilers (gcc 9) would detect and warn
that the pointer had gone out of bounds.
When expanding variadic parameter packs in ArrayHandleDecorator
implementations, make sure that the types used are appropriate.
Since std::declval is used to test whether or not a method with
specific arguments exists, it is important that the reference types
are correct to ensure that the detection works as expected.
Portals are always passed to implementation functions as rvalue
references, and array handles are always passed as lvalue refs.
The convenience functions `ArrayPortalToIteratorBegin()` and
`ArrayPortalToIteratorEnd()` wouldn't detect specializations of
`ArrayPortalToIterators<PortalType>` since the specializations aren't
visible when the `Begin`/`End` functions are declared.
Since the CUDA iterators rely on a specialization, the convenience
functions would not compile on CUDA.
Now, instead of specializing `ArrayPortalToIterators` to provide custom
iterators for a particular portal, the portal may advertise custom
iterators by defining `IteratorType`, `GetIteratorBegin()`, and
`GetIteratorEnd()`. `ArrayPortalToIterators` will detect such portals
and automatically switch to using the specialized portals.
This eliminates the need for the specializations to be visible to the
convenience functions and allows them to be usable on CUDA.
bf2290c9e Fixed an implicit conversion change warning.
18caed60e Fixed some of the compiler warning from CDash.
d7d7cdd5b Merges with upstream reformated version.
d6cbd8301 Merge with unformated previous state of the remote branch.
9a6dec8bc Refactored control side function call from a VTKM_EXEC function.
ca5f79056 Swapped x and y dimensions when reading in contour trees from text files.
da83076d7 Merge branch 'master' into peter-changes
01c49f139 Wrote some documentation for the CT Height Branch Decomposition code.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1899
Fixes#447
This uses a more robust set of checks to determine if std::aligned_union
and std::is_trivially_copyable exist given the libstdc++ version value
7b53a52e6 ExtractStructured now compiles quicker and with less compiler memory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Allison Vacanti <allison.vacanti@kitware.com>
Merge-request: !1922
There were issues with the particle advection code where a small number
of work-heavy task invocations were needed. Since we were enforcing a
minimum of 1024 invocations per thread, this effectively serialized
scheduling.
Now the scheduler dynamically adjusts for small thread launches,
allowing finer scheduling.
4659d69c7 Remove some commented out code
aec75ab1a Suppress CUDA warning about device calling host
851864d0b Work around with Visual Studio 2015 issue
452a2e1c9 Suppress warnings about CUDA host/device mismatch
4fdefe9f1 Suppress some deprecated warnings in visual studio
5cfc14482 Implement old ListTag features with new ListTag implementations
d5fe4046c Remove instances of ListTag in favor of List
92db37623 Convert uses of ListTagBase to List
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1918
The destructors of some control side objects (such as CellSet and
ArrayHandle) are defined. These destructors are obviously only compiled
for the control environment (i.e. for CUDA only for the host). However,
not all of the subclasses implemented their own destructors. In CUDA,
when a default destructor is used, it is compiled for both host and
device. This caused a problem as the superclass's destructor was only
compiled for the host and therefore caused a warning.
Fixed the problem by defining an empty destructor to any subclasses that
needed one.
It's weird that I ran into this problem while chaning the List TMP
class, but the solution seems fine.
Was getting the following error:
vtkm/List.h(284): error C2210: 'T' : pack expansions cannot be used as
arguments to non-packed parameters in alias templates
This is probably an issue with the compiler not resolving templated
aliases correctly.
This cleans up the code a bit by removing duplication. More importantly,
it makes sure that the old ListTag functions work with both the new
`List` and old `ListTagBase`.
Previously, the `VTKM_ALWAYS_EXPORT` and `VTKM_NEVER_EXPORT` macros
used the gnu-specific `__attribute__` keyword. This change instead
uses the C++11 standard method of using `[[ ]]` as attributes.
Specifically, `__attribute(visibility("---"))` is changed to
`[[gnu::visibility("--")]]`.
The main impetus for this change is that `__attribute__` does not
seem to work with `[[deprecated]]` on GCC compilers. (For sure on
GCC 6. I didn't check all compiler versions.) This change was
recommended from
https://stackoverflow.com/questions/40886628/deprecated-attribute-visibility-default-in-gcc-6-2
This creates a minor backward incompatibility. We have always meant
for these macros to be used before the return type when used with
a function. However, GCC accepted placing `__attribute__` after
the return type. The C++11 `[[ ]]` cannot be placed there, so
some macros might have to be moved. Still, this was a broken
use that happened to work.
A new header named TypeList.h and the type lists have been redefined in
this new file. All the types have been renamed from `TypeListTag*` to
`TypeList*`. TypeListTag.h has been gutted to provide deprecated
versions of the old type list names.
There were also some other type lists that were changed from using the
old `ListTagBase` to the new `List`.
The newer List operations should still work on the old ListTags, so make
those changes first to ensure that everything still works as expected if
given an old ListTag.
Next step is to deprecate ListTagBase itself and move all the lists to
the new types.
Instead of incrementally building a new Invocation object
for each modified parameter, we construct a single new type
with all the new parameters.
GCC 9.2, Release, Contour Filter:
Master: 1:08.96min, max memory: 1762644 KB
This: 1:04.56min, max memory: 1730376 KB
`vtkm::List` is meant to replace `vtkm::ListTag`. Rather than
subclassing a base class with a variadic template, all lists expose the
list of types.
`vtkm::ListTag` was originally created before we required C++11 so
supporting variadic templates was problematic. To hide the issue we had,
we made list tags subclass other lists rather than be the list
themselves. It makes for nicer types in the compiler, but hides
important details about what is actually in the type. It also creates
lots of unnecessary new types.
The new `vtkm::List` is in some ways simpler. All lists have to be a
`vtkm::List`. Subclasses are not supported (or rather, they will not
work as expected). All manipulations (such as `vtkm::ListAppend`)
resolve directly back to a `vtkm::List`. Although the types reported by
the compiler will be longer, they will be more specific to the types
being used. Also, the new implimentation should ultimately use fewer
types.
Yet more ways that we can reduce the complexity of `FunctionInterface`.
This is another step in figuring out what set of features the replacement
for `FunctionInterface` needs to have.
Using GCC 9.2 the pre change vtkm::filter::Threshold would
take 31.84sec to compile and use 1.1GB of memory. After
these changes the filter takes 24.16sec to compile and
uses 885MB of memory.
CMake 3.16 includes support for unity builds which merge multiple
translation units together automatically for faster builds.
A couple of translation units in VTK-m already require lots of
system memory, and merging them actually decreases compile performance
When it was originally created, it was assumed that the ArrayHandle
class would be used by a single thread. As the use of VTK-m expands,
that is no longer a safe assumption. To ensure that operations on
ArrayHandle happen correctly, add a mutex to the Internals of
ArrayHandle and require all operations on the Internals lock that mutex.
There is some behavior of GCC compilers before GCC 9.0 that is
incompatible with the specification of OpenMP 4.0. The workaround was
using the workaround any time a GCC compiler >= 9.0 was used. The proper
behavior is to only use the workaround when the GCC compiler is being
used and the version of the compiler is less than 9.0.
Also, switch to using VTKM_GCC to check for the GCC compiler instead of
__GNUC__. The problem with using __GNUC__ is that many other compilers
pretend to be GCC by defining this macro, but in cases like compiler
workarounds it is not accurate.
Older GCC compilers were giving warnings in the operator of the
GeneratePoints worklets for tubes because they could not completely
determine that variables were being properly initialized in the first
loop iteration (and therefore initialized for every subsequent
iteration). Fixed that by moving the initialization for the first
iteration outside of the loop.
Previously we relied on CMake's compiler detection module to build the
macros for using the deprecated attribute. However, CMake created macros
for pre-C++14 versions of the feature, which do not work in all cases.
Also, we have the need to be able to suppress deprecation warnings when
we are implementing a deprecated thing. Since we have to query compilers
ourself, we might as well figure out if the deprecated attribute we want
is supported.
Worst case is that we won't support deprecation warnings everywhere we
could. That will not create incorrect code and we can always add that
later.
Previously, Configure.h.in used a pragma to disable warning 4996 is all
VTK-m code and anything that used it. The reason for this was that the
warning was given for any use of std algorithms such as fill_n that the
Visual Studio team deemed unsafe. Although we could fix it in our code,
it was impossible to work around warnings in other headers as the actual
warning comes from a system header file (xutility) that we have very
little control over. At the time we disabled this warning, we were
getting the warning from a bost header file, and the warning was never
to be fixed (https://svn.boost.org/trac/boost/ticket/11426).
Unfortunately, disabling warning 4996 also disables all warnings about
deprecated items. We want to support warnings for things deprecated in
VTK-m itself, so turning off this warning means we cannot correctly
support VTK-m deprecation.
Fortunately, a lot has changed since then. We no longer boost at all, so
the issue there is no longer our problem. We can thus re-enable the
warning (by removing the pragma). We've managed to avoid using these
"unsafe" functions anyway, so we should be able to cleanly build with
this warning on.
The `VTKM_DEPRECATED` macro allows us to remove (and usually replace)
features from VTK-m in minor releases while still following the conventions
of semantic versioning. The idea is that when we want to remove or replace
a feature, we first mark the old feature as deprecated. The old feature
will continue to work, but compilers that support it will start to issue a
warning that the use is deprecated and should stop being used. The
deprecated features should remain viable until at least the next major
version. At the next major version, deprecated features from the previous
version may be removed.
Previously when ApplyPolicyFieldOfType was used in cases where not all
of the types matched not all of the storages, those invalid arrays were
replaced with an ArrayHandleDiscard. This unnecessarily increased the
length of the type names used for the resulting ArrayHandleMultiplexer.
Now, ListTagRemoveIf is used to remove any invalid arrays so that the
resulting ArrayHandleMultiplexer only includes the valid arrays.
Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few
C++11 features they do not support. One of these features is
std::is_trivially_copyable. So on these platforms, do not attempt to use
it. Instead, treat nothing as trivially copyable.
The code from the previous commit was causing one of the dashboards,
which is using gcc-7, to produce the following warning:
In file included from ../testing/UnitTestVariant.cxx:11:0:
../Variant.h: In function 'void {anonymous}::TestCopyDestroy()':
../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized]
this->Storage = std::move(rhs.Storage);
^~~~
At best, this warning is not helpful as it does not seem to point to
anything that could be used uninitialized. At worst, it might be a
compiler bug. A Google search finds a few similar bugs although none I
can assert with any confidence of this issue. However, many reported
bugs and issues point to the use of anonymous namespaces. So, I'm going
to attempt to fix the problem by removing anonymous namespaces.
Hopefully it will fix the warning or at least point me to something
concrete that I can fix.
The Variant template can hold any type. If it is holding a type that is
non-copyable, then it has to make sure that appropriate constructors,
copiers, movers, and destructors are called.
Previously, these were called even the Variant was holding a trivially
copyable class because no harm no foul. If you were holding a trivially
copyable class and did a memcpy, that work work, which should make it
possible to copy between host and device, right?
In theory yes, but in practice no. The problem is that Cuda is
outsmarting the code. It is checking that Variant is not trivially-
copyable by C++ semantics and refusing to push it.
So, change Variant to check to see if all its supported classes are
trivially copyable. If they are, then it use the default constructors,
destructors, movers, and copiers so that C++ recognizes it as trivially
copyable.
79f7f8275 Fix UnitTestError failure
901711bff Fix test failure due to floating point issues
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1896
This file was using the Matrix class but not including Matrix.h. When I
tried to use the MeshQuality filter in an example that did not include
Matrix.h on its own, I got a compile error.
