topic Hi BruceB, in OpenCL* for CPU

Uninstall Intel OpenCL Platform?

Russel_D_ — Fri, 09 Dec 2016 17:46:58 GMT

Machine Details:

Windows 10

CPU: Intel Core i5 4670K Quad Core

Integrated Graphics: HD 4600

I've been developing an AMD OpenCL application using their SDK. I use VS2015 to compile, then I test on a different machine with a discrete AMD GPU.

Recently I installed a AMD RX 470 on my dev machine, which means I now have two OpenCL platforms: Intel and AMD. Now, my application crashes when run from the IDE :

Unhandled exception at 0x00007FFB3F76A74A (igdrcl64.dll) in ethminer.exe: 0xC0000005: Access violation reading location 0x0000000000000994.

The error appears to be occurring in igdrcl64.dll when my application attempts to enumerate installed OpenCL platforms by calling clGetPlatformIDs. Interestingly, my application seems to run fine when run from the command line, outside the IDE.

I don't really know the best way to solve this, but I was thinking it might help to remove the Intel OpenCL platform. How can I do that? Before installing the new GPU, I uninstalled the Intel Graphics Driver from the control panel, but I don't think it got everything.

If you're comfortable mucking

Ben_A_Intel — Fri, 09 Dec 2016 21:55:35 GMT

If you're comfortable mucking with the registry, the easiest thing to do is to modify:

HKLM\SOFTWARE\Khronos\OpenCL\Vendors (for 64-bit applications)

HKLM\SOFTWARE\Wow6432Node\Khronos\OpenCL\Vendors (for 32-bit applications)

These registry keys should contain one REG_DWORD value for each OpenCL platform. If you change the REG_DWORD value for a platform from 0 to 1 then that platform will no longer enumerate. The nice thing about this method is that if you change your mind, you can re-enable the platform by simply changing the value from 1 back to 0.

The ICD loader extension spec has more detail, if you're curious:

https://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt

Thanks! That was super easy!

Russel_D_ — Fri, 09 Dec 2016 23:03:12 GMT

Thanks! That was super easy!

We have no information about

Borden__bruce — Fri, 26 Apr 2019 17:32:00 GMT

We have no information about how the runtime .dlls got there. We're running a pre-compiled app from the command prompt, not from ICD.

My GUESS is that somebody went looking for obsolete or missing drivers and discovered a suggestion to install something that was probably called something like "Missing drivers for your CPU." Once those drivers are installed, there's no obvious way to remove them, but the regedit change is, as he says above .... is super easy.

Maybe we don't need to recommend that. I'd also consider the option of intentionally installing the cooperative runtime that works with multiple OpenCL implementations. Presumably that will overwrite whatever is causing the conflict.

EDIT: setting the appropriate dwords to 0 or 1 resolved our original issue.

I read somewhere that if the iGPU is detected when Windows is installed, it may also silently install IntelOpenCL*.dll. This is a bad idea because of potential conflicts like the one I mentioned in the other topic,

Hi BruceB,

Michael_C_Intel1 — Fri, 26 Apr 2019 23:16:25 GMT

Hi BruceB,

Glad you were able to use the registry as a solution. For completeness here is a reference to the other thread.

Borden, bruce wrote:
We have no information about how the runtime .dlls got there. We're running a pre-compiled app from the command prompt, not from ICD.

A verbose walkthrough for other forum viewers who may have similar issues:

Strictly speaking, recent OpenCL applications all leverage the ICD loader library, opencl.lib/opencl.dll in windows. It serves as a demultiplexer that will reroute operations to particular implementations available... It looks for the implementation .dll's you've identified on the system via the registry. The programming model puts the onus on the application developer to interrogate systems to find available implementations... or perhaps only find a subset as they see fit.

It's possible the application's logic for choosing an implementation is limited... Therefore the application may not detect available devices when either a runtime is updated or hardware is added to the platform... example:

The application may look for a device named "ExampleCorp A1000 v.3 OpenCL2.0" but perhaps not "ExampleCorp A1000 v.3 OpenCL2.1". As a consequence it may not reflect that to the application user.
It's also possible the application chooses the first detected device only.

There are many ways devices could be omitted... particularly from legacy programming practices.

Borden, bruce wrote:
conflicts like the one I mentioned in the other topic

Do you have any more details that can be shared about the conflict? An error box screen shot? An application reported error? The version, vendor, and name of the application?

An opaque application above is why an application like clinfo... which currently has precompiled builds available for windows os... is useful to interrogate the system... clinfo interrogation methodology is known. It's expected to provide information on all available OpenCL implementations... so it's a more clear place to start to determine if an issue is with an application or the OpenCL implementation.

Borden, bruce wrote:
I'd also consider the option of intentionally installing the cooperative runtime that works with multiple OpenCL implementations. Presumably that will overwrite whatever is causing the conflict.

It may be useful to revisit the obtaining drivers comment from the other thread. To recap, the recommended guidance is:

1) Obtain OpenCL runtimes from the Intel Graphics Driver package from the system vendor website... This may be required for support or even warranty constraints presented by the vendor.

2) Obtain OpenCL runtimes from graphics section of downloadcenter.intel.com matching the specified hardware of the system. Note this may not be appropriate on systems that have vendor support constraints.

3) Windows OS does install some OpenCL runtimes automatically if Intel Graphics devices are detected. These may not be recent... so one of the other two methods is to be preferred.

I hope this context helps navigate prerequisite setup more easily for your use case.

-MichaelC