Graphics backend for opengl and metal

Another solution is that, no matter using SLES 1 or SLES 3.1, pass both name and location in the API, and use name in GLSL 1, and use location in GLSL 3.1. And the shader looks like

#ifdef METAL
layout(location = 0) in vec3 position;
#else
varying vec3 position;
#endif

The codes to set attribute look like

// name is used in GLES 2.0
// location is used in metal( GLES3.1 -> spir-v -> metal)
commandBuffer->setAttribute(name, location, value);

Yeah, I would think you’d just query by name in ESSL 1.0 and specify location in Metal.

In ESSL 1.0 you can only set the attribute location via GLES code. Like this:

glBindAttribLocation(your_program_handle, attributeIndex, "position");

Note that this has to be called before linking the shader program together, or else the new attribute location wouldn’t be visible/used.

Also @zhangxm, if the shader code you posted with the #ifdef METAL preprocessor block, is that of a vertex shader, it has to be attribute vec3 position instead of varying vec3 position. The varying keyword in ESSL 1.0 is only used fpr vertex shader outputs and fragment shader input

Yeah, the ESSL 1.0 shaders & code are already written and exist in the engine.

Default Attribs: https://github.com/cocos2d/cocos2d-x/blob/b26e1bb08648c11a9482d0736a236aebc345008a/cocos/renderer/CCGLProgram.cpp#L321 .

Custom Attribs: https://github.com/cocos2d/cocos2d-x/blob/b26e1bb08648c11a9482d0736a236aebc345008a/cocos/renderer/CCGLProgram.cpp#L546 .


Good to note in case it was a mistake, and to be aware of while working on this.

It’s also possible it was from shadow shader. Or just a test shader that passed position into the fragment shader.
https://github.com/cocos2d/cocos2d-x/blob/b26e1bb08648c11a9482d0736a236aebc345008a/tests/cpp-tests/Resources/Sprite3DTest/simple_shadow.frag .

@Darinex thanks for the information. Yep, the varying is a mistake, good catch.
@stevetranby thanks, i will be aware of it.

As i saw, an metal backend was implemented in cocos2d-objc a long time ago. Can some of it source code be useful?

Another option for 3rd party renderer:

1 Like

I created another ticket to update the progress of the design: Progress of new backend API.

1 Like

[ignore this: personal post as bookmarked reference]

Since the real discussion has moved I figure I’d write a final reply as a collection of options for anyone who wants to write OpenGL or use a game/app that renders using OpenGL and run it on a platform that only has Vulkan/Metal/DX HAL drivers.

Projects

Cocos2D w/new Backend (zhangxm / cocos team writing native Metal backend)
** major benefit is native perf (depends on date completed, rest should be usable today w/unknown perf hit)
Progress of new backend API .

ANGLE - OpenGL ES 2.0 -> GL 4 (desktop), WebGL, DX9, DX11, Vulkan, ES 3.1, and “soon” Metal
https://chromium.googlesource.com/angle/angle .

Zink - OpenGL -> Vulkan
Uses MESA software rendering lib/framework and acts as Proxy to Vulkan rendering.
https://www.kusma.xyz/blog/2018/10/31/introducing-zink.html .

MoltenGL - OpenGL -> Metal (unknown pricing for license(s))
https://moltengl.com/ .

MoltenVK - Vulkan -> Metal - Open Sourced by Khronos Group
** usable to use as MacOS backend for Zink or ANGLE(vulkan) with unknown perf hit
https://github.com/KhronosGroup/MoltenVK .

Others Rendering/Game Engines
https://github.com/google/filament .


Self link back to reply listing shader porting reference:
Graphics backend for opengl and metal .

1 Like

Why just don’t use Metal at first and then adopt everything?
Apple is a leader in this, doing something with compromises and not natively for their platform could lead to low quality of the product and performance. What do you think about that?

They (the Cocos dev team) are doing native Metal first, and the discussion has moved to another topic.
Progress of new backend API .


My interest in other options is for both cocos2d games that can’t upgrade to 3.18+ for whatever reason, other games/apps that are currently written in pure OpenGL. Mostly it’d be useful for inactive projects whether old game, a toy/demo project, or say a GUI library you want to use that are written for GL.

It’d take little effort to get running with one of these proxy layers, whereas it may take many weeks to port the rendering code over to run on Metal/Vulkan/DX drivers.

If you replied about new projects then yes you’d start with Vulkan or Metal or DX12 depending on your desired set of release platforms. Or for full cross-platform games you’d just use Unity/Unreal and not worry about this topic. Cocos2d-x will eventually be an option once the Metal and Vulkan rendering back-ends are completed.

(I could’ve posted this in my own private notes, but decided here on the off chance someone finds it useful)

Just for the sake of completeness (or maybe added by someone else somewhere else)

oryol renderer:

the forge:

Just F.Y.I.
I have implemented “Angle running on top of MoltenVK” solution as part of another game engine.

You can try it out:
git clone -b angle-vulkan https://github.com/elix22/Urho3D.git

I have created 4 scripts that will create for you the Xcode projects with all the samples:

cmake_ios-metal.sh - will create an iOS Xcode project using the metal backend (my work)
cmake_ios-gles.sh - will create an iOS Xcode project using the default OpenGL-ES backend
cmake_xcode-metal.sh - will create an Mac Xcode project using the metal backend (my work)
cmake_xcode-gl.sh - will create an Mac Xcode project using the default OpenGL-ES backend

For the Metal projects , In order to get the best performance you will have to modify the scheme to release build configuration and also disable metal API validation .

Everyone is free to use it for any purpose
I will Appreciate your feedback , a specially if you try it on iOS device.

Enjoy!

2 Likes

@elix22 sounds good. Does it mean the app uses OpenGL ES 2.0 don’t have to modify anything to run on metal? And how about the performance?

It seems to be using https://github.com/google/angle.


The goal of ANGLE is to allow users of multiple operating systems to seamlessly run WebGL and other OpenGL ES content by translating OpenGL ES API calls to one of the hardware-supported APIs available for that platform. ANGLE currently provides translation from OpenGL ES 2.0 and 3.0 to desktop OpenGL, OpenGL ES, Direct3D 9, and Direct3D 11. Support for translation from OpenGL ES to Vulkan is underway, and future plans include compute shader support (ES 3.1) and MacOS support.

For some unexplained reason my post was tagged as spam , so I could not reply

Your post was flagged as spam : the community feels it is an advertisement, something that is overly promotional in nature instead of being useful or relevant to the topic as expected.

The only thing I promote is an open source and free solution that might address also your problem , Mainly providing a metal backed replacing the deprecated OpenGL-ES framework by Apple.
You can use freely without any constraints part or all of my code and in-cooperate it into Cocos2d-x

I will reply only once to this post in order to avoid to be tagged as spammer once again.

Answers to your questions:

  • Yep , this is exactly OpenGL ES on top of Metal , transparent to the users , pleasenot that it is still under development
  • Performance is great on my 6 gen iPad , steady 60 FPS, in release build configuration using complex scenes…

Please note that I modified and added new code to make it work , affected components are SDL2, Angle and MoltenVK.

There are still some bugs that I am fixing once a week , but in general it works great .
You can follow my progress on my Github page.
Also you can read my Wiki https://github.com/elix22/Urho3D/wiki

I am curious to know current state of multi backend for opengl and metal, and what are plans for opengl es 3.0/3.1/3.2 or Vulkan support. Most platform support Vulkan and its also performant so it would be great feature to add to cocos2dx.
I am keen to explore in this area and would like take up some task.

This is the current topic Metal support alpha1 released

1 Like

Newer topics available to participate in.