Aparapi won't work with Intel OpenCL SDK 1.5 about aparapi

[GoogleCodeExporter]

My guess is that this is an overly strict check. 

Although the check (now - after MacOS fix) should be checking the OpenCL 
version string and from the text above it should see the OpenCL 1.1 and be 
happy. 

Of course Intel's OpenCL will not work in GPU mode.  You should be able to make 
it work in CPU mode using -Dcom.amd.aparapi.executionMode=CPU.  The default is 
of course to run in GPU mode. 

Is it possible you were expecting GPU execution? Or were not requesting CPU 
mode?

Gary

Original comment by [email protected] on 28 Oct 2011 at 2:58

• Changed state: Accepted

[GoogleCodeExporter]

I was expecting CPU mode, but what I got is java threads mode instead. 
I actually tried with a svn checkout, but the native binaries were the ones of 
the latest release (2011-10-13)

Original comment by [email protected] on 28 Oct 2011 at 3:16

[GoogleCodeExporter]

Did you request CPU mode using -Dcom.amd.aparapi.executionMode=CPU or by 
setting Kernel.setExecutionMode(...) prior to first execution?

I should stress that there is no 'default to CPU' mode.  The default is to 
expect GPU and to drop back to JTP if GPU fails.  I considered dropping back to 
CPU if GPU is unavailable. 

Original comment by [email protected] on 28 Oct 2011 at 3:27

[GoogleCodeExporter]

Ah, brilliant, that works!
I was expecting it to enter in CPU mode automatically if GPU was not found.

It's quite a bit faster than JTP mode too. The mandel example reports:
- FPS 6 in JTP mode
- FPS 20 in CPU mode

It would be very useful if the code searched for the best possible mode 
automatically, so that one can distribute the software and have it find its 
best mode on the client machine without having to deal with system variable 
settings (thought having a way to force a specific mode is still going to be 
useful)

Original comment by [email protected] on 28 Oct 2011 at 3:44

[GoogleCodeExporter]

Glad that worked. I have seen a few applications where CPU outperforms JTP, but 
have also seen some where this is not the case.  Obviously Mandel is a great 
data-parallel example and so tends to demonstrate good parallel performance. 

Maybe the approach would be so allow the user to set a preferred fallback 
sequence for occasions where they know that CPU mode will help.

Something like. 

setFallBackSequence(Kernel.ExecutionMode.GPU_CPU_JTP)
setFallBackSequence(Kernel.ExecutionMode.GPU_JTP)
setFallBackSequence(Kernel.ExecutionMode.CPU_JTP)

Gary

Original comment by [email protected] on 28 Oct 2011 at 4:14

[GoogleCodeExporter]

Marking this as not a bug/defect. If anything it is an enhancement request to 
allow a fallback mechanism which tries CPU mode before JTP.

Original comment by [email protected] on 28 Oct 2011 at 4:15

• Changed state: WontFix

[GoogleCodeExporter]

The configurable fallback sequence seems interesting, should I open a 
enhancement request for it?

Original comment by [email protected] on 28 Oct 2011 at 4:20

[GoogleCodeExporter]

Sure.  I only have phone access here ;) if you open it as an
enhancement request I will track it from there.

Thanks.

Gary

Original comment by [email protected] on 28 Oct 2011 at 4:27

[GoogleCodeExporter]

The separate enhancement request allowing fallback from GPU to CPU and to allow 
fallback requests/polices to be requested is covered in issue #16.

Will close this as a duplicate.

Original comment by [email protected] on 10 Nov 2011 at 7:24

• Changed state: Duplicate