So... who's ready for some OpenCL rendering in JUCE components?

Hi everyone,

So over the past few months I’ve been working on using OpenCL together with JUCE, and OpenCL and JUCE can render stuff together in real-time! Ray casting, marching cubes and all those fancy algorithms just came a step closer, or you could consider offloading your heavy computations to the GPU…

Using JUCE results into code with (at least IMHO) very little boilerplate, allowing you to really focus on what OpenCL is actually doing and making interactivity a breeze. I’ve gotten quite some questions on how to set this up and as such, I’ve made a small bare-bones example and am thinking of doing a full tutorial.

Right now it only works on MacOS, but seeing that actually setting up OpenCL took around 20 lines of code, I expect compatibility to be close to trivial. Is anyone willing to have a look at Windows/Linux before I publish it? I also have some questions about the way I set up OpenGL-rendering.

4 Likes

Wouldn’t it be much more appropriate to move to Metal on macOS and e.g. Vulkan on Windows?
I have done a bit of OpenCL stuff in the past on macOS and at that time Apple used outdated drivers and some of the new stuff didn’t work.

There’s an easy way to interop GL and CL on macOS but I think we must accept that GL is not the way forward at least on macOS. On Windows Vulkan is probably the best bet for all of the new stuff.

EDIT: Didn’t read this before but looks like Apple did not just deprecate OpenGL on 10.14 but also OpenCL.

Well the scope of Vulkan/Metal is slightly different from OpenCL, with the latter focussing on compute. I do want to make a similar example with Vulkan/Metal, which also offer context sharing. However, I first want someone with a little more in-depth knowledge of OpenGL in JUCE to have a look at whether the way I set up context sharing is at least somewhat sane.

OpenCL is the easiest cross-platform method to test this IMO. I realize OpenCL has been deprecated on MacOS, but so far it still works great (despite being stuck on 1.2). Metal is Mac-only and Vulkan is probably a lot more verbose in addition to not being supported on Mac (without resorting to MoltenVK).

The idea of this example is more to create an easy starting point for some experimenting, because many of the examples I found online weren’t exactly easy to setup let alone offer easy to customize interactivity.

I can’t see the value in putting any effort into something that’s been deprecated for the last 18 months on one of the most significant platforms out there for people writing Juce plug-ins/apps. It’s hard to know when it will disappear completely in macOS, but it will. What I am ready for is a viable cross-platform solution for GPGPU like we had in OpenCL. I can’t be the only person who has ideas that could be relevant to GPGPU, but just disregards them because writing it at least twice is so unappealing.

Well like I said, it is meant more to offer an easy way to start with OpenCL, a technique that is still very useful and has not gained enough traction IMO. I agree that basing an entire plugin on OpenCL might not be the most future-proof decision, but for things like prototyping I think it still offers the quickest iteration/experimentation times (Vulkan is way more explicit and verbose). There are plenty other areas where OpenCL is useful, while people might now be discouraged by the setup required (I know I was when I started). The example will give them some handles and offers one-click compilation with the Projucer.

Besides that, Vulkan/Metal/TheNextBigThing will still require an OpenGLContext to render stuff into JUCE components. How to create a persistent context has been asked several times before and I think I’ve found a way, but I want someone to check if I’m not doing something dangerous/stupid. If not, you could use this context to render using any GPGPU technique that your heart desires, including most likely Vulkan on Mac (through MoltenVK).