1. 19 Jun, 2018 1 commit
  2. 18 Jun, 2018 1 commit
  3. 15 Jun, 2018 1 commit
  4. 14 Jun, 2018 1 commit
    • luz.paz's avatar
      Misc. typos · 940c8918
      luz.paz authored
      Found via `codespell` and `grep`
      more typos
      includes source typo change and a typo that needs further review
      follow-up typos
      Follow-up typos
      Revert a commit
  5. 13 Jun, 2018 1 commit
  6. 12 Jun, 2018 1 commit
  7. 07 Jun, 2018 1 commit
  8. 05 Jun, 2018 2 commits
    • Kenneth Moreland's avatar
      Add ability to "allocate" implicit storage · e62091a6
      Kenneth Moreland authored
      Previously, it was not possible to call Allocate or Shrink on an
      implicit storage. The reason for this is that the implicit storage does
      not represent any real memory and any attempt to modify it is wrong.
      However, there are some rare cases where ArrayHandle will attempt to
      "allocate" the storage even when behaving in a read-only manner. The use
      case this is being created for is when an ArrayHandleImplicit first
      calls ReleaseResources and then calls ReleaseResourcesExecution (or
      anything else that tries to get a control-side portal). In this case,
      the ReleaseResources makes the control side portal invalid and the
      ReleaseResourcesExecution attempts to make it valid again by allocating
      the storage to size 0. This change solves the problem by allowing the
      implicit storage to be "allocated" to something smaller than originally
    • Kitware Robot's avatar
      taotuple 2018-06-05 (ae493658) · 2d7ae33d
      Kitware Robot authored
      Code extracted from:
      at commit ae4936580baf117373e73c23f0f8407d7589e6ff (for/vtk-m).
  9. 01 Jun, 2018 2 commits
  10. 31 May, 2018 2 commits
  11. 30 May, 2018 3 commits
  12. 29 May, 2018 6 commits
  13. 25 May, 2018 1 commit
  14. 23 May, 2018 1 commit
  15. 22 May, 2018 1 commit
  16. 17 May, 2018 1 commit
  17. 16 May, 2018 8 commits
  18. 15 May, 2018 1 commit
    • Robert Maynard's avatar
      Re-implement DeviceAdapterRuntimeDetector to avoid ODR violations. · e28244f3
      Robert Maynard authored
      The previous implementation of DeviceAdapterRuntimeDetector caused
      multiple differing definitions of the same class to exist and
      was causing the runtime device tracker to report CUDA as disabled
      when it actually was enabled.
      The ODR was caused by having a default implementation for
      DeviceAdapterRuntimeDetector and a specific specialization for
      CUDA. If a library had both CUDA and C++ sources it would pick up
      both implementations and would have undefined behavior. In general
      it would think the CUDA backend was disabled.
      To avoid this kind of situation in the future I have reworked VTK-m
      so that each device adapter must implement DeviceAdapterRuntimeDetector
      for that device.
  19. 11 May, 2018 1 commit
  20. 10 May, 2018 2 commits
    • Kenneth Moreland's avatar
      Replace ExecutionObjectFactoryBase with ExecutionObjectBase · 0753131a
      Kenneth Moreland authored
      While making changes to how execution objects work, we had agreed to
      name the base object ExecutionObjectBase instead of its original name of
      ExecutionObjectFactoryBase. Somehow that change did not make it through.
    • Robert Maynard's avatar
      CUDA's RuntimeDeviceTracker and Timer are now built as part of vtkm_cont · 571556d9
      Robert Maynard authored
      This is done to not only reduce the amount of code that users need
      to generate but to reduce the amount of errors when using
      the RuntimeDeviceTracker. If the runtime device tracker is initially
      used in a library by a c++ file it will never properly detect the
      cuda backend. By moving the code into vtkm_cont we can make sure
      this problem doesn't occur.
  21. 08 May, 2018 2 commits