32b / 64b question - CUdeviceptr size

In my cuda.h I see CUdeviceptr is typedef’d to an unsigned int, but if I have a kernel write sizeof(void *) out [not in device emulation] it returns 8. How do I get the correct size?

thanks in advance,

Nicholas

btw, my uname is

uname -a

Linux oliver 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux

My understanding is that GPU code uses the same pointer sizes as CPU code, to ensure compatibility. That is, if you are trying to create a binary-compatible structure on the CPU, use “something *”, rather than CUdeviceptr. CUdeviceptr currently seems to be restricted to 32 bits, which matches up with current hardware limits, but I expect this limitation to go away soon. In any case, CUdeviceptr should not be assumed to be layout-compatible with pointers on the device.

HTH & please correct me if I’m wrong,

Andreas

Thanks. Any nVidia employees – please verify this. It seems interesting that there isn’t another layer of abstraction for int’s; are GPUs unlikely to be used with big-endian CPUs?

regards,
Nicholas

If they had an intention to do this, I guess they could’ve added switchable endianness to the hardware. Who knows. :)

“Machine C types are the same as GPU C types” is good enough for me.

Andreas

If you look at the PTX output by nvcc, you will see a comment that says:

    //  Target:ptx, ISA:compute_10, Endian:little, Pointer Size:64

So the compiler author is at least paying attention to this attribute, although it’s not clear what would happen if they wanted to add a big-endian target. (If the next-generation of game consoles are still using PPC cores, there might be a market for big-endian support in CUDA.)

Since there’s a 256 byte limit on the size of kernels’ parameter lists, does compiling on a 64-bit platform reduce the amount of pointers we can pass to a kernel?