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.
Also made the TextAnnotation classes conform better to VTK-m coding
style. Specifically, changed the order of words in subclass names (e.g.
TextAnnotationBillboard instead of BillboardTextAnnotation) and broke
out each subclass into its own header/source files.
There were many tests that created code paths for every base and Vec
type that VTK-m supports (up to 4 components). Although this is
admirable, it is also excessive, and our compile times for the tests are
very long.
To shorten compile times, remove the TryAllTypes method. Replace it with
a version of TryTypes that uses a default list of "exemplar" set of
integers, floats, and Vecs.
There are various reasons why you might want to execute something but
not have a specific device to execute on. To mange this, add a general
function that will try a list of devices in order and attempt to run on
them in order.
It is more common to use degrees when specifying a transform (thanks to
the classic OpenGL interface). Also, camera specifies the field of view in
degrees, which made rotations inconsistent. This change unifies all that.
Affine transformations of homogeneous coordinates using 4x4 matrices are
quite common in visualization. Create a new math header file in the base
vtkm namespace that has common functions for such coordinates.
Much of this implementation was taken from the rendering matrix helpers.
First, be more explicit when we mean a range of values in a field or a
spacial bounds. Use the Range and Bounds structs in Field and
CoordinateSystem to make all of this more clear (and reduce a bit of
code as well).
After the most recent changes, I noticed that the matrix unit test
started failing for some optimized compiles. I'm not sure if it was
these changes or others. What I think happened is that it was a check
for a Matrix operation that should be invalid. It checked the valid flag
without checking the data (which, of course, is invalid). However, I
think the optimizer saw that the data generated was never used so
removed that part of the computation so the invalid flag was never set.
Add a condition that uses the result even though it should never be
called to hopefully force the compiler to compute it.
Fix issues with UnitTestVectorAnalysis for MSVC.
We have been having a problem with one of the MSVC dashboards failing
the UnitTestVectorAnalysis test. The test just dies in the middle with
no indication of what problematic thing was run.
After playing with this for quite a while, I found that it could by
triggered exclusively in the Lerp test. I further found that if I
switched the order of the test and check Lerp the test worked. This is
strange behavior and leads me to believe one of the following is going
on:
1. There is an error such as an invalid memory access happening in
the VTK-m code that is sometimes corrupting the stack.
2. Somewhere there is an expression that has undefined behavior. Usually
it works OK, but some optimization sequence causes it to fail.
3. There is a bug in one of the compiler's optimizations.
It concerns me that I cannot identify exactly where the problem lies.
I've looked very hard at the vtkm::Vec and vtkm::Lerp code to try to find
possible problems, but I have not been able to find anything.
See merge request !399
We have been having a problem with one of the MSVC dashboards failing
the UnitTestVectorAnalysis test. The test just dies in the middle with
no indication of what problematic thing was run.
After playing with this for quite a while, I found that it could by
triggered exclusively in the Lerp test. I further found that if I
switched the order of the test and check Lerp the test worked. This is
strange behavior and leads me to believe one of the following is going
on:
1. There is an error such as an invalid memory access happening in
the VTK-m code that is sometimes corrupting the stack.
2. Somewhere there is an expression that has undefined behavior. Usually
it works OK, but some optimization sequence causes it to fail.
3. There is a bug in one of the compiler's optimizations.
It concerns me that I cannot identify exactly where the problem lies.
I've looked very hard at the vtkm::Vec and vtkm::Lerp code to try to find
possible problems, but I have not been able to find anything.
All the other math functions are in the vtkm package. This one was in
vtkm::exec because it uses a callback method. This can be problematic on
CUDA the the declaration of NewtonsMethod does not match the callback
method. However, we now have a VTKM_SUPPRESS_EXEC_WARNINGS macro that
allows a VTKM_EXEC_CONT_EXPORT function (like NewtonsMethod) to call
either a VTKM_EXEC_EXPORT or VTKM_CONT_EXPORT without a warning.
We have decided that we do not need the concept of an Extent in our data
model. Instead, we simply use dimensions, which can be represented in a
vtkm::Id3.
When vectorization is enabled we start using 'fast' math, and therefore instead
of getting perfect 0.0 values we get values that are extremely close to zero.
There was an error in the test_equal comparison that would return true
when the second value was 0 (or close to 0) and the first value was not.
This was a bug I introduced with commit
b270438fea8a9fe4200322bfe6344ab2075c4d9a. I clearly misinterpreted how a
conditional worked.
This class implicitly stores the point coordinates for a rectilinear
cell (such as a voxel) with just the location of the lower left point
and the spacing in each dimension. In addition to saving space, this
class should allow cell-specific functions to specialize for faster
processing.
