基于软件定义图形处理器的docker图像加速方法及系统与流程

1.本公开涉及图像处理领域，尤其涉及基于软件定义图形处理器的docker图像加速方法及系统。


背景技术：

2.在软件定义图形处理器(soft define graphics processing unit，简称为：sd-gpu)的概念后，势必引爆云游戏的概念。针对这种重度渲染的中大型手游来说，需要在云端部署能够进行安装的安卓虚拟机(android virtual machine，简称为：android vm)运行手游，需要有专业的图形图像渲染池支持三维(3dimensions，简称为：3d)渲染。对于手游来说，需要基于物理主机中央处理器(host central processing unit，简称为：host cpu)提供硬件载体，同时利用虚拟化技术，提供android vm，安装手游，并提供给用户使用，有两种提供虚拟化技术的方案，一种是使用全虚拟，基于内核虚拟机(kernel virtual machine，简称为：kvm)的方案，另外一种是基于linux上的docker容器技术的方案。基于kvm虚拟化方案的3d加速，可以使用sd-gpu方案进行，但对于容器虚拟化，可以使用的是基于host上的gpu进行加速。图一展示了基于docker容器的云游戏3d图像加速的典型场景图。
3.按照图1所示，在android docker使用host os上的gpu进行加速，对于android产生的3d图像渲染请求经过local host gpu渲染后，送入encode service流水线进行编码，将编码之后的音视频码流发送到client app进行解码，这样就能够看到3d game的图像，之后用户就可以在client app上进行操作，操作的时间反向发送回对应的android container中，完成游戏的操控互动。以上就是基于docker容器技术的android云游戏典型的方案。
4.在图1所示的典型方案中，具有如下的缺点：1.gpu渲染和docker计算节点在同一台主机，算力相互影响，导致游戏渲染高帧率情况下，host cpu成为瓶颈引起掉帧；2.gpu安装在host的主机上，受制于主板插槽最大数量限制，能够支持的渲染能力有限；3.gpu的驱动和显卡只能使用某一特定型号，无法突破nvidia/intel/amd显卡厂家设置的最大授权数量。


技术实现要素：

5.本公开实施例提供一种基于软件定义图形处理器的docker图像加速方法及系统，能够解决图形处理器渲染和docker计算节点在同一台主机，算力相互影响，导致游戏渲染高帧率情况下，host cpu成为瓶颈引起掉帧的问题。
6.所述技术方案如下：
7.根据本公开实施例的第一方面，提供一种基于软件定义图形处理器的docker图像加速方法，所述方法应用于软件定义图形处理器的docker图像加速系统中的第一服务器，所述软件定义图形处理器的docker图像加速系统包括：客户端、计算节点所在的第一服务器和软件定义图形处理器所在的第二服务器；所述方法包括：
8.启动docker并与所述第二服务器通过网络连接；
9.载入安卓镜像，启动安卓虚拟机；
10.生成游戏画面渲染请求和音视频数据，并将所述游戏画面渲染请求和所述音视频数据发送给所述第二服务器。
11.本公开提供一种基于软件定义图形处理器的docker图像加速方法，包括：启动docker并与第二服务器通过网络连接；载入安卓镜像，启动安卓虚拟机；生成游戏画面渲染请求和音视频数据，并将游戏画面渲染请求和音视频数据发送给第二服务器；以使第二服务器接收三维图像渲染请求和音视频数据后，并通过第二服务器上的三维计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；第二服务器在检测到客户端与第二服务器连接后，发送渲染数据和音视频数据给客户端；客户端播放和显示渲染数据和音视频数据。由于将渲染过程和计算过程分别由两台不同的服务器实现，从而可以解决计算节点和渲染节点的算力互扰的问题，带来持续稳定的高画质和高帧率。
12.在一个实施例中，所述方法还包括：
13.接收所述第二服务器发送操作信息，所述操作信息中包括：客户端标识和用户输入事件；
14.根据所述客户端标识确定对应的目标docker-android vm；
15.将所述用户输入事件注入所述目标docker-android vm中，以使所述docker-android vm将所述用户输入事件加载至对应的游戏应用，以使所述游戏应用根据所述用户输入事件进行游戏内部相应的响应，生成新的游戏画面渲染请求和音视频数据，并重新执行渲染流程。
16.在一个实施例中，所述将所述游戏画面渲染请求发送给所述第二服务器，包括：
17.通过所述第一服务器中的计算机图形库调用opengl指令；
18.通过所述所述第一服务器中的计算机图形库调用渲染截获指令，以将所述游戏画面渲染请求发送给所述第二服务器；所述渲染截获指令用于截获渲染指令并发送到外部。
19.根据本公开实施例的第二方面，提供一种基于软件定义图形处理器的docker图像加速方法，所述方法应用于软件定义图形处理器的docker图像加速系统中的第二服务器，所述软件定义图形处理器的docker图像加速系统包括：客户端、计算节点所在的第一服务器和软件定义图形处理器所在的第二服务器；所述方法包括：
20.启动服务并与所述第一服务器通过网络连接；
21.接收所述第一服务器发送的游戏画面渲染请求和音视频数据；
22.通过所述第二服务器上的计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；
23.在检测到所述客户端与所述第二服务器连接后，发送所述渲染数据和所述音视频数据给所述客户端，以使所述客户端播放和显示所述渲染数据和所述音视频数据。
24.本公开提供一种基于软件定义图形处理器的docker图像加速方法，包括：第二服务器接收第一服务器发送的游戏图像渲染请求和音视频数据，其中，游戏图像渲染请求和音视频数据是第一服务器在载入安卓镜像，并启动安卓虚拟机后生成的，通过第二服务器上的计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；在检测到客户端与第二服务器连接后，发送渲染数据和音视频数据给客户端，以使客户端播放和显示
渲染数据和音视频数据。其中，由于将渲染过程和计算过程分别由两台不同的服务器实现，从而可以解决计算节点和渲染节点的算力互扰的问题，带来持续稳定的高画质和高帧率。
25.在一个实施例中，所述方法还包括：
26.接收所述客户端发送的操作信息，所述操作信息中包括：客户端标识和所述用户输入事件，所述操作信息为所客户端在检测到用户输入事件后生成的；
27.将所述操作信息发送给所述第一服务器。
28.在一个实施例中，所述发送所述渲染数据和所述音视频数据给所述客户端，包括：
29.对所述渲染数据进行编码得到编码渲染数据；
30.对所述音视频数据进行编码得到编码音视频数据；
31.将所述编码渲染数据和所述编码音视频数据发送给所述客户端。
32.在一个实施例中，所述将所述编码渲染数据和所述编码音视频数据发送给所述客户端，包括：
33.将所述编码渲染数据和所述编码音视频数据分别发送给所述客户端；
34.或者，
35.将所述编码渲染数据和所述编码音视频数据进行混合，以得到具有2个通道的媒体文件流；
36.将所述媒体流文件发送给所述客户端。
37.在一个实施例中，所述对所述渲染数据进行编码得到编码渲染数据，包括：
38.在所述物理图形处理器内部对所述渲染数据进行编码得到编码渲染数据。
39.在一个实施例中，所述方法还包括：
40.在检测到所述客户端未与所述第二服务器连接，丢弃所述渲染数据和所述音视频数据。
41.根据本公开实施例的第三方面，提供一种基于软件定义图形处理器的docker图像加速系统，包括：客户端、计算节点所在的第一服务器和软件定义图形处理器所在的第二服务器；
42.其中，第一服务器用于执行上述任一项实施例中第一服务器对应的基于软件定义图形处理器的docker图像加速方法；
43.所述第二服务器用于执行上述任一项实施例中第二服务器对应的基于软件定义图形处理器的docker图像加速方法。
44.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
45.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
46.图1是本公开实施例提供的相关技术中基于sd-gpu的docker图像加速系统示意图；
47.图2是本公开实施例一提供的一种基于sd-gpu的docker图像加速系统示意图；
48.图3是本公开实施例二提供的一种基于sd-gpu的docker图像加速系统示意图；
49.图4是本公开实施例提供的基于sd-gpu的docker图像加速方法的流程图；
50.图5是本公开实施例提供的基于sd-gpu的docker图像加速方法的流程图；
51.图6是本公开实施例提供的基于sd-gpu的docker图像加速方法的流程图；
52.图7是本公开实施例提供的基于sd-gpu的docker图像加速方法的流程图。
具体实施方式
53.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
54.本公开实施例提供一种基于软件定义图形处理器的docker图像加速系统，如图2和图3所示，该系统可以很好解决如上面列举的几种问题，分离计算节点和渲染节点算力，池化图形处理器硬件，动态调配图形处理器的数量，来达到较为稳定的高帧率，取得高性能。系统包括：客户端11、计算节点所在的第一服务器12和软件定义图形处理器所在的第二服务器13，其中，客户端11、第一服务器12和第二服务器13是三个相对独立的硬件系统，三个系统之间可以通过万兆网络进行连接。
55.如图3所示，客户端11为图2中左边的部分所示的client app，该client app是云游戏客户端，运行在用户的手机上，负责用户接入云游戏系统；负责接收云游戏的编码画面，进行解码，图像显示，音频播放；以及负责发送用户的操作事件给到第二服务器上的input service模块。
56.计算节点对应的第一服务器12，负责管理和运行docker软件，负责启动安卓镜像androidimage，负责启动android容器container-android中的gameapp；第一服务器12具有sdgclient(sdg客户端)模块，该模块和第二服务器中的sdg server模块一一对应，同时具有音视频(audio)数据透传(redirect)能力，具有处理用户输入(input)事件redirect能力；第一服务器12具有假渲染(render wrapper)模块，该模块属于应用层图形处理器驱动模块，负责将mesa lib中生成的相关渲染请求截获，并将截获后的渲染指令发送到第二服务器13上对应用户的会话(session)中；audio模块负责将android系统产生的音频数据截获，发送到第二服务器13上的audio service模块，用于和图像数据最后的合成；input模块接收来自第二服务器13上的input service数据，包含用户的输入、触控、传感器数据，并将这些用户操作数据注入用户对应的android容器中，完成云游戏的操控。
57.软件定义图形处理器所在的第二服务器(也可以称之为：sd-gpu server)13提供用户接入后的session管理，负责在session中渲染游戏图像数据，对应渲染服务render service模块，编码图像数据和音频数据，对应encoderstream编码模块；负责将用户的反向操作事件接收后发送回第一服务器中的docker所在的sdg client中。同时，该第二服务器还具有管理插入该服务器的多张gpu，负责按照用户接入的数量，进行gpu资源的调度的能力。
58.如图4所示，为本公开提供的基于软件定义图形处理器的docker图像加速方法，该方法应用于如图2和图3所示的软件定义图形处理器的docker图像加速系统中的第一服务器，该方法包括：
59.101、启动docker并与第二服务器通过网络连接；
60.具体的，计算节点启动docker。
61.其中，第一服务器和第二服务器之间可以通过万兆网络进行连接。
62.102、载入安卓镜像，启动安卓虚拟机；
63.具体的，docker载入android镜像，并启动android vm。
64.103、生成游戏画面渲染请求和音视频数据，并将游戏画面渲染请求和音视频数据发送给第二服务器；
65.具体的，docker-android vm图形模块生成游戏画面渲染请求；docker-android生成音视频数据(audio data)。
66.在一个实施例中，将游戏画面渲染请求发送给第二服务器，包括以下子步骤a1-a2：
67.a1、通过第一服务器中的计算机图形库调用opengl指令；
68.其中，计算机图形库包括mesa库。
69.a2、通过第一服务器中的维计算机图形库通过渲染截获指令以将游戏画面渲染请求发送给第二服务器；其中，渲染截获指令用于截获渲染指令并发送到外部。
70.上述的渲染截获指令可以为render wrapper模块对应的功能。
71.具体的，第一服务器中的安卓的图形图像模块通过mesa lib(mesa库)调用opengl指令，mesa lib调用render wrapper模块，该render wrapper模块起到截获渲染指令，并发送到外部的能力；render wrapper模块发送渲染指令数据到第二服务器。
72.其中，mesa lib为开源opengl/opengl es实现库，适配多种显卡，例如：nvidia、intel和amd。
73.在一个实施例中，将音视频数据发送给第二服务器，包括：
74.audio redirect模块发送audio data给sdg server上的audio service模块。
75.本公开提供一种基于软件定义图形处理器的docker图像加速方法，包括：启动docker并与第二服务器通过网络连接；载入安卓镜像，启动安卓虚拟机；生成游戏画面渲染请求和音视频数据，并将游戏画面渲染请求和音视频数据发送给第二服务器；以使第二服务器接收三维图像渲染请求和音视频数据后，并通过第二服务器上的三维计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；第二服务器在检测到客户端与第二服务器连接后，发送渲染数据和音视频数据给客户端；客户端播放和显示渲染数据和音视频数据。由于将渲染过程和计算过程分别由两台不同的服务器实现，从而可以解决计算节点和渲染节点的算力互扰的问题，带来持续稳定的高画质和高帧率。
76.在一个实施例中，如图5所示，上述方法还包括以下子步骤：
77.104、接收第二服务器发送操作信息，该操作信息中包括：客户端标识和用户输入事件；
78.所客户端在检测到用户输入事件后，会向第二服务器发送操作信息，操作信息中包括：客户端标识和用户输入事件；
79.具体的，用户在客户端的app中进行操作后，例如点击屏幕或者操作轨迹球，翻转用户手机，产生重力传感数据等；客户端的app将产生的用户输入事件input event(包括输入的事件和传感器数据)和客户端标识通过第二服务器发送给第一服务器。
80.具体的，第二服务器上的input service模块接收用户输入事件后，将接收的用户输入事件，根据客户端标识发送回第一服务器上的docker-android所在的sdg client input redirect模块。
81.105、根据客户端标识确定对应的目标docker-android vm；
82.106、将用户输入事件注入目标docker-android vm中，以使docker-android vm将用户输入事件加载至对应的游戏应用，以使游戏应用根据用户输入事件进行游戏内部相应的响应，生成新的游戏画面渲染请求和音视频数据，并重新执行渲染流程。
83.具体的，sdg client input redirect模块根据客户端标识，注入用户对应的docker-android vm中；docker-android注入用户输入事件到game app中；game app根据用户输入事件进行游戏内部相应的响应，生成新的游戏画面渲染请求和音视频数据，同时进入下一次远程渲染流程。
84.值得注意的是，在上述实施例中对于用户和android docker镜像一一对应，以及登陆后和android vm的绑定没有进行描述，默认docker会根据用户创建和绑定唯一的android docker镜像，这些技术目前是本行业的惯常操作，因此在这里不在赘述。
85.同时，对于集群管理docker镜像，采用业界通用的k8s(kubernetes)架构，就可以实现批量的镜像管理和部署，该方法是docker比较通用的方法，因此在这里不在赘述。
86.以上步骤是本专利的一个典型的实现方式，可以看到，实际在设计中，对于基于docker容器的其他操作系统如linux，如果需要有3d图形加速需求的都可以采用本公开模式。
87.如图7所示，为本公开提供的基于软件定义图形处理器的docker图像加速方法，该方法应用于如图2和图3所示的软件定义图形处理器的docker图像加速系统的第二服务器中，该方法包括：
88.201、启动服务并与第一服务器通过网络连接；
89.具体的，sd-gpu server启动服务。
90.其中，第一服务器和第二服务器之间可以通过万兆网络进行连接。
91.202、接收第一服务器发送的游戏画面渲染请求和音视频数据；
92.具体的，第二服务器上的render service模块在收到三维图像渲染请求的同时，也会收到来自docker-android vm产生的音频数据。
93.203、通过第二服务器上的计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；
94.具体的，第二服务器上的render service模块在收到游戏画面渲染请求后；第二服务器调用第二服务器上的mesa lib，然后第二服务器上的mesa lib调用真正的物理gpu的驱动，进行图像渲染得到渲染数据。
95.204、检测客户端是否与第二服务器连接；
96.205、在检测到客户端与第二服务器连接后，发送渲染数据和音视频数据给客户端，以使客户端播放和显示渲染数据和音视频数据。
97.具体的，客户端一旦收到渲染数据和音视频数据，就进行解码，然后播放和显示解码后的渲染数据和音视频数据。
98.在一个实施例中，发送渲染数据和音视频数据给客户端，包括以下子步骤b1-b3：
99.b1、对渲染数据进行编码得到编码渲染数据；
100.示例的，在物理图形处理器内部对渲染数据进行编码得到编码渲染数据。
101.具体的，渲染完毕后，可以在gpu内部交由encoder进行编码，节省内存数据搬运，提高效率。
102.b2、对音视频数据进行编码得到编码音视频数据；
103.b3、将编码渲染数据和编码音视频数据发送给客户端。
104.示例的，可以将编码渲染数据和编码音视频数据分别发送给客户端；或者，可以将编码渲染数据和编码音视频数据进行混合，以得到具有2个通道的媒体文件流，然后将媒体流文件发送给客户端。
105.206、在检测到客户端未与第一服务器连接，丢弃渲染数据和音视频数据。
106.具体的，如果检测到client app连接到sdg server上，就发送渲染数据和音视频数据到client app。
107.本公开提供一种基于软件定义图形处理器的docker图像加速系统，包括：第二服务器接收第一服务器发送的游戏图像渲染请求和音视频数据，其中，游戏图像渲染请求和音视频数据是第一服务器在载入安卓镜像，并启动安卓虚拟机后生成的，通过第二服务器上的计算机图形库调用物理图形处理器的驱动，进行图像渲染得到渲染数据；在检测到客户端与第二服务器连接后，发送渲染数据和音视频数据给客户端，以使客户端播放和显示渲染数据和音视频数据。其中，由于将渲染过程和计算过程分别由两台不同的服务器实现，从而可以解决计算节点和渲染节点的算力互扰的问题，带来持续稳定的高画质和高帧率。
108.并且由于在sd-gpu对对应的第二服务器中可以设置多个gpu插槽，从而解决容器所在主机gpu插槽限制问题，可以根据需要进行扩展多个sd-gpu server，形成gpu池。
109.同时，本公开也可以解决三大显卡厂家对于显卡渲染编码授权数量的限制，提高服务器上使用gpu的密度，降低成本。
110.在一个实施例中，上述方法还包括以下步骤c1-c2：
111.c1、接收客户端发送的操作信息，操作信息中包括：客户端标识和用户输入事件，操作信息为所客户端在检测到用户输入事件后生成的；
112.具体的，用户在客户端的app中进行操作后，例如点击屏幕或者操作轨迹球，翻转用户手机，产生重力传感数据等；客户端的app将产生的用户输入事件input event(包括输入的事件和传感器数据)和客户端标识发送回第二服务器。
113.c2、将操作信息发送给第一服务器；
114.具体的，第二服务器上的input service模块接收用户输入事件后，将接收的用户输入事件，根据客户端标识发送回docker-android所在的sdg client input redirect模块。
115.以下通过图3和图7实施例详细介绍本公开的方案。
116.步骤1：计算节点启动docker；sd-gpu server启动服务，两个服务器连接成功；
117.步骤2：docker载入android镜像，启动android vm；
118.步骤3：docker-android vm图形模块生成游戏图像渲染请求；
119.步骤4：安卓的图形图像模块通过mesa库调用opengl指令；
120.步骤5：mesa库调用render wrapper模块；该render wrapper模块起到截获渲染指
令，并发送到外部的能力；
121.步骤6：render wrapper模块发送渲染指令数据到sdg server；
122.步骤7：docker-android生成audio data；
123.步骤8：audio redirect模块发送audio data给sdg server上的audio service模块。
124.步骤9：sdg server上的render service模块收到渲染指令；同时也会收到来自docker-android vm产生的audio码流；
125.步骤10：render service模块调用sdg server上的mesa库；
126.步骤11：sdg server上的mesa库调用真正物理gpu的驱动，进行图像渲染；
127.步骤12：渲染完毕后，在gpu内部交由encoder进行编码，节省内存数据搬运，提高效率；同时，将编码后得到的编码码流和audio码流进行混合成具有2个通道的媒体文件流；
128.步骤13：检测到客户端的用户client app是否连接到sdg server；
129.步骤14：如果检测到客户端的用户client app未连接到sdg server上，丢掉编码后的媒体文件流；
130.步骤15：如果检测到客户端的用户client app连接到sdg server上，就发送编码后的媒体文件流到客户端client app；
131.步骤16：客户端的app一旦收到媒体文件流，就进行解码；
132.步骤17：客户端的app播放和显示解码后的媒体文件流；
133.步骤18：用户在客户端app中操作，例如点击屏幕或者操作轨迹球，翻转用户手机，产生重力传感数据等；
134.步骤19：客户端app将产生的input event发送回sdg server；
135.步骤20：sdg server上的input service模块接收input event，并将接收的数据，根据用户信息(上述实施例中的客户端标识)发送回docker-android所在的sdg client input redirect模块；
136.步骤21：sdg client input redirect模块根据客户端标识，注入对应的docker-android vm中；
137.步骤22：docker-android加载input event到game app中；
138.步骤23：game app根据input event进行游戏内部相应的响应，生成新的游戏画面渲染请求和音视频数据，同时进入下一次远程渲染流程；
139.以上的步骤中，对于音频和视频数据的混合不是必须，完全可以将视频数据、音频数据单独发送到用户的clientapp上，也可以实现音视频的解码和播放。
140.本公开实施例还提供一种基于软件定义图形处理器的docker图像加速系统，包括：客户端、计算节点所在的第一服务器和软件定义图形处理器所在的第二服务器；
141.其中，第一服务器用于执行上述任一项实施例中第一服务器对应的基于软件定义图形处理器的docker图像加速方法；
142.所述第二服务器用于执行上述任一项实施例中第二服务器对应的基于软件定义图形处理器的docker图像加速方法。
143.基于上述第一服务器对应的基于软件定义图形处理器的docker图像加速方法，本公开实施例还提供一种基于软件定义图形处理器的docker图像加速装置，可以用于执行本
公开中第一服务器对应的基于软件定义图形处理器的docker图像加速方法。
144.基于上述第二服务器对应的基于软件定义图形处理器的docker图像加速方法，本公开实施例还提供一种基于软件定义图形处理器的docker图像加速装置，可以用于执行本公开中二服务器对应的基于软件定义图形处理器的docker图像加速方法。
145.基于上述第一服务器对应的基于软件定义图形处理器的docker图像加速方法，本公开实施例还提供一种计算机可读存储介质，例如，非临时性计算机可读存储介质可以是只读存储器(英文：read only memory，rom)、随机存取存储器(英文：random access memory，ram)、cd-rom、磁带、软盘和光数据存储装置等。该存储介质上存储有计算机指令，用于执行本公开中第一服务器对应的基于软件定义图形处理器的docker图像加速方法，此处不再赘述。
146.基于上述第二服务器对应的基于软件定义图形处理器的docker图像加速方法，本公开实施例还提供一种计算机可读存储介质，例如，非临时性计算机可读存储介质可以是只读存储器(英文：read only memory，rom)、随机存取存储器(英文：random access memory，ram)、cd-rom、磁带、软盘和光数据存储装置等。该存储介质上存储有计算机指令，用于执行本公开中第二服务器对应的基于软件定义图形处理器的docker图像加速方法，此处不再赘述。
147.本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
148.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。