Allow access to clGetDeviceInfo

[GoogleCodeExporter]

We are at a point where we need access to a number of items returned by 
clGetDeviceInfo.

Operating without knowledge of the following parameter's return value in 
particular is really giving us grief:

CL_DEVICE_MAX_MEM_ALLOC_SIZE    

Return type: cl_ulong

Max size of memory object allocation in bytes. The minimum value is max (1/4th 
of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024)

Original issue reported on code.google.com by ryan.lam...@gmail.com on 7 May 2012 at 11:34

[GoogleCodeExporter]

http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetDeviceInfo.html

Original comment by ryan.lam...@gmail.com on 7 May 2012 at 11:41

[GoogleCodeExporter]

Ryan 

In the extension mechanism we can expose this via the Device type.  Would you 
consider testing your code and using the extension mechanism branch in the 
meantime?

Otherwise we run into the issue that we hide the chosen device until first 
execution. In which case you don't have the opportunity to query prior to first 
execute. 

One hack is to create a dummy kernel. Execute it, then query it to extract 
device info.  This would be fairly easy to hack together. 

At one time we allowed a 'callBack' to be registered which was called (from 
JNI) just prior to execution, this allowed the developer to query local/global 
size and could also be used to query device parameters. 

I think the answer is to clean this all up with the extension proposal. 

So the process would be:

Device device = Device.getSomeDevice(); // say first GPU, first CPU etc

This device can then be queried for parameters (getDeviceInfo keys)

We would also use the Device to act as a factory for a Range. Ensuring that the 
Range is always a valid size. 

device.createRange2D(width, height); // localWidth and localHeight will be 
suitable for the device.

Also we will use the device (instead of current ExecutionMode) to decide where 
to execute. 

Either 
kernel.setDevice(device);
kernel.execute(Range range, int count);

Or (preferrably) the range will capture the device that was used as a factory 
so we can still use

kernel.execute(Range range, int count);

I plan on merging parts of the extension mechanism to the trunk this week. How 
fast do you need this?  I am guessing fast...

Gary

Original comment by frost.g...@gmail.com on 8 May 2012 at 5:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm seeing strange behavior, it appears that if you request too large of a 
buffer, you will see the following in the console:

!!!!!!! Execution status of execute event failed out of resources
May 26, 2012 11:59:14 PM com.amd.aparapi.KernelRunner executeOpenCL
WARNING: ### CL exec seems to have failed. Trying to revert to Java ###

Interestingly, it also appears that each time you do this, the amount of buffer 
memory you can request decreases...?

The test I'm running increases the buffer request until the error above appears 
and then I record the settings. Strangely enough, the second time the test is 
run the buffer size until failure is much smaller. Rinse, repeat.

I wonder if it is just OS X.

Original comment by ryan.lam...@gmail.com on 27 May 2012 at 7:15

[GoogleCodeExporter]

I wonder if aparapi is failing to release resources in this situation 
(exception thrown). Essentially my concern is we are leaking GPU resources.  I 
will try to investigate. 

It would be interesting to create a pure OpenCL + C CPU Host code to vindicate 
the OpenCL runtime.

Gary

Original comment by frost.g...@gmail.com on 27 May 2012 at 1:36