binding 3rd party libraries

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

binding 3rd party libraries

notzed
Hi Michael,

I was looking into binding amd's clAmdFft library to java, and inter-operating with jocl naturally ...

Simple enough in the latter regard, except for CLEventList - IDs is inaccessible outside the library.  I can obviously just iterate the CLEvent's and build my own equivalent, but that seems non-ideal.  Any chance of it being exposed?

Incidentally clAmdFft uses size_t * in a few places, can I safely just assume that size_t is related to the platform pointer size?  I was going to create my own SizeTBuffer type or some-such to make sure, but JOCL just uses a PointerBuffer, and appears none the worse for it.

 Michael

PS good work on the api tweaks, although i'm pretty happy with it as is already.
Reply | Threaded
Open this post in threaded view
|

Re: binding 3rd party libraries

Michael Bien
  On 08/06/2011 11:57 AM, notzed [via jogamp] wrote:
> Hi Michael,
>
> I was looking into binding amd's clAmdFft library to java, and
> inter-operating with jocl naturally ...
>
> Simple enough in the latter regard, except for CLEventList - IDs is
> inaccessible outside the library.  I can obviously just iterate the
> CLEvent's and build my own equivalent, but that seems non-ideal.  Any chance
> of it being exposed?
so, you want to have access to (line 52)
     /**
      * Points always to the first element of the id buffer.
      */
     final NativeSizeBuffer IDsView;

problem is that if i would expose it and anyone would change the buffer
position (e.g unintentionally by iterating through it) the list would be
broken.
The variable is package private. Would it be OK for you to write a
utility and place it in com.jogamp.opencl to access the buffer?
buffer = Hack.get(events);

Or maybe you have a better idea how to solve that..

> Incidentally clAmdFft uses size_t * in a few places, can I safely just
> assume that size_t is related to the platform pointer size?  I was going to
> create my own SizeTBuffer type or some-such to make sure, but JOCL just uses
> a PointerBuffer, and appears none the worse for it.
I am using NativeSizeBuffer* in my repository for size_t to separate
both types (and other reasons). However if you want to stay compatible
with jogamp you probably better stick with PB.

>   Michael
>
> PS good work on the api tweaks, although i'm pretty happy with it as is
> already.
>
thanks. It should make a few scenarios less verbose (and therefore
easier to read which is often my goal).
The next blog entry will focus on actual features (concurrent package).

regards,
michael

*https://github.com/mbien/gluegen/blob/master/src/java/com/jogamp/common/nio/NativeSizeBuffer.java

--
http://michael-bien.com/

Reply | Threaded
Open this post in threaded view
|

Re: binding 3rd party libraries

notzed
Michael Bien wrote
The variable is package private. Would it be OK for you to write a
utility and place it in com.jogamp.opencl to access the buffer?
buffer = Hack.get(events);

Or maybe you have a better idea how to solve that..
Ahah, well that would probably do.  I figured you probably had a reason to hide it.

Michael Bien wrote
> Incidentally clAmdFft uses size_t * in a few places, can I safely just
> assume that size_t is related to the platform pointer size?  I was going to
> create my own SizeTBuffer type or some-such to make sure, but JOCL just uses
> a PointerBuffer, and appears none the worse for it.
I am using NativeSizeBuffer* in my repository for size_t to separate
both types (and other reasons). However if you want to stay compatible
with jogamp you probably better stick with PB.
Ok, thanks for the info.  I'm not too fussed which way so long as it works.

I'll let the list know if i end up finishing it off.

 !Z