18ba2baf3 Suppress system lib memory leak warnings found by asan
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1550
Due to a bug in pthread, loguru would leak 12 bytes memory from the main
thread when `loguru::init` is in use. Since GCC does not support
blacklist file, the suppression logic is added to
ctest_memcheck_supp_file file.
See details in loguru github issue #59.
d19524016 Refactor View class and fix its memory leak
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1546
Do not check for the copyright statement for files in the third party
directory. These files shouldn't have the VTK-m copyright. Frankly, I
don't understand why this has not been a problem before.
451bff6f1 vtkmdiy: Use the new mangled VTKM_DIY_ defines
7d307b96c Merge branch 'upstream-diy' into diy_conditional_serialization
0adcc4d45 diy 2019-02-08 (72a201e1)
74acc2a7b vtkmdiy: Support only including the serialization headers of diy
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1541
6e6968d97 Fix diy include and Timer construction errors in examples
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1539
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.
9580b1921 Introduces SourceInInstall which verifies that VTK-m install its headers
c501500e1 Install missing headers found by VTKmCheckSourceInInstall
baaa47af4 Reduce verbosity of VTKmCheckCopyright
545a2ce91 VTKmCheckSourceInBuild now shows all missing files in a directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1532
