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.
Previously we hinted to the compiler that it should vectorized operations
where the input and output are the same array. This obviously caused problems,
and these hints had to be removed.
In the future we need to first check for aliased arrays, and go from there.
85084f2c ScatterIdentity::GetVisitArray parameters are now named properly
86ecad65 ScatterIdentity::GetOutputToInputMap parameters are now named properly
40896e2b Allocate the scatter arrays to be proper length.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !359
e4237c3a Fix warnings found by the dashboard machines.
179b48e0 Reduce compile time for MarchingCubes by passing less info by Invoke.
8e4a47ef Update IsosurfaceUniformGrid to use the marching cubes filter.
d370155e MarchingCubes filter now generates coordinates when point merging is enabled.
c00fb53b Marching Cubes now generates vertices when merge duplicates is enabled.
f699c986 Renamed the ```Convert``` method to ```ApplyPolicy```
8e72ec8e Switch filter::threshold over to have a lower and upper bounds.
bcee8270 First draft of vtkm::filter design.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !311
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.
Even when running with the serial backend, the compiler might enable SIMD
vectorization when optimizations are turned on. When this occurs, we need
to use properly atomic Add's and CAE's.
When the number of parameters to a worklet hits 6+ like the EdgeGenerate
worklet did, the compile times when some of those parameters are dynamic array
handle is very bad.
For example when building the MarchingCubes filter for VTK integration the
EdgeGenerate worklet would take 800+ seconds to compile, but when we switch
it to have fewer arguments the compile time comes down to ~250sec.
5ddade7a Adding some basic documentation on atomics.
e5c4aa3f Fixing cuda index error
00a7f6c1 Correcting function call
249cce35 Adding type restrictions to serial atomics
43131ee0 Adding comments about CAS
40b6db7e Inserted missing ,
3b46706e Adding compare and swap and removing unsigned atomics
12632de3 Casting Uint64 to long long
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !336
