Details here. A working build should be up soon, I could use more people testing it. Crash reports and/or API feedback will be appreciated.
congrats. Java has now the fourth CL binding…
[quote=“bienator,post:26,topic:34594”]
Why on earth would that be your first reply.
Do I need to remind you JOGL was the ‘fourth’ GL binding?
@spasi Thanks for quoting me since i still fully agree with it, despite the fact that its a bit off topic here.
Let me try to explain why:
CL bindings are completely independent libraries. You (as a LWJGL contributer or user) could have the choice between Marco’s jocl.org which looks similar to LWJGL’s API, Olivie’s JNA bindings or http://jocl.jogamp.org which has similar API design as JOGL/JOAL on the low level (lets ignore the high level bindings for now since differ a bit more).
CL-GL interoperability is just about sharing 2 longs at context creation - thats all.
Nonetheless (or even because of that 
), i am very carious to take a look at the javadocs of the low level part (we call it LLB).
@Riven
sorry, don’t get it what you want to tell me with the first sentence
happy coding!
Hi!
You’re going to duplicate efforts once again whereas OpenCL is quite young (unlike OpenGL), it could have been an opportunity to concentrate all efforts on a single binding (forget the 2 other ones that will be given up in some years). We are doing the same mistakes… I don’t think choice is always a good thing.
The difference with OpenGL is that LWJGL and its main competitor are quite “old” which drives any merge complicated whereas we could have joined our forces to develop and maintain a single powerful and coherent OpenCL binding from the beginning.
Good luck.
sigh could you all please stop this?
just get along or shut up. if they want to duplicate effort, what the heck. everybody can do what he wants with his time. let everyone work on their favorite project or use whatever they want. either join one party or the other. let spasi etc talk about LWJGL, let julien etc talk about JOGL.
either, or both will survive or die in the end and it absolutely does not matter what opinion any of us has on the quality or api or development model or whatever of them. learn from, or ignore eachother - but please stop this “kindergarden”.
Congrats, Spasi et. al! This is a big milestone for you guys.
so… what was your excuse :
NIH FTW!
Cas
Are you kidding?
There was no JNI based binding out there at this time. Even drivers weren’t officially available. Both, Marco and me had to wait for the driver release before publishing binaries & code. He decided to code everything by hand, I instead used gluegen to generate everything from headers. Additionally Marco initially licensed his stuff with a non commercial license (he changed the license recently to MIT/X11).
This alone was a showstopper for my needs over one year ago. (and yes we worked together to resolve technical issues)
(thats my last post on that topic)
Can’t say I agree with you guys. Having OpenCL in LWJGL means one less DLL I have to bundle with my engine. It will also integrate neatly into the already existing OpenGL renderer with buffer sharing and all.
Also this having the LWJGL brand I can trust them to have a good and clean API that works.
I’ve been reading up on openCL and I’m nearly convinced. It makes a lot of sense to use the GPU to do the donkey work, and to have that tied in with the lwjgl package. So, hey, this is a really good addition to lwjgl - a new tool (which I don’t fully understand yet) which could turn out to be a big asset in time. ATM I’m wondering: ‘how many cards support openCL?’ but then I distrusted openGL generally - until minecraft made it real!
Thumbs up!
fwiw, opencl can run on either the gpu or cpu - sort of a “hardware fallback”.
OpenCL running on the CPU is not simply a fallback*. The OpenCL programs you write are not only automatically multithreaded when they run; they’re also automatically vectorized. The compilers can do that because of how the OpenCL C language is defined, the same way that multiple actions in your GLSL shaders can be converted to e.g. a single MAD instruction on the GPU. I don’t know about you, but I think being able to write cross-platform code that gets automagically converted to SSE2/AVX instructions and whatnot, is a big deal. Especially for us poor Java developers, it’s the huge opportunity we’ve been waiting for.
Of course, that’s all assuming Intel releases their implementation soon enough and AMD improves Stream’s one. Btw, with the OpenCL ICD (that AMD already supports) you can mix-and-match OpenCL platforms. So, for example, a computer with an Intel CPU and an AMD GPU will be able to use Intel’s implementation for CPU algorithms and AMD’s one for GPU stuff.
- Arguably, an algorithm designed for GPU execution will probably perform horribly on the CPU. So you might as well provide an alternate (non-OpenCL?) implementation anyway.
Hmm, just found this in today’s dev newsletter from AMD:
[quote]Aparapi is an API for expressing data parallel workloads in Java and running those workloads on a compatible GPU if possible. Where your workload actually ends up running depends on
* whether you have the ATI Stream SDK installed
* whether you have a compatible GPU
* whether your Java parallel code avoids any constructs that would make it untranslatable to OpenCL™. These restrictions are detailed in the Aparapi Readme file.
If your code and your target platform meet all of the above, Aparapi will translate your workload to OpenCL™ and will run your workload on the GPU. Otherwise, your same code will still run as a parallel workload using a Java Thread Pool and will be able to take advantage of multiple cpu cores if you have them.
[/quote]
wow that sounds pretty cool, looking forward to see how it turns out.
That’s kinda interesting… I was also prototyping with this sort of thing. But I did it in the bytecode level, which, by virtue of being low-level, doesn’t have some of the odd limitations of this API. (e.g the a[i++] = b[i++] thing for example)
I guess that in the future there would be workarounds for various Java features to be converted into OpenCL code that had the same effect but used different ways of doing it.
so basically, Aparapi is a threadpool executor - that may or may not translate some or all of the code to run on OpenCL if you happen to have a compatible dll with a compatible gpu.
color me unimpressed.
The lack of control on whether or not it will run in java or opencl is a pretty big issue. From my point of view, you’d be better of using ExecutorService and then having OpenCL tasks inside (which is basically what Aparapi is doing anyway (sans the bytecode translation))