I’ve got a scene with a fairly extensive city environment. There’s no game logic in this scene, it’s purely for testing the 3D environment so I can optimize it. The stats window shows that with a typical camera location, I’ve got:
-504 drawcalls
-193k tris
-294k verts
I know this is too much for older iPads, and I’m going to use SECTR, but right now I’m just trying to get a handle on optimizations. There are no shadows, no physics, and no skinned meshes in this test scene. Everything is marked Static. There are some mesh colliders, but none are very complex, and most objects have no collider or cube colliders. Most of the meshes use echoLogin’s Fastest unlit shader. The scene has lightmapping. Quality is set to “fastest” with no pixel lights and no anti-aliasing. Just a few meshes have transparency, and they’re small (car windows, far from the camera).
So I would expect this, on iPad, to be heavier on GPU than CPU, due to all the drawcalls. But in xcode, running on iPad Air, I get:
CPU: 30ms static camera, 32-38ms moving camera
GPU: 15ms static camera, 16ms moving camera
In the Unity profiler, CameraRender uses 25ms - 35ms (mostly Drawing, a bit of Culling).
So I’m not sure what I need to do to reduce the CPU usage (which I need for the game logic). What am I not understanding here?
Thanks! Right, that is what the docs say, but everything I read is that you’re more likely to be GPU than CPU-bound on mobile, so it’s surprising that it’s the opposite for me. How do I reduce culling? I don’t have Occlusion Culling set up, so what could that be besides frustrum culling?
Now I’ve reduced drawcalls to 230 (and tris to 66k), simply by shortening the camera draw distance, and that did indeed reduce CPU usage, though not as much as I hoped–it’s 23ms with a static camera. GPU is 8ms now. In the Unity profiler, CameraRender is 15ms, with 13ms of that being Drawing. (But xcode’s profiler is more accurate, isn’t it, so it’s really 23ms, not 15ms, right?)
So now I’ve shortened the camera draw distance further, so there’s only 138 drawcalls. And that brings the xcode CPU readout to 17ms (and GPU to 7ms). So that’s good – but this is on iPad Air, which I expected to be much better at handling drawcalls than this…
138 draw calls is easily handled even with an older device. The bottleneck is probably now elsewhere, and you will need a proper unity pro profiler to dig in and discover why.
I’ve got Pro. Here’s the profiler (I switched the camera draw distance back to have about 500 drawcalls.) It just seems to say that there are a lot of objects to be drawn, right? There’s no indication of a particular bottleneck? (For comparison, also attached is the profiler from the editor on my 2013 MBP – I certainly expect it to run better there, but that much better?)
But the bottleneck here is from draw calls on the CPU.
