re validation. I wonder if the validator itself might need a slight tweak to the acceptable tolerances.
maybe if Bernd has time, he can take a look at how far apart results end up being to be deemed inconclusive, and see how close that is to the pair of accepted results, and check if the original pair might have been close enough to be deemed a valid result and within their science goals.
With that stated, does your Iris Xe igpu get sent BRP7 tasks?
I notice that between your Iris Xe igpu output and say my RTX 3080 Ti output, the values for the
<half_fp_config>0</half_fp_config>
and the
<double_fp_config>63</double_fp_config>
are swapped.
Your values:
<half_fp_config>63</half_fp_config>
<double_fp_config>0</double_fp_config>
My values:
<half_fp_config>0</half_fp_config>
<double_fp_config>63</double_fp_config>
The only place 64 comes up is in the other parameter strings with int64 prefaced by khr. I believe khr refers to Khronos which I believe is the main developer of the current OpenCL platform.
I've never had any issues with the OpenCL driver component of the Nvidia drivers. They work on all OpenCL apps at the required OpenCL level as needed by whatever app.
the app is only for Windows. So I had to use an app_info to get tasks. Bernd said that the linux amd binary would work so that's what i used. (claiming the opencl binaries are all the same anyway)
when you use the anonymous platform, those kinds of server side checks dont matter. you're just telling the project "i have my own application, send me tasks"
if there was a stock linux app, it might not have sent me anything if it indeed looks for fp64 server side.
On a larger scale (overall project), 0.15 (Linux) had an invalid rate of >10% when paired with 0.12 (Windows), while 0.17 has 3-4%. From my perspective this looks like an improvement, though possibly not for each and every host.
This host finished FGRPB1G GPU tasks for years successfully (also validates). Logfiles of each FGRPB1G task always state the following:
Using OpenCL device "Intel(R) HD Graphics 4600" by: Intel(R) Corporation
Max allocation limit: 340158054
Global mem size: 1360632218
Error in OpenCL context: Build program failure.
OpenCL compiling FAILED! : -11 . Error message: :10:30: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
error: front end compiler failed build.
OpenCL device has no FP64 support
Clearly this iGPU doesn't support FP64 but successfully crunched FGRPB1G GPU tasks on iGPU.
Yes, the FGRP app doesn't rely on the OpenCL information it gets from the client when checking if the GPU supports fp64, it does indeed try to compile a kernel that uses this. That's not a problem for the FGRP app, because when the GPU doesn't support fp64, it does the double precision part on the CPU. The BRP7 app can't do this, so in selecting which Intel GPU gets "work", the scheduler relies on information from the client, which apparently is wrong.
Intel Arc GPUs don't support hardware accelerated FP64 calculations. However, they do support emulated FP64 calculations for niche cases. This is because Intel removed FP64 hardware support in their 12th generation GPU architecture. Instead, they added code to the driver to emulate FP64 calculations with software instructions.
Thanks, this is helpful. Then it's likely not the client, but the driver which wrongly reports fp64 support to the client. Can you point me to any documentation of this? Does this fp64 software emulation require specific instructions or activation?
hey that's super helpful for linux though! it linked to the github page for how to enable FP64 emulation on Linux with the NEO drivers (which is what I'm using).
By default NEO driver enables double precision operations only on platforms with supporting hardware. This is signified by exposing the "cl_khr_fp64" extension in the extension string. For other platforms, this support can be emulated by the compiler (IGC).
There are two ways you can enable this feature in NEO:
Set an environment variable OverrideDefaultFP64Settings to 1: OverrideDefaultFP64Settings=1
In igdrcl.config configuration file in the same directory as application binary (you may have to create this file) add a line as such: OverrideDefaultFP64Settings = 1
IGC reads flags only from environment, so set IGC_EnableDPEmulation to 1 as such: IGC_EnableDPEmulation=1
After both settings have been set you can run the application normally.
after setting those two env vars, the task actually runs now. I'm sure it's terribly slow, but I'll run a couple for the fun of it. no luck for Windows users, but this will actually work on Linux with the caveat of needing NEO drivers and to set these values in the same environment that BOINC runs in.
re validation. I wonder if
)
re validation. I wonder if the validator itself might need a slight tweak to the acceptable tolerances.
maybe if Bernd has time, he can take a look at how far apart results end up being to be deemed inconclusive, and see how close that is to the pair of accepted results, and check if the original pair might have been close enough to be deemed a valid result and within their science goals.
_________________________________________________________________________
Ian, what is interesting is
)
Ian, what is interesting is this value:
<double_fp_config>0</double_fp_config>
in your coproc_info.xml output.
With that stated, does your Iris Xe igpu get sent BRP7 tasks?
I notice that between your Iris Xe igpu output and say my RTX 3080 Ti output, the values for the
<half_fp_config>0</half_fp_config>
and the
<double_fp_config>63</double_fp_config>
are swapped.
Your values:
<half_fp_config>63</half_fp_config>
<double_fp_config>0</double_fp_config>
My values:
<half_fp_config>0</half_fp_config>
<double_fp_config>63</double_fp_config>
The only place 64 comes up is in the other parameter strings with int64 prefaced by khr. I believe khr refers to Khronos which I believe is the main developer of the current OpenCL platform.
I've never had any issues with the OpenCL driver component of the Nvidia drivers. They work on all OpenCL apps at the required OpenCL level as needed by whatever app.
the app is only for Windows.
)
the app is only for Windows. So I had to use an app_info to get tasks. Bernd said that the linux amd binary would work so that's what i used. (claiming the opencl binaries are all the same anyway)
when you use the anonymous platform, those kinds of server side checks dont matter. you're just telling the project "i have my own application, send me tasks"
if there was a stock linux app, it might not have sent me anything if it indeed looks for fp64 server side.
_________________________________________________________________________
Oh, OK. I keep forgetting
)
Oh, OK. I keep forgetting that you kludge the gpu description to fool the scheduler into sending tasks.
On a larger scale (overall
)
On a larger scale (overall project), 0.15 (Linux) had an invalid rate of >10% when paired with 0.12 (Windows), while 0.17 has 3-4%. From my perspective this looks like an improvement, though possibly not for each and every host.
BM
Scrooge McDuck wrote:This
)
Yes, the FGRP app doesn't rely on the OpenCL information it gets from the client when checking if the GPU supports fp64, it does indeed try to compile a kernel that uses this. That's not a problem for the FGRP app, because when the GPU doesn't support fp64, it does the double precision part on the CPU. The BRP7 app can't do this, so in selecting which Intel GPU gets "work", the scheduler relies on information from the client, which apparently is wrong.
BM
Keith Myers wrote: Intel Arc
)
Thanks, this is helpful. Then it's likely not the client, but the driver which wrongly reports fp64 support to the client. Can you point me to any documentation of this? Does this fp64 software emulation require specific instructions or activation?
BM
Oh: "We have verified that
)
Oh: "We have verified that double-precision floating point emulation is not available on Windows.".
From: https://community.intel.com/t5/GPU-Compute-Software/Iris-Xe-Graphics-can-t-compute-double-precision-floating-point/m-p/1281976
BM
Ian&Steve C. schrieb:I'd be
)
Bernd Machenschalk
)
hey that's super helpful for linux though! it linked to the github page for how to enable FP64 emulation on Linux with the NEO drivers (which is what I'm using).
https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64
after setting those two env vars, the task actually runs now. I'm sure it's terribly slow, but I'll run a couple for the fun of it. no luck for Windows users, but this will actually work on Linux with the caveat of needing NEO drivers and to set these values in the same environment that BOINC runs in.
_________________________________________________________________________