【浅入浅出】 讨论移动端游戏体验面对的问题 -- 大小核

引入

看到GAMES104之后，课程组还有这么大的热情，构建这么一个引擎社区，尝试去讨论一些有价值的东西。感到非常nice，因此想再把一些我们在行业讨论的问题和知识带过来，希望能够很好把这个社区氛围构造起来。

开篇，我们就讨论的一个比较common的主题，也就是移动平台的一些情况。

big.LITTLE 到 DynamIQ

由 ARM 推出的提出的异构运算架构，这个算是移动平台早于PC的一个设计（目前PC侧也在往这块发展，能效核）。对于移动设备来说，性能与功耗一样重要，该架构就是对于性能与功耗这一问题的解决方案：由能耗高但运算能力强的处理器核心组成的“big集群” 与 能耗低，算力弱的处理器核心组成的“LITTLE集群”结合。再面对不同场景和任务时，选择能效比最合适的计算资源。

对于早期的big.LITTLE 同一个Cluster Goup 来说 Core 使用的Micro-Architecture 要一样。这显然限制了不同Core之间的组合。

直到17年DynamIQ 的推出，给了这个问题答案，简单来说DynamicIQ下 cluster 的 cores 可以属于不同的 Micro-Architecture，因此其可拓展性比 big.LITTLE 更高。DynamIQ 允许至多 32 个 clusters，每个 cluster 支持8个核，因此可以出现各种各样的组合如下：

高通最新8Gen2组合：1 + 4 + 3

在移动游戏中的挑战

前面介绍了移动架构的背景，为了就是讲清楚目前在移动游戏所遇到的困境。当前移动游戏主流使用的 UE 和 Unity 版本基本都把游戏主要分为两个线程，一个游戏逻辑线程，一个渲染线程。稍微新一点的游戏还会通过游戏逻辑线去创建一些job thread 来完成一些系统的Tick或者逻辑计算。

资源供给 就是我们要讨论的问题。

我们来讨论两个实际案例：

某游戏A，使用了早期Unity的版本，该版本的大多数脚本逻辑都是在UnityMain主线程的中进行运算的，所以有时候就会出现UnityMain的运行时间长，从而影响了渲染线程，导致游戏掉帧。而手机厂商无法感知游戏运行时动态的负载，所以只能把UnityMain绑到大核上来减少这种情况。但是因为一直在大核上跑，导致游戏整体的功耗变差，游戏发热变多，用户体验下降。

某游戏B，基于某个UE版本，在运行时能够去创建worker thread，然后worker thread 去做一些系统的update，最后更新完后和游戏逻辑线程进行一次同步，然后再继续游戏主逻辑线程逻辑，接着再与渲染线程同步。看起来实现了很好的多线程来加速游戏逻辑更新，而实际上出现的问题就在创建的多线程的worker thread被绑到了小核上。因为小核作为能效核在频率和算力上都比较弱，导致计算时间长，从而导致掉帧。

这个两个例子其实讲诉都是同一个问题，就是在面对复杂的现代计算架构下，资源供给如何做到合理的问题。这也是移动端做好游戏体验的关键。
（一更）

Reference

https://en.wikipedia.org/wiki/ARM_big.LITTLE
https://hackmd.io/@sysprog/big-little#%E5%BE%9E-bigLITTLE-%E5%88%B0-EAS