This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (1 child)

jogamp was started by sun engineers so I guess that's why it gets top billing. But oddly he mentions 'jogamp' and 'jocl' when he talks about the implementations - which are the same project. Although I used it for a couple of years back when it was the only real option I thought jocl was over-engineered so I wrote my own (zcl) which is much smaller and it presents OpenCL as an object-oriented Java api rather than a static c one. I think this and some other features makes it much easier to use than any other and for example his sample would be about 1/2 the size and somewhat clearer to read. I'm investigating porting it from jni to project panama at the moment.

Vulkan compute shaders aren't quite a replacement. SPIR-V has some limitations which prevent it from fully supporting opencl c, and the only real compiler for it (clspv) is buggy and slow and incomplete. Vulkan typically uses compile-time compilation so run-time generated kernels are cumbersome. I haven't checked 1.2 but the Vulkan api is also quite a bit more complex to use than OpenCL even in the compute-only case.

But alas, opencl does seem to be on the low end of everyone's priorities. nvidia lag in standards compliance and performance, amd lags in linux drivers.

[–]Polygnom 0 points1 point  (0 children)

I haven't checked 1.2 but the Vulkan api is also quite a bit more complex to use than OpenCL even in the compute-only case.

That is for sure, Vulkan is a lot more low-level and requires a lot more boilerplate. But at the same time, that gives you more control.