cl_khr_icd spec

Is there a formal cl_khr_icd specification? Are ICD tests part of the conformance tests?

NVIDIA and AMD are currently doing a poor job with ICD interoperability and it would be good to know what the problem is.

I suspect the problem is that neither company has any incentive to make their software compatible with their competitor’s. :slight_smile: I’m not sure how one fixes that.

Well, one way would be to make a conformance test that verified cl_khr_icd support. Even the process of writing the conformance test would probably sort out most of the issues. Getting conformance to be able to ship an OpenCL implementation would be a strong incentive.

Of course that requires the group to make it a priority, but I think its a little sad that NVIDIA and AMD ship different DLLs marked with the Khronos name but that don’t interoperate.

I think the problem is that the platform layer is tested explicitly (since you kind of have to use it for anything) but there’s no way to write a vendor-unspecific test that verifies that it works with other vendors’ libraries.

A basic question I have is how many implementations of OpenCL.dll are there? If the answer is more than one, there is a serious problem. There may be revisions to the library in which case the version number should be incremented to aid in proper installation. New versions of the library should maintain compatibility with previous versions.

I would think that this library should be provided to the vendors as a binary by Khronos based on a common code base. Vendor specific modifications should not be made to OpenCL.dll. Anything vendor specific should be handled by OpenCL.dll delegating to the vendor libraries. If Khronos provides the OpenCL.dll for the testing, it will be immediately obvious if there is a problem with interoperability because the fault will by definition be in the vendor library.

Even if all of this is off to a rocky start, it is critical to get it on track if the goal is to move OpenCL beyond developer labs to actual applications on end user machines.

Is there a formal cl_khr_icd specification? Are ICD tests part of the conformance tests?

NVIDIA and AMD are currently doing a poor job with ICD interoperability and it would be good to know what the problem is.

Actually, if you install the ATI Stream SDK 2.0.1 and copy their new OpenCL.DLL over the NVidia OpenCL.DLL in Windows\System32 or Windows\SysWOW64 you can use both platforms with that one DLL.

This is good news.

On the flip side I can’t seem to get the AMD OpenCL implementation to work on linux because of ICD. clGetPlatformIDs always returns -10001.

Oops, typo in my previous post, the error code is actually -1001.

I have installed the AMD Stream SDK 2.01 and verified that the AMD DLLs are in the system directories but I don’t see the NVIDIA platform in this configuration. I’m on XP64 with an ATI 4850 (Catalyst 10.1) and a NVIDIA 9800GT (195.62). With the AMD OpenCL.dll I see the AMD platform with 2 devices: CPU and AMD GPU. With the NVIDIA DLL I see the NVIDIA platform with a NVIDIA GPU device.

The Khronos Promoters recently ratified the ICD extension specification and it is available in the Registry now.

The Khronos Promoters recently ratified the ICD extension specification and it is available in the Registry now.[/quote]

Thanks for passing along the new information Jon!

There are a couple URLs in the spec. Are these public and if so should I be able to browse there with a web browser? When I follow the links I am prompted for a password.
https://cvs.khronos.org/svn/repos/OpenCL/trunk/icd/
https://cvs.khronos.org/svn/repos/regis … HR/drafts/

In the section “ICD Loader Vendor Enumeration on Windows” the LoadModule function is mentioned. Should this be LoadLibrary?

After reading the spec I believe that the interop problem I have with AMD and NVIDIA is that the NVIDIA Vendor ICD and the ICD Loader that NVIDIA shipped (in driver version 195.62) use the entry point clIcdDispatchGetPlatformIDsKHR instead of the specified clIcdGetPlatformIDsKHR. This may not be totally unexpected since the NVIDIA implementation predates both the ratified version of the spec and the ratification date, but I am slightly surprised that the conformance would have passed or that a conformant implementation could claim adherence to an unratified Khronos extension.

So unless I’ve misunderstood, the next step appears to be for NVIDIA to ship an updated Vendor ICD and ICD Loader that conforms to the ratified spec.

No, they are pointers into our internal SVN repository. I’ve updated the spec to remove those links. I don’t know if it’s intended for the ICD source to be made publicly available eventually or not, that’s up to the WG.

In the section “ICD Loader Vendor Enumeration on Windows” the LoadModule function is mentioned. Should this be LoadLibrary?

I’m not sure. If you want to file a bug in the public Khronos Bugzilla I’ll see it gets forwarded to the extension authors. I also asked them to poke their heads in on the various message board threads - it is really outside my domain to answer detailed questions about the ICD Windows internals much less the vendor implementation status :slight_smile:

After reading the spec I believe that the interop problem I have with AMD and NVIDIA is that the NVIDIA Vendor ICD and the ICD Loader that NVIDIA shipped (in driver version 195.62) use the entry point clIcdDispatchGetPlatformIDsKHR instead of the specified clIcdGetPlatformIDsKHR. This may not be totally unexpected since the NVIDIA implementation predates both the ratified version of the spec and the ratification date, but I am slightly surprised that the conformance would have passed or that a conformant implementation could claim adherence to an unratified Khronos extension.

I believe the WG felt a lot of pressure to get this done quickly so it isn’t surprising for there to be some teething pains. But the intent is certainly to get it working cleanly and consistently across all the vendor drivers.