This project is mirrored from Pull mirroring updated .
  1. 08 Mar, 2021 1 commit
  2. 03 Mar, 2021 4 commits
    • Kenneth Moreland's avatar
      Do not assume CUDA reduce operator is unary · a7100c84
      Kenneth Moreland authored
      The `Reduce` algorithm is sometimes used to convert an input type to a
      different output type. For example, you can compute the min and max at
      the same time by making the output of the binary functor a pair of the
      input type. However, for this to work with the CUDA algorithm, you have
      to be able to also convert the input type to the output type. This was
      previously done by treating the binary operator as also a unary
      operator. That's fine for custom operators, but if you are using
      something like `thrust::plus`, it has no unary operation. (Why would
      So, detect whether the operator has a unary operation. If it does, use
      it to cast from the input portal to the output type. If it does not,
      just use `static_cast`. Thus, the operator only has to have the unary
      operation if `static_cast` does not work.
    • Kenneth Moreland's avatar
      Fix casting issues in TBB functors · f3a6931f
      Kenneth Moreland authored
    • Kenneth Moreland's avatar
      Add casts to FunctorsGeneral.h · cc5b9a01
      Kenneth Moreland authored
      If you are using the classes in `FunctorsGeneral.h`, you specify both
      the result type and the type of the operands. Presumably you are already
      comfortable with any type conversions. So let them keep.
    • Kenneth Moreland's avatar
      Allow for different types in basic type operators · d9c988b2
      Kenneth Moreland authored
      The basic type operators in `Types.h` (i.e. `vtkm::Add`,
      `vtkm::Subtract`, `vtkm::Multiply` and `vtkm::Divide`) required the same
      type for both arguments. This caused problems when used with `Reduce`
      and the initial value type did not match exactly.
      Use some tricks from `BinaryOperators.h` to be flexible about using
      different types.
  3. 02 Mar, 2021 2 commits
  4. 01 Mar, 2021 3 commits
  5. 27 Feb, 2021 1 commit
  6. 26 Feb, 2021 9 commits
  7. 25 Feb, 2021 4 commits
  8. 24 Feb, 2021 6 commits
  9. 23 Feb, 2021 3 commits
  10. 22 Feb, 2021 7 commits
    • nadavi's avatar
    • Kenneth Moreland's avatar
      Fix CUDA issues · 096e7457
      Kenneth Moreland authored
    • Kenneth Moreland's avatar
      Suppress deprecation warnings in deprecated class · 8c662373
      Kenneth Moreland authored
      The implementation of a deprecated class should not give deprecation
      warnings from its own implementation.
    • Kenneth Moreland's avatar
      Remove use of deprecated ImplicitFunctions with virtual methods · a6725b3a
      Kenneth Moreland authored
      Unfortunately, this introduces a backward-incompatible change with the
      filters that use ImplicitFunctions. Before, they would get an
      ImplicitFunctionHandle. This class is deprecated, and there is no easy
      way to get back the actual type of implicit function stored in it.
    • Kenneth Moreland's avatar
      Add ImplicitFunctionGeneral · 180d11e7
      Kenneth Moreland authored
    • Kenneth Moreland's avatar
      Update ImplicitFunction tests to use non-virtual objects · 5ab9ddb6
      Kenneth Moreland authored
      There is still a test for the deprecated functionality (for now). The
      deprecated test only happens if deprecated virtuals are still compiled,
      and warnings are suppressed for this part of the code.
    • Kenneth Moreland's avatar
      Deprecated virutal methods in ImplicitFunctions · 0cddbef0
      Kenneth Moreland authored
      The `ImplicitFunction` classes are now trivial classes that can be
      passed among host and devices. Because of this, we now need to know the
      type of the `ImplicitFunction` in order to use it.
      The old functionality still exists (when virtual methods are still being
      compiled), but will give deprecation warnings. It is also not possible
      to get a pointer from `ImplicitFunctionHandle` and cast it back to the
      original data type (because the type changed). This is a weird testing
      feature that makes little sense in practice.
      Also unsupported in the deprecated classes is the ability to change
      the object and have those changes reflected in the handle. This is
      unfortunate, but it would have been difficult to implement this
      feature that is going away and only appears to be used in some of
      the tests.