In the previous guide, this was (mostly) in its own chapter. This may
have been an excessive amount of splitting things up.
There is still a missing section on the interface to the execution
environment (i.e. PrepareFor*). I plan to put that in the execution
objects chapter as this is the most likely place for a user to use them.
4f0db5f2e Added log entry when a cast and call fallback is used
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3242
7d0c1e66c fix bug with ray subsetting using wrong near and far planes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3246
7d0c1e66c fix bug with ray subsetting using wrong near and far planes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3246
This method was deprecated because it was not well explained in the
documentation nor was it used in VTK-m or Ascent. However, it is used in
VTK, and VTK has a bit more documentation on what this feature is
supposed to do. Thus this feature has been un-deprecated so that it will
continue to stick around. Also, additional documentation is provided to
describe the feature, and the testing has been expanded a bit.
Some common VTK-m options such as the device and log level could be
specified on the command line but not through environment variables. It is
not always possible to set VTK-m command line options, so environment
variables are added.
Also added documentation to the user's guide about what options are
available and how to set them.
Several places in VTK-m use the `CastAndCallForTypesWithFallback` method in
`UnknownArrayHandle`. The method works well for catching both common and
corner cases. However, there was no way to know if the efficient direct
method or the (supposedly) less likely fallback of copying data to a float
array was used. VTK-m now adds a log event, registered at the "INFO" level,
whenever data is copied to a fallback float array. This helps developers
monitor the eficiency of their code.
We've been having problems with PerformanceTestBenchContour. In the last
few iteration, the runtime goes way up. We cannot find any reason for
this in the source code. There don't appear to be any particular
problems with memory or tables. The best we can figure is an issue with
the device hardware in the container.
The easy solution should be to break the benchmark into smaller peices
to avoid the problem.
VTK-m development is in a mode where backward compatibility should be
maintained between minor versions of the software. (You may get deprecation
warnings, but things should still work.) To match this behavior, the
generated CMake package now supports finding versions with the same major
release and the same or newer minor release. For example, if an external
program does this
``` cmake
find_package(VTKm 2.1 REQUIRED)
```
then CMake will link to 2.1 (of course) as well as newer minor releases
(e.g., 2.2, 2.3, etc.). It will not, however, match older versions (e.g.,
2.0, 1.9), nor will it match any version after the next major release
(e.g., 3.0).