Yet another discussion about OpenCL.dll

I’d like to once again raise the question about ICD model, and in particular, the OpenCL.dll.

As far as I understand the model, the OpenCL.dll (loaded by application) does not contain any real OpenCL stuff. It serves only as a frontend that looks for ICD drivers registered in the system and redirects OpenCL calls to them. As a result, there is no need to worry about which implementation of OpenCL the user has installed. Also, it is possible to have several different implementations in a single system, and everything works correctly in a friendly way :slight_smile:

And there is no problem with this model unless you have a real-world application that uses OpenCL, and you want to distribute it to the clients. In such case you are going to face “OpenCL.dll” not found crashes problem if the client’s system has NO OpenCL installed.
The most disturbing thing is: everything works fine on every machine and every platform. Except for the fact that the application cannot detect that there is not OpenCL, because it crashes on startup.

Indeed, there are some ways to fix the issue:
[li]Load DLL dynamically and load functions manually from it. Too much pain.[/li][li]Use delayloading of OpenCL.dll by Visual C++. Perhaps this can work. Not to mention that I have never even heard of this mechanism until I have faced the problem of distributing OpenCL application.[/li][li]Use CLEW (or whatever other helper library). This also can work, but I’m not sure if CLEW is still alive… In fact, using CLEW on top of OpenCL.dll is like using helper on top of helper. OpenCL.dll is already just a dispatcher between implementations, so it is really weird to add one more helper that does the same thing.[/li][li]Distribute OpenCL.dll with your application. This is an easy and perfectly working way (though people tend to object). However, it is copyrighted by Khronos, and it is not clear whether it is legal to redistribute it.[/li][li]Build your own OpenCL.dll and distribute it along with your application. The sources are available in OpenCL registry, but only for version 1.2. The license inside permits everyone to build a binary and distribute it freely.[/li][li]Build application statically with OpenCL dispatching mechanism. Perhaps this can be done using the sources from the previous case.[/li][/ol]
Currently I’m using the self-made OpenCL.dll (case 5). It is quite strange to use a rogue OpenCL.dll. I really wish to distribute the official Khronos DLL, but I’m not sure if I can.
That’s why I want to resurrect the discussion about whether it is good or bad to distribute OpenCL.dll with application.

The most popular objection is: “you cannot do it because OpenCL.dll is vendor-specific”. I have three implementations from different vendors installed, and OpenCL.dll in my system says that it is copyrighted by Khronos. It means that none of the three risked to modify OpenCL.dll with his own version. Because if any vendor messes with the DLL, he can easily break the dispatching mechanism, so all the implementations from the other vendors would not work. In fact, distributing self-owned version of OpenCL.dll ensures that even if some vendor breaks dispatching mechanism by placing improper DLL into the system directory (like some early versions), your application would still properly work with all the ICD-compliant implementations available.

As far as I see it, the ICD model is a standard that requires all the vendor implementations to be properly registered and be usable by the dispatch mechanism. Doesn’t it mean that OpenCL.dll is no longer a necessary part of the OpenCL, but only a helper library (like CLEW)?
Isn’t it correct that any ICD-compliant implementation can be used directly by looking up Windows registry and loading the vendor DLL found there (f.i. amdocl.dll) directly? I mean, doesn’t the standard guarantee that this way must work? If it does, than OpenCL.dll is indeed only a helper library, and there is no problem with distributing it.

Do (2). It works great.

Never do (4) or (5), only drivers should install the ICD and you could hurt other applications if you do it wrong.

Well, it looks like I should try it out.

I do not see reasons for this restriction. Indeed, I should never mess with ICD drivers (i.e. vendor DLLs). However, I can’t get it why I can’t use my own OpenCL.dll since it is only a helper library that calls ICD drivers in a standard way.

Also, I do not see how can I break other applications. By “distribute with your application” I mean distribute it in the local directory of the application EXE. Of course, substituting the DLL from the system directory is a very bad decision. At least because it can magically downgrade the consumer’s OpenCL version from whatever he had before to your version (which is 1.2 because the newer sources are not published). As long as you just place proper OpenCL.dll in local directory, you can expect only your application to use it.

In fact, many applications use boost dynamic libraries, and no one can ask a customer to install boost himself. So everyone is distributing boost libraries with application. Doing it wrong can break other application using boost, doesn’t it? It seems like the problem we have to tolerate in Windows environment, where everyone distributes all the DLLs he needs.
Perhaps renaming OpenCL.dll to MyOpenCL_1_2.dll will make it less dangerous?

To clarify, never install OpenCL.dll in the system directory. If you install it in your application folder or bundle, that’s less of a system-wrecking technical issue. Legally you might not have the right to distribute it; check the license.