Hi,
I would like to report a problem I discovered when running clFFT on Surface Pro i5 GPU Driver Version 10.18.14.4222 Driver Date 5/22/2015. After some tedious investigation I think I could boil the problem down to local memory read/write synchronization failures if specific memory access patterns are used.
Tested devices where the problem does not exist (I ran the same kernel on those devices): Surface 3 (non pro) GPU and CPU, MacBookPro 11,3 dedicated Nvidia GPU, Surface Pro i5 CPU. The problem only exists on Surface Pro i5 GPU.
I determined that the local work group collaborates on filling local memory with data. Then the local work group synchronizes using a barrier. Then the local work group collaborates on reading data from local memory in a different pattern than the pattern that was used to write the data. A higher level explanation of this operation is: work items within a local work group interchange intermediate results through shared memory.
I determined that this operation is faulty. The behaviour observed is similar to behaviour one would expect if reads and writes were not separated by a barrier. A small modification of the memory access pattern solved this problem: when adding +1 to each read and write from and to local memory, the kernel behaves correctly and no error is observed. The following table shows the expected output on the left generated by the CPU, on the right the incorrect output is illustrated.
This https://gist.github.com/sschaetz/f37e15ec2f059e13777b contains a reduced reproducer code that fails. It contains the offending kernel in kstr and runs the same kernel on OpenCL platform 0 device 0 and device 1 and compares the output. On Surface Pro 3 i5 this corresponds to GPU and CPU. As is, the code should produce the error. If the first line in the kernel string is commented, and the second line is uncommented, the error should disappear. It requires pyOpenCL to work.
The incorrect output is:
The expected output is:
Based on this I conjecture that either the OpenCL compiler determines the barrier shielding overlapping reads from writes can be omitted or the GPU does not execute the barrier correctly.
Best,
Sebastian
Link Copied
Hi Sebastian,
I was able to reproduce you issue on a newest 5th Generation Intel(R) Processor though a pattern is slightly more regular. I am sending it on to our compiler architects to take a look.
