(not open source).
public LLB (not recommended to use in most cases):
com.jogamp.opencl.llb.CL (exposes full core functionality)
com.jogamp.opencl.llb.gl.CLGL (exposes opengl extension)
HLB (recommended, thats what all the samples use):
the binding interfaces probably won't be public in the final release. CL
extends all binding interfaces and exposes therefore full functionality.
The binding interfaces represent the object model of the CL API which
will be needed internally. The last time i used LWJGL they did something
similar for GL which allowed easy composition of the
features/versions/extensions you where using in the app.
The edge branch is fully backwards compatible nothing has to be modified
in client code. (as i said before, impl detail)
edge -> experiments aka bleeding edge, use at your own risk
master -> main branch
On 05/30/2011 02:33 AM, Sven Gothel [via jogamp] wrote:
> Using multiple low level classes w/ a verbose suffix 'Binding'
> separating the CL API is IMHO too much.
> Especially since those llb classes are in the public namespace.
> A simpler approach IMHO would be to use JOGL's public API interfaces
> and to leave out some of the CL API methods if desired, hooking 'em up w/
> public manual methods which use those 'llb' ones.
> This would remove the public llb package and keep it all in one place
> com.jogamp.*.CLContext public API interface and
> jogamp.*.CLContextImpl private implementation
> Now we have 'CLContext' and 'CLContextBinding' in public,
> where the latter maybe be useful for the public .. or not.
> A one stop for a CL context might be easier and reduce confusion.
> If you reply to this email, your message will be added to the discussion below:
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, visit
they are only implementation details which simplify my current project