图形处理器中的任务处理方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，更具体地，涉及一种图形处理器中的任务处理方法、装置、电子设备及存储介质。

背景技术

游戏应用中游戏画面的渲染和视频流编码是在图形处理器中实现的，随着对游戏画面的画质和分辨率等提出更高的要求，需要提高图形处理器中任务的处理效率。因此，如何提高图形处理器中任务的处理效率是现有技术中亟待解决的技术问题。

发明内容

鉴于上述问题，本申请实施例提出了一种图形处理器中的任务处理方法、装置、电子设备及存储介质，以提高图形处理器中的任务处理效率。

根据本申请实施例的一个方面，提供了图形处理器中的任务处理方法，应用于内核态中的虚拟驱动，所述方法包括：接收用户态进程发起的任务处理请求；所述任务处理请求包括所请求处理的基础数据的虚拟地址；所述虚拟地址是将各物理图形处理器的内存地址进行虚拟化得到的；响应于所述任务处理请求，获取所述各物理图形处理器的负载信息；根据所述各物理图形处理的负载信息，为所述任务处理请求分配第一物理图形处理器；根据所述基础数据的虚拟地址，获取所述基础数据并将所述基础数据拷贝至所述第一物理图形处理器；调用所述第一物理图形处理器中的驱动，以在所述第一物理图形处理器中基于所述基础数据执行所述任务处理请求所指示的处理任务。

根据本申请实施例的一个方面，提供了一种图形处理器中的任务处理装置，应用于内核态中的虚拟驱动，所述装置包括：接收模块，用于接收用户态进程发起的任务处理请求；所述任务处理请求包括所请求处理的基础数据的虚拟地址；所述虚拟地址是将各物理图形处理器的内存地址进行虚拟化得到的；负载信息获取模块，用于响应于所述任务处理请求，获取所述各物理图形处理器的负载信息；分配模块，用于根据所述各物理图形处理的负载信息，为所述任务处理请求分配第一物理图形处理器；拷贝模块，用于根据所述基础数据的虚拟地址，获取所述基础数据并将所述基础数据拷贝至所述第一物理图形处理器；调用模块，用于调用所述第一物理图形处理器中的驱动，以在所述第一物理图形处理器中基于所述基础数据执行所述任务处理请求所指示的处理任务。

在本申请的一些实施例中，基于前述方案，拷贝模块包括：第一物理内存地址确定单元，用于根据虚拟地址与物理内存地址之间的映射关系，确定所述基础数据的虚拟地址对应的第一物理内存地址；基础数据获取单元，用于根据所述第一物理内存地址从对应的物理图形处理器中获取所述基础数据；拷贝单元，用于根据在所述第一物理图形处理器中为所述基础数据分配的第二物理内存地址，将所获取到的所述基础数据拷贝到所述第一物理图形处理器中。

在本申请的一些实施例中，基于前述方案，图形处理器中的任务处理装置还包括：第一内存申请模块，用于在所述第一物理图形处理器上进行内存申请，获得所述处理任务所对应计算结果的第三物理内存地址，以在执行所述任务处理请求所指示的处理任务过程中按照所述第三物理内存地址进行所对应计算结果的存储；计算结果获取模块，用于根据所述第三物理内存地址，从所述第一物理图形处理器中获取所述任务处理请求对应的计算结果；计算结果拷贝模块，用于将所获取到的所述计算结果拷贝到所述计算结果所对应虚拟地址指示的位置处，以使所述用户态进程根据所述计算结果所对应虚拟地址获取对应的计算结果。

在本申请的一些实施例中，基于前述方案，所述第三物理内存地址所指示的第一内存量与第二内存量相等，所述第二内存量是所述任务处理请求所对应计算结果的虚拟地址所指示的内存量；图形处理器中的任务处理装置还包括：第二内存申请模块，用于为所述任务处理请求所对应计算结果进行图形处理器内存申请，获得为所述任务处理请求所对应计算结果分配的虚拟地址。

在本申请的一些实施例中，基于前述方案，图形处理器中的任务处理装置还包括：内存申请请求接收模块，用于接收所述用户态进程发送的内存申请请求；虚拟地址分配模块，用于根据所述内存申请请求所请求申请的内存量和所述各物理图形处理器的存储状态信息，为所述用户态进程分配所述基础数据的虚拟地址；虚拟地址返回模块，用于向所述用户态进程返回所述基础数据的虚拟地址。

在本申请的一些实施例中，基于前述方案，所述任务处理请求包括所要调用的接口的接口标识；所述任务处理请求是通过用户态中的预设图形库转发至所述虚拟驱动的；调用模块进一步被配置为：调用所述第一物理图形处理器中的驱动，以在所述第一物理图形处理器中根据所述接口标识调用对应的接口，由所调用的接口根据所述基础数据执行所述任务处理请求所指示的处理任务。

在本申请的一些实施例中，基于前述方案，所述处理任务包括渲染任务，所述负载信息包括物理图形处理器中渲染管线的占用信息；分配模块进一步被配置为：根据各物理图形器中渲染管线的占用信息，确定渲染管线可用于所述任务处理请求所指示渲染任务的第一物理图形处理器。

在本申请的一些实施例中，基于前述方案，所述处理任务包括视频编码任务；所述负载信息包括物理图形处理器中视频编码器的占用信息；分配模块进一步被配置为：根据各物理图形器中视频编码器的占用信息，确定视频编码器可用于所述任务处理请求所指示视频编码任务的目标图形处理器。

在本申请的一些实施例中，基于前述方案，图形处理器中的任务处理装置还包括：第一接收模块，用于接收用户态进程发起的下一次任务处理请求；确定模块，用于若所述下一次任务处理请求对应的基础数据包括所述任务处理请求对应的计算结果，且所述第一物理图形处理器中的剩余处理资源满足所述下一次任务处理请求所请求的处理资源，则确定在所述第一物理图形处理器上执行所述下一次任务处理请求。

在本申请的另一些实施例中，基于前述方案，图形处理器中的任务处理装置还包括：第二接收模块，用于接收用户态进程发起的下一次任务处理请求；第二分配模块，用于根据各物理图形处理器的负载信息，分配满足所述下一次任务处理请求所请求处理资源的第二物理图形处理器，所述第二物理图形处理器不同于所述第一物理图形处理器；第二拷贝模块，用于若所述下一次任务处理请求对应的基础数据包括所述任务处理请求对应的计算结果，则根据在所述第二物理图形处理器上为所述下一次任务处理请求对应的基础数据所分配的第四物理内存地址，将所述任务处理请求对应的计算结果拷贝至所述第二物理图形处理器。

根据本申请实施例的一个方面，提供了一种电子设备，包括：处理器；存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如上所述图形处理器中的任务处理方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被处理器执行时，实现如上所述图形处理器中的任务处理方法。

在本申请的方案中，通过内核态中的虚拟驱动将用户态进程与物理图形处理器中的驱动相隔离开，由内核态中的虚拟驱动将用户态进程发起的任务处理请求进行转发，实现了在内核态中进行多个物理图形处理器的调度，可以有效利用多个物理图形处理器中的处理资源，相较于单图形处理器中的任务处理，本方案可以有效提高任务处理的效率；而且本方案实现了多个物理图形处理器的负载均衡，实现了多个物理图形处理器上的内存的联动，能够发挥多个物理图形处理器的算力。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本申请一实施例示出的实施环境的示意图。

图2是根据本申请一实施例示出的服务器的架构图。

图3是根据本申请的一个实施例示出的图形处理器中的任务处理方法的流程图。

图4是根据本申请一实施例示出的步骤340的流程图。

图5是根据本申请一实施例示出的步骤340之前步骤的流程图。

图6是根据一具体实施例示出的图形处理器中的任务处理方法的流程图。

图7是根据本申请一实施例示出的步骤350之后步骤的流程图。

图8是根据本申请另一实施例示出的步骤350之后步骤的流程图。

图9是根据本申请一实施例示出的图形处理器中的任务处理装置的框图。

图10示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在进行具体描述之前，先对本申请涉及的名词进行解释。

GPU：Graphics Processing Unit，图形处理器，又称显示核心、视觉处理器、显示芯片，是在计算机设备(例如个人电脑、游戏机、工作站、服务器)上进行图像等并行处理的微处理器。在本方案的描述中，为便于区分物理的图形处理器与虚拟的图形处理器，将图形处理器称为物理图形处理器。

vGPU:virtual GPU，虚拟GPU。通常是指把一个物理GPU虚拟化为多个逻辑GPU，且虚拟的逻辑GPU之间提供一定的资源隔离。

API Forward:API转发，是实现软件虚拟化的一种方法。通常是A调用虚拟化后的软件包B，然后B把调用指令转发给进程C，最终由进程C调用真实的软件包B`，其是通过应用层的代理进程来转发指令。

NVLink：是英伟达(NVIDIA)开发并推出的一种总线及其通信协议。NVLink采用点对点结构、串列传输，用于中央处理器(CPU)与图形处理器(GPU)之间的连接，也可用于多个图形处理器之间的相互连接。

Vulkan:是一个跨平台的2D和3D绘图应用程序接口(API)。

GLSL:OpenGL Shading Language，OpenGL着色语言，是用来在OpenGL中着色编程的语言，也即开发人员写的短小的自定义程序，它们是在图形卡的GPU(Graphic ProcessorUnit图形处理单元)上执行的，代替了固定的渲染管线的一部分，使渲染管线中不同层次具有可编程性。

云游戏(Cloud gaming)又可称为游戏点播(gaming on demand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

用户对于云游戏的画面的画质和分辨率提出了更高的要求，而游戏画面的画质、分辨率等的提升对于图形处理器中任务处理的效率提出了更高要求，因此，如何提高任务处理器中任务处理效率是现有技术中亟待解决的技术问题。

图1是根据本申请一实施例示出的实施环境的示意图。如图1所示，系统架构可以包括终端110,、网络120和服务器130。网络120用以在终端110和服务器130之间提供通信链路的介质。网络120可以包括各种连接类型，例如有线通信链路、无线通信链路等等。

服务器130可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端110可以是智能手机、平板电脑、笔记本电脑、台式计算机、车载终端、游戏终端、智能电视等，但并不局限于此。应该理解，图1中的终端110、网络120和服务器130的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端、网络和服务器。

在本申请的一些实施例中，服务器130中设有多个物理图形处理器，该服务器130可以作为云游戏的服务端，按照本申请的方案，利用多个物理图形处理器的并行处理能力，将云游戏的游戏画面渲染为视频流；再向终端110发送该视频流。

图2是根据本申请一实施例示出的服务器的架构图。该服务器可以是游戏服务器，其可用于进行游戏画面的渲染。如图2所示，服务器上设有多个物理图形处理器：GPU1、GPU2、......、GPUn。

在图2所示服务器的操作系统按照运行级别，将程序分为处于用户态运行级别的程序和处于内核态运行级别的程序。用户态和内核态是操作系统的两种运行级别，两者最大的区别就是特权级不同。用户态拥有最低的特权级，内核态拥有较高的特权级。运行在用户态的程序不能直接访问操作系统内核数据结构和程序。如果一个程序运行在特权态，则该程序就可以访问计算机的任何资源，即它的资源访问不受限制。如果一个程序运行在用户态，则其资源需求将受到各种限制。

如图2所示，运行在用户态的程序包括Docker容器210，该容器来隔离服务器上的多个游戏进程211和资源，所隔离的资源主要是CPU(中央处理器，Central ProcessingUnit)、内存、可见GPU等。同时Docker容器也是一种云端的发布和运维技术体系，通过Docker容器可以提升云游戏在运营部署过程中的效率。当然，在其他实施例中，还可以通过其他容器来隔离游戏进程。

游戏进程211可以是基于Linux系统开发，使用unity/unreal等游戏引擎来构建，下层依赖Vulkan图形库中的API。游戏进程在Docker容器的限定下使用CPU、主机内存、GPU等资源，通过网络通讯接口来接收用户输入；在完成游戏画面渲染后，编码为视频流，然后通过网络将视频流发送给用户所在客户端。

/proc文件系统220是一个特殊的文件系统，用来允许用户空间的程序访问内核中的某些信息(比如进程信息在/proc/[0-9]+/中)。在Linux系统中，该/proc文件系统作为Linux内核向用户态暴露信息的方式，具体在本方案中，通过/proc文件系统中一个虚拟的文件向用户态暴露驱动层的部分信息。

Vulkan图形库230，其遵循业界标准的图形API(Application ProgrammingInterface，应用编程接口)的设计，提供了与本方案中的虚拟驱动相配合的图形API。对游戏进程而言，图形库是Linux系统目录下的一个或多个.so文件。该Vulkan图形库230可视为下文中的预设图形库。

/dev/master_gpu文件240，是用于虚拟一个GPU的设备文件，游戏进程可以通过这个设备文件来使用虚拟的GPU，以最终在这个虚拟GPU上实现了多个物理GPU的资源(例如GPU的占用率(算力)、GPU内存、PCI-E总线带宽)等的管理。

虚拟驱动250，是可以在内核态加载的驱动程序，当该虚拟驱动被加载后：在/dev/master_gpu文件中虚拟出一个额外的GPU；通过/proc文件系统来提供内部的状态信息；可以通过Vulkan api图形库来与驱动通信。

在虚拟驱动250中包括渲染管理模块251、任务队列252、GPU内存虚拟化模块253。其中，渲染管理模块251用于管理多个物理GPU中的渲染管线，例如进行渲染管线分配等。任务队列252用于对上层提供的各种计算任务进行排队、分发，还包括在云游戏环境中的视频编码任务的管理。GPU内存虚拟化模块253，用于把多块物理GPU的内存进行虚拟化，提供虚地址映射来把所有物理GPU上的内存进行统一管理。

请继续参阅图2所示，运行在内核态的程序还包括GPU厂商提供的GPU内核模块260，该GPU内核模块260是用于驱动物理GPU。虚拟驱动250最终要把用户进程的API调用转换成GPU内核模块260中驱动接口的调用。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图3示出了根据本申请的一个实施例示出的图形处理器中的任务处理方法的流程图，该方法可以由设有多个图形处理器的计算机设备执行，例如图1中的服务器等，在此不进行具体限定，具体的，该方法由在内核态中的虚拟驱执行。参照图3所示，该方法至少包括步骤310至350，详细介绍如下：

步骤310，接收用户态进程发起的任务处理请求；任务处理请求包括所请求处理的基础数据的虚拟地址；虚拟地址是将各物理图形处理器的内存地址进行虚拟化得到的。

在本方案中，虚拟驱动是在内核态中用于进行请求转发的中间层。在现有技术中，用户态进程发起的任务处理请求是直接发送到物理图形处理器中的驱动，而在本方案中由于加载了该虚拟驱动，用户态进程发起的任务处理请求并不是直接发送到物理图形处理器中的驱动，而是先将任务处理请求发送到虚拟驱动，然后由该虚拟驱动将任务处理请求转发到物理图形处理器中。

用户态进程是指运行在用户态的进程，进程是系统进行资源分配和调度的基本单位，是操作系统结构的基础。该用户态进程例如图2中的游戏进程。

该任务处理请求用于请求物理图形处理器进行处理。在本申请的一些实施例中，任务处理请求可以指示所需要物理图形处理器中的处理资源，处理资源例如物理图形处理器中内存、GPU占用率等。

在本申请的方案中，基于所加载的虚拟驱动，将多个物理图形处理器虚拟化为一个虚拟图形处理器，并且，将多个物理图形处理器中的内存地址进行了虚拟化，提供了各物理图形处理器的虚拟地址。

由于相互独立的物理图形处理器的内存地址是不连续的，而通过对物理图形处理器的地址进行虚拟化，可以将多个物理图形处理器的内存地址转换成连续的虚拟地址，提供给用户态中的程序的是物理图形处理器的虚拟地址，而不是物理图形处理器的物理内存地址，实现了物理图形处理器中内存地址的虚拟化。对于用户态的程序而言，该多个物理图形处理器被虚拟化为一个虚拟的图形处理器。

基础数据是指该任务处理请求所请求进行处理的数据，例如，若任务处理请求是请求进行游戏画面渲染，则该任务处理请求的基础数据为待进行渲染的游戏画面。又例如，若任务处理请求对两个矩阵进行计算，则该任务处理请求的基础数据为该两个矩阵。

在步骤310之前，需要在内核态加载该虚拟驱动，从而，虚拟驱动可以对应接收用户态进程发起的任务处理请求。在本申请的一些实施中，在加载虚拟驱动后，在用户态的/dev/master_gpu文件中虚拟出一个虚拟GPU，对于用户态进程，基于该虚拟GPU发起任务处理请求。

步骤320，响应于任务处理请求，获取各物理图形处理器的负载信息。

计算机设备中设有多个物理图形处理器，每个物理图形处理器之间可以通过PCI-E总线与计算机设备的主板相连。该多个物理图形处理器之间可以采用NVLink总线协议通信，从而，在物理图形处理器之间可以通过利用该NVLink总线协议进行高效的数据拷贝。在其他实施例中，物理图形处理器之间可以采用PCI-E总线协议通信。

物理图形处理器的负载信息可以包括GPU的占用率(GPU的算力)、GPU内存、渲染管线的占用信息、视频编码器的占用信息等。

步骤330，根据各物理图形处理的负载信息，为任务处理请求分配第一物理图形处理器。

第一物理图形处理器是指所分配用于执行任务处理请求的物理图形处理器。根据各物理图形处理器的负载信息可以确定各物理图形处理器的剩余处理资源，进而确定各物理图形处理器的剩余处理资源是否可以承担执行任务处理器请求所需的处理资源，将剩余处理资源可以承担执行任务处理请求所需的处理资源的物理图形处理器确定为第一物理图形处理器。

在本申请的一些实施例中，可以将多个物理图形处理器中剩余处理资源最多(相当于是最不繁忙的)的物理图形处理器确定为第一物理图形处理器。

在本申请的一些实施例中，任务处理请求所指示的处理任务包括渲染任务，负载信息包括物理图形处理器中渲染管线的占用信息；在该实施例中，步骤330，包括：根据各物理图形器中渲染管线的占用信息，确定渲染管线可用于任务处理请求所指示渲染任务的第一物理图形处理器。

渲染管线，又称渲染流水线，是物理图形处理器内部处理图形信号相互独立的并行处理单元。在物理图形处理器中，通过渲染管线来执行图像渲染。

在任务处理请求所指示的处理任务包括渲染任务的情况下，根据各物理图形处理器中渲染管线的占用信息，将渲染管线资源充足的物理图形处理器确定为第一物理图形处理器，以此保证第一物理图形处理器中的渲染管线满足执行任务处理请求所指示渲染任务的渲染管线资源需要。

在本申请的一些实施例中，处理任务包括视频编码任务；负载信息包括物理图形处理器中视频编码器的占用信息；在该实施例中，步骤330包括：根据各物理图形器中视频编码器的占用信息，确定视频编码器可用于任务处理请求所指示视频编码任务的目标图形处理器。

视频编码器用于进行音视频编码。在云游戏场景下，可以通过物理图形处理器将游戏画面进行渲染后，再将渲染后的游戏画面编码为视频流。相比GPU中的图像渲染而言，GPU上的视频编码一般不会出现瓶颈，但是在要求高帧率和高分辨率的场景下，可能导致GPU中的视频编码器资源不足，在这种情况，可以采用本申请的方案利用多个物理图形处理器中的视频编码器来进行编码。

在任务处理请求所指示的处理任务包括视频编码任务的情况下，根据各物理图形处理器中视频编码器的占用信息，将视频编码器资源充足的物理图形处理器确定为第一物理图形处理器，以此保证第一物理图形处理器中的视频编码器满足执行任务处理请求所指示视频编码任务的视频编码器资源需要。

以上渲染任务和视频编码任务仅仅是物理图形处理器上所执行并行计算任务的示例性举例，不能认为是对本申请使用方案的限制，可在物理图形处理器上执行的其他并行处理任务也可以按照本申请的方案执行。

在本申请的一些实施例中，为任务处理请求所分配的第一物理图形处理器可以是一个或者多个。具体的，若根据各物理图形处理器的负载信息，和执行任务处理请求所指示的处理任务需要的处理资源，确定每一物理图形处理器中的处理资源均低于执行任务处理请求所指示的处理任务需要的处理资源，可以将该任务处理请求所指示的处理任务分解为至少两个子任务；然后在基于各物理图形处理器的负载信息和每个子任务所需要的处理资源，为每一子任务分配一物理图形处理器，以在所分配的物理图形处理器上执行对应的子任务。

步骤340，根据基础数据的虚拟地址，获取基础数据并将基础数据拷贝至第一物理图形处理器。

虚拟地址是将物理图形处理器中的内存地址进行虚拟化得到的，因此，虚拟地址是指向一物理内存地址的(即为该虚拟地址所指示的物理内存地址)。在此基础上，在虚拟地址分配过程中，存储虚拟地址与物理内存地址之间的映射关系，进而在步骤340中可以基于虚拟地址与物理内存地址之间的映射关系和任务处理请求所对应基础数据的虚拟地址，读取该基础数据并将该基础数据拷贝到第一物理图形处理器中。

步骤350，调用第一物理图形处理器中的驱动，以在第一物理图形处理器中基于基础数据执行任务处理请求所指示的处理任务。

物理图形处理器中配置了用于驱动该物理图形处理器的驱动程序，即物理图形处理器中的驱动。借助于该物理图形处理器中的驱动可以使该物理图形处理器进行任务处理。

在步骤350中，虚拟驱动将任务处理请求转发至第一物理图形处理器中，由第一物理图形处理器根据所对应的基础数据执行对应的计算，得到对应的计算结果。

在本申请的一些实施例中，物理图形处理器中配置了执行并行计算的计算函数，在将任务处理请求转发至所分配的第一物理图形处理后，可以由该第一物理图形处理器调用对应的计算函数，对该任务处理处理请求所对应的基础数据进行并行计算，得到对应的计算结果。

在本申请的一些实施例中，任务处理请求包括所要调用的接口的接口标识；任务处理请求是通过用户态中的预设图形库转发至虚拟驱动的；步骤350，包括：调用第一物理图形处理器中的驱动，以在第一物理图形处理器中根据接口标识调用对应的接口，由所调用的接口根据基础数据执行任务处理请求所指示的处理任务。

为了在物理图形处理器上进行并行处理，在物理图形处理器的厂商提供了对应的图形库，用户态进程通过调用该图形库中的接口(可以视为上文中的计算函数)，来使物理图形处理器执行处理任务。在本方案中，由于在内核态加载了用于转发任务处理请求的虚拟驱动，对于通过调用图形库的接口来执行处理任务的任务处理请求，需要保证该任务处理请求(相当于调用图形库中某一接口)转发到虚拟驱动，而不是直接发送到物理图形处理器中。

原本由物理图形处理器的厂商所提供的图形库是与物理图形处理器中的驱动强相关的，因此，由物理图形处理器的厂商所提供的图形库无法直接应用到虚拟图形处理器上。为了解决该问题，在本方案中，在用户态中设置该预设图形库，由该预设图形库来替代由物理图形处理器的厂商所提供的图形库。通过该预设图形库中的接口来实现原本由图形处理器的厂商所提供图形库中的接口的功能。该预设图形库一方面兼容原来的应用，另一方面在内部提供API转发的机制，将虚拟图形处理器上的请求转到多个物理图形处理器上去。在本实施例中是该预设图形库与虚拟驱动相结合来实现任务处理请求的转发。

在本申请的一些实施例中，可以将该预设图形库拷贝到操作系统(例如Linux系统)目录来替换由物理图形处理器厂商提供的图形库，也可以在游戏加载中通过指定动态库的目录来加载该预设图形库。该指定动态库是为配合本申请的虚拟驱动而设置的动态库，在具体实施例中，可以通过修改动态目录的环境变量，来实现从不同目录加载程序库。

在本方案中用户态进程并不直接面向物理图形处理器中的驱动，而是面向虚拟驱动，并且将多个物理图形处理器的内存地址进行虚拟化，向用户进程提供物理图形处理的虚拟地址，在应用层看起来连续的GPU内存，会在驱动层自动分布到多个物理图形处理器的内存上去。因此，对于用户态进程而言，所直接面向的相当于是一个虚拟的图形处理器，而不是面向多个物理图形处理器，因此本方案实现了将多个物理图形处理器的虚拟化为一个图形处理器。

在本申请的方案中，通过内核态中的虚拟驱动将用户态进程与物理图形处理器中的驱动相隔离开，由内核态中的虚拟驱动将用户态进程发起的任务处理请求进行转发，实现了在内核态中进行多个物理图形处理器的调度，可以有效利用多个物理图形处理器中的处理资源，实现了多个物理图形处理器的负载均衡，实现了多个物理图形处理器上的内存的联动，能够发挥多个物理图形处理器的算力。

而且，运行在内核态的虚拟驱动有更大的权限，能够直接访问用户态进程的所有内存空间；采用内核驱动的方式进行物理图形处理器的虚拟化，通过内核态更大的权限来做数据的存取，且是由内核态的虚拟驱动调用物理图形处理器中的驱动，是驱动与驱动之间的相互调用，没有上下文切换，性能损耗低。

在内核态加载虚拟驱动，而不需要对运行在内核态的应用程序进行改动即可使用多个物理图形处理器的并行计算能力；通过内核驱动的方式，隐藏的复杂的细节，对于应用方可以透明的使用；因此本申请的方案使用范围广。

本申请的方案可以应用于游戏应用，而且不需要对游戏应用进行改动即可利用多个物理图形处理器的处理资源，使得游戏应用的画面可以呈现出更高画质、更大帧率，高分辨率，有效提升游戏画面渲染的质量，提升游戏体验。

在本申请的一些实施例中，如图4所示，步骤340，包括：

步骤410，根据虚拟地址与物理内存地址之间的映射关系，确定基础数据的虚拟地址对应的第一物理内存地址。

第一物理内存地址是指任务处理请求所对应基础数据的虚拟地址所指示的物理内存地址。物理内存地址是作为硬件的物理图形处理器中实际的内存地址。

在本申请的一些实施例中，在用户态进程为基础数据进行内存申请的过程中，该虚拟驱动存储了为该基础数据所分配虚拟地址与物理内存地址之间的映射关系。因此，在步骤410中，可以根据所存储虚拟地址与物理内存地址之间的映射关系，确定对应的第一物理内存地址。

步骤420，根据第一物理内存地址从对应的物理图形处理器中获取基础数据。

步骤430，根据在第一物理图形处理器中为基础数据分配的第二物理内存地址，将所获取到的基础数据拷贝到第一物理图形处理器中。

第二物理内存地址是指在第一物理图形处理器中为基础数据所分配的物理内存地址。可以理解的是，在步骤430之前，在第一物理图形处理器中进行内存分配，获得为该任务处理请求所对应基础数据分配的第二物理内存地址。

可以理解的是，在第一物理图形处理器中是按照基础数据的数据量进行内存申请的。可以通过基础数据的虚拟地址所指示的内存量来在第一物理图形处理器中为该任务处理请求所对应基础数据分配内存量相同的第二物理内存地址。

在本申请的一些实施例中，步骤350之前，该方法还包括：在第一物理图形处理器上进行内存申请，获得处理任务所对应计算结果的第三物理内存地址，以在执行任务处理请求所指示的处理任务过程中按照第三物理内存地址进行所对应计算结果的存储。在该实施中，步骤350之后，该方法还包括：根据第三物理内存地址，从第一物理图形处理器中获取任务处理请求对应的计算结果；将所获取到的计算结果拷贝到计算结果所对应虚拟地址指示的位置处，以使用户态进程根据计算结果所对应虚拟地址获取对应的计算结果。

在本实施例中，由于为任务处理请求的计算结果在第一物理图形处理器中进行了内存申请，从而，在第一物理图形处理器中执行该任务处理请求的过程中，按照第三物理内存地址进行计算结果的存储。

在本申请的一些实施例中，可以是在第一物理图形处理器中为任务处理请求所对应的基础数据进行内存申请的同时，在第一物理图形处理器中为任务处理器所对应的计算结果进行内存申请，得到所对应计算结果的第三物理内存地址。

在本申请的一些实施例中，第三物理内存地址所指示的第一内存量与第二内存量相等，第二内存量是任务处理请求所对应计算结果的虚拟地址所指示的内存量；在该实施例中，在第一物理图形处理器上进行内存申请，获得处理任务所对应计算结果的第三物理内存地址的步骤之前，该方法还包括：为任务处理请求所对应计算结果进行图形处理器内存申请，获得为任务处理请求所对应计算结果分配的虚拟地址。

在申请获得计算结果的虚拟地址后，该虚拟地址所指示的内存量即为第二内存量，从而，在第一物理图形处理中的为计算结果进行内存申请的过程中可以按照该第二内存量进行内存申请，以此保证第三物理内存地址所指示的内存量(即第一内存量)与第二内存量相等。

在本申请的一些实施例中，如图5所示，步骤340之前，该方法还包括：

步骤510，接收用户态进程发送的内存申请请求。

在本申请的一些实施例中，可以是通过调用图形处理器中的内存分配函数来进行为基础数据进行内存申请，内存分配函数例如cudaAlloc()。换言之，在步骤510中，用户态进程所发送的内存申请请求包括所要调用内存分配函数的函数标识。

在本申请的一些实施例中，该内存申请请求指示了请求申请的内存量，所请求申请的内存量可以是根据基础数据的数据量大小确定的，以保证所申请的虚拟地址所指示的内存量可以满足基础数据的存储需要。

步骤520，根据内存申请请求所请求申请的内存量和各物理图形处理器的存储状态信息，为用户态进程分配基础数据的虚拟地址。

各物理图形处理器的存储状态信息指示了所对应物理图形处理中未被占用的内存地址，基于物理图形处理器的存储状态信息可以确定物理存储器上当前未被占用的内存量。在此基础上，按照该内存申请请求所请求申请的内存量，进行内存空间的分配，保证申请到所请求申请的内存量。

在本申请的方案中，用户态进程所发起的内存申请请求实际请求的内存空间必然是物理图形处理器上的内存空间，因此，在步骤520中，可以先将该内存申请请求转发至当前未被占用的内存量不低于所请求申请的内存量的物理图形处理上，由该物理图形处理器基于该内存申请请求进行内存分配。在按照所请求申请的内存量在物理图形处理器上进行物理内存地址分配后，基于物理内存地址与虚拟地址之间的映射关系，可以确定所分配物理内存地址对应的虚拟地址，即为该用户态进程所分配的虚拟地址。换言之，用户态进程发起的内存申请请求也是经虚拟驱动转发到物理图形处理器上完成内存分配的。

在本申请的一些实施例中，任务处理请求所对应的基础数据可能包括多份，例如基础数据为待处理的两矩阵，则需要为每一份基础数据按照上述的过程进行内存申请，获得对应的虚拟地址。

步骤530，向用户态进程返回基础数据的虚拟地址。

如上所描述，由于在内核态将多个物理图形处理器进行了虚拟化，而面向用户态进程的是物理图形处理器的虚拟地址，而不是物理图形处理器的物理内存地址，从而，在步骤530中，向用户态返回所分配的虚拟地址，而不是所分配物理图形处理器中的物理内存地址。

通过如上的过程，实现了为用户态进程的数据进行虚拟地址的分配。

下面，结合一具体实施例对本申请的方案进行进一步说明。假设把复杂的图形处理的某一细节视为看成两个矩阵的运算，如图6所示，按照如下的过程在物理图形处理中进行处理：

步骤610，用户态的游戏进程在主机内存中产生矩阵A、矩阵B。

步骤620，用户态的游戏进程生成任务处理请求。该任务处理请求指示了在预设图形库中所要调用的接口的接口标识。

步骤630，将任务处理请求发送到虚拟驱动。具体的，该任务处理请求中包括矩阵A和矩阵B的虚拟地址vir_A，vir_B、以及矩阵A和矩阵B的大小，运算方式等输入参数。在同时，同时，用户态的游戏进程为计算结果进行虚拟地址申请，得到计算结果的虚拟地址，假设为vir_C。

如上所描述，矩阵A和矩阵B的虚拟地址vir_A，vir_B是通过调用物理图形处理器上的内存分配函数(例如cudaAlloc())来确定的。在步骤630之前，用户态的游戏进程先发起内存申请请求，虚拟驱动在接收到该内存申请请求后，将该内存申请请求转发到一物理图形处理器(假设为GPU-1)中进行内存分配，得到矩阵A的物理内存地址phys_A、矩阵B的物理内存地址phys_B。并基于物理内存地址与虚拟地址之间的映射关系，确定物理内存地址phys_A和phys_B分别对应的虚拟地址vir_A和vir_B。在完成内存分配后，将所分配的物理内存地址、以及所在的物理图形处理器的标识与所对应的虚拟地址关联存储。

步骤640，内核态的虚拟驱动确定虚拟地址vir_A、vir_B、vir_C所对应的物理内存地址phys_A,phys_B,phys_C。

如上所描述，由于内核态的虚拟驱动存储了物理内存地址与虚拟地址之间的映射关系，因此，在步骤640中，基于该映射关系确定各虚拟地址所对应的物理内存地址。

步骤650，虚拟驱动根据各物理图形处理器中的负载信息，为任务处理请求分配第一物理图形处理器。假设分配的第一物理图形处理器为GPUx。其中，所分配的第一物理图形处理器中的处理资源可以满足执行任务处理请求所指示处理任务的资源需要。

步骤660，虚拟驱动把物理地址phys_A,phys_B的数据拷贝到第一物理图形处理器GPUx的GPU内存中，得到矩阵A和矩阵B在第一物理图形处理器GPUx中的物理内存地址GpuMem_A,GpuMem_B。

步骤670，在第一物理图形处理器GPUx中为计算结果分配物理内存地址GpuMem_C来保存计算结果。其中，GpuMem_C的空间大小与vir_C的空间大小相同。

步骤680，虚拟驱动将第一物理图形处理器GPUx的内存地址GpuMem_A,GpuMem_B传递给GLSL的对应计算函数进行计算。其中，若用于计算的GLSL算子在GPUx上未进行编译，则需要先将该GLSL算子进行编译，然后执行步骤680。当然，如果该GLSL算子已编译，则直接基于编译的结果执行步骤680。

GLSL是标准的GPU上的图形编程语言，可以理解为对每个像素逐个像素处理的方式，GPU可以利用多核对多个像素并行计算，最终提升图形渲染的效率。因为真正执行计算的是物理图形处理器，虚拟驱动只是做请求的转发。因此，用于像素计算的GLSL语言也必然要到物理GPU上编译。当存在多个物理GPU的时候，GLSL不一定在所有GPU上都会编译，其可以仅在部分物理图形处理器上编译。

进一步的，由于在第一物理图形处理器GPUx上为计算结果进行了内存申请，因此，在计算过程中，计算结果被保存到第一物理图形处理器GPUx的内存地址GpuMem_C。

步骤690，将GpuMem_C中的计算结果拷贝到虚拟地址vir_C。

通过如上步骤610-680的过程，基于所加载的虚拟驱动和在物理图形处理器上的内存地址虚拟化为虚拟地址，将用户态进程发起的任务处理请求转发到处理资源充足的第一物理图形处理器进行处理，有效实现了多个物理图形处理器中的负载均衡，和多个物理图形处理器中处理资源的调度。

在本申请的一些实施例中，步骤350之后，如图7所示，该方法还包括：

步骤710，接收用户态进程发起的下一次任务处理请求。

步骤720，若下一次任务处理请求对应的基础数据包括任务处理请求对应的计算结果，且第一物理图形处理器中的剩余处理资源满足下一次任务处理请求所请求的处理资源，则确定在第一物理图形处理器上执行下一次任务处理请求。

在本实施例的方案中，在接收到下一次任务处理请求后，如果下一次任务处理请求的基础数据包括本次任务处理请求所对应的计算结果，且执行本次任务处理请求所指示处理任务的第一物理图形处理器中的资源充足，则继续在该第一物理图形处理器上执行该下一次任务处理请求。由于本次任务处理请求的计算结果保存在第一物理图形处理器中，因此，在执行下一次任务处理请求的过程中，不需要从其他物理图形处理器中拷贝本次任务处理期请求的计算结果，避免了两物理图形处理器之间进行数据传输，可以提高处理任务执行的效率。

在本申请的另一些实施例中，步骤350之后，如图8所示，该方法还包括：步骤810，接收用户态进程发起的下一次任务处理请求。步骤820，根据各物理图形处理器的负载信息，分配满足下一次任务处理请求所请求处理资源的第二物理图形处理器，第二物理图形处理器不同于第一物理图形处理器。步骤830，若下一次任务处理请求对应的基础数据包括任务处理请求对应的计算结果，则根据在第二物理图形处理器上为下一次任务处理请求对应的基础数据所分配的第四物理内存地址，将任务处理请求对应的计算结果拷贝至第二物理图形处理器。

在本实施例中，相当于是下一次任务处理请求对应的基础数据包括(本次)任务处理请求的计算结果，且执行(本次)任务处理请求所指示处理任务的第一物理图形处理中的处理资源不足以用于执行下一次任务处理请求，在该种情况下，需要根据各物理图形处理器的负载信息，选择除第一图形处理器外的其他图形处理器执行下一次任务处理请求，所选择的物理图形处理器即为第二物理图形处理器。

在该种情况下，对应需要在第二物理图形处理器中进行内存申请和分配，然后将对应的基础数据拷贝到该第二物理图形处理器中，以执行对应的处理任务。

在本实施例中，由于涉及到在不同物理图形处理器之间进行数据传输，可以采用GPU-TO-GPU的直连传输技术进行数据传输，GPU-TO-GPU的直连传输技术例如采用NVLink传输协议的数据传输方式、PCI-E的数据传输方式。在本申请的一些实施例中，可以优先采用NVLink传输协议的数据传输方式进行数据拷贝，如果不支持NVLink，则采用PCI-E的数据拷贝方式来实现。

在本申请的一些实施例中，当两次处理任务之间切换了物理图形处理器后，虚拟驱动对应会记录每一块数据的虚拟地址，确保计算结果有效的跟踪。进一步的，还可以对存储的数据进行冗余缓存(即针对同一块数据，在多个物理图形处理器中存储)，这样，当某次计算都需要这块数据的时候，就可以立即进行计算。举例来说，如果一物理图形处理器(例如GPU-3)存储有某一数据(假设为数据T)，而物理GPU-4没有数据T，则当计算在物理GPU-4上进行的时候，就要先从物理GPU-3进行数据拷贝。而如果进行了数据T的冗余缓存，则先将数据T缓存到物理GPU-4中，当计算在物理GPU-4上进行时，就不需要从物理GPU-3进行数据拷贝，从而减少物理图形处理器之间的数据拷贝，提升处理效率。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述方法实施例。

图9是根据本申请一实施例示出的图形处理器中的任务处理装置的框图，如图9所示，该图形处理器中的任务处理装置，应用于内核态中的虚拟驱动，包括：接收模块910，用于接收用户态进程发起的任务处理请求；任务处理请求包括所请求处理的基础数据的虚拟地址；虚拟地址是将各物理图形处理器的内存地址进行虚拟化得到的；负载信息获取模块920，用于响应于任务处理请求，获取各物理图形处理器的负载信息；分配模块930，用于根据各物理图形处理的负载信息，为任务处理请求分配第一物理图形处理器；拷贝模块940，用于根据基础数据的虚拟地址，获取基础数据并将基础数据拷贝至第一物理图形处理器；调用模块950，用于调用第一物理图形处理器中的驱动，以在第一物理图形处理器中基于基础数据执行任务处理请求所指示的处理任务。

在本申请的一些实施例中，拷贝模块940，包括：第一物理内存地址确定单元，用于根据虚拟地址与物理内存地址之间的映射关系，确定基础数据的虚拟地址对应的第一物理内存地址；基础数据获取单元，用于根据第一物理内存地址从对应的物理图形处理器中获取基础数据；拷贝单元，用于根据在第一物理图形处理器中为基础数据分配的第二物理内存地址，将所获取到的基础数据拷贝到第一物理图形处理器中。

在本申请的一些实施例中，图形处理器中的任务处理装置，还包括：第一内存申请模块，用于在第一物理图形处理器上进行内存申请，获得处理任务所对应计算结果的第三物理内存地址，以在执行任务处理请求所指示的处理任务过程中按照第三物理内存地址进行所对应计算结果的存储；计算结果获取模块，用于根据第三物理内存地址，从第一物理图形处理器中获取任务处理请求对应的计算结果；计算结果拷贝模块，用于将所获取到的计算结果拷贝到计算结果所对应虚拟地址指示的位置处，以使用户态进程根据计算结果所对应虚拟地址获取对应的计算结果。

在本申请的一些实施例中，第三物理内存地址所指示的第一内存量与第二内存量相等，第二内存量是任务处理请求所对应计算结果的虚拟地址所指示的内存量；图形处理器中的任务处理装置还包括：第二内存申请模块，用于为任务处理请求所对应计算结果进行图形处理器内存申请，获得为任务处理请求所对应计算结果分配的虚拟地址。

在本申请的一些实施例中，图形处理器中的任务处理装置，还包括：内存申请请求接收模块，用于接收用户态进程发送的内存申请请求；虚拟地址分配模块，用于根据内存申请请求所请求申请的内存量和各物理图形处理器的存储状态信息，为用户态进程分配基础数据的虚拟地址；虚拟地址返回模块，用于向用户态进程返回基础数据的虚拟地址。

在本申请的一些实施例中，任务处理请求包括所要调用的接口的接口标识；任务处理请求是通过用户态中的预设图形库转发至虚拟驱动的；调用模块950进一步被配置为：调用第一物理图形处理器中的驱动，以在第一物理图形处理器中根据接口标识调用对应的接口，由所调用的接口根据基础数据执行任务处理请求所指示的处理任务。

在本申请的一些实施例中，处理任务包括渲染任务，负载信息包括物理图形处理器中渲染管线的占用信息；分配模块930进一步被配置为：根据各物理图形器中渲染管线的占用信息，确定渲染管线可用于任务处理请求所指示渲染任务的第一物理图形处理器。

在本申请的一些实施例中，处理任务包括视频编码任务；负载信息包括物理图形处理器中视频编码器的占用信息；分配模块930进一步被配置为：根据各物理图形器中视频编码器的占用信息，确定视频编码器可用于任务处理请求所指示视频编码任务的目标图形处理器。

在本申请的一些实施例中，图形处理器中的任务处理装置，还包括：第一接收模块，用于接收用户态进程发起的下一次任务处理请求；确定模块，用于若下一次任务处理请求对应的基础数据包括任务处理请求对应的计算结果，且第一物理图形处理器中的剩余处理资源满足下一次任务处理请求所请求的处理资源，则确定在第一物理图形处理器上执行下一次任务处理请求。

在本申请的另一些实施例中，图形处理器中的任务处理装置还包括：第二接收模块，用于接收用户态进程发起的下一次任务处理请求；第二分配模块，用于根据各物理图形处理器的负载信息，分配满足下一次任务处理请求所请求处理资源的第二物理图形处理器，第二物理图形处理器不同于第一物理图形处理器；第二拷贝模块，用于若下一次任务处理请求对应的基础数据包括任务处理请求对应的计算结果，则根据在第二物理图形处理器上为下一次任务处理请求对应的基础数据所分配的第四物理内存地址，将任务处理请求对应的计算结果拷贝至第二物理图形处理器。

图10示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图10示出的电子设备的计算机系统1000仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图10所示，计算机系统1000包括中央处理单元(Central Processing Unit，CPU)1001，其可以根据存储在只读存储器(Read-Only Memory，ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(Random Access Memory，RAM)1003中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM 1003中，还存储有系统操作所需的各种程序和数据。CPU1001、ROM1002以及RAM 1003通过总线1004彼此相连。输入/输出(Input/Output，I/O)接口1005也连接至总线1004。

以下部件连接至I/O接口1005：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被中央处理单元(CPU)1001执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质承载计算机可读指令，当该计算机可读存储指令被处理器执行时，实现上述任一实施例中的方法。

根据本申请的一个方面，还提供了一种电子设备，其包括：处理器；存储器，存储器上存储有计算机可读指令，计算机可读指令被处理器执行时，实现上述任一实施例中的方法。

根据本申请实施例的一个方面，提供了计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一实施例中的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。