Ogre 2.1: macOS support
- PsyCowboy
- Halfling
- Posts: 74
- Joined: Fri Apr 24, 2009 8:01 am
Ogre 2.1: macOS support
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
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
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
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:
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.
Btw check out our 2.1 FAQ.
Cheers
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: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.Code: Select all
rsc->setCapability(RSC_TEXTURE_COMPRESSION_DXT);
- 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
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 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?)
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.
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.d. Ogre 2.1 uses intensively HLMS (=> even for old materials if still supported?)
Btw check out our 2.1 FAQ.
Cheers
- PsyCowboy
- Halfling
- Posts: 74
- Joined: Fri Apr 24, 2009 8:01 am
Re: Ogre 2.1: macOS support
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)?
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
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
I don't think so. You could ask Hotshot user about it, but I think he has mostly focused on GLES3, not 2.PsyCowboy wrote:1. Would it be a possibility to run RenderSystem_GLES2 on macOS?
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.PsyCowboy wrote:2. Do you have any plan for RenderSystem_GLES3?
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.
I personally prefer Bitbucket. Paroj (Pavel) is the GH guy.PsyCowboy wrote:3. Is it preferable I create a branch from Github or from BitBucket (I prefer Github)?
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.
-
- OGRE Contributor
- Posts: 226
- Joined: Thu Oct 14, 2010 12:30 pm
- x 56
Re: Ogre 2.1: macOS support
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.PsyCowboy wrote: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)?
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.
-
- OGRE Retired Team Member
- Posts: 63
- Joined: Tue May 02, 2017 8:15 pm
- x 16
Re: Ogre 2.1: macOS support
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.
But I have worked a lot on Metal so hopefully that will help.
-
- Gnome
- Posts: 324
- Joined: Sun May 11, 2008 9:27 pm
- x 20
Re: Ogre 2.1: macOS support
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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
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
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
Thank you!DimA wrote: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.
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.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.
Even if you fix those issues, you'll still have to fix the shaders which require GL 4.2 syntax.
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.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 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.
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.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
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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?
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
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
Hi!
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.
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.
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.DimA wrote: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!
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.DimA wrote: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?
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.
Point 1 & 2 rely on what you chose.DimA wrote: 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)
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
Thank you Matias!
I'll give GLES3 a try.
I'll give GLES3 a try.
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Ogre 2.1: macOS support
I will add the 1.10 parts
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.
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.
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 whichDimA wrote: 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 the HLMS essentially is just a Shader specific template engine/ processor as described here. This part is identical between 1.10 and 2.1.DimA wrote: Matias, I saw some HLMS code in the 1.10 branch. Is it OK?
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.
Metal is not a prerequisite for PBS and as stated above PBS is already there.DimA wrote: 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.
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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!
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
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
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).
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
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
Oh! Probably I have to test on more complicated scene.
I'll try, thanks
I'll try, thanks
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Ogre 2.1: macOS support
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!
Good job!
- DimA
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
I have created pull request #775
- DimA
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
Oops, changes in
RenderSystems/GL3Plus/include/OgreGL3PlusVertexArrayObject.h
should be ignored - that was temporary visibility changes for debug purposes.
RenderSystems/GL3Plus/include/OgreGL3PlusVertexArrayObject.h
should be ignored - that was temporary visibility changes for debug purposes.
- DimA
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
Matias,
I've just commented almost each change in my pull request #755
Hope these will help to review them.
I've just commented almost each change in my pull request #755
Hope these will help to review them.
- DimA
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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+
I've got FPS under 60 and Metal 15..20% faster than GL3+
Metal
GL3+
- DimA
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
- Contact:
Re: Ogre 2.1: macOS support
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.
- 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.