1. 20 Jun, 2018 1 commit
    • Shreeraj Jadhav's avatar
      constexpr construction for Vec classes · 94749655
      Shreeraj Jadhav authored
      Vec class objects can now be constructed during compile-time
      as constant expressions by calling Vec( T, ... ) constructors
      or through brace-initialization.
      Constant expression using fill constructor and nested vectors
      of sizes greater than 4 are not supported yet.
      Changes made to WrappedOperators.h for resolving overload
      ambiguities in Vec construction and typecasting.
      Appropriate test cases were added to UnitTestTypes.cxx.
      Addresses issue #199.
      94749655
  2. 18 Jun, 2018 1 commit
  3. 05 Jun, 2018 1 commit
  4. 04 Jun, 2018 1 commit
    • Kenneth Moreland's avatar
      Enable Vec construction with intializer_list of single value · 15789443
      Kenneth Moreland authored
      Previously, the initilaizer_list of Vec had to be the exact
      same number of values as the size of the Vec. Now, we also
      accept a single value that is duplicated for all values in
      the Vec. That allows you to more easily construct lists
      of lists with repeated values.
      15789443
  5. 30 May, 2018 1 commit
    • Kenneth Moreland's avatar
      Add support for initializer lists in Vec · ae8d994d
      Kenneth Moreland authored
      Add constructors to the `vtkm::Vec` classes that accept
      `std::initializer_list`. The main advantage of this addition is that it
      makes it much easier to initialize `Vec`s of arbitrary length.
      ae8d994d
  6. 17 May, 2018 1 commit
  7. 02 May, 2018 1 commit
  8. 27 Apr, 2018 1 commit
    • Robert Maynard's avatar
      VTK-m Vec<> constructors are now more conservative. · adcabb03
      Robert Maynard authored
      When you have a Vec<Vec<float,3>> it was possible to incorrectly correct
      it with the contents of a Vec<double,3>. An example of this is:
      
      using Vec3d = vtkm::Vec<double, 3>;
      using Vec3f = vtkm::Vec<float, 3>;
      using Vec3x3f = vtkm::Vec<Vec3f, 3>;
      
      Vec3d x(0.0, 1.0, 2.0);
      Vec3x3f b(x); // becomes [[0,0,0],[1,1,1],[2,2,2]]
      Vec3x3f c(x, x, x); // becomes [[0,1,2],[0,1,2],[0,1,2]]
      Vec3x3f d(Vec3f(0.0f,1.0f,2.0f)) //becomes [[0,0,0],[1,1,1],[2,2,2]]
      
      So the solution we have chosen is to disallow the construction of objects such
      as b. This still allows the free implicit cast to go from double to float.
      
      So while `Vec3x3 b = x is supported by vtk-m, it produces very incorrect results.
      adcabb03
  9. 25 Apr, 2018 1 commit
  10. 10 Mar, 2018 1 commit
  11. 30 Jan, 2018 1 commit
    • luz.paz's avatar
      Misc. typos · 80b11afa
      luz.paz authored
      Found via `codespell -q 3` via downstream VTK
      80b11afa
  12. 17 Jan, 2018 1 commit
  13. 08 Jan, 2018 1 commit
  14. 03 Jan, 2018 1 commit
  15. 18 Oct, 2017 1 commit
    • Allison Vacanti's avatar
      Ensure that Pair and Vec are trivial classes. · 4cd79193
      Allison Vacanti authored
      For std::copy to optimize a copy to memcpy, the valuetype must be both
      trivially constructable and trivially copyable.
      
      The new copy benchmarks highlighted an issue that std::copy'ing pairs
      and vecs were not optimized to memcpy. For a 256 MiB buffer on my
      laptop w/ GCC, the serial copy speeds were:
      
      UInt8:                 10.10 GiB/s
      Vec<UInt8, 2>           3.12 GiB/s
      Pair<UInt32, Float32>   6.92 GiB/s
      
      After this patch, the optimization occurs and a bitwise copy occurs:
      
      UInt8:                 10.12 GiB/s
      Vec<UInt8, 2>           9.66 GiB/s
      Pair<UInt32, Float32>   9.88 GiB/s
      
      Check were also added to the Vec and Pair unit tests to ensure that
      this classes continue to be trivial.
      
      The ArrayHandleSwizzle test was refactored a bit to eliminate a new
      'possibly uninitialized memory' warning introduced with the default
      Vec ctors.
      4cd79193
  16. 20 Sep, 2017 1 commit
    • Kenneth Moreland's avatar
      Update copyright for Sandia · c3a3184d
      Kenneth Moreland authored
      Sandia National Laboratories recently changed management from the
      Sandia Corporation to the National Technology & Engineering Solutions
      of Sandia, LLC (NTESS). The copyright statements need to be updated
      accordingly.
      c3a3184d
  17. 07 Aug, 2017 1 commit
  18. 07 Jul, 2017 2 commits
  19. 25 May, 2017 1 commit
  20. 04 May, 2017 1 commit
  21. 28 Mar, 2017 1 commit
  22. 24 Feb, 2017 1 commit
  23. 16 Jan, 2017 1 commit
  24. 10 Jan, 2017 1 commit
    • Kenneth Moreland's avatar
      Fix warnings about assignment operators not being generated · f23ff9fa
      Kenneth Moreland authored
      For some reason when VTK-m was being compiled as an accelerator in VTK,
      Visual Studio 2013 gave a bunch of warnings about not being able to generate
      assignment operators for many classes. This happened for classes with a
      const ivar that could not be automatically set. (Automatic copy constructors
      are fine on this count.) I'm not sure why these warnings did not happen
      when just compiling VTK-m, nor am I sure why they were generated at all as
      no code actually used the copy constructors.
      
      This commit fixes the problems by adding a private declaration for assignment
      operators that cannot be automatically created. No implementation is
      provided, nor should any be needed.
      f23ff9fa
  25. 03 Jan, 2017 1 commit
    • Robert Maynard's avatar
      Types and Matrix don't emit Wunused-value warnings from __builtin_expect · 270ece24
      Robert Maynard authored
      When using Types or Matrix with the nvcc compiler with Wunused-value
      enabled you would get the following warning:
      (__builtin_expect(!(rowIndex < (this,NUM_ROWS)), 0)) ?
      __assert_rtn(__func__, "vtkm/Matrix.h", 86, "rowIndex < this->NUM_ROWS") :
      ((void)0);
      
      This is solved by changing this->NUM_ROWS to just NUM_ROWS.
      270ece24
  26. 08 Dec, 2016 1 commit
    • Kenneth Moreland's avatar
      Add VTKM_EXEC_CONT to make_VecC · eb7ea792
      Kenneth Moreland authored
      I forgot to add the VTKM_EXEC_CONT modifier to the make_VecC methods,
      and that causes them to fail on CUDA devices.
      
      I wish the compiler would have said something. I was calling one of them
      from a VTKM_EXEC method.
      eb7ea792
  27. 01 Dec, 2016 1 commit
    • Kenneth Moreland's avatar
      Add VecC and VecCConst structs · f53cd748
      Kenneth Moreland authored
      These structs behave much like Vec except that they work on a short C
      array given to them rather than having the statically sized short array
      defined within.
      
      I expect to use this in the short term to help implement cell face
      classes, but there are probably many other uses.
      f53cd748
  28. 16 Nov, 2016 3 commits
  29. 14 Nov, 2016 1 commit
  30. 28 Oct, 2016 2 commits
  31. 31 Aug, 2016 1 commit
  32. 02 Aug, 2016 1 commit
  33. 20 Apr, 2016 1 commit
    • Kenneth Moreland's avatar
      Add POSIX assert wrapper · 2ddad8bc
      Kenneth Moreland authored
      Add in the vtkm namespace an assert macro (technically VTKM_ASSERT) that
      basically replicates the functionality of the POSIX assert macro. This
      form of assert is set to replace the separate control/exection asserts.
      
      It has been decided that an assert that throws an exception instead of
      terminating the program is not all that great of a feature and it causes
      some limitations on how it is used. The next commit will remove the
      other forms of VTK-m assert.
      2ddad8bc
  34. 13 Apr, 2016 1 commit
  35. 22 Feb, 2016 1 commit
  36. 26 Jan, 2016 1 commit
    • Kenneth Moreland's avatar
      Fix MSVC warnings · cadf0e53
      Kenneth Moreland authored
      Fix your typical batch of MSVC warnings including picky type conversions
      and using "unsafe" std functions on pointers for iterators.
      cadf0e53