Metal. (MoltenVK) support for iOS an Mac devices


For the update .
I will take a look at the logs during the weekend .

  • What device are you using ?
    -You can try disabling the crash for now in your Xcode :
    Menu : Product -> Scheme -> Edit Scheme -> Run
    Select Options tab and disable Metal API Validation.
    Options -> Metal API Validation : Disabled


I fixed samples 09 & 10
Sample 07 - Needs more time to debug , will work on it next weekend

In addition :
Since Google supports Windows Angle Vulkan backend officilly (and not supporting Metal)
I added Windows Vulkan backend support using the same development branch (angle-vulkan) .
Windows would be used only for reference , and finding bugs on the Angle side .
So people that have a Windows machine and would like to try it , please read the WIKI on my Github

1 Like


You’re on a roll :slight_smile: Me too!! Most stuff is just working how I expect, and I’m asking less stupid questions :smiley: I’m hoping to be able to build your code soon



MGKL2TY/A iPad AIR 2 64gb wifi 2014, Ios 11.4.1

Samples 9 and 10 are ok now. :smiley:

Here comes the biggest one.

11-12-13 Physics - Every time objects move, frame rate drops to 3-4 fps. :open_mouth:

ex 11 when the crates settles and when you throw at them 3 fps.
ex 12 it takes 20 seconds for crates to start rolling down.
ex.13 7 fps taking down the guys

Did I miss some building step, maybe?

EDIT: False alarm.
I tried latest Ios build from master, and it has the same problems… :disappointed_relieved::disappointed_relieved::disappointed_relieved:



It’s ok :slight_smile:

Just run release build configuration , you will see 60 FPS .

  1. Choose Legacy Build System .

Menu : File -> Project Settings … -> Build System : Legacy Build System

  1. Edit the project Scheme , choose the run action.

Menu : Product -> Scheme -> Edit Scheme -> Run

  1. Select the Info tab , set build configuration to Release.

Info -> Build Configuration : Release

  1. Still in the Info tab , Debug executable checkbox should be unchecked.

Info -> Debug executable : unchecked

  1. Select Options tab and disable Metal API Validation.

Options -> Metal API Validation : Disabled



I had a similar problem in my first few days on Urho, frame rate would go below 1FPS - it could take several seconds for each frame! It had something to do with contacts, and only happened with debug draw enabled, I will try to remember the exact details.



Ok. Basically it has to run in release mode.
Physics is ok. Steady 60 fps. :open_mouth:



Aaargh :scream::scream::scream: I’m stuck with the dreaded

The request was denied by service delegate (SBMainWorkspace) for reason: Unspecified

I’ve gotta to clean everything and restart… f$%£*ing Apple… :confounded::confounded::confounded:



@elix22 going forward after cleaning everything
looks like XCode doesn’t like switching from debug builds to release and vice-versa…
15_Navigation, 18_CharacterDemo, 19_VehicleDemo are ok.

1 Like


Yes I am aware of this , seems to be an Xcode bug.
Initially release build was failing for me , I googled it and people were reporting the same issue .
The only thing that fixed it for me was choosing the Legacy build system .
Menu : File -> Project Settings … -> Build System : Legacy Build System

So my advice would be to use the legacy build system for both debug and release.



i quit working for That Fruit Company, but I can’t talk about it for a while



I had some spare time so I debugged this issue , it appears to be an angle-vulkan bug .
I communicated that to Angle development.
An issue was filled .and will be fixed , I will integrate it once the fix will be provided .

You can follow my discussion with the Google guys on this!topic/angleproject/D2GNJ7wB1HA

Issue link



24_Urho2dSprite and 25_Urho2dParticle are ok.
23_Water has problems. Even in release mode and without debug, average frame rate is stuck around 45…

Read about the issue. What a nuisance. Memory hog calls for sure rejection from the app store… :confused:



Argh, finally found some time to go on…

27_Urho2DPhysics,28_Urho2DPhysicsRope,30_LightAnimation,31_MaterialAnimation,32_Urho2DConstraints are all ok

33_Urho2DSpriterAnimation there’s no physical button to test animations, rendering looks ok

looks ok. Only the center triangle is all black. My mistake, or was it lightened?

20_HugeObjectCount - totally broken
759476 tris, 62339 batches, 3fps :open_mouth:



07 shows increasing resources consumption and falling fps

I fixed it for now (on my branch) ,specific use case in which multiple non-directional lights are moving in different directions.
Once Angle will provide a more general fix for the Scissor test issue then I will revert my fix.

23_Water has problems. Even in release mode and without debug, average frame rate is stuck around 45…

Yep , in this scenario it performs worse than the default legacy OpenGL/ES .
Current phase is to make it all functional , we didn’t reach the optimization phase yet.

20_HugeObjectCount - totally broken
759476 tris, 62339 batches, 3fps :open_mouth:

Did you try it in release build configuration ?
This specific sample is a nice performance marker indicator but no more than that , it’s not a valid use case in any game .
If anyone is making a mobile game that has tens of thousands of draw-calls each frame than something is wrong with the game design not the game engine.



Something is wrong with the culling, is more likely - I take it that the Huge Object Count sample does not cull by visibility, and certainly does not attempt to cull by occlusion. The former would make sense and cost little, but the latter makes no sense and costs a lot.



Yes, I disabled molten debug and used release conf.
I think you have a point here - probably the 62339 batches don’t fit the ipad. Tris count is not so high - I’ve loaded multi million models some time ago inside Urho on this ipad with apparently no slow down…
I’m going to update the branch and retest 07…



Are we using gpu instancing? If we were, the batch count would be a lot lower…



I don’t have the slightest idea…



when we want to draw ten thousand of the same thing, gpu instancing offers us a way to set up a buffer full of instance transforms, and make one draw call to draw all the instances, so the number of batches comes down to how big a buffer we provided for our instance transforms (typically 4x4 matrices)
This helps batch count immensely, but we’re really just moving the bottleneck from the cpu to the gpu, and it’s not useful in a wide number of use cases, but its worth looking into for things like drawing grass