Add NANOVDB_USE_SYNC_CUDA_MALLOC define to force sync CUDA malloc

[w0utert]

In virtualized environments that slice up the GPU and share it between instances as vGPU's, GPU unified memory is usually disabled out of security considerations. Asynchronous CUDA malloc/free depends on GPU unified memory, so before, it was not possible to deploy and run NanoVDB code in such environments.

This commit adds macros CUDA_MALLOC and CUDA_FREE and replaces all CUDA alloc/free calls with these macros. CUDA_MALLOC and CUDA_FREE expand to asynchronous CUDA malloc & free if the following two conditions are met:

• CUDA version needs to be >= 11.2 as this is the first version that supports cudaMallocAsync/cudaMallocFree
• NANOVDB_USE_SYNC_CUDA_MALLOC needs to undefined

In all other cases, CUDA_MALLOC and CUDA_FREE expand to synchronous cudaMalloc/cudaFree.

Since NanoVDB is distributed as header-only, setting the NANOVDB_USE_SYNC_CUDA_MALLOC flag should be handled by the project's build system itself.

[linux-foundation-easycla[bot]]

• :white_check_mark:login: w0utert / (0f46c21ddb99c309b160a765f52fbc4107a8c012)
• :white_check_mark:login: w0utert / (0f46c21ddb99c309b160a765f52fbc4107a8c012, 4c01b380f9d10b502054ddffabb06ae606be64da)

The committers listed above are authorized under a signed CLA.

@kmuseth that was the first solution I tried, but it didn’t work, because cudaMalloc and cudaFree calls would still be resolved to the CUDA ones and not the redefined ones from the NanoVDB header. Without any modification to our build I still got CUDA ‘not supported’ errors on allocations.

Maybe this can be worked around with some linker directives but that seems brittle and could require possible annoying changes to the build system of projects that include the NanoVDB headers.

[w0utert]

This was on Linux by the way, so it’s interesting it did work on your side, I assume there could be some link differences between our builds. I could double check next week to verify again to be sure and to find out why.

[kmuseth]

@w0utert I think you're right so I changed my implementation by simply placing the definitions of the functions in a namespace (nanovdb). So in the end my solution looks very much like yours, except I define functions vs macros. Let me create a PR that includes this fix plus a ton of other (long overdue) improvements to NanoVDB. I'll point you to the relevant changes so you can validate that it does indeed work for you.

A warning, this new PR introduces new namespaces in NanoVDB so your client code might need to be tweaked. I can of course help.

[w0utert]

@kmuseth sounds good, that’s actually nicer than using macro’s! I will try your PR early next week and report back, but I’m pretty sure it will work.

[w0utert]

@kmuseth I tested the feature/nanovdb_v32.7 branch from your fork and it works on Linux as well, thanks!

[kmuseth]

@w0utert excellent - so are you okay if we close this PR?

[w0utert]

@kmuseth yes, you can close this PR!