With the Intel One API (tested on the 2021.1-beta06 release), the OpenCL compiler seems to perform some unsafe optimisations even if the no-fast-math flag from the OpenCL standard is passed to the run-time compilation stage. this results in OpenCL tests failing, in particularily
Other environments or run-time compilers tested so far seem to not show this problem.
Short-term solution: Relax the absolute difference tolerance for these tests from currently 2e-14 to 5e-11, which seems to be large enough to accomodate the resulting differences
Proposed mid-term solution:
Allow the configuration of the tests and the track-job compiler options on a per-platform / per-device level to adjust for such problems in the future
Investigate the specific root-cause for the numerical deviation, isolate the effect on the API level and research compiler flags in order to establish the expected behaviour. To this end, create API that allows the default compiler option string to be pre-configured on a per-device / per-platform level
With the Intel One API (tested on the 2021.1-beta06 release), the OpenCL compiler seems to perform some unsafe optimisations even if the no-fast-math flag from the OpenCL standard is passed to the run-time compilation stage. this results in OpenCL tests failing, in particularily
Other environments or run-time compilers tested so far seem to not show this problem.
Short-term solution: Relax the absolute difference tolerance for these tests from currently
2e-14to5e-11, which seems to be large enough to accomodate the resulting differencesProposed mid-term solution: