Skip to content

GitLab

Switch branch/tag
  1. 12 Apr, 2018 1 commit
  3. 10 Apr, 2018 3 commits
  5. 09 Apr, 2018 13 commits
  7. 06 Apr, 2018 1 commit
  9. 05 Apr, 2018 14 commits
  11. 04 Apr, 2018 5 commits
    • Kenneth Moreland's avatar
      Do not use __assume for icc in gcc compatability mode · 3dd66e85
      Kenneth Moreland authored 
      When using the GNU header files on a system, the icc compiler emulates
the behavior of the gcc compiler on the system. (See https://
software.intel.com/en-us/node/522750) This appears to mean that icc
features that are not available in gcc could get turned off. In
particular, we found that the __assume feature stopped working.

To get around this problem, do not use __assume when compiling with icc
and __GNUC__ is defined. Instead, use the available gcc features.
      3dd66e85
    • Robert Maynard's avatar
      VTK-m ArrayHandle can now take ownership of a user allocated memory location · c1237969
      Robert Maynard authored 
      Previously memory that was allocated outside of VTK-m was impossible to transfer to
VTK-m as we didn't know how to free it. By extending the ArrayHandle constructors
to support a Storage object that is being moved, we can clearly express that
the ArrayHandle now owns memory it didn't allocate.

Here is an example of how this is done:
```cpp
  T* buffer = new T[100];
  auto user_free_function = [](void* ptr) { delete[] static_cast<T*>(ptr); };

  vtkm::cont::internal::Storage<T, vtkm::cont::StorageTagBasic>
      storage(buffer, 100, user_free_function);
  vtkm::cont::ArrayHandle<T> arrayHandle(std::move(storage));
```
      c1237969
    • Robert Maynard's avatar
      VTK-m StorageBasic is now able to give/take ownership of user allocated memory. · 707970f4
      Robert Maynard authored 
      This fixes the three following issues with StorageBasic.

1. Memory that was allocated by VTK-m and Stolen by the user needed the
proper free function called which is generally StorageBasicAllocator::deallocate.
But that was hard for the user to hold onto. So now we provide a function
pointer to the correct free function.

2. Memory that was allocated outside of VTK-m was impossible to transfer to
VTK-m as we didn't know how to free it. This is now resolved by allowing the
user to specify a free function to be called on release.

3. When the CUDA backend allocates memory for an ArrayHandle that has no
control representation, and the location we are running on supports concurrent
managed access we want to specify that cuda managed memory as also the host memory.
This requires that StorageBasic be able to call an arbitrary new delete function
which is chosen at runtime.
      707970f4
    • Robert Maynard's avatar
      vtkm::Lerp now casts integer types to an appropriate scalar type. · 83b360f1
      Robert Maynard authored 
      Previously types such as vtkm::Id or vtkm::U/Int32 would be cast to whatever
the weight type was. This is problematic as they should actually be casted to
a double type as the weight type could be a float and therefore the results
      83b360f1
    • Robert Maynard's avatar
      Correct warnings found after disabling all warning when CUDA is enabled. · 0d45c5cf
      Robert Maynard authored
      0d45c5cf
  13. 03 Apr, 2018 3 commits