ARTICLE AD BOX
This is doable, but the only way I know of is imperfect.
bool is_cuda_associated(void const* ptr) { CUmemorytype mem_type; CUresult status = cuPointerGetAttribute( &mem_type, CU_POINTER_ATTRIBUTE_MEMORY_TYPE, reinterpret_cast<CUdeviceptr>(ptr)); switch(status) { case CUDA_SUCCESS: return true; case CUDA_INVALID_VALUE: return false; default: handle_error_somehow(); // e.g. throw an exception } }for CUDA-associated memory, we get their type (host, device, etc.) and the API call is successful; and it fails, i.e. returns an error status, for non-CUDA pointers. But therein lies the problem with this approach - the intentional triggering an error. This shows up as error if you run your app, for example, via compute-sanitizer --tool memcheck.
138k86 gold badges448 silver badges924 bronze badges
4 Comments
@AndrewHenle: 1. No pointer is dereferenced here. The cast is due to the API call taking the address as a number. 2. Nobody is "losing track". This is useful in code that needs to act differently on memory areas depending on their type; especially in the context of libraries. It is also of use when debugging.
2026-01-16T16:27:09.393Z+00:00
@RemyLebeau Because the function specs say "If ptr was not allocated by, mapped by, or registered with a CUcontext which uses unified virtual addressing then CUDA_ERROR_INVALID_VALUE is returned." - they are specified on all pointers, not just cuda ones. The function specs could lie, but that is an interface lie, not an implementation detail.
2026-01-16T17:59:52.503Z+00:00
Explore related questions
See similar questions with these tags.
