1. 22 Apr, 2019 1 commit
    • Robert Maynard's avatar
      For VTK-m libs all includes of DeviceAdapterTagCuda happen from cuda files · ff687016
      Robert Maynard authored
      It is very easy to cause ODR violations with DeviceAdapterTagCuda.
      If you include that header from a C++ file and a CUDA file inside
      the same program we an ODR violation. The reasons is that the C++
      versions will say the tag is invalid, and the CUDA will say the
      tag is valid.
      
      The solution to this is that any compilation unit that includes
      DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled
      must be invoked by the cuda compiler.
      ff687016
  2. 17 Apr, 2019 1 commit
  3. 09 Apr, 2019 1 commit
  4. 03 Apr, 2019 1 commit
  5. 29 Jan, 2019 1 commit
  6. 24 Jan, 2019 1 commit
  7. 17 Jan, 2019 1 commit
  8. 16 Jan, 2019 1 commit
    • Robert Maynard's avatar
      Remove VTK-m TestBuild infrastructure · 4ec5bae0
      Robert Maynard authored
      The purpose of the TestBuild infrastructure was to confirm that
      VTK-m didn't have any lexical issues when it was a pure header
      only project. As we now move to have more compiled components
      the need for this form of testing is mitigated. Combined
      with the issue of TestBuilds causing MSVC issues, we should
      just remove this infrastructure.
      4ec5bae0
  9. 27 Dec, 2018 1 commit
  10. 07 Aug, 2018 1 commit
  11. 02 Aug, 2018 1 commit
    • Haocheng LIU's avatar
      Replace std::random_shuffle with std::shuffle · 1fcbca3e
      Haocheng LIU authored
      std::random_shuffle is deprecated in C++14 because it's using std::rand
      which uses a non uniform distribution and the underlying algorithm is
      unspecified. Using std::shuffle can provide a reliable result in a 64
      bit version.
      1fcbca3e
  12. 05 Jun, 2018 1 commit
  13. 17 May, 2018 1 commit
  14. 16 May, 2018 1 commit
    • Robert Maynard's avatar
      copying cpu memory to pascal managed memory now works consistently. · e0b6e698
      Robert Maynard authored
      When copying small arrays from cpu memory to pascal memory we would
      see subsequent kernels fail as the memory transfer hadn't finished.
      This is a bug as each stream should act like a FIFO queue. So
      for now when encountering this use case we explicitly synchronize
      after the memcpy.
      e0b6e698
  15. 23 Feb, 2018 1 commit
  16. 16 Feb, 2018 1 commit
  17. 30 Jan, 2018 1 commit
    • luz.paz's avatar
      Misc. typos · 80b11afa
      luz.paz authored
      Found via `codespell -q 3` via downstream VTK
      80b11afa
  18. 08 Jan, 2018 2 commits
  19. 27 Oct, 2017 3 commits
  20. 09 Oct, 2017 1 commit
  21. 02 Oct, 2017 1 commit
  22. 20 Sep, 2017 2 commits
  23. 24 Aug, 2017 1 commit
  24. 17 Aug, 2017 1 commit
  25. 15 Aug, 2017 1 commit
    • Robert Maynard's avatar
      Refactor vtkm::interop::TransferToOpenGL for implicit ArrayHandles. · a185cd29
      Robert Maynard authored
      Previously TransferToOpenGL would rely on every array handle implementing
      the CopyInto method for transferring to work properly. This was problematic
      as most Implicit arrays don't implement CopyInto.
      
      Now we use the Devices built in Copy infrastructure to facilitate moving
      data from an implicit array to concrete memory which we can be passed
      to OpenGL. As an additional optimization, the temporary memory for this
      interop is cached in the bufferstate.
      a185cd29
  26. 14 Aug, 2017 1 commit
  27. 26 May, 2017 1 commit
  28. 25 May, 2017 1 commit
  29. 18 May, 2017 1 commit
  30. 04 May, 2017 1 commit
  31. 13 Apr, 2017 1 commit
    • David C. Lonie's avatar
      Silence warnings about unavoidable weak vtables. · 4807b3c4
      David C. Lonie authored
      - Exception classes cannot be exported due to MSVC's design decisions.
        See http://stackoverflow.com/questions/24511376. We must leave these
        classes as header only and silence the warnings.
      - TransferResource in BufferState.h must remain a header-only class since
        there is no vtkm_interop library to compile the class into.
      - The VTKDataSetReader hierarchy must similarly remain header-only since
        there is no vtkm_io library.
      - The OptionParser Action classes are part of a header-only utility and
        cannot be easily compiled into a library.
      -
      4807b3c4
  32. 24 Feb, 2017 1 commit
  33. 23 Feb, 2017 1 commit
  34. 07 Feb, 2017 1 commit
    • David C. Lonie's avatar
      Simplify exception hierarchy. · f601e38b
      David C. Lonie authored
      Remove the ErrorControl class such that all subclasses now inherit from
      error. Renamed all exception classes via s/ErrorControl/Error/.
      
      See issue #57.
      f601e38b
  35. 27 Jan, 2017 1 commit
  36. 16 Nov, 2016 1 commit
    • Kenneth Moreland's avatar
      Remove exports for header-only functions/methods · fdaccc22
      Kenneth Moreland authored
      Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
      EXEC_CONT.) Remove the inline from these macros so that they can be
      applied to everything, including implementations in a library.
      
      Because inline is not declared in these modifies, you have to add the
      keyword to functions and methods where the implementation is not inlined
      in the class.
      fdaccc22