How does OpenCL work without ICD loader extension?

Question

AFAIK it works like this with ICD loader extension:

• ICD (installable client driver) = proprietary OpenCL implementation = OpenCL runtime; You can find it in files like amdocl.so/dll or IntelOpenCL.so/dll
• ICD loader (in OpenCL.dll/libOpenCL.so): for managing multiple ICDs in the same system
  • It is linked with the OpenCL application and acts as a placeholder for the ICD.
  • The application invokes the functions exported by the ICD loader's library. However the ICD loader just decides to which ICD to redirect to depending on the selected OpenCL platform.
  • The ICD loader mechanism is necessary, because a vendor's OpenCL implementation usually just supports this vendor's hardware, but you might want to use multiple devices from different vendors in the same OpenCL application.

As the ICD loader is just an optional OpenCL extension, I wonder how OpenCL works without the ICD loader. Of course, in this case you can not use multiple vendors' implementations in the same application at the same time, but what is used for linking the application? If the developer linked it against a specific implementation, then the main goal of OpenCL, portability, could not be reached anymore.

Or do the vendors have to provide dynamic libraries, that are compatible to each other? That means, if the developer linked to the dynamic library of vendor A, at runtime it would also work, if the target system has the dynamic library of vendor B installed?

Is that anywhere documented?

Stratiform

The whole "portability" thing is all about source code portability, isn't it? – Uttermost

Source code of ICD loader is available at khronos.org site, so you can incorporate it into your application, and manage ICDs yourself. There is no practical sense in this though. But answering your question, yes, ICDs all have the same interface, because this is how ICD loader works with them. Best documentation is probably ICD loader source code. – Dubuffet

@Dubuffet From your answer I infer, that ICDs have already existed before the ICD loader and have already had the same interface at that time. If so, then it would be clear now. (Of course, there have always been some libraries, that implement OpenCL, but I was not sure, whether they have always had the same interface.) – Stratiform

Or they could have co-evolved. I don't know how things worked prior to the introduction of multi-platform support. And by now this is of purely historical interest. – Dubuffet

"Is that anywhere documented?" You just did it. And thank you for that. – Felonious

Answer 1

For Windows OpenCL applications, your application includes OpenCL.h (or cl.h) and links to OpenCL.lib, which is a static library wrapper for OpenCL.dll which resides in the Windows System32 folder. You don't know if it is an ICD or a vendor driver. For the past many years it has been an ICD, but before that (for very early OpenCL implementations) it was a vendor driver. The beauty of the ICD is that the application does not need to know, you just call the OpenCL API. Only when it is an ICD will the number of platforms be greater than 1.

Proteiform

Answer 2

A program is not built against a vendor OpenCL implementation. It is build against OpenCL itself, and the vendor OpenCL is the OpenCL implementation for the end user's processor.

So the specific implementation is for the end user, and multiple implementations are for when the user wants to use any of the multiple OpenCL capable processors. It's about the end-user preferences.

Typesetter