As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.
1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.
To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.
Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.
The only reason Keys has a template is so that it can hold a UniqueKeys
array and provide the key for each group. If that is not needed and you
want to implement a library function that takes a keys object, you can
now grab the Keys superclass KeysBase. KeysBase is not templated, so you
can pass it to a standard method in a library.
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.
Previously, we precompiled just about any version of Keys that you could
be expected to use. This caused the time to compile Keys to be
unnecessarily long.
This reduces the compilation to types that are actually likely to be
used as keys. Also removed the less likely to be used build methods.
Also moved the Keys<>::SortType outside to KeysSortType. The problem
with having it inside the Keys class was that there was a different
object created for every instances of Keys.
Now that the dispatcher does its own TryExecute, filters do not need to
do that. This change requires all worklets called by filters to be able
to execute without knowing the device a priori.
This ensures that the order of the values presented to the
WorkletReduceByKey functor is consistent.
After this change, the key array used to build the worklet::Keys object
is no longer modified. The sorted keys can be obtained by using permuting
the input keys with Keys::GetSortedValuesMap().
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
Previously the arguments to the operator of a vtkm::cont::arg::Transport
were the control object, the input domain object, and the output range.
If you wanted to, for example, check the size of an input array to make
sure it matched the input range, you would have to know the meaning of
the input domain object to query its range. This made it hard to create
generic transports, like TransportTagArrayIn, that accept data from
multiple different input domains but need to know the input range.
Previously, the Keys class constructor took an array of keys, made a
copy of it, and sorted the copy. This was to protect the caller in case
it needed the original keys array again. However, this copy takes a
significant chunk of time and it is probably rare in practice to ever
need the original keys array again. So instead just do an in-place sort.
There was a static assert in a templated function that was never
supposed to be used. Some compilers were fine as long as there was no
use of the templated function, but others errored out anyway. Change the
implementation to use the =delete keyword instead.
This won't have as nice of an error message, but you would have to jump
through some hoops to get to this point anyway. If this still does not
work, we could just probably remove the invalid templated function. The
compiler error would get even more obfuscated, but again I don't expect
anyone to actually run into it.