مؤشرات إلى ذاكرة GPU

cudaMalloc hands you a normal C++ pointer variable. It sits in host memory, but the address inside it points into GPU memory. 🔗

A device pointer holds a number that is only valid in the GPU's address space. To the CPU it is just an integer, not real RAM.

Programmers prefix device pointers with d_ and host pointers with h_. The name alone reminds you which side each one belongs to.

Writing *d_data in CPU code is a trap. The host cannot touch GPU memory directly, so this crashes or reads nonsense.

Inside a kernel the same device pointer is perfectly valid. There, d_data[i] reads and writes real GPU memory as you expect.

You hand the device pointer to a kernel as an argument. The GPU then uses that address to find your data.

Keep host and device pointers strictly apart. A host pointer is meaningless on the GPU, and a device pointer is meaningless on the CPU.

To get data between the two, you copy it. cudaMemcpy takes both pointers and moves bytes across the divide for you.

You may offset a device pointer on the host, like d_data + n, to point at a slice. You just must not read through it there.

The compiler will not stop you from confusing the two. Many CUDA bugs are simply a host pointer handed where a device pointer belonged.

Clear naming and a fixed convention save hours. Decide your d_ and h_ scheme early and never break it. 🧹

Let us test where a device pointer can safely be dereferenced.

You learned a device pointer lives in a host variable but addresses GPU memory: usable inside kernels, off-limits to direct host access. 🎉