koobas.hobune.stream
Big Resolution Low FPS
Hello,
I made a game that runs very good on telephones (Galaxy S2,S3 ..) and tablets (7 inch) but it runs very slow (few FPS) on 10 inch tablets.
I have low draw calls (i think), few verts , few objects , scripts run ok.
I tried to disable objects , occlusion culling , disable lights , change shaders and so on but nothing worked.
The only thing that worked was to change to OpenGL 1.x and than every thing worked ok but i lost the graphics.
The tablet i tested was Galaxy Tab 2 10.1 .
Does anybody know what to do with this kind of problem ? I do not want to go to OpenGL 1
Thank you, Razvan
I have around 60 draw calls. The "map" is formed with multiple objects and are marked as static.
Problem solved, kinda change in build settings, rendering path: to legacy vertex lit
Scene now looks like shit, but at least the shit runs now in 60FPS on a Galaxy Tab 2 10.1
There are many of factors when it comes to performance on mobile. At least one of them will be your bottleneck.
Common ones people think about are fill-rate and vertex processing. For good reason too, but if you have less than a few thousand vertices and aren't doing anything stupid in your shaders, they probably won't be your bottleneck. If you're sticking to Unity's shaders, try using less complex ones.
A big limiting factor on mobile GPUs, especially for high resolutions, is memory bandwidth. Mobile chipsets share the same memory between their GPU and CPU. What this means is that the more memory bandwidth the CPU uses the less room their is for the GPU (and vise-versa).
Not a big deal right? It's not like your GPU is reading a few hundred megabytes of memory every frame to draw your scene. Oh wait, actually, it is. Texture look-ups! Every time a shader samples a pixel from a texture, it has to be loaded from memory. When each pixel is 4 bytes it adds up fast.
Down-sampling is expensive. Don't use antialiasing. Pixel density is high enough that you don't need it anyways.
Reduce texture footprint as much as you can. That doesn't just mean pixel dimensions. If you can get away with it, use RGB565, which will cut the memory cost of your texture in half. Use texture compression when possible as well.
Blending. Avoid transparency as much as possible. Fake it everywhere you can. It is exceptionally expensive on Tegra GPUs as they have no dedicated memory for blending operations (which means a read and write to system memory for every pixel (remember, memory bandwidth is a problem.))
Draw calls are, relatively, very expensive on mobile. Desktop developers are used to state changes being expensive. On mobile, operations like changing the bound texture are cheep. Draw calls are not.
There are a dozen other things that could be causing your performance problems, but hopefully this can help you narrow it down.
EDIT: 60 draw calls is a lot for a mobile chip to swallow. Getting that down as much as you can will help. Unity has some documentation on how they handle dynamic batching.
You can also try forcing your game to run at a lower resolution, which will at least help with fill-rate.
Draw calls are a function of CPU, and modern mobile CPUs are relatively fast. $$anonymous$$y iPod touch 5th gen can handle 370 draw calls or so while maintaining 60fps, as long as not much else is going on. A more realistic limit is probably around 150, assu$$anonymous$$g a goal of 60fps anyway. If you're willing to settle for 30fps then 300 draw calls is no problem.
Draw calls do mostly require work by the CPU (although it isn't quite that simple. Remember that the CPU and GPU share critical resources.)
$$anonymous$$obile Unity will do transformations on the CPU ins$$anonymous$$d of the GPU many times. You always benefit from using less CPU.
It will really depend on what the bottle-neck is. If it's fill-rate, then reducing the draw call count may not be noticeable.
When I worked at Samsung building Touchwiz, reducing draw calls by 20% had a noticeable effect. Granted, we were mostly trying to keep the average load as low as possible to avoid stutters caused by the GC.
