论文1：LiveRender: A Cloud Gaming System Based on Compressed Graphics Streaming
论文要解决的问题
服务器端通过使用对图形流（Graphic Stream）进行压缩传输至客户端，并由客户端进行渲染，以解决传统基于流的远端渲染产生的高带宽和可扩展性差的问题
系统架构
系统架构如下图所示，其中LiveRender需要处理三种数据：图形命令、图形数据（包括顶点、indices、法向量等）、纹理数据
服务器侧
LiveRender在服务器侧实现一个代理库用于拦截图形命令和数据，并将其传输至客户端进行渲染。Cache管理器模块负责存储可以重用的图形命令、图形数据和纹理数据。几何压缩器模块用于对顶点和indices数据进行帧内和帧间压缩。
客户端侧
用于处理输入和图形渲染
客户端-服务器交互
本文对比了LiveRender和GamingAnyWhere两种云游戏系统因为交互导致的响应延迟。
对于GamingAnyWhere，SP过程包括处理输入、渲染图形和生成H.264视频流。CP过程表示解码和显示图像。
对于LiverRender，PS过程包括图形命令以及相关数据的打包分批发送，客户端收到第一个batch便开始渲染，PO表示传输过程、服务器处理过程和客户端处理过程的并行过程，PE表示从全部数据传输至客户端到渲染完所有batch。
图形压缩和状态同步
帧内压缩
基于二次误差度量实现帧内压缩，以简化图形的顶点数据
算法如下
此外，本文针对帧内压缩提出两种策略：
- 对每个模型只进行一次简化，如果模型后续发生变化，则重新通过indices进行映射。
- 只对更新频繁的模型进行简化
帧间压缩
由于连续帧之间的关联性，采用帧间压缩可以减少几何数据的冗余
将帧分为原始帧（O帧）和衍生帧（D帧），将帧序列转换为O,D1,D2,…,Dk,O…,这里的k是O帧的间隔。D帧只保留图形命令数据和纹理数据。几何数据通过相邻的两个O帧恢复出来。 实验表明k=1可以在开销和性能之间取得一个权衡。
缓存机制（Caching）
LiveRender缓存机制处理三种数据：图形命令，几何数据和纹理。
图形命令
在较短的时间段内，渲染所使用的图形命令较为接近，部分图形命令会被频繁调用。
缓存过程：Server端维护一个hash表用于插入，查找和删除缓存。客户端使用数组维护缓存。当一个新的命令被拦截，服务器端首先计算这个命令对应的hash code，然后查找在hash表中查找此项，如果命中，则服务器端向客户端发送一个index，用于在客户端检索命令存放的位置。如果没有命中，则服务器端向客户端发送完整的命令。
图形数据和纹理
对于图形数据：如果一个模型只有一小部分的数据被更新，则只传输这一部分数据即可。
对于纹理：纹理在游戏开始前预加载到客户端，后续新的纹理随着游戏的进行不断传输至客户端,注意每一个纹理只被传输一次。
延迟同步
在服务器侧，维护一个抽象设备模型，用于模拟客户端GPU所有的状态（包括光照，视角，转换矩阵等，个人认为这里的状态表述不明确，可以理解为GPU 常量缓冲区所存的数据），服务器侧检查状态值，只有被修改的数据将被传输到客户端以保证同步。
实验及分析
这里就不枚举实验了，直接上结论。
由于本系统的渲染过程不需要在服务器端运行，因此服务器端可同时服务更多的客户端，此外，由于对需要传输的数据进行了压缩和缓存，因此大幅地减少了带宽。
以下是个人见解：本系统虽然有效地降低了带宽传输，但是由于游戏的主要部分“渲染”被放到了本地，这导致一部分在shader中需要进行复杂运算的游戏并不适用于本系统。此外，随着带宽的不断提高，服务器端压缩数据的过程便成为瓶颈
论文2： Kahawai: High-Quality Mobile Gaming Using GPU Offload
论文要解决的问题
通过移动客户端和服务器端协同渲染以减少传输带宽和移动客户端能耗
系统架构
Kahawai实现了两种协同渲染技术，分别是delta encoding和client-side I-frame rendering
delta encoding
移动客户端渲染低细节帧，服务器端分别渲染低细节帧和高细节帧，并将其差值通过H.264编码传输至移动客户端。
client-side I-frame rendering
移动客户端渲染高分辨率的I帧；服务器端渲染所有帧，在进行H.264编码后丢弃所有的I帧，转换为placeholder，并传输至客户端；客户端接收到仅包含P帧的输出后，将I帧插入进去，并进行H.264解码得到最终的输出。
实现细节
delta encoding
由于具有不同细节等级的输出具有相似的信息，因此编码高质量和低质量版本的帧的差值比编码高质量帧所需要的bit更少。虽然在某些情况下会出现反例，但大多数都符合这个情况。
此外，delta encoding具有以下两种挑战：
- 差值的压缩导致在最终恢复图像时产生黑点
这是由于高细节帧的像素和低细节帧的像素之间的差值可以是正的也可以是负的，需要额外的符号位，因此为了简化，采用模运算作为一个简单的解决方案。下图是原文中的一个例子。
本文通过如下公式(1)将值转换为正值，并通过式(2)在客户端进行恢复。
- 被编码的差值无法精确表示高细节帧和低细节帧的差异
其主要原因是有损压缩，压缩产生的误差与高清晰度和低清晰度帧的相似程度成反比。如果高清晰度和低清晰度的帧之间差距较大，相比于直接传输H.264编码的高细节帧需要更高的带宽，并会产生更大的误差。比如，下面两个例子：
其中图5的例子的差值相比于高清晰度帧来说更难压缩。
Client-side I-frame rendering
移动客户端能够渲染的I帧帧率越高，服务器端传输所需的带宽越低。
在传统的H.264中如果I帧越多，由于I帧所含的信息量较高，因此所需的带宽越高。但是在Client-side I-frame rendering就不会存在这种问题，这是由于I帧在客户端渲染，并不会被服务器端传输。
Kahawai实现
基于开源游戏引擎idTech4和闭源游戏街霸4分别实现了该系统。
该系统的实现主要存在以下3个挑战：
- 支持确定性的图形输出；
- 输入处理
- 针对两种协同渲染技术实现编解码支持
确定性图形输出
对于delta encoding，客户端的低分辨率输出必须与服务器端的低分辨率输出相匹配。
对于Client-side I-frame rendering，客户端的I帧必须与服务器端的I帧相匹配。
本文通过服务器端的游戏实例重播移动客户端的输入来达到输出的匹配。但由于在底层实现重播会产生较高的开销，这会导致用户体验变差。另一方面，将重播与游戏的内部逻辑纠缠在一起是不切实际的。
Kahawai采取了一种折中的方案，即kahawai不需要完全重播所有的游戏执行，只要产生相同的画面即可。比如，服务器端的渲染不需要产生于客户端相同的文件写入或线程调度。
渲染线程的代码如下：
其中Frame()用于更新游戏状态（如光照，视角，转换矩阵等），UpdateScreen用于渲染并输出至屏幕。
有三种不确定性因素会影响idTech引擎的渲染线程的输出：
- 系统时间：Kahawai通过拦截渲染中的GetSystemTime调用以确保重播执行时使用相同的时间值。
- 伪随机数生成器：正确的重播键盘和鼠标输入便可以使得伪随机数生成器的是确定的。
- 游戏音乐：有些游戏的光照等依照于音乐的响度，Kahawai将音乐播放时对应的系统时间记录下来，依照该系统时间进行渲染。
当服务器连接中断时，客户端将继续采取低分辨率的渲染继续执行，并执行以下步骤:
- 游戏继续执行直到游戏被保存
- 暂停执行
- 将当前状态发送至服务器端
- 当服务器确定已经完成恢复游戏状态后继续执行。
输入处理
挑战：代码中，当Frame和UpdateScreen处理第N帧时，系统在缓存第N+1帧的事件。为保证服务器端和客户端同步，Kahawai必须确保当客户端再处理第N帧的输入时，服务器端页必须处理第N帧的输入。为保证这一点，客户端需要将渲染线程的事件戳输入和适当的帧号发送至服务器端，当接收到下一帧的输入之前，服务器将暂停。
pipeline的总结
图中不同的符号意思如下
编解码支持
对于client-side I-frame，本文使用x264在可预测的间隔生成I帧
，然后将编码视频中的I帧丢弃，将被压缩的P帧和placeholder传输至移动客户端。在移动客户端，使用帧捕捉来确定提取被渲染的I帧，并将其插入至视频流中，最终通过ffmpeg进行解码。
实验及分析
直接上结论：
- 本文实现的两种系统在用户体验方面与thin-client策略类似；
- 在相同的画面质量下，本文实现的两种系统所需的带宽更低，但随着画面质量的增加，本文实现系统与thin-client的差距会减小，这是由于delta encoding的细节变多
- Kahawai部署在在局域网或附近的CDN的服务器中性能最好
以下是个人见解：delta encoding由于高清晰度和低清晰度帧的差值较大时表现不佳，因此该方法不能轻松适配于全部游戏。此外，该系统没有考虑负载均衡，这使得系统具有更进一步优化的空间。
论文3：Layered Coding for Mobile Cloud Gaming
论文要解决的问题
提出一种分层编码的框架，以减少传输码率和带宽，并证明该框架在云游戏场景下优于H.264/AVC编码
系统架构
服务器端分别渲染一个高质量IHQ和低质量（base-layer）IBL的画面,客户端只渲染与服务器端同样的低质量画面。高质量和低质量画面的差值被称为（enhencement layer）IEL。
关系如下：
IEL使用H.264编码进行转换，并传输至客户端，由客户端进行解码，并与低质量画面合并得到最终的高质量画面。
此外，为客户端能够渲染低画质的画面，需要将3D模型和渲染指令传输至客户端。
Base layer pipeline的设计
本文认为，在多边形的建模中，base layer的计算复杂度与多边形的数量（这里的数量可以理解为base layer中使用的多边形与高质量画面使用的多边形的比例）线性相关。
通过衡量IEL的信息熵以估计被压缩的IEL的码率。实验表明，base layer中使用10%的多边形，IEL便会产生相比于IHQ50%的信息。
光照算法
phong光照模型
本文衡量了当客户端采用简化的光照模型时，enhencement layer所需包含的信息量。
当IBL渲染完整的光照模型时,enhencement layer包含的信息量HEL为0,如果IBL不进行渲染时，则HEL = HHQ
全局光照和纹理映射
全局光照由于计算过于复杂，仅考虑放在服务器端。
纹理信息也仅考虑放在服务器端
实验及分析
直接上结论，分层的框架相比于thin-client模式，在相同的画面质量下，需要更少的码率。
以下是个人见解本文分析了不同渲染操作所需计算量与画面包含信息量的关系，但论文中的表述存在部分问题，比如没有确切证据可以表明”画面的计算复杂度与多边形数量相关”，因为在顶点着色器后，片元着色器的计算负载通常更高
对比
三篇论文均考虑到云游戏场景中带宽的限制导致在thin client模式下游戏帧率主要取决于网络延迟，因此分别使用了不同的方法将渲染的部分计算量offload到client端。
对于论文1而言，由于全部的渲染计算均在客户端进行，服务器端相当于充当传统渲染管线中的内存和CPU的角色，而客户端相当于充当GPU的角色，因此当采用全局光照等高计算负载的渲染逻辑时，该系统并不能很好的发挥其性能。
对于论文2和论文3而言，他们分别将一部分渲染负载offload到client端，而另一部分在服务器端，通过在客户端合并的方式，将最终画面呈现给用户。其中论文2的所提出的两种模式并不能很好地保证负载均衡，而论文3中所提的负载的计算存在些许问题，需要改进。
完成日期：2020-7-2 15:30