OpenCLDevice#best not working

[GoogleCodeExporter]

Hi there,

I just switched over to a new computer. When running my program here I always 
get the following message for GPU execution: 

18.06.2013 14:18:43 com.amd.aparapi.KernelRunner warnFallBackAndExecute 
WARNUNG: Reverting to Java Thread Pool (JTP) for class 
gpu.abstraktion.aparapi.evaluation.MatrixMultiplicationLocal$LocalMemoryMatrixMu
ltiplicationKernel: GPU request can't be honored OpenCLDevice.best() returned 
null

As I saw in the source code, this can only happen if no OpenCL device can be 
found. However, this cannot be the reason as the computer here has got loads of 
graphics computing power (Quadro K5000 and two Tesla K20c). Cuda Toolkit 5.0 is 
also installed and other gpu abstraction frameworks recognize the graphics card.

Is the GPU too modern to work with Aparapi?

Thanks,
Matthias

Original issue reported on code.google.com by matthias.klass@gmail.com on 18 Jun 2013 at 12:23

[GoogleCodeExporter]

Hi,

I found out the reason (pretty fast ...)

Aparapi has to have the OpenCL library within the path. If putting the path 
there, everything works. Maybe another question here - would it be possible to 
specify the name of the OpenCL library? Currently, Aparapi looks for a 
"opencl.dll". 

For Nvidia the names of the library are "OpenCL.dll" and "OpenCL64.dll". Now if 
you want to use Aparapi, you either have to generate symlinks on Linux or to 
copy the files around, which is not very neat.

Matthias

Original comment by matthias.klass@gmail.com on 18 Jun 2013 at 12:32

[GoogleCodeExporter]

Matthias

I do not have much exposure to NVidia devices, but we have had users using 
NVidia for some time now. So I am suprised we are hitting this. 

Is this a windows machine (I assume so because you are listing dlls)? if so the 
OpenCL.dll name should match because windows is not case sensitive. You just 
need to set the directory in your PATH.

It sounds like you are suggesting that to use 64 bit aparapi, 64 bit JVM on a 
64 bit OS we may need to build against the OpenCL64.dll?  This seems to violate 
the opencl icd rules... We should not have to deal with this at build time.

Let me ask around to see how others fix this.  

Gary

Original comment by frost.g...@gmail.com on 18 Jun 2013 at 1:31

[GoogleCodeExporter]

I'm on a fresh install of Windows 7 64-bit with a 64-bit JVM and the x86_64 
version of aparapi, and an Nvidia GTX 560. I tried one of the samples and it 
worked in GPU mode. Using ProcMon, I was able to see what libraries it was 
loading. On my machine, it searches for OpenCL.dll first in the jdk\bin folder, 
then in c:\windows\system32 (and finds it there). The version of the file is 
1.1.

I did notice that if I use my trunk build which is set up to use OpenCL 1.2, it 
fails because it can't bind clEnqueueMarkerWithWaitList in opencl.dll, but I 
wouldn't think the pre-packaged dll would require this.

I poked around to see what versions of opencl.dll were on my machine. In 
windows\system32, opencl.dll was 64-bit v1.1. In windows\syswow64, it was 
32-bit v1.1. In C:\Program Files\NVIDIA Corporation\OpenCL, opencl.dll was 
32-bit v1.0, and opencl64.dll was 64-bit v1.0. I don't think these should be 
used, because libraries expect to find "opencl.dll" (which is why 64-bit apps 
are directed to system32, and 32-bit apps are directed to syswow64 (yeah the 
naming seems backwards)). And all versions of the file are from Khronos because 
the dll is not specific to a vendor.

If you could use a program like procmon and set it to filter events from 
java.exe, you might be able to see where it's looking for opencl.dll when it 
fails -- perhaps one of the nvidia specific directories took precedence over a 
standard one?

Original comment by paul.mi...@gmail.com on 19 Jun 2013 at 3:30

[GoogleCodeExporter]

Hm but if some folder took precedence over another, some library would have 
been found, wouldn't it? But Aparapi told me that no library could be found. In 
effect, it was ultimately found when I moved the OpenCL64.dll to a folder being 
in the PATH variable and renaming it to opencl.dll. 

@paul: I used the library from C:\Program Files\NVIDIA Corporation\OpenCL. When 
I'm back to this Windows machine I'll have a look whether I can find the file 
also in windows\syswow64.

Original comment by matthias.klass@gmail.com on 19 Jun 2013 at 9:57

[GoogleCodeExporter]

The message about the library not being found is misleading, in that it can't 
distinguish between the library (in this case, aparapi_x86_64.dll) not being 
found, from not being able to completely load it due to missing bindings, such 
as an improper version of opencl.dll. Though if you're using the precompiled 
dll, I don't know why that would be because it should work with v1.0 of 
opencl.dll.

I played around with replacing the copy of opencl.dll on my machine, and 
noticed that when it found a 32-bit version when expecting a 64-bit version, it 
would open and read the file, but it continued searching. But if I compiled a 
version of aparapi that needed OpenCL 1.2 and gave it a v1.1 file, it would 
stop.

If possible, could you induce failure and monitor the process with ProcMon (a 
Microsoft utility: http://technet.microsoft.com/en-us/sysinternals/bb896645 ), 
and see what copy/copies of OpenCL.dll it opens or tries to open? To use it, 
stop the capture with Ctrl-E (annoyingly, it begins capture as soon as you run 
the program), clear events (Ctrl-X), and add a filter: path excludes "opencl" 
then exclude. Then start capture and run your program. I'm on a different 
machine now, but running this here, I see:

CreateFile C:\jdk1.6.0_32\bin\OpenCL.dll (result NAME NOT FOUND)
CreateFile C:\Program Files (x86)\AMD\AMD APP Profiler\x64\OpenCL.dll (result 
NAME NOT FOUND)
CreateFile C:\Windows\System32\OpenCL.dll (result SUCCESS)

It doesn't seem to search beyond the version in system32, so I believe that's 
the one I'm using.

Original comment by paul.mi...@gmail.com on 19 Jun 2013 at 1:21

[GoogleCodeExporter]

(if there's a better way of logging this same information I'd like to know 
about it because while ProcMon is a great utility, this method is a bit of a 
hassle)

Original comment by paul.mi...@gmail.com on 19 Jun 2013 at 1:25

[GoogleCodeExporter]

I tend to use dependencywalker for this sort of thing. 

http://www.dependencywalker.com

My guess is that if we bring up aparapi_x86_64.dll in dependency walker, it 
should help locate the dependencies and how they will be resolved. 

Gary

Original comment by frost.g...@gmail.com on 19 Jun 2013 at 3:40

[GoogleCodeExporter]

Original comment by frost.g...@gmail.com on 7 Aug 2013 at 1:57

• Changed state: Invalid