Libgdx: Metal port since Apple is deprecating OpenGL

[riho]

Issue details

Apple announced that they're pulling OpenGL support (link and link). What would that mean for Mac and iOS support in LibGDX going forward? Since Vulkan support is off the table (#3344), would Metal support be unfeasible for the same reasons?

• [ ] Android
• [x] iOS (robovm)
• [x] iOS (MOE)
• [ ] HTML/GWT
• [ ] Windows
• [ ] Linux
• [x] MacOS

[badlogic]

We don't know when Apple is actually removing OpenGL. Metal is not feasible
for the same reasons as Vulkan: all of libGDX is based on OpenGL. We'd have
to essentially rewrite large parts of it. If someone wants to try that in a
fork, I'll be happy to check it out. Could be build on top of Sokol or bgfx.

On Tue, Jun 5, 2018, 7:11 PM Riho Peterson [e-mail] wrote:

Issue details

Apple announced that they're pulling OpenGL support (link
https://developer.apple.com/macos/whats-new/ and link
https://developer.apple.com/ios/whats-new/). What would that mean for
Mac and iOS support in LibGDX going forward? Since Vulkan support is off
the table (#3344 https://github.com/libgdx/libgdx/issues/3344), would
Metal support be unfeasible for the same reasons?

• Android
• [x ] iOS (robovm)
• [x ] iOS (MOE)
• HTML/GWT
• Windows
• Linux
• [ x] MacOS

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/5251, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAfYBG1YQFLUI8c1opi-XeaVYt6Z_kqgks5t5rvPgaJpZM4UbOIF
.

[barkholt]

Could we, when necessary, rely on a software implementation of OpenGL on top of Metal or Vulkan?

Something like what these projects have attempted?
https://github.com/doitsujin/dxvk (implements DirectX using Vulkan).
https://moltengl.com/moltengl/
https://github.com/g-truc/glo

[badlogic]

We could, and especially for our 2D use cases something like MoltenGL would
do just fine. Another alternative would be ANGLE, which I'm sure will have
Metal support soonish. If not, then ANGLE serves as a good canary for when
Google thinks it's time to switch from OpenGL to Metal to implement WebGL.

On Tue, Jun 5, 2018, 10:51 PM Michael Barkholt [e-mail]
wrote:

Could we, when necessary, rely on a software implementation of OpenGL on
top of Metal or Vulkan?

Something like what these projects have attempted?
https://github.com/doitsujin/dxvk (implements DirectX using Vulkan).
https://moltengl.com/moltengl/
https://github.com/g-truc/glo

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/libgdx/libgdx/issues/5251#issuecomment-394855742, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfYBC2d47I5VscvOGoEjwYSTvwK_kOgks5t5u9NgaJpZM4UbOIF
.

[noblemaster]

I also think writing a wrapper, similar to MoltenGL, is most feasible. We'd have to (1) map function calls and also need a way to (2) convert shader code to Metal. Mapping the function calls is probably the easy part. The shader code is harder to do but not impossible. From what I saw, the RoboVM library supports calling the Metal API already (?), it's just a matter of us actually using it.

Also, similar to what badlogic said, I do not think converting libGDX to Vulkan makes a lot of sense. Vulkan is (a) even less supported than OpenGL and (b) what functionality does it offer that we really need that isn't supported in OpenGL already? OpenGL has its quirks, but besides that, it generally does what it does pretty well. In addition, if libGDX sticks with OpenGL (for better or worse), given the "simplicity" of OpenGL, I think we should be able to create and maintain wrappers for any upcoming future graphics APIs forever.

Another possiblity is to use MoltenGL. It's not free at the moment, but who knows, it might get open sourced also?

What OpenGL deprecation concerns: it's possible that OpenGL is there to stay. But given Apple's plans to allow iOS apps to run on Mac OS X, this might happen early rather than later, i.e. as in 2019!

[julienvillegas]

@noblemaster, in regards to your point about Molten and converting shaders : "_(2) convert shader code to Metal. Mapping the function calls is probably the easy part. The shader code is harder to do but not impossible._"

According to MoltenGL product factsheet:
"_MoltenGL will automatically convert your GLSL shaders to their MSL equivalents. This can be done transparently at run time, using the Runtime Shader Conversion feature of MoltenGL, or at development time using the offline MoltenGLShaderConverter development tool, provided with MoltenGL._"

So that´s quite good for us.. That said Molten is not free.. $149 per user. so I am not sure it would even be an option-

[noblemaster]

Yes, MoltenGL is definitely an interesting option. Given it costs $99/year to release on iOS, I think the 1x $149.- isn't that much of a problem. I am just wondering how easy it will be integrate into the libGDX iOS backend?

[Stellarspace]

@badlogic Apple decided that it would be best to solder all of the components of the Macbook Pro to the logic board and you think that Apple won't remove OpenGL in macOS 10.15? Apple is all about proprietary software. macOS 10.14 will be the last operating system to support 32-bit applications. They gave developers a longer time to move away from 64-bit, but they didn't give developers time to move away from OpenGL because developers weren't developing games for the platform in the first place.

[NathanSweet]

@Stellarspace He said, "We don't know when Apple is actually removing OpenGL.", which is true. Your example doesn't change that.

[Whiteseeker]

Maybe one day https://github.com/google/angle will help ^^
"Support for translation from OpenGL ES to Vulkan is underway, and future plans include compute shader support (ES 3.1) and MacOS support."

[kakashidinho]

It might be a little late but I'm adding Metal support to ANGLE. It will eventually be in the official ANGLE repo, however currently the integration process is quite slow due to their code review process. ANGLE already merged my skeleton Metal backend code. However the full implement is still not merged yet. The full implementation is still in my own repo here https://github.com/kakashidinho/metalangle

The current implementation status is basically completed for ES 2.0 level. It passed ANGLE's built-in tests. If anyone interested in trying to use it with libgdx, it will be much appreciated. I will need a large project like libgdx to use it to see how it performs as well as potential bugs.

[kakashidinho]

I’m trying to test libgdx with ANGLE metal port. I saw libgdx has an es 3.0 module for ios. Is it required atm?

[noblemaster]

I don't think ES 3.0 is that important(?). I am using ES 2.0 myself. If you can test integration, that would be great :) 👍

[davidgiga1993]

Is there any update on this? An angle backend for libgdx would be very nice! I'm happy to test some ports.

[kakashidinho]

Although I am not familiar with libgdx much, but I think libgdx needs RoboVM/MOE to setup the GL views and contexts. So in order to integrate with angle, a RoboVM/MOE binding has to be made for angle first.

[davidgiga1993]

I'm currently integrating EGL in the lwjgl3 backend of libgdx using angle. I'm not sure what exactly needs to be done for robovm to work with angle

[kakashidinho]

I think lwjgl3 (EGL) backend can be used directly on macOS. iOS though needs robovm binding.

[davidgiga1993]

OSX will also deprecate openGL sooner or later, so it makes sense to switch to angle for the desktop version as well. I've got a working POC for lwjgl3 using angle in my fork: https://github.com/davidgiga1993/libgdx/tree/google-angle/glestest/src/main/java/com/mygdx/game

[NathanSweet]

Let's hope Mac users will abandon OS X once all their OpenGL apps stop working.

[obigu]

This looks promising, Google ANGLE seems right now the best approach to protect libGDX against future OpenGL deprecations. We already have a working POC on lwjgl, on Android it should be straightforward being a Google project (and it will be part of Android 11) and we can expect a Metal backend will be ready before Apple drops support. It also has @badlogic blessing (at least in 2018) which is always great :).
@kakashidinho I'm interested on this, if you want, for RoboVM/MobiVM bindings we can start a discussion in MobiVM Gitter channel (https://gitter.im/MobiVM/robovm) to see what it would trake.

[kakashidinho]

I'm not sure if this is the place to ask for robovm issues. But currently I'm not even able to run the gdx-tests-iosrobovm module with default gdx-backends-robovm backend. It keeps saying:

java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
    at com.badlogic.gdx.graphics.glutils.VertexBufferObject.<init>(VertexBufferObject.java:69)
    at com.badlogic.gdx.graphics.Mesh.makeVertexBuffer(Mesh.java:145)

[obigu]

@kakashidinho Please ask the question in the Gitter channel I've linked on my previous comment for RoboVM related stuff. Thanks!

[kakashidinho]

Thanks, I will ask there also. Just that I'm not sure whether this is robovm issue or libgdx's configurations issue.

[crykn]

Hey @kakashidinho, sorry to bug you, but have you ever gotten the ANGLE stuff working for iOS?

[kakashidinho]

Hey @kakashidinho, sorry to bug you, but have you ever gotten the ANGLE stuff working for iOS?

No, I encountered some errors when compiling lingdx + robovm for iOS which I haven’t managed to find the root cause yet. Will retry some day