JOCL OpenCL 1.1 support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JOCL OpenCL 1.1 support

Michael Bien
Hello everyone,

I forgot to mention on this list that JOCL already supports OpenCL 1.1 since the release day.

There is only one minor incompatible change:
CLCommandQueue.setProperties(...) does no longer exist, since it has been deprecated in 1.1 for good reasons (race conditions etc).
(http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clSetCommandQueueProperty.html)
If you was using this method you might consider using multiple specialized queues, e.g one in-order and one out-of-order queue instead of switching the properties of one queue at runtime.

So we decided to remove it instead of introducing profiles like in JOGL for now. Profiles might appear later to solve more severe incompatibility issues in future OpenCL releases.

I will update the high level binding to better expose the new functionality the next days.

best regards,
michael
Reply | Threaded
Open this post in threaded view
|

Re: JOCL OpenCL 1.1 support

jcpalmer
Ah, that does kind of suck.  I am not making property changes to change out of order, but to toggle CL_QUEUE_PROFILING_ENABLE in order to determine optimum kernel group size first time / or when hardware/driver changes are detected since the last run of the program.

I do not remember, but I thought just leaving profiling turned on was a slight performance hit.  Guess I should re-test that. I never submit commands to a given queue on more than one thread or change this while something is queued, but of course one cannot assume this is always done by everyone.
Reply | Threaded
Open this post in threaded view
|

Re: JOCL OpenCL 1.1 support

Michael Bien
Hi Jeff,

hmm. haven't thought about profiling. But maybe it would work for you to call queue.finish() and switch to a new queue with profiling enabled?

It seems like the reason why its deprecated (and basically untested in 1.1) is to simplify the drivers.

quote from Khronos headers:
/*
 *  WARNING:
 *     This API introduces mutable state into the OpenCL implementation. It has been REMOVED
 *  to better facilitate thread safety.  The 1.0 API is not thread safe. It is not tested by the
 *  OpenCL 1.1 conformance test, and consequently may not work or may not work dependably.
 *  It is likely to be non-performant. Use of this API is not advised. Use at your own risk.
 *
 *  Software developers previously relying on this API are instructed to set the command queue
 *  properties when creating the queue, instead.
 */

That warning convinced me to remove it... Given how unstable the drivers are (esp in corner cases) we decided to not expose untested APIs :)

Adding it again is basically a #define CL_USE_DEPRECATED_OPENCL_1_0_APIS in resources/opencl.h and it should appear in the low level binding again.

regards,
michael



On 06/16/2010 06:56 PM, jcpalmer [via jogamp] wrote:
Ah, that does kind of suck.  I am not making property changes to change out of order, but to toggle CL_QUEUE_PROFILING_ENABLE in order to determine optimum kernel group size first time / or when hardware/driver changes are detected since the last run of the program.

I do not remember, but I thought just leaving profiling turned on was a slight performance hit.  Guess I should re-test that. I never submit commands to a given queue on more than one thread or change this while something is queued, but of course one cannot assume this is always done by everyone.


View message @ http://jogamp.762907.n3.nabble.com/JOCL-OpenCL-1-1-support-tp899589p900353.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.