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.
If Error.h was loaded before windows.h on windows compilers, then it
happily defined GetMessage and then GetMessageA and GetMessageB. However,
if the load order was reversed, then GetMessage is a macro that changes
it to GetMessageA or GetMessageB and you get an error about the same
method being declared twice.
Get around the problem by not defining GetMessage if it is already
declared as a macro.
These asserts are consolidated into the unified Assert.h. Also made some
minor edits to add asserts where appropriate and a little bit of
reconfiguring as found.
Add in the vtkm namespace an assert macro (technically VTKM_ASSERT) that
basically replicates the functionality of the POSIX assert macro. This
form of assert is set to replace the separate control/exection asserts.
It has been decided that an assert that throws an exception instead of
terminating the program is not all that great of a feature and it causes
some limitations on how it is used. The next commit will remove the
other forms of VTK-m assert.
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
Move NewtonsMethod to the vtkm package
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.
See merge request !398
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.
c24d4395 Change max # of cells associated with a point in a 3-D grid from 6 to 8.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !395
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.
Have make_ArrayHandleCompositeVector consistent with fancy arrays
Previously the make_ArrayHandleCompositeVector template was declared in
such a way that if you passed it a fancy array handle, it would change
the type to a base ArrayHandle with a fancy storage. This was
inconsistent with types generated from ArrayHandleCompositeVectorType
when using the same fancy array handle types. This change makes that
more consistent.
See merge request !396
Previously the make_ArrayHandleCompositeVector template was declared in
such a way that if you passed it a fancy array handle, it would change
the type to a base ArrayHandle with a fancy storage. This was
inconsistent with types generated from ArrayHandleCompositeVectorType
when using the same fancy array handle types. This change makes that
more consistent.
Some minor changes to fancy array handles.
This are just some minor things I ran into while documenting these classes.
One change is just an error in a comment. The other change allows you
to specify the type in make_ArrayHandleCast as a template argument instead
of creating an instance.
See merge request !388
27f23480 Correct more warnings and formatting issues with vtkm::rendering.
4269e007 Only build the rendering example if MESA has been found.
daf419fe Correct unused and casting warnings in Scene.h
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !389
779bd587 Bug: CellAverage output storage type can be different than the input.
c0bd0a67 Add missing new lines and #endif comments to vtkm::filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !387
This are just some minor things I ran into while documenting these classes.
One change is just an error in a comment. The other change allows you
to specify the type in make_ArrayHandleCast as a template argument instead
of creating an instance.
d8175015 Fixed issues with NVCC and anonymous namespace compilation issues.
12ffd536 Suppress false positive warnings from nvcc about host/device.
1edc4650 Add a demo for GTC2016 that covers io/filters/rendering.
7543bfe1 Fixed warning about unused variables in RenderSurface.
e0f496ce Fix warnings about unreachable break statement in ParametricCoordinates.
0c36aef5 Fix warnings about unreachable break statement in CellInterpolate.
ec1e1a3a Fix warnings about unreachable break statement in CellDerivative.
265b778a Fix unused warning in VTKDataSetReaderBase.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !386
76b6179a Add missing copyright headers.
6a2a47d3 Remove order from new entries in MakeTestDataSet
d7c295f4 added rectilinear to test.
a8c7f92d Move mesa package to right place. Also, add in code for rectlinear mesh.
294b73e0 Make the rendering part of the build optional. Add the mesa libs to the link line.
719b715b Support for explicit cell sets.
98837735 Corrected error in projection matrix that was causing mismatches with ray tracing image and depth buffers.
f9c6f9cd cleanup of code.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !383
2d3d157e Properly use the policy to determine the coordiante policy conversions.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: T.J. Corona <tj.corona@kitware.com>
Merge-request: !385
8d5833ef Add a missing switch default to cleanup more warnings.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !384
