Apps won't launch on Win10 after Upgrade to 1.9

[simono]

3 minutes ago, Mark Ingram said:

I imagine it's the Intel driver you have. Is there no later driver you can install?

According to Intel - no. And the 8th of January 21 is pretty new anyway.

But here we have something:

... requires further installations.

[Mark Ingram]

6 minutes ago, simono said:

But here we have something:

... requires further installations.

Hmm, wonder what that means 🤔

[Mark Ingram]

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/intel-hd-graphics-device-requires-further/b9b8326d-b573-442f-a79f-0ff573eb569e?auth=1

https://appuals.com/how-to-fix-device-requires-further-installation-on-windows-10/

https://community.intel.com/t5/Graphics/Intel-HD-Graphics-4600-Driver-Failure-requires-further/td-p/529534

[simono]

It's a red herring. If I scroll down do the last device event the contents of the bottom window change to:

======================================================Das Gerät PCI\VEN_8086&DEV_5916&SUBSYS_39E817AA&REV_02\3&11583659&1&10 wurde gestartet.

Treibername: oem135.inf
Klassen-GUID: {4d36e968-e325-11ce-bfc1-08002be10318}
Dienst: igfx
Untere Filter: 
Obere Filter: 
 

 

[simono]

In other words - all is well.

[simono]

I might add - this laptop was migrated from Win 8 to Win 10. About a year ago, maybe.

On the other hand, the graphics driver was de-installed and re-installed a few days ago. Quite apart from getting the very latest version directly off the Intel site. Intel ran a program to check my system and identify any Intel stuff that needed updating. 

Anyway, the funny info was due to standing on the first event. Standing on the last event looks rather different.

[simono]

Look what I have found in the registry. Everything else is on "Standard". Could we be talking about the wrong openCL DLL the whole time?

[simono]

This file is not so new. There's a 32 bit version in there too.

[v_kyr]

2 hours ago, simono said:

... requires further installations.

• So beheben Sie “Gerät erfordert weitere Installation” unter Windows 10

[simono]

Thanks for the reply. Actually it was only me being a bit daft. The bottom window is showing extra info about the line you are standing on. The default is: you stand on line 1 and nobody tells you so.

If you scroll down to the bottom line - i.e. 09.02.21 12:49:46 - you get a completely different info displayed.

I couldn't have designed it better myself! 😊😊😊

[v_kyr]

3 hours ago, Mark Ingram said:

...OpenCL.dll is just a wrapper around the "real" drivers, so it's not OpenCL.dll that's at fault.

Here's a short description article ("Multiple OpenCL devices with the Installable Client Driver (ICD)") about this, which might be useful for people to get an overall better understanding here.

• Multiple OpenCL devices with the Installable Client Driver (ICD)

[v_kyr]

1 hour ago, simono said:

Look what I have found in the registry. Everything else is on "Standard". Could we be talking about the wrong openCL DLL the whole time?
...

Quote

ICD Loader Vendor Enumeration on Windows

To enumerate Vendor ICDs on Windows, the ICD Loader scans the values in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors. For each value in this key which has DWORD data set to 0, the ICD Loader opens the dynamic link library specified by the name of the value using LoadLibraryA.

For example, if the registry contains the following value

     [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors]
     "c:\\vendor a\\vndra_ocl.dll"=dword:00000000

then the ICD will open the library "c:\vendor a\vndra_ocl.dll".

See:

• https://www.khronos.org/registry/...

[v_kyr]

13 hours ago, ZY Chang said:

...

There are a lot of OpneCL.dll files at various places.  Which ones does the test code check?  Any idea as which OpenCL driver is faulty?

A good point, an iteration through all of them here via a test prog should idealy then print out the appropriate data.

[ZY Chang]

5 hours ago, Mark Ingram said:

Try this, use the "fork" parameter:

cltest.exe fork

I get:

 

Here is my 'fork' run result:

[simono]

1 hour ago, v_kyr said:

For example, if the registry contains the following value

     [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors]
     "c:\\vendor a\\vndra_ocl.dll"=dword:00000000

then the ICD will open the library "c:\vendor a\vndra_ocl.dll".

This means that only one openCL DLL is being used, the one pointed to by the path in the registry. Then I ask myself why another twenty odd openCL.DLL's are hanging around all over the place.

Anyway, in my case the one being used is as below, and the files updated by Intel, as I did an update, are not being used, unless of course my "IntelOpenCL64.dll" tucked away in a remote corner performs calls to "openCL.dll" in system32.

[walt.farrell]

6 minutes ago, simono said:

This means that only one openCL DLL is being used, the one pointed to by the path in the registry. The I ask myself why another twenty odd openCL.DLL's are hanging around all over the place.

Anyway, in my case the one being used as below, and the files updated by Intel are not being used, unless of course my "IntelOpenCL64.dll" tucked away in a remote corner does calls to "openCL.dll" in system32.

I think you have that backward. The Affinity code would call openCL.dll, and openCL.dll is what calls the vendor code listed in the registry. So openCl.dll would call IntelOpenCL64.dll when routing a call to the Intel GPU.

[simono]

Aha. Yeah, that makes more sense. This means that Intel updated my front-end openCL and did not update the back-end IntelOpenCL64 or IntelOpenCL32.

[v_kyr]

26 minutes ago, simono said:

This means that only one openCL DLL is being used, the one pointed to by the path in the registry. Then I ask myself why another twenty odd openCL.DLL's are hanging around all over the place.

Quote

Last but not least, keep in mind that:

• An OpenCL platform can have one or several devices.
• The same device can have one or several OpenCL implementations from different vendors. In other words, an OpenCL device can belong to more than just one platform.
• The OpenCL version of the platform is not necessarily the same with the OpenCL version of the device.

The OpenCL ICD

ICD stands for Installable Client Driver and it refers to a model allowing several OpenCL platforms to coexist. It is actually not a core-functionality, but an extension to OpenCL.

How does this model work?

While a machine can have several OpenCL platforms, each with its own driver and OpenCL version, there is always just one ICD Loader. The ICD Loader acts as a supervisor for all installed OpenCL platforms and provides a unique entry point for all OpenCL calls. Based on the platform id, it dispatches the OpenCL host calls to the right driver.

This way you can compile against the ICD (opencl.dll on Windows), not directly to all the possible drivers. At run-time, an OpenCL application will search for the ICD and load it. The ICD in turn looks in the registry (Windows) to find the registered OpenCL drivers. Each OpenCL call from your software will be resolved by the ICD, which will further dispatch requests to the selected OpenCL platform.

A few things to keep in mind

The ICD gets installed on your system together with the drivers of the OpenCL devices. Hence, a driver update can also result in an update of the ICD itself. To avoid problems, an OS can decide to handle the OpenCL itself.

Please note that the ICD, the platform and the OpenCL library linked against the application may not necessarily correspond to the same OpenCL version.

 

[simono]

Means in my case:

The ICD is openCL.dll, probably the one in system32.

The platform, in my case just one platform, is

C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_1a33d2f73651d989\IntelOpenCL64.dll

 

[simono]

C:\WINDOWS\system32>clTest fork
Checking for OpenCL binaries: Found
Querying OpenCL platform count:
C:\WINDOWS\system32>

Mark discovers there are platforms - or at least an ICD - but does not get a valid platform count. In my case he ought to get "1". The question is where does the count come from. He ought to get a List or something similiar based on the paths in my registry. In my case a list with one element. 

I wonder if the integer in that section should be a count and in my case be a 1 and not a zero.

 

[Mark Ingram]

3 hours ago, ZY Chang said:

Here is my 'fork' run result:

Thanks - again this shows you have the same problem as @simono. The program is crashing inside the OpenCL function clGetPlatformIDs.

[simono]

Hi Mark

Please take a look into your registry to see what you have in the Khronos openCL section. It should be a list of paths to each Platform - in most cases, just one entry.

Just to see if you have what I have.

If my registry section is any way corrupted it would be easy enough to fix.

[Mark Ingram]

22 minutes ago, simono said:

Hi Mark

Please take a look into your registry to see what you have in the Khronos openCL section. It should be a list of paths to each Platform - in most cases, just one entry.

Just to see if you have what I have.

If my registry section is any way corrupted it would be easy enough to fix.

Hi @simono, I don't have that registry key (but I do have Intel and NVIDIA OpenCL platforms available). 

[simono]

What surprises me is that Intel updated the everybody's ICD openCL.dll but the Intel platform IntelOpenCL.dll was left untouched. 

[v_kyr]

The following PDF-file "OpenCL ICD Installation Guidelines" from the OpenCL specification tells how things should usually be handled here (see there then Chapter 3, for Windows) ...

• OpenCL_ICD_Installation.pdf
• OpenCL_ICD_Installation (online HTML readable version)

BTW, the OpenCL specifications as PDF files (there are also HTML files etc.) for 2.2 and 3.0 can be found here ...

• https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/
• https://www.khronos.org/registry/OpenCL/specs/3.0-unified/pdf/

The "opencl-icd-1.2.11.0.tgz" archive there gives some related C code examples and tests.