Intel GPU brp app returns incorect results with beignet 1.2 drivers

Paulie
Paulie
Joined: 24 Jun 08
Posts: 11
Credit: 20765556
RAC: 0
Topic 201789

Since Fedora 24 updated openCL (beignet) drivers for intel GPU to 1.2 version, all my intel opencl tasks are not validating. I'm not sure if more people are seeing this issue, I searched the forum but did not find anything. Maybe other distros are just slower in updating the openCL drivers. If this was already solved somewhere please point me to the right thread. Nevertheless I managed to bisect beignet to commit:

27a95c6678e3e6426ad1bc7927d92f1488fe884c is the first bad commit
commit 27a95c6678e3e6426ad1bc7927d92f1488fe884c
Author: Guo Yejun <yejun.guo-[at]-intel.com>
Date:   Mon Feb 29 08:08:06 2016 +0800
    enable FP_CONTRACT on as default, and implemented with MAD

According to docs: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/FP_CONTRACT.html , this allows the implementation to contract expressions. I reported a bug against beignet: https://bugs.freedesktop.org/show_bug.cgi?id=98164 the developers are able to reproduce  the difference in results with FP_CONTRACT on and off, but were unable to isolate the issue.

I was asked in the bug report to try to isolate the issue more, however at the moment I'm unable to do so. I'm actually not even able to compile the latest brp sources. For this testing I'm using the brp4-igpu-test app that I downloaded here in another intel thread some time ago (I can not even find the link right now).

As a workaround it was suggested by the developers to disable FP_CONTRACT directly in the kernel. Would this be reasonable to do globally? It would be nice if some developer could check the bugreport and maybe halp the beignet developers with fixing this. Or maybe just guide me how to prepare a really simple test app to pinpoint the issue down...

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

Paulie wrote:As a workaround

Paulie wrote:
As a workaround it was suggested by the developers to disable FP_CONTRACT directly in the kernel. Would this be reasonable to do globally? It would be nice if some developer could check the bugreport and maybe halp the beignet developers with fixing this. Or maybe just guide me how to prepare a really simple test app to pinpoint the issue down...

I think this thread brp4-intel-gpu-app-feedback may explain why the invalids are occurring, it may not be a bug - but that the validation is over sensitive.

By globally i guess you mean, where do i put the #pragma statement(s)?

#pragma OPENCL FP_CONTRACT off

I'd rather not embarrass myself at this point, as it has been a long time since i C coded for a living.

Good luck with finding it.

 

Paulie
Paulie
Joined: 24 Jun 08
Posts: 11
Credit: 20765556
RAC: 0

Hi Agentb, thanks for the

Hi Agentb,

thanks for the info, however I'm not sure if the problems described in the thread really apply to this. To be fair I did not read the whole thread due to its size, but just from quickly going over it, it seems that the majority of problems was caused by windows drivers. I didn't find any mention of beignet producing invalid results.

Moreover I have been validating quite fine before the driver update. If I did understand properly the cause for intel validation problem described in the brp4-intel-gpu-app-feedback thread, it is caused because mul+add is less precise than fused instruction (rounding 2x vs rounding 1x). However the FP_CONTRACT directive should in fact enable such operations so this doesn't make any sense why this commit would actually break thinks.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

Quote:quote=Paulie]Moreover I

Paulie wrote:

Moreover I have been validating quite fine before the driver update. If I did understand properly the cause for intel validation problem described in the brp4-intel-gpu-app-feedback thread, it is caused because mul+add is less precise than fused instruction (rounding 2x vs rounding 1x). However the FP_CONTRACT directive should in fact enable such operations so this doesn't make any sense why this commit would actually break thinks.

Hmmm, my reading of one cause of non-validating (on some iGPUs / some drivers) was the MAD instructions (working on some iGPUs) causing a differing result. 

In that case the MAD results were invalid (perhaps more accurate results - but most importantly - different).  Christian adjusted the validator's sensitivity and that should have reduced the percentage of invalids.  Edit: i would expect small differences between beignet and windows as well.

Perhaps you could run the test case and manually compare a before and after result?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.