Overheating on mobile platforms

Development Platform & Builds Mobile
, ,
1

Hello,

Currently, we are experiencing problems with overheating and performance overall on mobile platforms in the project ported from our engine to UE. There are several key points I would like to share at the moment.

<br/>

<br/>

CPU Frequency Percentage

There’s significant difference in CPU percentage between our original game and UE-based. Here and below I provide results from Xiaomi Redimi-14c, which we treat as Low-tier Android.

Original:

CPUFreqPercentageGroup0: 70 to 85

CPUFreqPercentageGroup1: 45 to 48

UE-based:

AVG CPUFreqPercentageGroup0: 90

CPUFreqPercentageGroup1: 87%

<br/>

Frame Time Breakdown

There are significant differences in the structure of frame. Matching a trace in Unreal and our engine is a tricky task, but we get the following.

World Tick:

Original: 5.3ms

UE-based: above 10ms

UI (layout) — not completely sure if Slate rendering is included or not:

Original: 1.1ms

UE-based: 3ms

Rendering (a lot of work is done on a main thread in original project. UE utilizes a separate thread for that):

Original:

World: 3.31ms

UI: 3.54ms

I don’t have exact numbers for UE, but it looks pretty much in parity with tick, so up to 15ms in total.

<br/>

Calling yield in the Game Thread

A cthread_yield call In UEngine::UpdateTimeAndHandleMaxTickRate takes up to 7% of CPU cycles. We would like to replace it with 100ms sleep instead.

<br/>

Questions

To summarize, I would like to ask advise on the following questons:

  1. Is there any possibility to reduce workload on the Render Thread? As we suspect there might be some workload, which is unused on Mobile, we would appreciate if there was a chance to turn something off.
  2. What potential consequences you see if we replace FPlatformProcess::SleepNoStats(0) to avoid yield’ing in the Game Thread? Do you have any advice?
  3. Is there any other areas we can look at, in order to reduce CPU workload?

Best regards,

Igor Mayevski

[Attachment Removed]

2

Hi Ihar,

Thanks for sharing your findings. Given the more generic natiure of UE vs an customized engine, I would expect CPUFreqPersentageGroupN to be higher. It would be interesting to see a utrace containing a frame with 10ms+ World Tick.

  1. Reducing workload on the render thread can be achieved by enabling the RHI thread (r.RHIThread.Enable=1). This would offload the low level RHI translation to a separate thread at the cost of some latency.
  2. Replacing a yield with a sleep (non zero SleepNoStats) could affect scheduling. Sleep will put the thread into an idle state for at least the specified time but in practice it could be more. This could affect timing precision in throttling vs the busier yield based approach.
  3. If we are talking in the context of the GameThread CPU workload, a utrace of a heavy frame captured on target would be great to look at to assess.

Best regards.

[Attachment Removed]

3

Hello Stephane,

  • Reducing workload on the render thread can be achieved by enabling the RHI thread (r.RHIThread.Enable=1). This would offload the low level RHI translation to a separate thread at the cost of some latency.

Regarding this point — I’m not sure if it helps a lot, because it won’t lead to less work on CPU and currently we think that only cutting (or optimizing of course) some features could be helpful. But thanks for the tip, we’ll definitely try it.

  • Replacing a yield with a sleep (non zero SleepNoStats) could affect scheduling. Sleep will put the thread into an idle state for at least the specified time but in practice it could be more. This could affect timing precision in throttling vs the busier yield based approach.

Yes, we have thought about it. Still, we would like to experiment with it. Unless there’s a strong NO from your side.

  • It would be interesting to see a utrace containing a frame with 10ms+ World Tick.

Sure, I can share it. I should add one caveat: I based the 10ms figure on the developer’s research with the NamedEvents stat enabled and divided by the rough overhead. In reality, the time varies from 7 to 10+ms.

[Attachment Removed]

4

Also shared the CPU Counters trace with [Content removed] and [Content removed]

[Attachment Removed]

5

Thanks for sharing that Ihar. Apologies, we’ve both been OOO but will look at this this week. It may also be interesting to subscribe to the OnTemperatureChange delegate and track reported temperature operating levels.

Best regards.

[Attachment Removed]