Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
10 Views

Local Memory read/writes fail on Surface Pro 3 i5 GPU

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:

bad.png

The expected output is:

good.png

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

0 Kudos
11 Replies
Highlighted
Employee
10 Views

Hi Sebastian,

Could you please specify the following:

Operating System you are running

The exact designation of the processor, e.g. Intel(R) Core(TM) i5-3427U, as reported in your Control Panel\System and Security\System

Thanks!

0 Kudos
Highlighted
Beginner
10 Views

Hi Robert,

it's a Surface 3 Pro i5 running Windows 8.1 Pro 64bit. The processor is Intel(R) Core(TM) i5-4300 CPU @ 1.90 GHz 2.49 GHz, 8GB Memory installed.

Best,

Sebastian

0 Kudos
Highlighted
Employee
10 Views

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.surface_pro_fail.png

0 Kudos
Highlighted
Beginner
10 Views

That is great news Robert. Thanks for the fast response. It would be great if you could update this post with any information you have from compiler architects. Feel free to contact me if you need additional information.

Best,

Sebastian

0 Kudos
Highlighted
Beginner
10 Views

Hi Robert,

any news about this issue? I'm anxious to hear what compiler architects found out.

Best,

Sebastian

0 Kudos
Highlighted
Employee
10 Views

Hi Sebastian,

Our compiler architect just left on Sabbatical, which I found out yesterday: I am trying to find out who will be the backup for this issue, since this looks pretty serious. No news so far.

0 Kudos
Highlighted
Beginner
10 Views

Hi Robert,

Thanks for the update. I have some news: I was able to reproduce the issue on all Surface Pro (i3, i5, i7). The Surface 3 (non-pro) is NOT affected by this.

Best,

Sebastian

0 Kudos
Highlighted
Beginner
10 Views

Hi Robert,

any news? It has been almost one month since I reported this.

Best,

Sebastian

0 Kudos
Highlighted
Employee
10 Views

Hi Sebastian,

Just returned from a two weeks vacation. Haven't seen any progress on this issue yet. I will try to escalate and get some response from the driver team: 1) included the issue in the top three in report to management; 2) send email with all relevant data to a developer on the driver team. Will keep you posted. Sorry for the delay!

0 Kudos
Highlighted
Employee
10 Views

Hi Sebastian,

Driver team just informed me that the issue is fixed on the driver mainline, which means that the fix should be available with the next driver release, which I expect around the end of August. In the meantime, driver team is looking into a possible workaround for your code using existing driver.

0 Kudos
Highlighted
Employee
10 Views

Just verified on 15.40.18.4380 driver from https://downloadcenter.intel.com/download/25818/Intel-Graphics-Driver-for-Windows-7-8-1-10-15-40- - definitely fixed!

0 Kudos