GPUImage2
GPUImage2 copied to clipboard
BradLarson
Bye Bye GPUImage - Apple is Deprecating OpenGL ES
Source: https://developer.apple.com/ios/whats-new/
Deprecation of OpenGL ES Apps built using OpenGL ES will continue to run in iOS 12, but Open GL ES is deprecated in iOS 12. Games and graphics-intensive apps that previously used OpenGL ES should now adopt Metal.
Metal is designed from the ground up to provide the best access to the modern GPUs on iOS, macOS, and tvOS devices. Metal avoids the overhead inherent in legacy technologies and exposes the latest graphics processing functionality. Unified support for graphics and compute in Metal lets your apps efficiently utilize the latest rendering techniques. For information about developing apps and games using Metal, see the developer documentation for Metal, Metal Performance Shaders, and MetalKit.
More will be forthcoming regarding this.
There's still going to be good reasons to use OpenGL / OpenGL ES to target older devices, Linux, and other targets, but yeah, the writing has been on the wall for a while.
@xaphod as an alternative there is MetalPetal framework that uses Metal for rendering filters. Altho it would be great to revamp GPUImage.
Has anyone tried using Molten for graphics yet? I'm curious what a "GPUImageX" might look like if it was written for Vulkan and used Molten to translate calls to the appropriate graphics API depending on the age and device platform. For example old iOS (OpenGL ES), new iOS (Metal), Linux (Vulkan), or Windows (Direct3D). This would allow Swift programs to work everywhere without sacrificing performance. I'm not sure if this is exactly what Molten delivers though.
@BradLarson do you mean an update regarding a new version of GPUImage, or continuing forward supporting OpenGL?
So this is what I was hinting at:
https://github.com/BradLarson/GPUImage3
I'm working with Janie Clayton to translate all of GPUImage 2 to Metal, building it as an OpenGL-free project to avoid deprecation notices but maintaining API compatibility with GPUImage 2. Ideally, the two frameworks will be interchangeable and require no adjustment in code on the application side.
We figured that a separate, but parallel, version of the framework would be the best way to handle this so that those who need OpenGL (ES) can continue to use this and those who want to transition to Metal can use GPUImage 3 with minimal effort on the developer side.
Envisioning a future version of iOS that fully ends support for OpenGL, this creates 3 classes of devices:
- those that support only OpenGL (old iOS version and/or old chipset)
- those that support either OpenGL or Metal
- those that only support Metal
Is the idea that a single app can link to both libraries and use GPUImage3 when possible or GPUImage2 as a fallback, as decided at runtime? Or would the developer need to release two versions of the app that link either to GPUImage2 or GPUImage3 and then rely on the App Store to distribute them correctly?
@mblaughton - The case of supporting either is something we're debating right now. We want to have a pure Metal version of the framework, to avoid OpenGL deprecation warnings and errors. We also want to support OpenGL for those who need it. Having both in one version of the framework probably isn't going to be practical, due to the internal architecture differences between the two rendering APIs.
One possible way of handling this would be to give the modules different names ("GPUImage" and "GPUImage3", for example). A runtime check could be performed for Metal device support in GPUImage3, and based on that the application could use two different paths for rendering, relying on module namespaces. For example, GPUImage.Camera or GPUImage3.Camera instead of Camera.
For now, we figure that people who want backwards compatibility will stick with GPUImage 2 and OpenGL (ES) and those who want a pure Metal solution will jump to GPUImage 3. We'll have to see where any performance or capability advantages are in the Metal version to see if it's worth it to use Metal where you can and OpenGL for the rest. This will require some experimentation.
Very happy to hear this. Your support is very much appreciated as always.
Does this mean that for GPUImage3 we will write our shaders/filters directly in Metal / CIFilter etc.. ? No GLSL i guess?
I read Molten SDK has a translator from GLSL to Metal. Anyways... i think we all should start learning Metal from scratch. On Jul 13, 2018, 14:27 -0500, Josh Bernfeld [email protected], wrote:
Wow @BradLarson @RedQueenCoder very impressive! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
@omarojo - Yes, the shaders will be in .metal files using the Metal Shading Language. Some of the operations may also have parallel paths that can use built-in Metal Performance Shaders, as available.
Rather than using machine translation, we'll be rewriting these by hand to craft them to be readable and well-organized. Things like uniforms and varyings have completely different forms in OpenGL and Metal, so I think it's best to rewrite to fit a native style. Hopefully, the project will serve as a useful public comparison of common OpenGL shaders vs. their Metal equivalents. A public repository of shaders can be handy by itself.