New Contributor
Frequent ContributorVolatile is certainly required to disable the private cache for global memory accesses and force all accesses to actually go to global memory to make sure all updates by each kernel is propagated to others.
I am not sure what you mean by "write-ack LSU". I think Intel's OpenCL compiler also supports "atomic" memory operations which might solve your problem; however, performance will be very poor because that basically serializes memory accesses and stalls the pipeline until the memory operation has finished (maybe this is what you call write-ack LSU?).
New Contributorhere is a reference of write-ack in the best practice guide https://www.intel.com/content/www/us/en/programmable/documentation/mwh1391807516407.html#lsu-modifiers__lsu-modifier-write-ack
Frequent ContributorI see, that has been added in the newer versions of the compiler; didn't exist in the older versions. However, that seems to be something the compiler decides on based on the characteristics of the memory accesses, rather than something the programmer/user can explicitly control. Furthermore, the compiler will never analyze global memory access dependencies between two separate kernels and hence, such LSU will never be created by the compiler for your case. Based on the example in the guide, this LSU is created for cases a write-after-write dependency exists in the code; needless to say, such dependency is a false dependency and any sane compiler will optimize out the first write and only keep the second one. I fail to see why Intel even needed to add support for this LSU type...
What you are looking for is likely the atomic memory read/write I mentioned earlier.
