OpenGL Deprecated in Mojave


#1

Just going through the changelog for 10.14 after watching the Keynote for WWDC, and this jumped out at me. (Page 9.) Not a big deal in the short term, but plan accordingly…


GUI Drawing Efficiency
#2

Saw it too :confounded:
This is going to make supporting macOS a real burden for those of us who make heavy use of GL.

For me and a few other devs I know this would mean rewriting most of their graphics engine + shaders just for the purpose of supporting Metal - which Apple might decide drop in a few years time, who knows.
Or maybe make use of a kind of a ‘transpiler’ layer such as MoltenGL (paid) or Angle.
At this point I’d rather spend my time re-writing the graphics engine for Vulkan, which is truly cross-platform (apart from native macOS support which Apple won’t allow) and future-proof, and use the free open-source MoltenVK layer to run on Metal.


#3

I was wondering when this would happen. Is there anything third-party left on the OS?


#4

Any chance Juce will eventually support Metal for accelerating its own drawing like we can do now by attaching an OpenGL context to components? Or will we have to stop using this method to improve draw speeds in Juce on macOS?


Apple Depreciating OpenGL
#5

A while back Jules had mentioned rendering engines for Metal/Vulkan

Here’s hoping that’s in the works!


#6

Isn’t Vulkan + MoltenVK for macOS the way to go then for cross platform code ?


#7

Here’s the official statement -

https://developer.apple.com/macos/whats-new/#deprecationofopenglandopencl

Nothing like good ol’platfrom lock-in.


#8

If they’re happy to deprecate OpenCL which they designed and is also with Khronos why would something like Vulkan be any different in future? (Serious question, I am not familiar with the levels at which those APIs and metal operate so it might indeed be the logical way to go).


#9

Damm… Was just getting into OpenCL on mac. Wanted to learn it as FPGA’s and certain micro controllers are adopting it for writing kernels…

Played around with CUDA and like it a lot but it’s a pain having to support OpenCL and CUDA in applications and now will have to do all three to cover majority of hardware setups.

Need to look at this Vulkan API but then that’s yet another thing to learn. It’s a shame because OpenCL 2.0 seems to be more inline with CUDA’s approach. HPC in an audio context shouldn’t be this difficult.


#10

Same here, I wanted to start working on a OpenCL based DSP codebase that’s more or less fully portable to FPGAs in a few months, as I got the impression that Intel and Xilinx embracing this standard for their FPGAs would definitely drive the industry even more towards OpenCL. I see that OpenGL will probably get a lot more attention as it might affect more people, but has anyone heard of something like MoltenGL for OpenCL?


#11

I suppose it’s not going to change the fact the FPGA programming will still be OpenCL. I’m more bothered about having yet another thing to learn. Over the last year I have been working with a client in health tech making medical devices (one of which was an audio one) and working side by side with electrical engineers and going through the process of designing PCB and Programming the controllers. I know whats involved in producing my own hardware based DSP boxes.

I usually favour working off my MBP for C++ programming and It’s great being able to test OpenCL kernels in Xcode as they wire up well. Just a shame that there pulling it - knowing apple there’ll be an Xcode update and then you just can’t do this anymore


#12

Obviously, we will need to discuss exactly how we react to the news of Apple deprecating OpenGL. However, I would like to point out that for many JUCE apps, JUCE’s own drawing via the CoreGraphics renderer (default) is faster than via the OpenGL renderer on macOS. So the deprecation would not impact these apps.

Depending on your exact complexity of your GUI though, some apps may render faster via the OpenGL renderer. Also, if you are using any custom shader (like our NOISE app does), then the deprecation of OpenGL will be a problem.


#13

I would guess a lot of UIs probably don’t need it, but I find in macOS the more active areas of mine do render more smoothly with an attached OpenGL context and with lower background CPU consumption as well. So I will be following any developments with interest, thanks!


#14

I don’t expect that too. The workflow I had in mind was building something highly portable, e.g. developing a CL kernel that does the DSP work under Mac OS, creating a prototype application that runs the whole thing in real time on a PC with a powerful GPU and then move the more or less final application to an FPGA SoC where the kernel now runs on the FPGA while the rest of the application developed with JUCE runs on the ARM. This could really speed up the development of FPGA-powered custom embedded devices. For me this seemed to open the ability of taking the JUCE cross-platform approach one step further and really speed up embedded development. What you described sounds a bit similar to me.

I have to confess that this might be a quite special use case, but the portability aspect applies for OpenGL too. Now as it will affect a lot more people than OpenCL does there seem to be solutions to keep GL code still running on Mac OS, I‘d love to see for OpenCL too. Let’s wait what future will bring…


#15

All sorts of frequency plots are definitely much faster with OpenGL, compared to using JUCE paths.


#16

A single renderer engine would be greatly appreciated.
Sadly, current JUCE Renderer is only 2D and there’s no easy way getting quick 3D going with the exception of OpenGL… (which is also not that nice to write within JUCE :slight_smile: )

Might be worth investigating common gaming-engine with proper license to be incorporated as a single JUCE renderer engine with appropriate translations to the multiple standards out there.


#17

Unity’s 2D engine is superb…:smiley:


#18

I’ve been experimenting a lot lately with NanoVG and this https://github.com/ollix/MetalNanoVG, getting very good performance - it would be pretty simple to make a JUCE low level graphics context that drew via NanoVG and could use MetalNanoVG - however I’m sure jules and co have their own metal plans


#19

Would certainly be interested to see how that performs, and how difficult it is to link into existing projects.


#20

Would probably make more sens to have a vulkan renderer and MoltenVK on top for OSX