1. 22 Apr, 2019 2 commits
    • Robert Maynard's avatar
      Remove unneeded diy build include directory · 030b03e4
      Robert Maynard authored
      The diy build configured files are all located by the include
      from the root vtkm include directory, so this include isn't needed
    • 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.
  2. 19 Apr, 2019 1 commit
  3. 18 Apr, 2019 2 commits
  4. 17 Apr, 2019 4 commits
    • Robert Maynard's avatar
      UnitTestBoundingIntervalHierarchy handles systems under load better · 9c292007
      Robert Maynard authored
      The UnitTestBoundingIntervalHierarchy has historically had problems
      when the machine is already under-load when the algorithm is executed.
      By limiting the number of openMP threads the test uses we can
      reduce the amount of CPU time slicing that this test causes.
    • Robert Maynard's avatar
    • Nickolas Davis's avatar
      conslidate the license statement · fbcea82e
      Nickolas Davis authored
    • 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:
        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;
  5. 15 Apr, 2019 1 commit
  6. 12 Apr, 2019 1 commit
  7. 11 Apr, 2019 6 commits
  8. 10 Apr, 2019 6 commits
  9. 09 Apr, 2019 5 commits
  10. 08 Apr, 2019 2 commits
    • Sujin Philip's avatar
      Fix a bug in MakeTestDataset · 2bbf501c
      Sujin Philip authored
      In Make3DExplicitDataSetZoo, only 25 cells are added, but the variable `nCells`
      is set to 27.
    • Sujin Philip's avatar
      ArrayHandleVirtual bugfixes · dae779b9
      Sujin Philip authored
      After the change to `ArrayHandleVirtual` where it became a subclass of
      `vtkm::cont::ArrayHandle`, a few extra changes are required.
      1. Functions with `ArrayHandleVirtual` as parameters will not be callable
      with the superclass `ArrayHandle`. This is fixed by changing the argument
      types to the superclass.
      2. Add Serialization classes specializations for the superclass, as "is-a"
      relation is not considered for class template parameters.
  11. 05 Apr, 2019 2 commits
  12. 04 Apr, 2019 3 commits
  13. 03 Apr, 2019 5 commits