Forum Discussion
Can you post a snippet of the report for that specific local memory buffer before and after adding the pragma? Note that if the replication is happening to support "simultaneous work-groups", it won't be possible to reduce the replication factor using the "private_copies()" pragma or any other local memory pragma.
Hi HRZ,
As I mentioned, the report shows before and after 8 copies. The same factor is for the loop of 4 where there is no need to replicate beyond 4. I suspect I have something wrong with the syntax of this attribute. Please note this is new attribute in 20.1 and a similar attribute exists in oneAPI, so you may have not seen it or tried it yet.
- AnilErinch_A_Intel5 years ago
Frequent Contributor
Hi
as you can see from the below link
https://www.intel.com/content/www/us/en/programmable/documentation/mwh1391807965224.html
The private_copies attribute is useful when the scope of a variable (through its declaration or access pattern) is limited to a loop.
So if you can provide a code snippet and report that would help to debug the issue.
Thanks and Regards
Anil
- Dr_FPGA5 years ago
New Contributor
Hi Anil,
Thank you for pointing out the scope of this new attribute. However, our use case is a __local buffer copied into FPGA accelerator block memory in one loop to avoid paying the latency penalty for each of the accesses/copies from global memory. The __local buffer values are used in another loop for computation. This is a very typical use case scenario for FPGAs.
It appears that AOCL offline compiler builds a pipeline with a memory replication factor based on some default parameters assuming multiple workgroups accessing local buffer(s) without knowing apriori how many workgroups will be launched from global_size/local_zise ratio. The user does not have full control over the generated memory replication factor in this very typical use case. This results in wasted local memory resources by several factors. I would suggest extending the scope of the private_copies attribute to the whole kernel on a per __local buffer basis in the next release of the OpenCL compiler to give users full control over __local buffers replication factor.
The current remedy is to increase the reqd_work_group_size or max_work_goup_size which would indirectly change default AOCL compiler computation in favor of a smaller memory replication factors.