- 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.
