The same site that is hosting the JOGL project is also hosting Java bindings for OpenCL, JOCL? How useful is this for game programmers? What’s the advantage?
it depends what your goals are. OpenCL makes it very easy to use the GPU for number crunching tasks. You could use OpenCL for example for heightfield generation, texture generation, particle effects and similar brute force tasks.
(In past it wasn’t that easy, you would have to map a computational task to vertex/geometry/fragment shaders [which is not always straight forward] or use a proprietary language like cuda)
OpenCL programs are just in time compiled (see line 30 in the sample) and you can even run them on the CPU (e.g for as fallback mode) or on special hardware (exotic things like crypto accelerators).
youtube is already full of OpenCL particle effects demos… just search for it.
Sorry to barge in, but is OpenCL - JOCL also migrated to github?
not yet. The master JOCL repository is still hosted on kenai. This will change eventually.
bienator; I notice yours is not the only fledgling Java OpenCL binding. I’m sure you’ve noticed OpenCL4Java, which has some interesting looking integration with Scala.
I wonder if you’ve had any contact with the author, or if you have any comments about the two libraries etc.
yes already had a friendly mail conversation with the authors. There is even yet another binding with the same name ‘JOCL’, i was just to lazy to think of a different name. All three started around the same time, short after the first spec went public. But there are enough differences between all three in api design, technical design (JNI vs JNA), license etc. I will blog about it when i go public with “my” JOCL (or whatever it will be called).
I look forward to reading that.
Intel certainly seem to think so. With Larrabee, it might be most of the way around.
It also seems fairly clear that software needs to become increasingly parallelised to take advantage of the hardware; whether the hardware is something we call a graphics card or not. As developers, we need nice ways of dealing with that. I don’t know how significant OpenCL will prove to be ultimately (I hope to see some more friendly high-level abstractions built on it). It certainly seems to scratch an itch for a general purpose cross-vendor/platform tool to allow us to make best possible use of available hardware.
OpenCL is really a kind of “computational shader” which runs on the hardware of your choice. It abstracts many parts of the concrete hardware to be portable (computing units, local - global memory etc). The most important decision the implementer has to make is: data parallel or task parallel. Most GPUs are inefficient for task parallelism and CPUs don’t like data parallel problems.
higher level as those which are already available?
Good point about task vs data parallelism… CPU / GPU distinction becomes increasingly blurred, but this will indeed be the fundamental nature of each for the time being.
[quote]higher level as those which are already available?
[/quote]
Well, to be fair I still haven’t really properly cut my teeth with OpenCL (or CUDA or whatever), but as a general rule things can always be profitably driven to a higher level IMO. The work of making computer languages more natural and expressive should never be given up. Ideally, people shouldn’t need to be engineers in order to tell their computers what to do… they should be able to get in just as deep as they need to to express what they want to express efficiently, no deeper.
For now, I don’t know if the core hardware abstractions in OpenCL itself need to be higher level, I just mean it will take time for a range of useful higher level libraries to be built… for example, OpenMM is a promising library for molecular mechanics simulation; if my physics engine was replaced with that I might have GPU acceleration which would work on CUDA or OpenCL platforms without needing to actually get my hands dirty with either. As well as libraries such as yours, we need more of those kinds of things - I think that’s all I’m saying.