cuPointerGetAttribute data pointer always returns 4 bytes ? CUDA Driver API Memory Management

Hello,

I have little question about:

CUresult CUDAAPI cuPointerGetAttribute(void *data, CUpointer_attribute attribute, CUdeviceptr ptr);

I think *data is “variable data” which means it always returns a 4 byte pointer.

So I am wondering how much data there is in data ? I think 4 bytes always, the documentation doesn’t really say, I guess it could be flexible in the future for perhaps 64 bit pointers.

For now I will assume 4 byte pointers are always returned in data.

So it would be conceptually as if it was written (void &data, …

(^ strangely enough this is not allowed in C/C++ External Image External Image

Bye,
Skybuck.

I now see what the problem is the code is misleading:

Case 1: CUresult CUDAAPI cuPointerGetAttribute(void *data, CUpointer_attribute attribute, CUdeviceptr ptr);

This seems as if it’s a call by reference to a void. However this is not allowed in C.

Therefore the code should have been written as :

Case 2: CUresult CUDAAPI cuPointerGetAttribute(void* data, CUpointer_attribute attribute, CUdeviceptr ptr);

This would be interpreted as: a call by value with data as a void pointer.

What a difference one little space makes eh ?! External Image

in a declaration, void* data == void *data. they are equivalent.

I figured out what the problem was but it creates a new problem, it was with my understanding of what was happening.

void test( void *data )

Can now be called in two ways so I am now unsure how to call this function:

case1: test( p ); // p being a pointer
case2: test( &p ); // p being a pointer

Case 2 would create a “pointer pointer” in data.

so for example:

**data = …; would change p.

So the question is now:

What does cuPointerGetAttribute expect ?

Does it expect me to call case1 or case2 ?

The API documentation says the following:

“Returns in *data”.

Usually “returns” means call by reference. So it could be ment here as well.

However it can also be interpreted as “returns data inside the data structure/memory pointed to by *data”.

For now I shall assume “call by reference” is ment, because a size parameter is missing, though there is an attribute parameter which could still be an indirect way of issueing the size.

Bye,
Skybuck.

This function and the data types which it is supposed to act on is a bit weird… the api is a bit weird… but I can understand it.

A host pointer uses a different pointer type than a cuda pointer.

(host pointer = void * or sometype *)
(cuda pointer = integer or unsigned long)

The documentation for this “unified addressing” function makes it seem as if both can be passed ? Is this indeed the intended case ?

This does create a little problem in practice since the pointers are of different types.

An easy solution would be to introduce two functions which simply point to the same library function, or if need to be be seperate

conceptually:

FunctionForHost( HostPointer )
FunctionForCuda( CudaPointer )

I find this all a bit strange…

The reason could be “type checking” this makes it easy to spot where pointers have been wrongfully mixed.

But now it creates this strange situation for the unified function External Image

There is also something else wrong here, which was my mistake… this is not part of “Memory Management” this is something special “Unified Addressing”.

I guess it has to be treated as something special External Image

I am gonna do just that ! External Image =D Or so… my millage my vary External Image :)