在2010年左右，OnLive、GA、NVIDIA等公司推出了云游戏产品，即是将游戏的计算、3D渲染等置于云端的服务器集群中，客户端仅用作显示，用户从而可以在性能稍弱的PC中获得流畅的游戏体验。这其中的主要技术是将游戏画面进行流媒体化（streaming），尽可能地减少传输带宽和客户端压力，同时保证用户的操作延时在可接受范围内，结构如图9-3。除了商业平台外，对此感兴趣的读者也可以查看其开源实现，比如Gaming Anywhere、Moonlight Game Streaming、Mishira等活跃项目。
图9-3 云游戏结构原理示意图
而前文提到的Virtual GL项目，则是这种实现的始作俑者。XWindows的早期实现便支持CS架构的访问，当服务器端运行大型3D程序时，其中的计算、渲染等命令是从服务器端通过网络传输至客户端，然后客户端再进行计算、渲染、显示，过程如图9-4所示。其中，Xlib负责应用程序XWindows窗口事件与命令操作，应用程序调用libGL时产生的处理指令会被GLX（XWindows的OpenGL扩展）发送到客户端，然后客户端X Server再进行3D计算、渲染后显示到本地。
图9-4 X W indows默认CS架构
这种架构的缺点是当应用程序比较复杂时则会占用大量带宽，同时对客户端的处理能力也是一种挑战。Virtual GL项目则主要将3D程序的计算、渲染与显示进行了服务器端转化成压缩的2D画面，然后客户端仅仅负责接收处理后的2D画面，如此一来便大大降低了带宽，原理如图9-5所示。
对spice协议了解的读者可能注意到两者的相似之处，图中VirtualGL与X Server（包括驱动）的组合即相当于spice协议中的QXL，X11命令、事件传递则可理解为发生在spice通道。
VirtualGL目前支持Linux、Solaris、MacOS（即OSX，仅客户端）、Windows（仅客户端），客户端可配合Java TurboVNC或其他VNC协议进行使用。
以Fedora 23的Mate Desktop（默认的Gnome 3需要硬件设备进行加速）为例，首先安装并配置VirtualGL。
图9-5 VirtualGL优化后的X W indows CS架构(www.xing528.com)
接下来在服务端中使用vglrun命令运行3D程序，以glxsphere64为例。
然后可使用任意VNC客户端到服务端，笔者同样在Windows中使用TurboVNC客户端进行连接，如图9-6所示。
图9-6 W indows中TurboVNC连接VirtualGL应用
最后如果成功连接即可在Windows客户端中看到如下画面，且可左下角的帧数对比VirtualGL与服务器上直接运行此应用的差异。
图9-7 GLX测试程序
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
