1. 26 Aug, 2015 1 commit
  2. 25 Aug, 2015 17 commits
  3. 24 Aug, 2015 3 commits
  4. 21 Aug, 2015 4 commits
  5. 19 Aug, 2015 3 commits
  6. 17 Aug, 2015 7 commits
    • Robert Maynard's avatar
      Merge branch 'workaround_thrust18_inc_scan_bug' into 'master' · c49684a2
      Robert Maynard authored
      Workaround thrust 1.8 inclusive scan issue.
      
      Starting in thrust 1.8 the implementation of scan inclusive inside
      thrust became highly optimized by using parallel task groups. This
      new implementation has a bug that only exists when using custom
      binary operators, large size arrays, release mode, and no
      debugger or mem-checker attached.
      
      While I have submitted the issue to thrust, we need to be able
      to work around the existing issue. The solution I have chosen is
      to mark all vtkm::exec::cuda::interal::WrappedBinaryOperators
      as being commutative as far as thrust is concerened. To make
      sure we don't get any unexpected behavior I have also had
      to create WrappedBinaryPredicate so that we don't mark any
      predicate as commutative.
      
      See merge request !129
      c49684a2
    • Robert Maynard's avatar
      Merge branch 'min_boost_ver' into 'master' · 4c529dfa
      Robert Maynard authored
      Min boost ver
      
      See merge request !133
      4c529dfa
    • Robert Maynard's avatar
      Workaround thrust 1.8 inclusive scan issue. · 157d8efe
      Robert Maynard authored
      Starting in thrust 1.8 the implementation of scan inclusive inside
      thrust became highly optimized by using parallel task groups. This
      new implementation has a bug that only exists when using custom
      binary operators, large size arrays, release mode, and no
      debugger or mem-checker attached.
      
      While I have submitted the issue to thrust, we need to be able
      to work around the existing issue. The solution I have chosen is
      to mark all vtkm::exec::cuda::interal::WrappedBinaryOperators
      as being commutative as far as thrust is concerened. To make
      sure we don't get any unexpected behavior I have also had
      to create WrappedBinaryPredicate so that we don't mark any
      predicate as commutative.
      157d8efe
    • Kenneth Moreland's avatar
      Merge branch 'pgi-fixes' into 'master' · 0ae19860
      Kenneth Moreland authored
      PGI fixes
      
      Attempts to resolve PGI warnings and test failures.
      
      See merge request !132
      0ae19860
    • Robert Maynard's avatar
      Update VTK-m to error out nicely when Boost isn't found. · 44412787
      Robert Maynard authored
      Previously VTK-m would error out on failing to find/setup backends, instead
      of clearly stating the issue was finding Boost.
      44412787
    • Robert Maynard's avatar
    • Kenneth Moreland's avatar
      Fix NaN check that was optimized away. · 616c179a
      Kenneth Moreland authored
      The PGI compiler appearently saw the condition (var != var) and optimized
      it to always be false. However, in this particular case var was holding
      a NaN value that we were testing to make sure it does not equal itself.
      Get around the problem by comparing the variable to the result of a
      function call.
      616c179a
  7. 14 Aug, 2015 5 commits
    • Kenneth Moreland's avatar
      Tell boost::iterator_facade that our value object is a reference. · ab2e12ec
      Kenneth Moreland authored
      My version of the PGI compiler was having problems with using
      IteratorFromArrayPortal with STL algorithms. I traced the problem to
      iterator_facade checking to see if the reference type we gave it was
      a real reference (e.g. T&). It is not, iterator_facade downgraded the
      iterator trait to a simple input iterator tag even though I declared
      it with a random access traversal. I don't know what the reference type
      has to do with random access, but in any case the value object is
      designed to behave like a reference in that when you assign to it
      the value gets propagated to the array. To tell boost this is the case,
      I made a specialization of boost::is_reference that declares the
      value type as a reference.
      
      I'm not sure why it failed for me but not elsewhere. It might be that
      this version of the PGI compiler is using "old-style" iterator traits
      whereas other were using newer style that matches better the boost
      iterator traits that iterator_facade is actually using.
      ab2e12ec
    • Kenneth Moreland's avatar
      Replace BOOST_MPL_ASSERT with BOOST_STATIC_ASSERT · e301ba0a
      Kenneth Moreland authored
      BOOST_MPL_ASSERT is causing warnings in the PGI compiler. Apparently,
      when BOOST_MPL_ASSERT succeeds it declares a static object with a unqiue
      name scoped to the file. The problem is that the PGI compiler is pretty
      picky about things being declared without being used, so it was emitting
      useless warnings about successful BOOST_MPL_ASSERTs. However,
      BOOST_STATIC_ASSERT does not seem to have this problem, so for the benefit
      of PGI change the compile-time assert method.
      e301ba0a
    • Kenneth Moreland's avatar
      Fix PGI compiler issues. · 50ac3af9
      Kenneth Moreland authored
      The PGI compiler is fussy about finding declared variables and methods
      that have limited scope and are never used. Thus, it is complaining about
      some internal test classes that are properly implementing the ArrayPortal
      interface even though not all of it is being accessed.
      
      To get around the problem, put them in a non-anonymous namespace with a
      name unlikely to conflict with anything. The compiler will recognize that
      it is possible to access these classes outside the scope of the file and
      shut up about items not being used.
      50ac3af9
    • Kenneth Moreland's avatar
    • Kenneth Moreland's avatar
      Remove TopologyData class. · 6598b296
      Kenneth Moreland authored
      This class was used to store a group of from field data in a topology
      map. However, the fetching has been changed to use a customized class
      for each type of fetch that can be optimized for the fetch type and does
      not require to know the number of items in the fetch at compile time.
      Thus, this class is no longer needed, so it is being removed.
      6598b296