Apps won't launch on Win10 after Upgrade to 1.9

[v_kyr]

Some additional OpenCL related hints here.

Most of the graphics card vendors (Nvidia, AMD, Intel) do have and offer OpenCL programming SDKs with supplied code examples. For example the Nvidia "GPU computing SDK" contains an "oclDeviceQuery" sample which queries OpenCL available platforms and devices (of course it uses and needs the opencl.dll lib and therefor an installed OpenCL driver). - For Windows platforms those samples are usually already precompiled, meaning there is often an already prebuild binary to execute.

1.) Here's an older Nvidia ocl v1.2 based "oclDeviceQuery" sample for Win, see ...

• https://developer.nvidia.com/opencl

... download from there beneath OpenCL Device Query the Windows [x64] one, which when extracted contains a Win executable under the following path ...

• /"NVIDIA GPU Computing SDK"/OpenCL/bin/win64/Release/oclDeviceQuery.exe

... you would run this from inside a Win cmd shell or Powershell since it's a CLI program.

The "oclDeviceQuery" sample will output it's queried data to the console and also create "oclDeviceQuery.txt" and "SdkMasterLog.csv" files which contain the output data too.

NOTE: you will find much newer Nvidia OpenCL/CUDA based SDKs under their toolkit archives ...

• https://developer.nvidia.com/cuda-toolkit-archive

2.) Another tool which might be helpful here is AMD's cliinfo, which outputs too relevant found OpenCL data. - A variant of that one can be found on Github here ...

• https://github.com/Oblomov/clinfo

... see the 32-bit/64-bit Win binaries at the bottom of that Github page for downloading precompiled binaries.

(Hope this possible helps the one or other to identify which OpenCL driver might be in use on their systems. - Good luck!)

 

[Mark Ingram]

clinfo will crash in exactly the same way. They even have a section calling out bad drivers on the readme. 

[v_kyr]

2 hours ago, Mark Ingram said:

clinfo will crash in exactly the same way. They even have a section calling out bad drivers on the readme. 

Good to know, since I'm on a Mac here haven't tried that one. - Instead I compiled the other one from Nvidia oclDeviceQuery, which after a few code adjustments then runs under my pretty old iMac and MacOS here. That generated then Mac system related OCL output due to my old platform here.

• oclDeviceQuery.txt
• SdkMasterLog.csv

However, such OCL things are easier to handle on Macs, since all comes just from one vendor hands here and thus there isn't so much possible graphics cards and driver mismatch available as in the Win world.

Note: that I couldn't test that oclDeviceQuery on a Win box, since I'm not in the company due to home office times and here I actually only have Macs.

 

[Mark Ingram]

Thanks @v_kyr, but the NVIDIA oclDeviceQuery will also crash in exactly the same place. The very first thing all of these examples do is, call clGetPlatformIDs (which is also the first thing the Affinity apps do). 

[simono]

In an effort to migrate to the Beta for production purposes, I copied my old directory "user" on top of the beta user directory. In other words I needed all my macros etc.

Now I see that the promised assets - among other things "fog" that I wanted to take a look at - do not appear. I do not see any way of downloading these give-aways. According to the test and demos on youtube, they are simply already there. Apparently they are not included in the beta package. Am I right?

[v_kyr]

2 hours ago, Mark Ingram said:

...do is, call clGetPlatformIDs (which is also the first thing the Affinity apps do). 

I wonder if there wasn't a way for the OpenCL developers to handle the clGetPlatformIDs implementation overall more secure and gracefully in terms of exception handling. - The following older stackoverflow entry is also interesting to read in this context here.

• OpenCL crashes on call to clGetPlatformIDs

Also don't know if GpuCapsViewer (a Win tool) then crashes too here, or uses some different approach in order to list all OCL related informations.

However, it might would be useful to have at least an easier indication output, on which opencl.dll access it crashes, so to say something which resembles what this Unix call claims to show, but for Windows systems instead.

Quote

find /etc/OpenCL/vendors/ -name '*.icd' | while read OPENCL_VENDOR_PATH ; do clinfo -l > /dev/null ; echo "$? ${OPENCL_VENDOR_PATH}" ; done

 

[simono]

47 minutes ago, v_kyr said:

Also don't know if GpuCapsViewer (a Win tool) then crashes too here,

Crashes on my system.

[Mark Ingram]

27 minutes ago, simono said:

Crashes on my system.

Thanks for checking. Developers should be able to rely upon the published APIs of OpenCL, and in this case, we can't (and neither can other apps, as you've experienced). The best we can do is, detect the crash, and disable hardware acceleration for your machine. This is Intel's fault I believe, so I've attempted to raise the issue with them.

[MilosG]

Ctrl+, Performance, Disable Hardware acceleration - disable OpenCL 

[simono]

Oh well:

try

{

   lstPlatformIds = clGetPlatformIds(whatever);

   // do any other initialization stuff //

}

except

{

    boolUseGPU = FALSE;

   // tell user to buy a new machine //

}

[Mark Ingram]

4 minutes ago, simono said:

Oh well:

try

{

   lstPlatformIds = clGetPlatformIds(whatever);

   // do any other initialization stuff //

}

except

{

    boolUseGPU = FALSE;

   // tell user to buy a new machine //

}

If only that worked 😞 In .NET that would be fine, and we could recover, but with native code, that's just not possible. 

[simono]

Doesn't an exception come up at all? Does it just croak downstairs and bail out?

[Mark Ingram]

Interestingly, this thread has users with the exact same crash in clGetPlatformIDs. They've solved the issue by uninstalling their device specific Intel drivers, and installing the OEM versions instead:

 

1 minute ago, simono said:

Doesn't an exception come up at all? Does it just croak downstairs and bail out?

Exceptions don't exist in native code 🙂 things either work, or they crash. In higher level languages, like .NET, then exceptions do exist, and you can handle them gracefully, but not when you're dealing with C or other low-level languages.

[simono]

So how do I de-install the device drivers? Just Control panel? But then all the files are still in place. Just re-booting will re-link them all.

If I look at the modules Lenovo consider to be on the latest version they don't even mention a cpu cum graphics driver. They do mention an Intel VGA, whatever that may be.

[simono]

C:\WINDOWS\system32>CLtest fork
Checking for OpenCL binaries: Found
Querying OpenCL platform count: 1
Attempting to initialise each platform: Success
Enumerating each platform:
        Name: Intel(R) OpenCL
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1

Success
Enumerating OpenCL devices for platform : Intel(R) OpenCL
Querying device count: 2
Attempting to initialise each device: Success
Enumerating each device:
        Name: Intel(R) HD Graphics 620
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1 NEO

        Name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1 (Build 611)

Success

C:\WINDOWS\system32>

[simono]

[walt.farrell]

4 hours ago, simono said:

In an effort to migrate to the Beta for production purposes, I copied my old directory "user" on top of the beta user directory. In other words I needed all my macros etc.

Now I see that the promised assets - among other things "fog" that I wanted to take a look at - do not appear. I do not see any way of downloading these give-aways. According to the test and demos on youtube, they are simply already there. Apparently they are not included in the beta package. Am I right?

The 1.9 beta had its own set of "free" resources, that 1.9 retail did not supply. The 1.9 retail version has different ones, that the 1.9 beta still doesn't have. I'm not sure whether the 1.9.1 beta will get the 1.9 free content, or not. If it doesn't, you can export it from 1.9 and import it into 1.9.1 beta.

I would hope they'll show up in the 1.9.1 retail, but until then only someone from Serif might know.

[v_kyr]

1 hour ago, Mark Ingram said:

...
Exceptions don't exist in native code 🙂 things either work, or they crash. In higher level languages, like .NET, then exceptions do exist, and you can handle them gracefully, but not when you're dealing with C or other low-level languages.

Yip, that's sadly the fact here for more native and old backward compliance languages like C. - And most exception handling like things act here only on top then and not directly as a defined and default initial language part, like ...

• Exceptions in C with longjmp and setjmp
• Try catch statements in C
• ...etc.

Of course there are also other opinions about the common sense of exception handling at all ...

• Why is exception handling bad
• ... and so on ...

And some more modern languages like GO and Rust don't have/use the common from other higher languages (Java, C# ... etc.) known Try/catch exception handling scheme. Instead they use in case of GO multiple return values and panic ...

• Error handling in GO ...

... and for Rust there Result<T, E> for recoverable errors and the panic! macro ...

• Rust error handling

However, the overall problem here in this threads context is, that the OpenCL implementation does suck in this specific area and can lead to crashes here due to clGetPlatformIDs function calls. This makes it overall difficult to handle this at all in software which uses and depends on these OpenCL implementations.

Maybe the OpenCL group should rewrite their OpenCL stuff better in Rust.

[simono]

I might mention, that I was advised to update straight from Intel here in this forum! Certainly well meant, but, interestingly enough, contraproductive.

Now the driver is three years older than the one I had installed off the Intel site.

1.9 is now up and running.

The same goes for hardware acceleration in Filmora 10.

My problem now is that the next Windows update might put in the latest Intel stuff again.

[ZY Chang]

1 hour ago, simono said:

C:\WINDOWS\system32>CLtest fork
Checking for OpenCL binaries: Found
Querying OpenCL platform count: 1
Attempting to initialise each platform: Success
Enumerating each platform:
        Name: Intel(R) OpenCL
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1

Success
Enumerating OpenCL devices for platform : Intel(R) OpenCL
Querying device count: 2
Attempting to initialise each device: Success
Enumerating each device:
        Name: Intel(R) HD Graphics 620
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1 NEO

        Name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
        Vendor: Intel(R) Corporation
        Version: OpenCL 2.1 (Build 611)

Success

C:\WINDOWS\system32>

What did you do on your system/driver so that  cltest returns 'success'?

[ZY Chang]

12 minutes ago, simono said:

I might mention, that I was advised to update straight from Intel here in this forum! Certainly well meant, but, interestingly enough, contraproductive.

Now the driver is three years older than the one I had installed off the Intel site.

1.9 is now up and running.

The same goes for hardware acceleration in Filmora 10.

My problem now is that the next Windows update might put in the latest Intel stuff again.

Did you un-installed the Intel latest driver and let the system install available driver or un-installed it first and manually  installed OEM versions instead?

[v_kyr]

43 minutes ago, simono said:

might mention, that I was advised to update straight from Intel here in this forum! Certainly well meant, but, interestingly enough, contraproductive.

Now the driver is three years older than the one I had installed off the Intel site.

1.9 is now up and running.

You mean the one you fetched from the Intels site was older than what Win 10 already did installed? - Strange!

[simono]

No, vice versa. Intel delivers January 2021.

The situation is as follows:

Driver 2021 - does not work. openCL crashes. Loaded manually from Intel.

Driver 2020 - does not work. openCL crashes. Loaded by Win update. What I had in the beginning.

Driver 2020 - does not work, openCL binaries not found at all. Loaded by Win update.

Driver 2018 - works perfectly (as far as I can see) Affinity runs with acceleration, Filmora runs with acceleration. Must have been somewhere on my disk.

The problem at the moment is to prevent Windows from updating this driver. Every reboot updates the driver.

[ZY Chang]

How did you end up with Driver 2018?  Did you keep uninstalling the driver until you saw it is 2018 by itself?  Or you manually installed the 2018 version?  Not sure if your solution applies to my computer.

[v_kyr]

9 minutes ago, simono said:

No, vice versa. Intel delivers January 2021.

...

The problem at the moment is to prevent Windows from updating this driver. Every reboot updates the driver.

Ah Ok, I understand. - Hmm maybe the following will be helpful then for Win 10 ...

• How to temporarily prevent a driver update from reinstalling in Windows 10

• How to disable automatic driver updates on Windows 10