云游戏技术概述

原创

魏雪

修改于 2019-11-07 18:57:10

6.2K1

修改于 2019-11-07 18:57:10

文章被收录于专栏：START云游戏START云游戏

历史

云游戏具有极大的想象空间，从20年前，就吸引众多的前辈们尝试。由于技术条件不够成熟，而纷纷成为了前浪。

我认为云游戏会有三个阶段（求高大上的三阶段总结名字）

『适配阶段』

这个阶段，大家比较好理解，主要的目标就是将当前已经开发好的游戏搬到云游戏的平台上来

『原生阶段』

到了这个阶段，市场已经接受了云游戏的方式，各家都准备大力投入了。在这个阶段，需要像大数据、AI一样，在云端使用GPU集群来完成游戏的渲染；同时利用平行可扩容的GPU能力，催生未来的云游戏形态，扩展游戏策划的空间。

『VR阶段』

经历了『原生阶段』，云端大规模GPU集群渲染技术已经成熟，可以支持更复杂，更精细的VR游戏制作。前两个阶段也准备好了更高压缩比、低耗时的音视频编解码方案以及实时网络传输方案，以支撑VR视频流的高压缩率、高带宽的需求。

下面重点讲一下『适配阶段』的整体技术，『原生阶段』和『VR阶段』还没有太清晰的思路，简单提一下现在的初步想法。

『适配阶段』

关键技术点

我们现在是处于第四波的云游戏浪潮中，这一波相对以前有更多的巨头入场，这是因为以下的5个核心技术点已经成熟起来了。

GPU服务器：随着AI、大数据的发展，推动了高密度GPU服务器的发展。虽然还不是特别贴合云游戏，但已经有了一个比较好的基础
虚拟化：这里的虚拟化技术包含了虚拟机、容器等隔离技术，也包含了GPU的虚拟化技术。针对不同的场景，会有不同的考虑。
音视频技术：264、265已经能成熟应用了，并且短视频、直播业务的发展，提升了编解码的效率，扩大了硬件编解码的市场普及度。
实时网络传输：同样得益于短视频、直播业务的发展，已有的网络协议优化技术为云游戏奠定了一定的基础，可以进化为适应大带宽、低时延的网络优化技术。
边缘计算：云业务的大力发展，推动了CDN业务的普及，就腾讯云在全国已经有1000+的CDN节点。现在国家牵头推动的5G中，有一个关键特性MEC(Multi-Access Edge Computing)，也会大力推动边缘节点的建设。

软件栈

国外主要是在做PC游戏、主机游戏的云游戏解决方案，国内除了这些，还有做移动游戏的云游戏方案（基于Android）。整个云游戏的一个软件栈全景图如下：

从下往上一一介绍

服务器层：

PC游戏/主机游戏：

服务器主要基于x86架构，最关键的软件技术在于显卡驱动，这部分是由显卡厂商把持的。虽然AMD的UMD层驱动开源，但其核心的KMD层还是闭源的，脱离显卡厂商在外部很难对驱动做出针对性的优化。

这一领域，定制服务器也有两个方向。

传统服务器+多显卡，多CPU核+多GPU，是一种资源池互相配合的服务器方案，这种方案下对资源调度到算法要求比较高，也有很大的灵活性。从调度方案上来看，个人是比较倾向这条路线的，在未来的『原生阶段』，为了充分发挥硬件资源超卖、性能可平行伸缩的特点，必然是CPU池+GPU池的IaaS方案。
小节点方案，从披露的信息看PS Now、GFN 2.0、xCloud都是这样的方案，即一个CPU带1-2张显卡，做一个最小的资源粒度。这个方案和『原生阶段』的理念有违背，比较难做到GPU能力的平行扩展，服务器硬件的更新换代有很高成本，应该是过渡期方案。

Android游戏：服务器形态有三种，

x86服务器，基于intel的houdini指令翻译工具将arm的risc指令集翻译成x86指令集，以实现Android游戏在x86服务器上运行；方案的优势在于x86服务器很成熟，很容易规模化，易于运维，劣势在于指令集翻译这一层有较大的损耗，且服务器成本相对于ARM的两个方案偏高。
ARM服务器，就是将传统服务器中的x86 CPU替换成ARM CPU；
ARM板卡阵列，相当于手机板卡上只留下CPU、GPU、MEM和网络等关键硬件，一定数目的板卡装配到一个服务器机箱内，配合上电源、交换机等设备，形成一个ARM板卡服务器。

ARM的两个方案优势在于成本和Android原生运行环境；劣势在于产业链还没有成熟，较难运维，一是服务器链条，包括方案，生产环节，一是GPU生态，无法使用A卡和N卡。不过ARM公司正在推进这一块，期待未来的演进。

虚拟化层

基于不同的底层操作系统会有不同的虚拟化方案

PC/主机云游戏：Linux Host + Linux docker/Linux VM

猜测Google Stadia平台会采用Linux Host + Linux docker的方案。docker现在已经可以实现静态资源（文件系统）和运行时资源（CPU/MEM等）的隔离，难点在于GPU渲染能力的共享和调度（CUDA已支持docker）。

在Linux OS + Linux VM(vGPU/GPU Passthrough)方案里，用虚拟机和GPU虚拟化来实现GPU资源的隔离和调度。

一种是vGPU，即GPU虚拟化方案。当前业内的GPU虚拟化方案，在核心的管线和shader资源上都是基于时间片轮询的虚拟化调度方案，时间片过大，则带来较长的响应延迟，时间片过短则有较大的调度损耗。

一种是GPU Passthrough，即GPU直通。将整个GPU直通进虚拟机，为单个VM独占。GPU资源的最大化利用存在难度，需要配合其他方案一起做（这里其实就回到docker方向的考虑了）。

PC/主机云游戏：Linux Host + Windows VM 这种方案运行PC游戏，可以快速构建云游戏服务器，很多技术积累不够深的创业公司选择的都是此方案，另外Nvidia GFN也是此方案。方案的弱点在于单纯的虚拟机方案，虚拟机的控制权完全或部分交给用户，无法控制用户行为。那云游戏宣传的No Cheating，No Hacking就是一句空话了。举个例子，玩家获得虚拟机控制权，通过浏览器可以在虚拟机上任意的上传下载内容，也就能获取游戏文件做分析，进而做出破解和外挂了。所以该方案不可单纯的使用，需要配合上系统权限控制的方案才行。另外，该方案在GPU虚拟化上的实现，同Linux VM。
PC/主机云游戏：Windows Host + Windows Sandbox 这里的思想类似于Linux Host + Linux Docker，Sandbox就是一个Windows Docker（或是叫做Container，微软有一个windows Container项目，该项目对图形接口的支持当前仅限于OpenGL）。Sandbox需要提供游戏进程运行资源和静态资源的隔离，同时要提供GPU调度能力。
Android云游戏基于服务器（x86/ARM）的方案，需要用到kvm（CPU、MEM虚拟化）和qemu（I/O虚拟化）的虚拟化技术。ARM板卡的方案就不需要虚拟化实现了，每个板卡提供一个真实Android环境即可。

游戏引擎

在『适配阶段』，游戏引擎参与较少，主要的工作会集中在游戏效果设置方面，以确定每一路玩家的资源消耗，便于服务器资源调度、体验保证和成本控制。

音视频编解码

云游戏是大带宽低时延场景，264和265是较成熟的方案；AV1和VP9当前还较难满足低时延的要求，因其授权免费，需持续关注。

编码端，由于低时延的要求，需要尽可能的使用硬件编码器；同时软件编码在特定场景下有很多压缩带宽的方法，因此带宽和时延需要平衡考虑，不同场景可做定制。

解码端，264硬件解码已经很普及了。265硬件解码也覆盖较广。因为移动端ROM和硬件解码实现有厂家差异，移动端的硬件解码需要有适配工作。

需要再提及一下和音视频流并列的一个方案，渲染指令流方案。在PC/主机云游戏领域，这不是一个好方案，因为：

1. 用户还是需要显卡渲染，还需要硬盘存储游戏素材，不是轻量客户端。
2. 大量的骨骼动画带来的动态数据，指令流需要的带宽也不低，并且没有现成的编解码方案。
3. 图形SDK的兼容性问题，云端1.0版本，客户端有2.0、3.0版本，这里需要做API的版本间兼容。
4. 手机上现在还不支持dx，只支持opengl和vulkan。

但在移动游戏领域，因为当前手机处于追求配置升级的阶段，因此可以通过该方案充分利用手机端的硬件能力，节省服务端的硬件开销，是一个可接受的方案

网络传输

这里的思路是做灵敏的流量控制。基本思想就是需要实时检测网络带宽能力，再结合客户端的数据包处理能力上限，动态的反馈给编码端，实时调节编码参数以适应网络抖动。

大家都把云游戏和5G放在一起讨论，但我接触到的大多数人对这两者的联系认识并不是很准确。准确的说，5G是云游戏的催化剂，没有5G云游戏还是会到来，只是速度会慢一些。下来说一下5G对云游戏具体的催化作用：

加速移动设备上应用云游戏的进程，5G会带来空口链路（手机到基站之间无线传输链路）上带宽的提升和时延的降低，有利于移动端云游戏体验提升。
5G推动核心网与固网的交换节点下沉，带来整体网络路由的缩短。在4G及以前的时代，交换节点通常在省会和大城市，5G时代，交换节点会下沉到二、三线城市。
5G中有个很重要的一个节点MEC（Multi-Access Edge Computing）多接入边缘计算节点，在基站之后会很快的接入到MEC，MEC会作为一个交换节点，快速接入到固网中。我们可以在MEC之后紧跟着部署云游戏服务器，以降低用户到云游服务器间的时延。同时MEC也允许有线接入网的接入，对宽带用户的云游戏体验也有提升。