How to Link to different Opencl.dll

when running JOCLSample_2_0_SVM

I was getting
Exception in thread “main” java.lang.UnsupportedOperationException: The function clCreateCommandQueueWithProperties is not supported

as the Project was linking to C
C:\Windows\System32\OpenCL.DLL, which is OpenCL 1.2 (and does not support this operation)
(also I cannot swap out this to a different version easily, as rest of system depends on it!!)

but, if I add in

then it loads the Intel version of OpenCL.dll, which has support for OpenCL 2.0

then JOCLSample_2_0_SVM, runs OK

Took me a couple of days to figure that out, brought a book on Amazon on JNI, and started writing my own driver,
before I realized

Thanks for this hint, and sorry for the hassle, but … as I tried to point out in the answer in the other thread: The OpenCL.DLL should always be that of the “newest” OpenCL installation, so manually entering any paths in the source code should not be necessary.

But I’m curious, and would like to avoid misunderstandings or possible hassles here.

  1. Did you install any OpenCL- or Graphics Card driver after you installed the Intel OpenCL SDK? (For example, an NVIDIA or AMD driver?). In this case, this installation might have overwritten the OpenCL.DLL with an older version. (It should not do this, but … who knows what the driver vendors are doing there … ;-))

  2. When you type
    dumpbin /EXPORTS C:\Windows\system32\OpenCL.dll
    at the console, does the list of exported names contain, for example clSVMAlloc (a CL 2.0 function) ? (I guess not - I assume that the DLL is simply one for OpenCL 1.2)

  3. I do not recommend to do this (although I would not hesitate to do it on my own machine - it should not cause any problem at all, but I don’t want to be blamed for anything ;-)) : On my machine, I would simply create a backup copy of the existing
    to something like
    and then plainly copy the
    to the
    directory, overwriting the existing one.
    Again: This DLL is only a “dispatcher” to the actual implementation DLLs. So everybody who needs the OpenCL.DLL should work as before with the newer one.

I tried copying C:\links\INTELOCLSDKROOT\bin\icd\x64\OpenCL.dll, to C:\Windows\system32\OpenCL.dll
And I could not get that to work.
Most of the system depends on the existing openCL.dll. System would not Init OpenCL

there are 3 platforms on my System
Intel® OpenCL, accessed by C:\Windows\system32\OpenCL.dll
NVIDIA CUDA accessed by C:\Windows\system32\OpenCL.dll
Experimental OpenCL 2.0 CPU Only Platform, (need to use C:\links\INTELOCLSDKROOT\bin\icd\x64\OpenCL.dll to access this, or start getting unsupported method errors )

hence, needed to work out how to load C:\links\INTELOCLSDKROOT\bin\icd\x64\OpenCL.dll
I brought a book on JNI., and started studying your c++ code
Eventually, I realized where you where you were loading the libary from , and how to specify a different library

what confused me, was that your dll does not depend on opencl.dll (according to the output from Dependency Walker (depends.exe) Home Page ),
I was expecting to see

c:\work3\opencl\mathfuncsdll_soln\mathfuncsdll\x64\debug\MATHFUNCSDLL.DLL (this was a DLL that I wrote)

but in your DLL

c:\opencl\java\jocl-0.2.0-rc-bin\JOCL_0_2_0-WINDOWS-X86.DLL (does not depend directly on OPENCL.DLL)

So, I was not sure how you implemented it, but had to study JNI, to work this out.

Anyway, your DLL works with C:\links\INTELOCLSDKROOT\bin\icd\x64\OpenCL.dll, and I can access Open Cl 2.0 functions
(as long as I use the JNI method,


And I could not get that to work.
Most of the system depends on the existing openCL.dll. System would not Init OpenCL

Can you explain that in more detail?
What happened after you replaced the (obviously out-dated) OpenCL.DLL with the (likely newer) one from your Intel SDK?

Also, did you install any drivers after installing the OpenCL 2.0 SDK?

I’d really like to understand what’s going on there, as the usage of JOCL should in the best case just be to “drop the JAR into the classpath”.

In any case, I’ll try to install the Intel SDK, probably early next week, to see if I encounter similar issues (it might also be that they messed something up with their installer).