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`.
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.
`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.
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.
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.
Added a BaseComponentType to VecTraits that recursively finds the base
(non-Vec) type of a Vec. This is useful when dealing with potentially
nested Vec's (e.g. Vec<Vec<T, M>, N>) and you need to keep the structure
but know the base type.
Also added a couple of templates for keeping the structure but changing
the type. These are ReplaceComponentType and ReplaceBaseComponentType.
These allow you to create new Vec's with the same structure as the query
Vec but with differen component types.
Currently, ListTags are implemented by having a subtype name list set to
a brigand::list. However, there is always a chance this will change. To
make things more explicit, create a vtkm::internal::ListTagToBrigandList
to make it clear what the resulting type should be (and provide some
potential future-proofing).
Also add a convenient vtkm::ListTagApply that allows you to easily
instantiate a template with the list of types in a ListTag.
vtkm::internal::Variant is a simplified version of C++17's std::variant
or boost's variant. It is a template that takes a list of types. The
Variant may be set to any one of those types. A CastAndCall allows you
to call a functor with the appropriately cast type.
The VTK-m testing infrastructure isn't public facing so it doesn't
need to be installed or clutter the main VTKmWrappers file.
At the same time I have refactored the code to make it clearer
to understand, and remove unused options.
2e0f4dd37 Fix floating point error in test
b766d9a92 Improve support of testing recursive types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1691
HasVecTraits<T> is a template that will resolve to std::true_type if
VecTraits<T> is properly defined and std::false_type otherwise. This is
helpful when defining classes and methods that use VecTraits but you
still want them to compile if VecTraits does not exist.
As the RuntimeDeviceTracker is a per thread construct we now make
it explicit that you can only get a reference to the per-thread
version and can't copy it.
ff687016e For VTK-m libs all includes of DeviceAdapterTagCuda happen from cuda files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1648
It is very easy to cause ODR violations with DeviceAdapterTagCuda.
If you include that header from a C++ file and a CUDA file inside
the same program we an ODR violation. The reasons is that the C++
versions will say the tag is invalid, and the CUDA will say the
tag is valid.
The solution to this is that any compilation unit that includes
DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled
must be invoked by the cuda compiler.
Fixes#277
DeviceAdapterError existed to make sure that the default device adapter
template was being handled properly. Since the default device adapter doesn't
exist, and nothing is templated over it we can now remove DeviceAdapterError.
`vtkm::cont::testing` now initializes with logging enabled and support
for device being passed on the command line, `vtkm::testing` only
enables logging.
Also
- Renamed vtkm::cont::make_DeviceAdapterIdFromName to just overload
make_DeviceAdapterId.
- Refactored CMake logic for unit tests
- Since we're now querying the device tracker for the names, they
cannot be all caps.
- Updated usages of InitLogging to use Initialize instead.
- Added changelog.
VTK-m has been updated to replace old per device worklet testing executables with a device
dependent shared library so that it's able to accept a device adapter
at runtime.
Meanwhile, it updates the testing infrastructure APIs. vtkm::cont::testing::Run
function would call ForceDevice when needed and if users need the device
adapter info at runtime, RunOnDevice function would pass the adapter into the functor.
Optional Parser is bumped from 1.3 to 1.7.
By making RuntimeDeviceInformation class template independent, vtkm is
able to detect
device info at runtime with a runtime specified deviceId. In the past
it's impossible
because the CRTP pattern does not allow function overloading(compiler
would complain
that DeviceAdapterRuntimeDetector does not have Exists() function
defined).
The VTKM_TEST_ASSERT macro is a very useful tool for performing checks
in tests. However, it is rather annoying to have to always specify a
message for the assert. Often the failure is self evident from the
condition (which is already printed out), and specifying a message is
both repetative and annoying.
Also, it is often equally annoying to print out additional information
in the case of an assertion failure. In that case, you have to either
attach a debugger or add a printf, see the problem, and remove the
printf.
This change solves both of these problems. VTKM_TEST_ASSERT now takes a
condition and a variable number of message arguments. If no message
arguments are given, then a default message (along with the condition)
are output. If multiple message arguments are given, they are appended
together in the result. The messages do not have to be strings. Any
object that can be sent to a stream will be printed correctly. This
allows you to print out the values that caused the issue.
947496550 constexpr construction for Vec classes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1254
Vec class objects can now be constructed during compile-time
as constant expressions by calling Vec( T, ... ) constructors
or through brace-initialization.
Constant expression using fill constructor and nested vectors
of sizes greater than 4 are not supported yet.
Changes made to WrappedOperators.h for resolving overload
ambiguities in Vec construction and typecasting.
Appropriate test cases were added to UnitTestTypes.cxx.
Addresses issue #199.
This commit adds several geometric constructs to vtk-m
in the `vtkm/Geometry.h` header. They may be used from
both the execution and control environments.
We also add methods to perform projection and Gram-Schmidt
orthonormalization to `vtkm/VectorAnalysis.h`.
See `docs/changelog/geometry.md` included in this commit
for more information.
Previously, the initilaizer_list of Vec had to be the exact
same number of values as the size of the Vec. Now, we also
accept a single value that is duplicated for all values in
the Vec. That allows you to more easily construct lists
of lists with repeated values.
Add constructors to the `vtkm::Vec` classes that accept
`std::initializer_list`. The main advantage of this addition is that it
makes it much easier to initialize `Vec`s of arbitrary length.
The maybe uninitialized warnings condition logic wasn't correct the
first time, and needed to be extended for gcc4+. This locally has
resolved the problems the first try didn't solve.
These changes now allow VTK-m to compile on CUDA 7.5 by using const arrays,
when compiling with CUDA 8+ support we upgrade to static const arrays, and
lastly when CUDA is disabled we fully elevate to static constexpr.
There was a bug where if you included an empty range into another range,
the range suddenly became infinite. This is because empty ranges have
the max at -infinity and the min at infinity. If you just include the
endpoints independently (which is what include does), then the min gets
-infinity and the max gets infinity. This gets a check to make sure that
empty ranges are ignored.
When using vtkm::dot on narrow types you easily rollover the values.
Instead the result type of vtkm::dot should be wide enough to store the results
(32bits) when this occurs.
Fixes#193
The intel compiler could not generate code in a timely manner ( 12+ hours ) when
asked to produce a cross product of very long lists. By moving to a lazy
evaluation scheme we now have all compilers product a cross product in a
reasonable amount of time ( 2-4 seconds ).
This resolves Issues:
- https://gitlab.kitware.com/vtk/vtk-m/issues/190
- https://gitlab.kitware.com/vtk/vtk/issues/17196
If a global static array is declared with VTKM_EXEC_CONSTANT and the code
is compiled by nvcc (for multibackend code) then the array is only accesible
on the GPU. If for some reason a worklet fails on the cuda backend and it is
re-executed on any of the CPU backends, it will continue to fail.
We couldn't find a simple way to declare the array once and have it available
on both CPU and GPU. The approach we are using here is to declare the arrays
as static inside some "Get" function which is marked as VTKM_EXEC_CONT.
Rather than requiring all the arguments to be placed as member variables to
the functor you can now pass extra arguments that will be added to the functor
call signature.
So for example:
vtkm::ForEach(functor, vtkm::TypeListTagCommon(), double{42.0}, int{42});
will be converted into:
functor(vtkm::Int32, double, int)
functor(vtkm::Int64, double, int)
functor(vtkm::Float32, double, int)
functor(vtkm::Float64, double, int)
...
For std::copy to optimize a copy to memcpy, the valuetype must be both
trivially constructable and trivially copyable.
The new copy benchmarks highlighted an issue that std::copy'ing pairs
and vecs were not optimized to memcpy. For a 256 MiB buffer on my
laptop w/ GCC, the serial copy speeds were:
UInt8: 10.10 GiB/s
Vec<UInt8, 2> 3.12 GiB/s
Pair<UInt32, Float32> 6.92 GiB/s
After this patch, the optimization occurs and a bitwise copy occurs:
UInt8: 10.12 GiB/s
Vec<UInt8, 2> 9.66 GiB/s
Pair<UInt32, Float32> 9.88 GiB/s
Check were also added to the Vec and Pair unit tests to ensure that
this classes continue to be trivial.
The ArrayHandleSwizzle test was refactored a bit to eliminate a new
'possibly uninitialized memory' warning introduced with the default
Vec ctors.
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.
1d5a4d47 Update ExternalFaces worklet to use hashes
fc7b90ac Add hash function
b1e6c1e3 Add method for getting a cononical edge id
8e72dc73 Add method for getting a cononical face id
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !900
All types of cell sets should have a consistent interface. This is
tested (and fixed) for explicit and permutation cell sets. However, an
unfixed bug that has been identified is that permutation cell sets only
work for point to cell topologies. All others are not supported
correctly.
- Exception classes cannot be exported due to MSVC's design decisions.
See http://stackoverflow.com/questions/24511376. We must leave these
classes as header only and silence the warnings.
- TransferResource in BufferState.h must remain a header-only class since
there is no vtkm_interop library to compile the class into.
- The VTKDataSetReader hierarchy must similarly remain header-only since
there is no vtkm_io library.
- The OptionParser Action classes are part of a header-only utility and
cannot be easily compiled into a library.
-
2e05c1dd Support derivatives of vectors
dd45b568 Vec of Vec fixes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !630
Fix a couple of places where having a Vec of a Vec (for example
vtkm::Vec<vtkm::Vec<vtkm::Float32, 3>, 3>) did not work as it should.
One major place was in the test_equal function used in the testing
framework. If given a Vec of Vec, it would try to convert the Vec to
Float64 and fail. Now the comparison decends as many levels as need be.
The second place was in TypeTraits::ZeroInitialization() for all Vec
types. Originally it initialized the Vec using the default constructor
of the component type. This works fine when the component type is a
standard type, but if the component type is itself a Vec, then the
default constructor does not actually set any of the sub components.
Solved the issue by using the result of ZeroInitialization for the
component type, which will work for basic types and Vecs and anything
else supported by TypeTraits.
These structs behave much like Vec except that they work on a short C
array given to them rather than having the statically sized short array
defined within.
I expect to use this in the short term to help implement cell face
classes, but there are probably many other uses.
I noticed the UnitTestTransform3D test failed using the random seed
1480544620. On closer inspection, I found that the issue was with the
comparison of two numbers close to 0. The numbers were just above the
threshold, but their difference was not quite enough to make the ratio
below the threshold.
After reviewing some other floating point comparisons, they seem to be
more forgiving of numbers close to 0. Thus, I changed this comparison to
pass if the difference between the numbers was below the threshold.
Because this makes the comparison a lot more forgiving for small
numbers, I lowered the default threshold by an order of magnitude. So
far it looks like the tests are passing, but we should look out for
occasional failures.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
When the intel compiler has vectorization enabled ( -O2/-O3 ) it converts the
`adjacent/hypotenuse` divide operation into reciprocal (rcpps) and
multiply (mulps) operations. This causes a change in the expected result that
is larger than the default tolerance of test_equal. So to resolve the problem
we increase the tolerance for acos when using icc.
When the intel compiler has vectorization enabled ( -O2/-O3 ) it converts the
`adjacent/hypotenuse` divide operation into reciprocal (rcpps) and
multiply (mulps) operations. This causes a change in the expected result that
is larger than the tolerance of test_equal.
