This is a start of moving the VTK-m User's Guide into the VTK-m source.
This is only the start of the process. There are several goals of this
work.
1. Integrate the documentation into the source code better to better
keep the code up to date.
2. Move the documentation over to Sphinx so that it can be posted online
and be more easily linked.
3. Incoporate Doxygen into the guide to keep the documentation
consistent.
4. Build the user guide examples as part of the VTK-m CI to catch
compatibility changes quickly.
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.
Previously, the arithmetic assignment operators (`+=`, `-=`, `*=`, `/=`)
on `VecBaseCommon` only accepted another subclass of `VecBaseCommon`.
Changed the operators to accept any type.
The benefit of this change is that the assignment operator of classes
that inherit from `VecBaseCommon` can now work with `Vec`-like classes
that do not inherit from `VecBaseCommon`. I think the only real downside
is that the template could match other classes that would lead to
invalid comparisons. But such use would lead to a compile error anyway.
The difference is that instead of getting an error that no overloaded
version of the operator is available, you will get an error inside the
code of the operator.
C++ template considers some types different even though they have the
exact same format. For example `int`, `long`, and `long long` all match
different types even though they all represent either signed 32-bit ints
or signed 64-bit ints.
List all these possible types in
`TypeListScalarAll`.
This allows for developers to do things such as the following
as constexpr's:
```cxx
constexpr vtkm::Id2 dims(16,16);
constexpr vtkm::Float64 dx = vtkm::Float64(4.0 * vtkm::Pi()) / vtkm::Float64(dims[0] - 1);
```
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.
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.
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.
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.
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.
When using vtkm::dot on narrow types you easily rollover the values.
Instead the result type of vtkm::dot should be wide enough to store the results
(32bits) when this occurs.
Fixes#193
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.
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.
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.
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.
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.
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.
4de37559 fix a pragma location bug
9048e0ba detect cuda versions and decide if to put a diagnostic inside or outside of a class.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !611
