CUDPP memory leaking

Hi All,

I am just starting with gvdb and run into a problem with running samples compiled from sources. The last terminal output from any such compiled sample is:

Starting GVDB Voxels. ver 1.11
Creating Allocator…
Creating Scene…
Creating CUDPP…

then the allocated memory is growing until the program finally crashes.

The same is for debug and release configurations.

Precompiled samples shipped with gvdb do run correctly (almost all… gFluidSurcafe, which is the most interesting to me, is crashing with a message “FLUID SYSTEM, CUDA ERROR: Launch status: an illegal memory access was encountered”).

I am using CUDA 9.2.88 for Win 10, Visual Studio 2017 15.7.4, CMake 3.11.4.
CUDPP and GVDB compiled with no errors, targeting Win64.

Any advice warmly appreciated…
Newbie

has there been any update to the problem above?

I did not manage to progress on this. Instead dived into OptiX, with more success. But will need issues with gvdb/cudpp addressed at some point…

We currently had to deal with the same problem.
The culprits were the __shfl functions within cudpp. Beginning with CUDA 9.0 those were deprecated.

Option A: use compute capability less than 6.0

Option B: replace all __shfl function of cudpp with its correspoinding sync version
__shfl --> ___shfl_sync as stated here https://devblogs.nvidia.com/using-cuda-warp-level-primitives . We always used the FULL_MASK, because after a brief inspection of the code there should be no deadlock between the warps.

There remains inline Assempler PTX code from the included moderngpu files, which uses __shfl functions. Those did not cause any problems yet.

We have a working setup with cudpp and gvdb on a Win10 PC

CUDA 10.0, Win64, Visual Studio 2017, CMake 3.14.3

Many thanks for solution “B”. Except, for some who don’t know, ALL __shfl functions should be replaced to corresponding _sync versions (that is __shfl_up as well).

“Create cuDPP” works extremely quickly now!