moving 8GB buffer to Alveo DDR

[benedetto73]

I am trying to move a huge buffer (8GB) to the Alveo DDR.
Even the SW emulation is taking forever, and I can't understand whether it is just taking time or it is hanging.

is it possible to move such a big array in one move?

I am using VItis, C++ kernels btw.

PS:
Transfer of   511*1024*1024 x uint64 words succeeds  (almost 4GB)
Transfer of   512*1024*1024 x uint64 words fails  (exaclty 4GB)
Transfer of   512*1024*1024-1 x uint64 wordssucceeds  (4GB minus 8 bytes)

PSS:
Looking carefully at the cl::Buffer ctor and stepping through it with the debugger... it is clear that the "size" argument is 32bit.
Is that a bug or a feature?

"The OpenCL Specification Version: 1.0 Document Revision: 48" (link) at paragraph 5.2.1 clearly states that "size" parameter is of type size_t (64bit) for clCreateBuffer.

[mcertosi · Accepted solution]

Hi @benedetto73 

Found a note in the documentation stating you cannot create a buffer larger than 4GB. 

https://www.xilinx.com/html_docs/xilinx2019_2/vitis_doc/Chunk560402095.html?hl=clcreatebuffer

Regards,

M

[benedetto73]

Thanks @mcertosi .
This is very unfortunate. 

I would like to recommend the development to adhere to the OpenCL standard which, I believe, supports buffers bigger than 4GB.

Thanks!

[mcertosi]

Hi @benedetto73 

I looked into this some more today. Assuming this is the correct reference 

The then size_t is defined below 

The unsigned integer type of the result of the sizeof operator. This is a 32-bit unsigned integer if CL_DEVICE_ADDRESS_BITS defined in clGetDeviceInfo is 32-bits and is a 64-bit unsigned integer if CL_DEVICE_ADDRESS_BITS is 64-bits.

I do not believe it is a spec violation to limit size_t to 32 bits. 

Regards,

M

[benedetto73]

Sad.

Thanks for the update.