extent is properly built.
PPtr returns pitch and xsize as identical numbers [that is, both are in unbits oif bytes]; BUT documentation says that xsize and ysize of cudaPitchedPtr are logical units [pixels in my case] while pitch is the stride – that is number of bytes from the start of one row to the next row.
shouldnt the returned cudaPitchedPtr conform to the documentation? what happens if i modify by:
In description of cudaMalloc3D, it says:
The returned cudaPitchedPtr contains additional fields xsize and ysize, the logical width and height of the allocation, which are equivalent to the width and height extent parameters provided by the programmer during allocation.
The description of cudaExtent::width says:
Width in elements when referring to array memory, in bytes when referring to linear memory
The description of cudaPitchedPtr::xsize says:
Logical width of allocation in elements
It seems the document has some conflicts, would you please file a bug on it? Thanks!
I ran this by the driver team, and received the following explanation:
cudaExtent passed to cudaMalloc3D() has to be specified in bytes, which in turn means that the returned pitched pointer’s ‘xsize’ cannot be specified in elements (since the driver has no idea how big an element is).