1. 12 Apr, 2018 1 commit
  2. 10 Apr, 2018 3 commits
  3. 09 Apr, 2018 13 commits
  4. 06 Apr, 2018 1 commit
  5. 05 Apr, 2018 14 commits
  6. 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
  7. 03 Apr, 2018 3 commits