We've recently encountered a performance problem in our unity game and I suspect that the reason was the CPU spikes in mali-cmar-backend thread.
As you can see from UnityMain thread and GpuCompeletion, there is no CPU Bound or GPU Bound in this test scene. The camera position is fixed in this test, and the GPU pressure should be the same in the whole systrace.
So the only clue seems to be this spike in the mali-cmar-backend thread. I tried googling mali-cmar-backend, but very little results was found, and they are not very helpful. So I wonder if I can have some information here, mainly about these two question:
1. What is this mali-cmar-backend thread? Is this CMAR the abbreviation of Control Memory Address Register?
2. What may cause this strange spikes in this thread?
Sorry about the broad questions, any ideas or keywords for me to dig into will be very helpful. Thanks in advance!
Our game is using a ton of uniform/UBO (likely far over 8k), which had caused some rendering problem on other devices eariler. Not sure if this is related to this issue.
We can reproduce this problem on a Exynos 2100 (Mali-G78) device and a kirin 820 (Mali-G77) device, but not all Mali GPUs have this problem.
We are using OpenGL ES 3.2.
I've just sent some systrace files and counter data.
I think we are not using too many flushes (if you mean glFlush or glFinish). We didn't manually call them, and I can't find any in the renderdoc captures. We are using some glflushmappedbufferrange (at most 15 per frame). I'm not sure if that is a type of flush, and I'll try to disable them and test again.
Though mentioned in the email, I'd also want to repeat it here, so that other readers won't miss some detail.
When collecting GPU data, I found out that we cannot reproduce the issue as long as SystemProfiler (from Huawei) or Streamline is connected to the game and actived. Take SystemProfiler as an example. we first reproduce this issue and confirm it is happening by seeing a spike in systrace. Then we click the start button to collect GPU counters, and the fps just went back to normal (also, the spike in mali-cmar-backend thread disappears). Then we click stop button to stop collecting data, the same issue just immediately happens again (we can see the spikes again in systrace).
May I ask if glInvalidateFrameBuffer or glBindFrameBuffer would implicitly call a flush in the drivers? We do switch framebuffers many times in a frame.