3868a5b30 Remove the commented out stack code.
e7066ad94 compiler errors.
de7d9cc27 fix compile errors, remove cudastack hacks.
9b9742f43 Merge branch 'no-recurse-bih' of https://gitlab.kitware.com/kmorel/vtk-m into gridEval
ab9d0fad2 Remove warning exceptions for BoundingIntervalHierarchy recursive calls
8127093a2 Add CellLocator to name of BoundingIntervalHierarchy
c008df90c Non-recursive method to find cells in BoundingIntervalHierarchyExec
c463bbec9 Add parent index to BIH tree
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1536
d4e1c1825 Update existing code to use the new functions
7b072b159 Add useful Get functions to Fields and Coordinates
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1578
Query and report number of components at runtime so that it can work with
arrays of types with runtime varying number of components
Eg. ArrayHandleGroupVecVariable.
The timer test would blindly wait for an expected interval each time.
However, in a busy system that might wait more than expected, this extra
wait time can accumulate. Fix the issue by monitoring how much time has
actually elapsed and only wait to the next expected point. Also add a
check to make sure that we have not waited too long (and adjust the
error message to hopefully make it more clear that the system waited
more than expected).
db0f5c31b Add a Transfer object for ArrayHandleVirtual
99cb10b9a Fix warnings about override keyword
0ff83e94b Properly handle conditions when VirtualStorage is null
0571c6335 Add missing allocation methods to ArrayHandleVirtual
68b2e5e65 Add move constructors to ArrayHandle subclasses
0b32831af Make ArrayHandleVirtual conform with other ArrayHandle structure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1557
Previously, UnitTestTimer paused for 1 second each time it wanted to
test that the timer did (or didn't) record the time elapsing. This was
done 3 times per test and tested seperately on (currently) 5 devices.
The accumulated 15 seconds is not a whole lot, but it can add up when
coupled with the well over 300 other tests.
This change moves from the POSIX sleep function (which is limited to
increments of 1 second) to the updated C++ thread/chrono classes. The
amount of time to wait each time is now 0.25 seconds, which should speed
the test up by 4 times. The risk is that the shorter wait times can
throw off the results if the computer being run on is busy. If that is
the case, we can bump up the wait time (perhaps to 0.5 seconds).
Previously, ArrayHandleVirtual was using the default Transfer object.
This was problematic because it would copy/allocate things in the
execution environment independently from the array that it was wrapped
around. This caused several negative effects, particularly for CUDA
devices. First, if the data were already on the device (or the array is
implicit), a second copy of the data would be made. Second, the copy to
the device is likely less efficient. Third (and worst of all), the data
did not always get pulled back to the original array correctly.
This commit also contains instantiations of ArrayHandleVirtual and its
components for the most common types.
If an ArrayHandleVirtual is constructed without an underlying concrete
array handle, then the Storage<T, StorageTagVirtual> holds a
StorageVirtual pointer that is null. Generally, a null
ArrayHandleVirtual cannot do much, but its operations should still be
correct. There were a few places where the Storage would blindly try to
use its StorageVirtual pointer without checking it first. This adds some
conditions that should correct the behavior when StorageVirtual is null.
There is a test to ensure that basic VTK-m classes have proper move
constructors that do not throw exceptions. Some of these are subclasses
of ArrayHandle. Add these move constructors to the
VTK_M_ARRAY_HANDLE_SUBCLASS macros so they get automatically added.
Previously, ArrayHandleVirtual was defined as a specialization of
ArrayHandle with the virtual storage tag. This was because the storage
object was polymorphic and needed to be handled special. These changes
moved the existing storage definition to an internal class, and then
managed the pointer to that implementation class in a Storage object
that can be managed like any other storage object.
Also moved the implementation of StorageAny into the implementation of
the internal storage object.
6797c6e33 Specify return type for GetTimerImpl
25f3432b1 Increase the conditions on which Timer is tested
4d9ce2488 Synchronize CUDA timer when stopping it
85265a9c8 Add const correctness to Timer
465508993 Allow resetting Timer with a new device
dd4a93952 Enable initializing Timer with a DeviceAdapterId
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Haocheng LIU <haocheng.liu@kitware.com>
Merge-request: !1562
The internal function GetTimerImpl has a rather complex expression for
its return type. Prevously this was derived using declspec, but one of
the versions of Visual Studio barfed on that for some reason. So now
declare the return type explicitly.
UnitTestTimer was changed to be initialized across all possible devices
and getting times across all possible devices. Also test all possible
ways to set the device in the Timer.
Previously, when Stop was called on a Cuda timer, it would record a stop
event but it would not synchronize it at that time. Instead, the
synchronize was only called when GetElapsedTime was called. The problem
is that the time of the event is only marked when synchronize is called.
Thus, if the event completed before GetElapsedTime was called, it would
record the time from when the event acutally happened to the time when
GetElapsedTime was called as part of the elapsed time, which is
incorrect.
Fix the problem by synchronizing when Stop is called. Although this
makes the Timer more invasive, generally using the Timer can cause
synchronization to happen. This behavior is consistent with the Timer
implementation for other devices.
It should be possible to query a vtkm::cont::Timer without modifying it.
As such, its query functions (such as Stopped and GetElapsedTime) should
be const.
Previously, in order to specify a device with the timer, it had to be
specified in the timer's construction or had to be specified every time
GetElapsedTime was called. The first method was inconvienient in the
case where there are multiple code paths to define the device and the
latter method was inconvienient because you would have to pass around a
device id.
Both these techniques still exist, but we have also added a new form of
Reset that allows you to change the device the timer is used on.
Previously, a vtkm::cont::Timer had to be initialized with either no
device or with a device adapter tag. However, this precluded
initializing the timer with a DeviceAdapterId, which made it difficult
to create a timer at runtime. Instead, just accept a DeviceAdapterId
(which all device adapter tags inherit from) and do runtime checks.
In certain circumstances (currently, when logging is enabled), VTK-m
libraries depend on the threading library. However, when the VTK-m
package was included from an external project, it did not automatically
find the threads package. This change makes the Threads library loaded
when the VTK-m package is found.
VTK-m has been updated to replace old per device benchmark executables with a device
dependent shared library so that it's able to accept a device adapter at runtime through
the "--device=" argument.
The ArrayPortalValueReference is supposed to behave just like the value
it encapsulates and does so by automatically converting to the base type
when necessary. However, when it is possible to convert that to
something else, it is possible to get errors about ambiguous overloads.
To avoid these, add specialized versions of the operators to specify
which ones should be used.
Also consolidated the CUDA version of an ArrayPortalValueReference to the
standard one. The two implementations were equivalent and we would like
changes to apply to both.
The timer class now is asynchronous and device independent. it's using an
similiar API as vtkOpenGLRenderTimer with Start(), Stop(), Reset(), Ready(),
and GetElapsedTime() function. For convenience and backward compability, Each
Start() function call will call Reset() internally and each GetElapsedTime()
function call will call Stop() function if it hasn't been called yet for keeping
backward compatibility purpose.
Bascially it can be used in two modes:
* Create a Timer without any device info. vtkm::cont::Timer time;
* It would enable timers for all enabled devices on the machine. Users can get a
specific elapsed time by passing a device id into the GetElapsedtime function.
If no device is provided, it would pick the maximum of all timer results - the
logic behind this decision is that if cuda is disabled, openmp, serial and tbb
roughly give the same results; if cuda is enabled it's safe to return the
maximum elapsed time since users are more interested in the device execution
time rather than the kernal launch time. The Ready function can be handy here
to query the status of the timer.
* Create a Timer with a device id. vtkm::cont::Timer time((vtkm::cont::DeviceAdapterTagCuda()));
* It works as the old timer that times for a specific device id.
The kernel launch component of the runtime device adapter is fairly
pointless. If the hardware supports CUDA we should expect that
VTK-m has the correct kernel versions.
Plus in the original version if the CUDA device was being used
and the kernel launch returns cudaErrorDevicesUnavailable it
was never possible to restore CUDA support. Now what happens
is that the runtime tracker is marked as failed, but the
calling code can always go back and trying the device again.
This is only set while compiling device code, and is useful
for code that needs different implementations on devices (e.g.
they call CUDA device intrinsics, etc).
`vtkm::cont::testing` now initializes with logging enabled and support
for device being passed on the command line, `vtkm::testing` only
enables logging.
When you call VariantArrayHandle::CastAndCall, it now tries both basic
storage and virtual storage. You can modify the types of storages tried
by giving a type list of storage tags as the first argument.
The purpose of the TestBuild infrastructure was to confirm that
VTK-m didn't have any lexical issues when it was a pure header
only project. As we now move to have more compiled components
the need for this form of testing is mitigated. Combined
with the issue of TestBuilds causing MSVC issues, we should
just remove this infrastructure.
The script fixed up most of the issues. However, there were some
instances that the script was not able to pick up on. There were
also some instances that still needed a means to select types.
We want to make sure that VariantArrayHandleContainer has as little
overhead when launch worklets as possible. To do so we cache
type information to make deducing the `T` type of ArrayHandles
as fast as possible.
543255c37 Move the HumanSize function to Logging.cxx as it is only used by the logger
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1508
Previously you had to exactly match the case of a device adapter's name to
construct it, which was a source of lots of problems ( OpenMP versus OPENMP, CUDA or Cuda ).
Now `vtkm::cont::make_DeviceAdapterId` and `vtkm::cont::RuntimeDeviceTracker` support
case-insensitive device construction.
The DeepCopy method is used when a ScopedGlobalRuntimeDeviceTracker
is constructed. This in turn causes the rebuilding of the device
names and states which isn't a free operation. Now we copy the already
computed information.
This was noticeable when using ArrayHandleTransform since it uses
ScopedGlobalRuntimeDeviceTracker when construction host side
portals.
Previously these two functions would give compile errors when asked to
compare against an Array with a different value type. This makes it easier
to write generic code that compares virtual handles.
ArrayHandleVirtual can automatically be constructed from any ArrayHandle.
In the cases where the input ArrayHandle doesn't derived from ArrayHandleVirtual,
it will automatically construct StorageAny to hold the array.
