3eec5e86 ICC: disable vectorization as both ivdep and simd generate bad code.
f021e4a5 Make the default for vectorization be none.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !368
removing all references to field order.
This removes all references to Field::order, since it is currently unused. If we decide to re-add it, it will be done in a more flexible and robust way.
See merge request !380
We are disabling the entire vectorization hints for ICC as it generates
both bad code, and dramatically decreases compile time.
The compiler does not check for aliasing or dependencies that might cause
incorrect results after vectorization, and it does not protect against illegal
memory references. #pragma ivdep overrides potential dependencies, but the
compiler still performs a dependency analysis, and will not vectorize if it
finds a proven dependency that would affect results. With #pragma simd, the
compiler does no such analysis, and tries to vectorize regardless.
A default of 'native' has the concern that people using vtk-m might by
default generate non portable binaries or libraries and will become
very hard to track down why this happens. So do enable vectorization we
default to 'none'.
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.
Previously we tried to capture rvalues by const ref, and would get
Undefined Behavior since the rvalue would go out of scope, and than
we would try to use it.
a4148d4e TestingWindow now explain why we need to call the pthread workaround method.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !374
cc489164 Force GCC linker to see that we need pthread to work around nvidia driver bug.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !373
Sometimes the compiler/linker notices that the workaround static function was
never reached and optimizes the function away. To workaround this issue we
explicitly call the function when ESC is pressed.
af7bba06 Refactor liner interpolation to use (1-w)*v0+w*v1
635f8c79 Add a CTestCustom file to to filter out warnings that cant be eliminated
f74c0d3c Remove type conversion related warnings for GCC
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !351
Using v0+w*(v1-v0) can be numerically unstaqble due to floating point
arithmatic errors. Additionaly, the newer form also resolves type
conversion warnings.
c1c43d19 Force GCC linker to see that we need pthread to work around nvidia driver bug.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !365
1. Some Linux distributions default linker implicitly enables the as-needed
linking flag. This means that your shared library or executable will only
link to libraries from which they use symbols. So if you explicitly link to
pthread but don't use any symbols you wont have a 'DT_NEEDED' entry for
pthread.
2. NVidia libGL (driver version 352 ) uses pthread but doesn't have
a DT_NEEDED entry for the library. When you run ldd or readelf on the library
you won't detect any reference to the pthread library. Aside this is odd
since the mesa version does explicitly link to pthread. But if you run the
following command:
"strings /usr/lib/nvidia-352/libGL.so.1 | grep pthread | less"
You will see the following:
{ pthread_create
pthread_self
pthread_equal
pthread_key_crea
...
libpthread.so.0
libpthread.so
pthread_create
}
This is very strong evidence that this library is using pthread.
3. So what does this all mean?
It means that on system that use the linking flag 'as-needed', are using
the nvidia driver, and don't use pthread will generate binaries that crash
on launch. The only way to work around this issue is to do either:
A: Specify 'no-as-needed' to the linker potentially causing over-linking
and a slow down in link time
B: Use a method from pthread, making the linker realize that pthread is
needed.
We went with method B.
f81e8c64 Fix example that was using the old interface to VTKDataSetWriter
6aaf85ba Fix compile error with ofstream.
e863ee99 Change interface of VTKDataSetWriter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !364
Make it match VTKDataSetReader better. It's also a bit easier to use
because you just have to give it a filename rather than open your own file
stream.