1. 20 Jun, 2019 1 commit
  2. 18 Jun, 2019 1 commit
  3. 21 May, 2019 2 commits
  4. 20 May, 2019 1 commit
  5. 15 May, 2019 1 commit
  6. 01 May, 2019 1 commit
  7. 17 Apr, 2019 1 commit
    • Robert Maynard's avatar
      VTK-m now provides better scheduling parameters controls · 047b6465
      Robert Maynard authored
      VTK-m now offers a more GPU aware set of defaults for kernel scheduling.
      When VTK-m first launches a kernel we do system introspection and determine
      what GPU's are on the machine and than match this information to a preset
      table of values. The implementation is designed in a way that allows for
      VTK-m to offer both specific presets for a given GPU ( V100 ) or for
      an entire generation of cards ( Pascal ).
      
      Currently VTK-m offers preset tables for the following GPU's:
      - Tesla V100
      - Tesla P100
      
      If the hardware doesn't match a specific GPU card we than try to find the
      nearest know hardware generation and use those defaults. Currently we offer
      defaults for
      - Older than Pascal Hardware
      - Pascal Hardware
      - Volta+ Hardware
      
      Some users have workloads that don't align with the defaults provided by
      VTK-m. When that is the cause, it is possible to override the defaults
      by binding a custom function to `vtkm::cont::cuda::InitScheduleParameters`.
      As shown below:
      
      ```cpp
        ScheduleParameters CustomScheduleValues(char const* name,
                                                int major,
                                                int minor,
                                                int multiProcessorCount,
                                                int maxThreadsPerMultiProcessor,
                                                int maxThreadsPerBlock)
        {
      
          ScheduleParameters params  {
              64 * multiProcessorCount,  //1d blocks
              64,                        //1d threads per block
              64 * multiProcessorCount,  //2d blocks
              { 8, 8, 1 },               //2d threads per block
              64 * multiProcessorCount,  //3d blocks
              { 4, 4, 4 } };             //3d threads per block
          return params;
        }
        vtkm::cont::cuda::InitScheduleParameters(&CustomScheduleValues);
      ```
      047b6465
  8. 11 Apr, 2019 2 commits
    • Allison Vacanti's avatar
    • Allison Vacanti's avatar
      Add support for BitFields. · 56cc5c3d
      Allison Vacanti authored
      BitFields are:
      - Stored in memory using a contiguous buffer of bits.
      - Accessible via portals, a la ArrayHandle.
      - Portals operate on individual bits or words.
      - Operations may be atomic for safe use from concurrent kernels.
      
      The new BitFieldToUnorderedSet device algorithm produces an ArrayHandle
      containing the indices of all set bits, in no particular order.
      
      The new AtomicInterface classes provide an abstraction into bitwise
      atomic operations across control and execution environments and are used
      to implement the BitPortals.
      56cc5c3d
  9. 10 Apr, 2019 1 commit
  10. 09 Apr, 2019 1 commit
  11. 03 Apr, 2019 1 commit
  12. 01 Apr, 2019 1 commit
  13. 26 Mar, 2019 3 commits
    • Kenneth Moreland's avatar
      Wrap third party optionparser.h in vtkm/cont/internal/OptionParser.h · 7237c468
      Kenneth Moreland authored
      Previously we just took the optionparser.h file and stuck it right in
      our source code. That was problematic for a variety of reasons.
      
      1. It incorrectly assigned our license to external code.
      2. It made lots of unnecessary changes to the original source (like
      reformatting).
      3. It made it near impossible to track patches we make and updates to
      the original software.
      
      Instead, use the third-party system to track changes to optionparser.h
      in a different repository and then pull that into ours.
      7237c468
    • Kenneth Moreland's avatar
      Allow Initialize to parse only some arguments · b0303c96
      Kenneth Moreland authored
      When a library requires reading some command line arguments through a
      function like Initialize, it is typical that it will parse through
      arguments it supports and then remove those arguments from argc and argv
      so that the remaining arguments can be parsed by the calling program.
      VTK-m's initialize did not do that, so add that functionality.
      b0303c96
    • Robert Maynard's avatar
      Redesign RuntimeDeviceTracker and RuntimeDeviceInformation · 838cb433
      Robert Maynard authored
      The RuntimeDeviceTracker had grown organically to handle multiple
      different roles inside VTK-m. Now that we have device tags
      that can be passed around at runtime, large portions of
      the RuntimeDeviceTracker API aren't needed.
      
      Additionally the RuntimeDeviceTracker had a dependency on knowing
      the names of each device, and this wasn't possible
      as that information was part of its self. Now we have moved that
      information into RuntimeDeviceInformation and have broken
      the recursion.
      838cb433
  14. 25 Mar, 2019 2 commits
  15. 22 Mar, 2019 1 commit
  16. 20 Mar, 2019 3 commits
  17. 05 Mar, 2019 1 commit
  18. 01 Mar, 2019 1 commit
    • Kenneth Moreland's avatar
      Make ArrayHandleVirtual conform with other ArrayHandle structure · 0b32831a
      Kenneth Moreland authored
      Previously, ArrayHandleVirtual was defined as a specialization of
      ArrayHandle with the virtual storage tag. This was because the storage
      object was polymorphic and needed to be handled special. These changes
      moved the existing storage definition to an internal class, and then
      managed the pointer to that implementation class in a Storage object
      that can be managed like any other storage object.
      
      Also moved the implementation of StorageAny into the implementation of
      the internal storage object.
      0b32831a
  19. 26 Feb, 2019 1 commit
  20. 25 Feb, 2019 2 commits
  21. 20 Feb, 2019 1 commit
    • Kenneth Moreland's avatar
      Add specialized operators for ArrayPortalValueReference · 1ca55ac3
      Kenneth Moreland authored
      The ArrayPortalValueReference is supposed to behave just like the value
      it encapsulates and does so by automatically converting to the base type
      when necessary. However, when it is possible to convert that to
      something else, it is possible to get errors about ambiguous overloads.
      To avoid these, add specialized versions of the operators to specify
      which ones should be used.
      
      Also consolidated the CUDA version of an ArrayPortalValueReference to the
      standard one. The two implementations were equivalent and we would like
      changes to apply to both.
      1ca55ac3
  22. 05 Feb, 2019 2 commits
    • Robert Maynard's avatar
      VTK-m now doesn't clobber external DIY installations · ad98d818
      Robert Maynard authored
      Fixes #334
      ad98d818
    • Haocheng LIU's avatar
      Introduce asynchronous and device independent timer · 415252c6
      Haocheng LIU authored
      The timer class now is asynchronous and device independent. it's using an
      similiar API as vtkOpenGLRenderTimer with Start(), Stop(), Reset(), Ready(),
      and GetElapsedTime() function. For convenience and backward compability, Each
      Start() function call will call Reset() internally and each GetElapsedTime()
      function call will call Stop() function if it hasn't been called yet for keeping
      backward compatibility purpose.
      
      Bascially it can be used in two modes:
      
      * Create a Timer without any device info. vtkm::cont::Timer time;
      
        * It would enable timers for all enabled devices on the machine. Users can get a
      specific elapsed time by passing a device id into the GetElapsedtime function.
      If no device is provided, it would pick the maximum of all timer results - the
      logic behind this decision is that if cuda is disabled, openmp, serial and tbb
      roughly give the same results; if cuda is enabled it's safe to return the
      maximum elapsed time since users are more interested in the device execution
      time rather than the kernal launch time. The Ready function can be handy here
      to query the status of the timer.
      
      * Create a Timer with a device id. vtkm::cont::Timer time((vtkm::cont::DeviceAdapterTagCuda()));
      
        * It works as the old timer that times for a specific device id.
      415252c6
  23. 04 Feb, 2019 2 commits
  24. 16 Jan, 2019 1 commit
  25. 14 Jan, 2019 1 commit
  26. 11 Jan, 2019 4 commits
  27. 09 Jan, 2019 1 commit