Can I use jocl to draw some images on the screen?

GPU calculating really fast (0.1 ms) and i need to draw some image on the screen (with good FPS). To generate the image i need to some calculations and work with arrays for each pixel, and with CPU it runs with 15-20 FPS. I wanna use GPU, but if i will load data from GPU (~40 ms) after calculating i can make only 30-35 FPS. Can JOCL draw right away on the screen or an BufferedImage without CPU?

I don’t know if JOCL can, but I know that JOGL can do it via Framebuffers. If you can use DirectBuffers instead of Arrays in your calculations, you can do them via CPU and store the Results direct into the Framebuffer. But you also can do your calculations via shading.

1 „Gefällt mir“

That’s right: OpenCL/JOCL itself (as well as CUDA/JCuda) are not responsible for bringing pixels on the screen. But they both offer interoperbility with OpenGL/JOGL/LWJGL… for that matter.

A basic example for general OpenGL/OpenCL interoperability is shown in https://github.com/gpu/JOCLSamples/blob/master/src/main/java/org/jocl/samples/JOCLSimpleGL3.java (although your use case might be much simpler if done properly).

But you should really first check whether the drawing is really the bottleneck. A standard BufferedImage already is hardware-accelerated, and copying the data from an OpenCL memory object into the DataBufferInt of an ARGB BufferedImage should already be pretty fast…

Doesn’t OpenGL also offer a compute shader, with similar capabilities as OCL? OCL interoperability wouldn’t even be necessary.

Never worked with OCL but raw OGL is pretty complicated with lots of limitations and drawbacks to overcome. Arrays are one such a thing. There are many solutions, just a few Google-key words to search for:

  • Uniform arrays (easy but very limited static size | 1 dimensional)
  • Uniform buffer arrays (more complicated but bigger limited static size | 1 dimensional)
  • Shader Buffer Objects (way more complicated but dynamic size | 1 dimensional)
  • Textures and texelFetch() (way more complicated but huge dynamic size | 1-4 dimensional)

All in all I would try to avoid OGL if possible. Or get a rendering library that does all the low-level OGL stuff.

That’s also true. I remember that once there was a question about implementing Conways Game of Life (mentioned here, in German [OpenCL] AI Projekt auf OCL/GPU - Portierung möglich? ), and someone eventually did the implementation in pure OpenGL with compute shaders, and it turned out to be faster than the OpenCL version (There are no memory copies and mapping involved, and some further reasons).

Actually, Vulkan is the new kid on the block, with extensive compute support (but it might be hard to get started there…)