Closed GoogleCodeExporter closed 9 years ago
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 frost.g...@gmail.com
on 28 Oct 2011 at 2:58
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 andrea.a...@gmail.com
on 28 Oct 2011 at 3:16
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 frost.g...@gmail.com
on 28 Oct 2011 at 3:27
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 andrea.a...@gmail.com
on 28 Oct 2011 at 3:44
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 frost.g...@gmail.com
on 28 Oct 2011 at 4:14
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 frost.g...@gmail.com
on 28 Oct 2011 at 4:15
The configurable fallback sequence seems interesting, should I open a
enhancement request for it?
Original comment by andrea.a...@gmail.com
on 28 Oct 2011 at 4:20
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 frost.g...@gmail.com
on 28 Oct 2011 at 4:27
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 frost.g...@gmail.com
on 10 Nov 2011 at 7:24
Original issue reported on code.google.com by
andrea.a...@gmail.com
on 27 Oct 2011 at 1:22