Following some issues I talked about in a previous post [ http://forum.jogamp.org/Code-working-under-Snow-Leopard-but-not-on-Lion-td3296875.html ] I am trying to integrate the CLWork utility in my code, so that I don't have to manually take care fo LWS vs GWS optimizations.
I am looking at the sample code on your blog post here [ http://michael-bien.com/mbien/entry/many_little_improvements_made_it ] but as I try to integrate those changes it is not fully clear to me the context in which that code fits.
In particular I am not sure if I have to change the way I create the buffers etc. since in order to figure out the buffer size I am doing all sorts of rounding up etc. and it is my understanding that the CLWork utility will get rid of that kind of prestidigitation :)
Also, you mention in the blog post you took that code from unit tests, it would be helpful if you could point me to that too!
P.S. btw, it would be neat if you could integrate CLWork usage in the Hello JOCL example [ https://github.com/mbien/jocl-demos/blob/d3d8c548223ec79987d7326c808f830bc3f65813/src/com/jogamp/opencl/demos/hellojocl/HelloJOCL.java ] or at least give a hint of how that example can be changed to use CLWork if it's not asking too much :)
On 11/08/2011 06:32 PM, Giovanni Idili [via jogamp] wrote:
well it depends. If you do a bounds check in the kernel the buffer size
> Following some issues I talked about in a previous post [
> http://forum.jogamp.org/Code-working-under-Snow-Leopard-but-not-on-Lion-td3296875.html ]
> I am trying to integrate the CLWork utility in my code, so that I
> don't have to manually take care fo LWS vs GWS optimizations.
> I am looking at the sample code on your blog post here [
> http://michael-bien.com/mbien/entry/many_little_improvements_made_it ]
> but as I try to integrate those changes it is not fully clear to me
> the context in which that code fits.
> In particular I am not sure if I have to change the way I create the
> buffers etc. since in order to figure out the buffer size I am doing
> all sorts of rounding up etc. and it is my understanding that the
> CLWork utility will get rid of that kind of prestidigitation :)
does not matter much. In this case you can just allocate the buffer as
needed and round the work size up. Manually or using CLWork. The other
option is to create a larger buffer (rounded up once again) and use it
in a kernel without boundschecks.
> Also, you mention in the blog post you took that code from unit tests,
> it would be helpful if you could point me to that too!
> P.S. btw, it would be neat if you could integrate CLWork usage in the
> Hello JOCL example [
> https://github.com/mbien/jocl-demos/blob/d3d8c548223ec79987d7326c808f830bc3f65813/src/com/jogamp/opencl/demos/hellojocl/HelloJOCL.java ]
> or at least give a hint of how that example can be changed to use
> CLWork if it's not asking too much :)
yeah ;) i should update HelloJOCL or add a second variant.
- - - -
thanks for the clarification and the example, which was particularly useful.
I am slowly coming to grasps with this stuff :)
I am now trying to grab a more recent version of JOCL that includes the CLWork stuff - which one would you advise downloading?
I tried with downloading the most recent one that includes OSX [http://jogamp.org/deployment/autobuilds/master/jocl-b474-2011-11-08_12-16-26/] from the auto-build list but I see that it contains only the jocl jar/lib (as opposed to a whole bunch of other stuff such as gluegen as on older builds such as the one I am currently using) and if I try to substitute jocl.jar and libjocl.dylib to my current ones I get:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class com.jogamp.common.os.Platform
... being annoyed by dumb asses like me is one of the perks of running an open source proj :)
Best Regards and thanks for your help,
On 11/18/2011 02:15 AM, Giovanni Idili [via jogamp] wrote:
you could try the experimental branch but it uses different binding code which makes it incompatible to jogl.
downloads are at github
Builds are only uploaded if all junit tests are green but they shouldn't be seen as stable. The builds use classpath libloading by default, so you can simply put all jars (containing natives) into the classpath and be set for desktop deployment (which is another experimental thing).
|Free forum by Nabble - Scala forum||Edit this page|