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
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.