Ogre 2.1: macOS support

[PsyCowboy]

Hi Ogre,

I started some investigation/tests about the macOS support in Ogre 2.1 in order to port my software to Ogre 2.1. This is blocking for me, and I have strong incertitudes on the current state of this project.

=> What are the remaining tasks to support macOS?
=> Could I expect this will be supported at some point?


Here are some facts I found by testing or in documentation:

a. RenderSystem_Metal is working on iOS only.
b. The main remaining points to port RenderSystem_Metal on macOS is the render views (Windowing/iOS/OgreMetalView.h is designed for iOS and is using UIKit) (=> are there other big tasks?)
c. RenderSystem_GL3Plus can be build on macOS (just did it), but I failed to create a working sample (except a window with a custom background color )
d. Ogre 2.1 uses intensively HLMS (=> even for old materials if still supported?)
e. HLMS implementation of RenderSystem_GL3Plus is using GLSL 330 + GL_ARB_shading_language_420pack while macOS support only > 410 (=> is there a way to get rid of GL_ARB_shading_language_420pack?)

=> Are these facts true?

Thank you in advance

[dark_sylinc]

Hi!

There is a thread where a user ported to OS X and got it to run, but it seems abandoned by now.
Making Metal work on macOS should be relatively easy (fixing small issues here and there due to the differences, possibly redirecting Ogre to use the iOS draw paths due to the macOS code paths not being complete) and not a major task at all.
However I don't have a Metal-capable Mac and no one else has stepped up. You could try if you dare

Probably the differences should be:

• NSView vs UIView, obviously.
• MetalRenderSystem::_render overloads are empty (not implemented). But MetalRenderSystem::_renderEmulated can be used instead (VaoManager::supportsIndirectBuffers must return false for Ogre to use _renderEmulated). Should be slightly less performance, not a big concern (and implementing this can be done later and shouldn't be much work).
• BCn compression (aka DXTn) clearly isn't working as that's the last post of the OS X thread. There is no BCn compression support in iOS. Shouldn't be too hard either:
  Not setting:

  Code: Select all

  rsc->setCapability(RSC_TEXTURE_COMPRESSION_DXT);

  will force Ogre to decode BCn compression using software. When this is set, BCn compression will be used; but obviously it appears MetalTextureBuffer::upload isn't handling this correctly. Most likely an issue with the MTLPixelFormat or wrong rowPitch & bytesPerImage parameters.
• Possibly any recent compiler error that could've been introduced by calling a function that is only available on iOS, in which case it would need to be ifdef'ed out

And that's it. It's all small tasks.

RenderSystem_GL3Plus can be build on macOS (just did it), but I failed to create a working sample (except a window with a custom background color )
HLMS implementation of RenderSystem_GL3Plus is using GLSL 330 + GL_ARB_shading_language_420pack while macOS support only > 410 (=> is there a way to get rid of GL_ARB_shading_language_420pack?)

There's several extensions we need from OpenGL aside from that one; I'm afraid macOS' implementation is simply too old, and the writing on the wall is clearly suggesting Apple doesn't care anymore or won't update their OpenGL implementation.
RenderSystem_GL3Plus builds, but would crash in several places if you try to use it (the best you'll get is the clear colour to work)

Another user has done incredible work to get GLES3 working which I have already cloned but didn't test/evaluate. GLES3 should theoretically work on macOS, but I don't think anyone has tried it there.

d. Ogre 2.1 uses intensively HLMS (=> even for old materials if still supported?)

We use it intensively, indeed. Old materials are still supported, but at severely reduced performance (if you're planning to use it on a large number of objects) and some features from 1.x may be missing. It's mostly useful for postprocessing effects or rendering a few special case objects that require custom shaders.

Btw check out our 2.1 FAQ.

Cheers

[PsyCowboy]

Thank you, I will definitively give a try, but I also clearly need your help here (I have only few knowledge in Metal and Objective C++).

I have questions:

1. Would it be a possibility to run RenderSystem_GLES2 on macOS?
2. Do you have any plan for RenderSystem_GLES3?
3. Is it preferable I create a branch from Github or from BitBucket (I prefer Github)?

[dark_sylinc]

1. Would it be a possibility to run RenderSystem_GLES2 on macOS?

I don't think so. You could ask Hotshot user about it, but I think he has mostly focused on GLES3, not 2.

2. Do you have any plan for RenderSystem_GLES3?

My plan is to look at Hotshot's fork, evaluate it and integrate it. But first I'm doing the texture refactor (which is btw bumping the Ogre version from 2.1 to 2.2); which would impact GLES3's code too.
One of the benefits is that work on GL3+ should be reusable on GLES3 too; but the disadvantage is that probably some porting effort will be involved. I may have checkout GLES3 in the middle of tex. refactor when I get some free time just so I see its quality and stability, and get a hang of the changes involved.

I liked Hotshot's approach of first having GLES3 work on Linux & Windows (via ANGLE) instead of just going directly for Android (which is the main reason to support GLES); because Android is a major PITA to develop for, and maintain too. So that may ease GLES3 development a lot.

3. Is it preferable I create a branch from Github or from BitBucket (I prefer Github)?

I personally prefer Bitbucket. Paroj (Pavel) is the GH guy.
However if you feel too strongly about git we may work something out. Eventually I'll have to convert thos git commits back to hg commits.

[Hotshot5000]

Thank you, I will definitively give a try, but I also clearly need your help here (I have only few knowledge in Metal and Objective C++).

I have questions:

1. Would it be a possibility to run RenderSystem_GLES2 on macOS?
2. Do you have any plan for RenderSystem_GLES3?
3. Is it preferable I create a branch from Github or from BitBucket (I prefer Github)?

1. GLES2 isn't working on 2.1 branch. I have a GLES3 version done for 2.1 but it probably needs more testing. I have only tested it on my PC (the ANGLE version) and I don't think others have used it that much. But it's a start if you want to implement GLES2. The thing is GLES2 is a nasty POS from many points of view. Getting 2.1 to run on GLES2 is going to be a PITA and a lot of performance optimizations that you would get with 2.1 just aren't going to happen on the GLES2 backend. So if you really want GLES2 maybe you want to go back to the last version of OGRE that support it (1.10 I think?). It's still maintained and updated regularly by paroj.

2. See above. My work isn't integrated on the main 2.1 repo because until I get at least a few low end, mid-end and high-end android devices to test on I can't say it's stable (getting GLES3 running on PC was an intermediary step towards my goal of getting 2.1 to run on android. For much easier debugging). I need to run it on different CPU-GPU configurations and see if everything is OK. Right now I have only tested it on a Nexus 5 (2013). My repo is at https://bitbucket.org/Sebastian_Bugiu/ogre. The main reason I created the GLES3 port for 2.1 was to get 2.1 working on android devices. I knew that the situation on macOS was bad... Never realized it has gotten THAT bad that you need GLES3 to get things working.

Now that I'm thinking.... Metal is the way to go on mac. I wouldn't waste time on getting GLES3 working on mac. The metal branch is older than the GLES3 and likely more tested. It should be easier to get Metal running on mac than GLES3. Still, ANGLE is working on mac so you should be able to get GLES3 working.

[berserkerviking]

I just joined the Ogre team. My first goal is to complete the macOS port for Metal. I'm not sure how long it will take me, because I'm new to Ogre.
But I have worked a lot on Metal so hopefully that will help.

[mrmclovin]

I'm also interested in macOS support, if you guys need any help with testing etc. let me know and i might be able to help!

[DimA]

Hi all!

First of all I would like to congratulate all Ogre team! You guys have made a great leap forward by developing 2.1 branch, indeed!
I've played with a macOS Metal implementation and it runs fine. PBS is really promised.

But I think it's a mistake to break GL3+ Mac implementation.
Indeed current GL3+ render system is incompatible with any macOS-based PC. I tried to fix it but finally have to give up!
It uses latest GL profiles everywhere(4.2 - 4.3) without fallbacks, for example: glDrawArraysInstancedBaseInstance (4.2), glDrawElementsInstancedBaseVertexBaseInstance(4.2), glTexBufferRange(4.3), etc. Do you know that Apple latest GL profile is 4.1? It's fine if Ogre can use the latest modern API, but it is also important to have the fallbacks.
Production quality Mac app can not depends on Metal only, because nowadays there are still a lot of users with old Macs without Metal: https://support.apple.com/en-us/HT205073
These make me sad
I'll try also with GLES3 - this is my last hope

[dark_sylinc]

Hi all!

First of all I would like to congratulate all Ogre team! You guys have made a great leap forward by developing 2.1 branch, indeed!
I've played with a macOS Metal implementation and it runs fine. PBS is really promised.

Thank you!

Indeed current GL3+ render system is incompatible with any macOS-based PC. I tried to fix it but finally have to give up!
It uses latest GL profiles everywhere(4.2 - 4.3) without fallbacks, for example: glDrawArraysInstancedBaseInstance (4.2), glDrawElementsInstancedBaseVertexBaseInstance(4.2), glTexBufferRange(4.3), etc.

As you found out, it's not a simple task. It's not just a matter of changing the call and patching a few things up.
Even if you fix those issues, you'll still have to fix the shaders which require GL 4.2 syntax.

But I think it's a mistake to break GL3+ Mac implementation.
Indeed current GL3+ render system is incompatible with any macOS-based PC. I tried to fix it but finally have to give up!

I understand your frustration, but likewise with that logic you could just flip the coin / point somewhere else and say Apple is doing a mistake by not supporting anything newer than GL 4.1; it is an 8 year old API that misses critical updates.

I heard the web drivers from NVIDIA for Mac do implement newer GL versions though.

Alternatively you could try Mesa3D. Even Mesa has caught up with the GL features we need. Although Mesa3D does not support hardware acceleration in macOS / OSX, it can be bundled as a lib and be used in software rasterizer mode. It will be slow but it would be able to render correctly if correctness is the only thing required.

It's fine if Ogre can use the latest modern API, but it is also important to have the fallbacks.
Production quality Mac app can not depends on Metal only, because nowadays there are still a lot of users with old Macs without Metal: https://support.apple.com/en-us/HT205073
These make me sad
I'll try also with GLES3 - this is my last hope

Implementing and maintaining those fallbacks would be a very time consuming process and we do not have the resources (time, money, and man power) to support such fallback paths. Lack of support for the GL 4.3 features we need hold back a modern rendered. Before 4.3; OpenGL was a very poor API to work with.
However the GLES3 path may workaround those issues, but we don't yet know what performance / quality / features that may have to be compromised in order to run GLES3.

[DimA]

Dear Matias,

thank you for explanation and suggestions.

Unfortunately/fortunately I cannot left Ogre and switch to Mesa or any other engine
I have been using Ogre since 2005 and I like it a lot!
Our team develops cross-platform app for home design Live Home 3D(a successor of Live Interior 3D): https://livehome3D.com
Right now we stay on Ogre 1.10 and support Win 10 and macOS 10.9 or later. Recently we've started port to iOS, probably you have already seen some commits with GLES fixes to default branch from Eugene Golushkov
I see a big opportunity to improve performance and visual rendering quality if we change material system to PBS and switch to Metal. But we also have to keep compatibility with all Macs supported by latest macOS at least. Because we can't prevent users with non-Metal system from installing our app.
So, now I have several options and have to choose the best one:
1. Stay with Ogre 1.10 as is.
2. Stay with Ogre 1.10 but port back Metal and re-implement PBS.
3. Switch to Ogre 2.1 and adopt GLES3
4. Switch to Ogre 2.1 and make fallbacks for GL3+

Matias, I saw some HLMS code in the 1.10 branch. Is it OK?
Also, what do you think about possibility to port Metal back to 1.10 branch?

[dark_sylinc]

Hi!

Unfortunately/fortunately I cannot left Ogre and switch to Mesa or any other engine
I have been using Ogre since 2005 and I like it a lot!

Mesa is not a different engine. It's only an OpenGL driver in software. You would use Ogre, and Mesa would provide the required OpenGL.

Matias, I saw some HLMS code in the 1.10 branch. Is it OK?
Also, what do you think about possibility to port Metal back to 1.10 branch?

Murat backported the HLMS to 1.10; however it has diverged significantly from the one present in 2.1; I do not know its quality, performance or usability.
As for backporting Metal to 1.10; it is not impossible but it would be extremely difficult.
Metal relies on PSOs (Pipeline State Objects) and explicit synchronization, and Ogre 2.1 also works with PSOs and explicit sync; therefore the Metal RenderSystem was very easy to write because most of Ogre 2.1 mapped 1:1 with Metal. However this is not true for Ogre 1.x which uses a Fixed Function / D3D9 style approach.

1. Stay with Ogre 1.10 as is.
2. Stay with Ogre 1.10 but port back Metal and re-implement PBS.
3. Switch to Ogre 2.1 and adopt GLES3
4. Switch to Ogre 2.1 and make fallbacks for GL3+
5. Added by me: Use Ogre 2.1 with GL3+ and use Mesa SW. (potentially slow, depends solely on CPU speed and number of cores)

Point 1 & 2 rely on what you chose.
I can comment on points 3 & 4: Point 3 looks like a much more reasonable approach. First, because any fallback you want to do would likely end up looking very similar to whatever GLES3 is doing, since the limitations are very similar. So there is little point in trying to make a fallback when it would end up being almost the same.
So if you choose to go for Ogre 2.1, investing in getting GLES3 to work sounds like the smartest idea. Hotshot5000 wrote a port of GLES3 and got it working on ANGLE, Linux and Android. I started testing it but due to several reasons I didn't finish testing it (I started by building the Android version but unfortunately hit a few minor walls then I got distracting into something else).
I do not know the state but it's likely the option with highest chance of success among Ogre 2.1 and macOS.

[DimA]

Thank you Matias!
I'll give GLES3 a try.

[paroj]

I will add the 1.10 parts

I see a big opportunity to improve performance and visual rendering quality if we change material system to PBS and switch to Metal.

note that PBS is more computationally demanding and probably will be slower then the simple blinn phong in 1.10. However Matias recently added blinn phong to HLMS as too. Speaking of which

Matias, I saw some HLMS code in the 1.10 branch. Is it OK?

Note that the HLMS essentially is just a Shader specific template engine/ processor as described here. This part is identical between 1.10 and 2.1.

Now there are the PBS implementations using HLMS in 2.1 and 1.10. These are quite different feature and implementation wise between 1.10 and 2.1. In 1.10 you only get the most basic PBS - no shadows or global illumination. On the plus side it even works with legacy GL though.
Also there are only Datablocks in 1.10 so there is no performance gain in using HLMS. (whereas you benefit by the Macro/ Sampler/ Blendblock separation in 2.1).

However the performance situation improved in 1.10 compared to when HLMS was introduced: the materials are now sorted by shader and we have state caches on all GL RenderSystems. So there are no redundant shader and uniform changes in 1.10 either.

So, now I have several options and have to choose the best one:
1. Stay with Ogre 1.10 as is.
2. Stay with Ogre 1.10 but port back Metal and re-implement PBS.

Metal is not a prerequisite for PBS and as stated above PBS is already there.

However if all you want is a PBS pipeline I think the fastest way would be to implement PBS as a RTSS SRS - similar to per pixel lighting. Then porting would be just adding a rtshader block to your existing materials. similar to this.

[DimA]

Thanks guys for explanations and suggestions!

My goal is to get better visual quality and better performance as well. In 2.1 I see better opportunities to rich this.
Thanks to GLES3 port I've found ideas how to make fallbacks in GL3+ to be compatible with legacy GL 3.3 API.

In few days I've got PBS and ESM shadows work fine via GL3+ render system. I have not finished yet. I have to fix also Forward3D and Global illumination.
Here is my current progress on macOS GL3+ render system :
https://ibb.co/naWbX5
https://ibb.co/eaZKkQ
https://ibb.co/b6tqs5

[DimA]

Hi Guys!

I've finished my modification to GL3+ render system. Now it works just fine on macOS 10.9 and later.
So, I'm ready to share my changes. What is the easiest way to do that? I've prepared a patch:
https://www.dropbox.com/s/xq4zamudpn4vt ... patch?dl=0

I've compared GL3+ with Metal on macOS 10.12.5 and got strange result. GL3+ 20% faster than Metal :

GL3+


Metal


My expectation was: Metal should be faster GL !!!
Probably Metal render system implementation still requires some polishing.

Any comments are welcome!

[dark_sylinc]

For unknown reasons our samples in macOS' Metal are locked to 120 fps, (that's twice 60hz).
Could be that we're missing some setting (i.e. something similar to VSync) or it could be that we have to wait for another MTLDrawable to become available (retired from screen).

[DimA]

Oh! Probably I have to test on more complicated scene.
I'll try, thanks

[dark_sylinc]

Mmmm.... the changes look much less invasive than I expected them to be. I'll be adding your patch to my TODO list for inclusion.

Good job!

[DimA]

I have created pull request #775

[DimA]

Oops, changes in
RenderSystems/GL3Plus/include/OgreGL3PlusVertexArrayObject.h
should be ignored - that was temporary visibility changes for debug purposes.

[DimA]

Matias,
I've just commented almost each change in my pull request #755
Hope these will help to review them.

[DimA]

I've made new comparison on Forward3D sample with 512 lights in scene.
I've got FPS under 60 and Metal 15..20% faster than GL3+

Metal


GL3+

[DimA]

I've just updated my pull request #755:
- added macOS hlms property to prevent Fragment stage disabling on macOS GLSL; (I think it's better to show the problem on Mac platform; If we do this trick in *.cpp that will hide it)
- reverted back OCGE( glActiveTexture( GL_TEXTURE0 ) ) call while depth texture creation.