global memory access cause II become large

[Altera_Forum]

I have memory read and memory write kernel in similar pattern. 

these two kernel have same memory access pattern that is not continuous access. and memory read have II=1, memory write have II = 312. how come read and write to global memory different so large? and what cause memory write have large II. an If I change access pattern to continuous access, read and write II will be 1. why memory read always have II=1,and memory write will require continuous access if I want II=1? and if I add# pragma ivdep before memory write loop, the II will be 1 no matter what access pattern, what is that mean?  memory read: int id=...; float temp[5]; for(...){  # pragma unroll  for(int i=0;i<5;i++){  temp = global[i*id+a];  write_channel_intel(data1_ch,temp);  } }  memory write: int id=...; float temp[5]; for(...){  # pragma unroll  for(int i=0;i<5;i++){  temp = read_channel_intel(data2_ch);  global[i*id+a] = temp; //Compiler failed to schedule this loop with smaller II due to memory dependency:Store Operation  } }

[Altera_Forum]

Based on how you have written your code, it seems to me that the same address in global memory could be overwritten multiples times by different threads; e.g. (id=X, i=0) and (id=0, i=X) will always write to global[a]. Since thread ordering is not guaranteed in NDRange kernels, depending on thread ordering, you will receive a different output. This is the source of the store (write after write) dependency. Whether you use ivdep or not, here, the output will still be unpredictable. To be honest, your code looks incorrect to me and will result in unpredictable output regardless of the hardware you use (CPU, GPU, FPGA, etc.), unless "a" is an id-dependent offset that ensures the same address in the global buffer is never overwritten. If the latter is indeed the case, you can safely use ivdep to avoid the false dependency. 

 Needless to say, this type of dependency does not apply to reading.

[Altera_Forum]

id and a represent row and col. 

but why reading won't suffer from this type of dependency?

[Altera_Forum]

--- Quote Start ---  id and a represent row and col. but why reading won't suffer from this type of dependency?  --- Quote End ---    Because there is no such thing as a read after read dependency. All types of true and false dependencies involve writing (read after write, right after read, write after write).