Mac OS X OpenGL deprecation

As can be read at https://developer.apple.com/macos/whats-new/, OpenGL is now deprecated in Mac OS X. I was wondering how this affects the future of JOGL on Mac. Would it, for example, be possible to change the native bindings to use Metal instead of OpenGL?

Hello

We plan to support Vulkan.

Anyone care to elaborate the practical implications...
Apple is deprecating OpenGL and OpenCL ...
Apple is not supporting Vulcan...

So what?

Are all OpenGL / OpenCL projects suddenly forced to abandon Mac?

I would have thought that some sort of OpenGL/CL -> Vulcan -> Metal bridge/layer would be developed by some community ? No?

Will this have any effect for jogamp users?

Is the world going to end when Apple removes OpenGL/CL support in some future MacOs release...
 

nyholku wrote

Anyone care to elaborate the practical implications...
Apple is deprecating OpenGL and OpenCL ...
Apple is not supporting Vulcan...

So what?

Are all OpenGL / OpenCL projects suddenly forced to abandon Mac?

TBD

nyholku wrote

I would have thought that some sort of OpenGL/CL -> Vulcan -> Metal bridge/layer would be developed by some community ? No?

There's MoltenVK (looks like Vulcan, but uses Metal underneath), I have the demos running on my Mac. But there are some stories that Apple disallowed some iOS apps from the Apple store that used MoltenVK. I guess if they play hardball, it's hard to understand the motivation for future dev of MoltenVK. But like Mongo, I'm just a pawn in the game of life. Who knows.

nyholku wrote

Will this have any effect for jogamp users?

Is the world going to end when Apple removes OpenGL/CL support in some future MacOs release...

Well I think it can be expected that applications employ JOGL (OpenGL for Java) will simply not work at some point in the future.

Wow, what does that mean exactly? A Java binding for Vulkan (may not help with OS X anyway), or the current Jogamp Java OpenGL binding which uses Vulkan under the hood? How would this happen, I had a discussion with an expert graphics developer who said "I've been working on Vulkan for half a year and I maybe understand half of it". Apparently, it's very low-level.

It means that there is a request for enhancement concerning a direct binding to Vulkan that would use only a part of JOGL in order to avoid reinventing the wheel, for example the windowing system (including NEWT) and some classes to manage the contexts.

Yes, Vulkan is very low level and harder to use than OpenGL and OpenCL.

Personally, if Apple decides to drop OpenGL completely and to prevent the use of Vulkan, I'll give up supporting OS X. I'm not interested in supporting an API only for Apple devices and Apple operating systems.

Finally, of course we'll need much more contributors to make it happen and using Vulkan will require some efforts. Don't expect your softwares to "magically" support Vulkan without effort with something that would expose OpenGL but that would rely on Vulkan.

So lets take a positive view of the situation.

Is Apple expecting everyone on the planet to rewrite their OpenGL/OpenCL code to use Metal if they want to support MacOS?

I doubt that, big players who need the oomph perhaps, even likely, but all the small players in non-gaming ... I doubt they will move to Metal as long as other platforms support OpenGL, they will simply drop MacOs and if OpenGL dies then they will likely move to Vulkan.

I doubt Apple wants or how could they event technically prevent Vulkan (in some form) from working on MacOs? On iOS yes (perhaps, not sure they could even do that) but I'm not interested in iOS.

My expectation is that Vulkan to Metal bridge will materialise in some form or other, for example and if jogamp supports Vulkan then that would solve this issue for many of the small players, right?

Of course only time will tell.

What about MoltenGL? Would it be rather a smaller task to support some subset of OpenGL in jogl with that? Personally I've moved all my jogl code to OpenGL 2.0 API so that would suit me perfectly...

Yes, supporting MoltenGL obviously requires a lot less work than supporting directly Vulkan but its licensing doesn't help whereas MoltenVK doesn't require a license.

If someone wants to investigate during a free trial period, I'll be able to help her/him to modify GlueGen so that JOGL finds MoltenGL's native library.

Thank you nyholky.

What about GLOVE?
https://github.com/Think-Silicon/GLOVE

GLO
https://github.com/g-truc/glo

Google ANGLE (OpenGL ES 2.0 support based on Vulkan in progress)
https://chromium.googlesource.com/angle/angle/+/master/README.md

Mesa Zink
https://gitlab.freedesktop.org/kusma/mesa/commits/zink

VKGL
https://github.com/kbiElude/VKGL

Well that looks promising, I had a quick look but will need to dive deeper to see which one looks most promising.

nyholku wrote

Is Apple expecting everyone on the planet to rewrite their OpenGL/OpenCL code to use Metal if they want to support
MacOS?

I think that's how most people are reading this:  https://developer.apple.com/macos/whats-new/

I doubt that, big players who need the oomph perhaps, even likely, but all the small players in non-gaming ... I doubt they will move to Metal as long as other platforms support OpenGL, they will simply drop MacOs and if OpenGL dies then they will likely move to Vulkan.

It's not so simple to say non-gaming small players will simply drop MacOS. OS X is very popular in the scientific community, but there's some indications that Linux is making a comeback there.

What about MoltenGL? Would it be rather a smaller task to support some subset of OpenGL in jogl with that? Personally I've moved all my jogl code to OpenGL 2.0 API so that would suit me perfectly...

But how would implementing only a subset of Desktop OpenGL impact Jogamp's Ardor3D and Java3D? Do these work with only OpenGL ES now? I wasn't aware of that. I think MoltenGL and the projects that Julien mention below are mostly related to ES?

Julien,

I'm willing to help with this, but if Java3D and Jogamp's Ardor3D can't with only the ES subset of full OpenGL, it's really a pointless endeavor to me.

Tom