Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Metal port since Apple is deprecating OpenGL #5251

Closed
3 of 7 tasks
riho opened this issue Jun 5, 2018 · 25 comments · Fixed by #6681
Closed
3 of 7 tasks

Metal port since Apple is deprecating OpenGL #5251

riho opened this issue Jun 5, 2018 · 25 comments · Fixed by #6681
Labels
desktop

Comments

@riho
Copy link

riho commented Jun 5, 2018 •
edited by noblemaster
Loading

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
  • iOS (robovm)
  • iOS (MOE)
  • HTML/GWT
  • Windows
  • Linux
  • MacOS
@badlogic
Copy link
Member

badlogic commented Jun 5, 2018 via email

@barkholt
Copy link
Contributor

barkholt commented Jun 5, 2018

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
Copy link
Member

badlogic commented Jun 5, 2018 via email

@noblemaster
Copy link
Member

noblemaster commented Jun 6, 2018 •
edited
Loading

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
Copy link
Contributor

@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
Copy link
Member

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?

@Mactastic1-5
Copy link

@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
Copy link
Member

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

@sistr22
Copy link

sistr22 commented Oct 5, 2018 •
edited
Loading

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."

@chrisdembia chrisdembia mentioned this issue Nov 13, 2018
Open
@kakashidinho
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

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

@kakashidinho
Copy link

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
Copy link

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
Copy link

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

@davidgiga1993
Copy link

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
Copy link
Member

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

@obigu
Copy link
Contributor

obigu commented Apr 20, 2020

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
Copy link

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
Copy link
Contributor

obigu commented Apr 20, 2020

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

@kakashidinho
Copy link

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

@crykn
Copy link
Member

crykn commented Oct 5, 2020

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

@kakashidinho
Copy link

kakashidinho commented Oct 6, 2020 •
edited
Loading

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

@davidgiga1993
Copy link

Anything working with metal? I somehow have the feeling that apple will deprecate openGL faster now that they have full control over the chips used by all their devices

@Berstanio Berstanio mentioned this issue Jul 10, 2021
Open
@Berstanio Berstanio mentioned this issue Oct 14, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
desktop
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add new MetalANGLE backend (ios/robovm) Berstanio/libgdx