GPU通用计算一般在集群系统中的多个节点上配备数量不等的GPU卡，现有的GPU编程技术(如CUDA、OpenCL)只支持单节点应用，GPU应用程序只能直接访问(访存、计算)节点本地的GPU资源。为了实现多节点多GPU应用，开发人员需要展开MPI编程或者借助于第三方运行时，使得单个应用程序能够访问更多的GPU资源，提高计算性能。MPI一定程度上增加了程序的复杂度与编程人员的负担，给系统的开发、调试以及维护带来困难。
为了充分利用集群系统的GPU计算能力，并降低应用程序的开发难度，本文提出一种基于CUDA架构的GPU虚拟化技术，实现对集群系统所有节点上GPU资源的统一抽象与管理。集群系统中的每一个GPU都可以看作节点本地设备，应用程序按照访问本地设备的方式访问集群系统的任何一个GPU。
基于虚拟化GPU计算平台，应用程序可以同时请求节点本地和其他节点上的GPU计算服务，每个节点也可以同时为本地和其他节点上的应用程序提供GPU计算服务。系统根据应用需求在全局范围静态或者动态优化GPU分配，从而提升计算资源的整体利用率，减少计算任务的响应时间。
1 GPU虚拟化技术 虚拟化技术被广泛应用于现代计算机系统，如VMware、KVM[1]和Xen[2]，能有效提高系统整体效能，并降低运行与维护成本。鉴于GPU在高性能计算领域的重要性，虚拟化技术被应用于GPU。GPU虚拟化技术可分为2类：
1) 硬件虚拟化：基于虚拟化PCIE总线(如NextIO N2800-ICA[3])，允许某个节点访问其他节点上的GPU，实现资源的复用。此类方法灵活性较差，且底层接口难以标准化，因此实施成本较高，一般鲜为工业界和学术界所用。
2) 软件虚拟化：基于函数库或者运行时系统，屏蔽底层硬件细节，采用标准化的高层接口实现对GPU资源的分时复用与透明共享(如OpenGL[4]、Direct 3D[5]、CUDA[6]和OpenCL[7])。
软件虚拟化技术又可分为2种应用场景：
1) 面向虚拟机监控器(Virtual Machine Monitor，VMM)，为虚拟机(VM)提供图形加速及通用计算支持。VMware Virtual GPU[8]提供了Windows虚拟机环境下对Direct 3D的支持，而VMGL[9]则提供了类Unix虚拟机环境下对OpenGL的支持，但二者并不提供对GPU通用计算功能的支持。vCUDA[10]基于前后端模式实现虚拟机环境下的GPU通用计算，前端CUDA接口以封装库的形式运行于客户机，而后端GPU计算服务则放置于宿主机。GViM[11]、gVirtuS[12]采用类似的架构方案，并提供CUDA支持。
2) 面向集群环境，为客户端提供访问其他节点GPU的API接口，实现分布式GPU资源的虚拟化。dOpenCL[13]通过对底层分布式细节的完全隐藏，实现对CPU、GPU以及其他加速部件的本地化抽象，并支持OpenCL编程接口。VCL[14]同样实现了OpenCL规范，并扩展OpenMP，允许集群系统某个节点上的GPU应用程序调用其他节点上GPU资源。除此之外，VCL还提供基于任务依赖关系的调度以及缓冲区管理功能。rCUDA[15-16]基于分布式系统环境，实现了虚拟化CUDA编程接口，支持对远程GPU的并发使用，使得没有GPU设备的节点也具备GPU计算能力。
rCUDA基于设备底层接口实现节点间通信，系统软硬件耦合紧密，可移植性较差。此外，rCUDA为闭源软件，其具体实现细节并未公开。鉴于此，本文提出一种面向集群系统环境的新型虚拟化GPU计算平台。
2 面向集群环境的GPU虚拟化 2.1 传统GPU计算架构 一个典型的集群系统架构[16]如图 1所示。系统中存在多个节点，每个节点上部署数量不等的GPU资源，节点之间基于互联网络方式实现通信。根据对计算资源需求的不同，GPU应用程序可分为3类：① 单节点单GPU应用；② 单节点多GPU应用；③ 多节点多GPU应用。由于GPU卡计算、存储资源的限制，单个节点上所部署的GPU卡无法满足某些GPU应用程序的需求，甚至某些节点由于没有部署GPU卡而无法提供GPU计算服务。多节点多GPU计算架构为这种需求提供了合理的解决方案，通过将GPU应用程序划分为多个分布在不同节点上的进程的方式实现对其他节点上GPU资源的调用，满足其对超出本节点负载能力的GPU资源的需求。
 |
| 图 1 集群系统架构[16] Fig. 1 Architecture of clustered system[16] |
| 图选项 |
多节点多GPU计算架构如图 2所示。该架构下的GPU应用程序开发一般基于MPI、CUDA相结合的方式实现，要求开发人员显式展开分布式MPI编程，并根据GPU资源的分布情况，优化进程在节点上配置。每个部署GPU资源的节点需要启动一个或者多个MPI进程，各MPI进程基于CUDA 接口访问本地GPU资源，MPI进程之间基于MPI消息接口通信，实现计算任务的分发以及计算结果的回收。应用程序并行性的开发需要在2个层次上展开：① MPI层：MPI进程间并行性的开发；② CUDA层：GPU线程间并行性的开发。
 |
| 图 2 多节点多GPU计算架构 Fig. 2 Computing framework of multiple GPUs on multiple nodes |
| 图选项 |
由于采用双层并行架构，程序的开发过程变得复杂，编程人员不仅要考虑层次内的并行性设计、优化问题，还需要考虑层次间的性能优化问题。此外，该架构灵活性较差，系统难以根据GPU资源的变化而动态改变程序在集群中的部署。为了提升应用程序的灵活性以及可移植性，并降低其开发难度，本文提出一种面向集群系统的新型虚拟化GPU计算架构。
2.2 虚拟化GPU计算平台框架 在本系统中，GPU的虚拟化基于CUDA运行时的虚拟化而实现，该设计为CUDA运行时引入了抽象层和通信层。通信层位于抽象层之下，基于MPI接口实现节点间通信。相对于rCUDA直接基于底层接口实现节点间通信，MPI能够适配各种硬件平台，具备更好的可移植性。通信层的引入为GPU应用程序屏蔽了MPI接口调用。
图 3为虚拟化GPU计算平台逻辑视图[16]。虚拟化之后的CUDA运行时基于通信中间件实现对集群GPU资源的统一抽象与管理，GPU资源的物理分布对于应用程序变得透明。基于虚拟化CUDA运行时，集群系统中的所有GPU设备构成一个设备库，任意节点上用户程序均以统一的逻辑视图访问设备库的GPU资源。各应用程序可以像访问本地GPU一样调用集群系统中的所有GPU，开发人员只需专注于CUDA编程，而关于GPU资源的分布、访问以及MPI接口等问题，则交由虚拟化CUDA运行时处理。由于抽象层实现对原有CUDA API的兼容性封装，原有GPU应用程序则可以不经任何修改而无缝迁移到虚拟化GPU计算平台运行。
 |
| 图 3 虚拟化GPU计算平台逻辑视图 Fig. 3 Logic view of virtualized GPU computing platform[16] |
| 图选项 |
虚拟化GPU计算平台的软件栈如图 4所示。虚拟化CUDA运行时由抽象层、通信层以及节点本地CUDA运行时三部分组成。通信层由分布于各节点的GPU访问代理服务器进程(以下简称GPU访问代理)以及MPI通信接口构成，是实现对各节点GPU资源统一抽象与管理的关键。GPU访问代理负责处理所有对其所属节点GPU的访问请求，并将请求转发给节点本地CUDA运行时，每个GPU拥有独立的访问代理。抽象层同样具备MPI通信能力，基于MPI与各GPU访问代理进行交互。
 |
| 图 4 虚拟化GPU计算平台软件栈 Fig. 4 Software stack of virtualized GPU computing platform |
| 图选项 |
当运行于某个节点上的应用程序发起GPU访问请求时，会首先调用CUDA运行时的抽象层，抽象层根据API参数以及集群系统当前GPU资源的配置以及状态，将访问请求传递到一个或多个GPU访问代理。访问代理根据参数调用本地CUDA运行时执行相应的操作，待操作完成之后再经由通信层回传相应的结果。
除了具备开发难度较低、可移植性好等优点之外，虚拟化GPU计算平台还具有以下特性：
1) 充分利用系统资源，对于没有配备GPU的节点，也能运行GPU应用程序。
2) 提升GPU应用程序的加速比，在单个节点上GPU资源有限的情况下，能够利用其他节点上的GPU资源，提升系统并行计算能力。
由于增加了额外的软件层次以及网络通信开销，系统性能的提升受到了一定程度的影响。
3 虚拟化GPU计算平台设计 如图 4所示，虚拟化CUDA运行时采用分布式架构，通过在抽象层与节点CUDA运行时之间插入通信层实现对分布式GPU资源的虚拟化。
3.1 CUDA运行时抽象层 为了实现对GPU资源的统一抽象与管理，抽象层除了对集群系统中分布式CUDA运行时API进行兼容性封装之外，还对各节点上的GPU资源进行全局管理。在GPU应用程序启动阶段，抽象层主要负责：① 完成MPI运行环境以及GPU资源信息的初始化，并根据配置要求启动GPU访问代理，记录其所属的应用句柄；② 维护GPU代码段(FatBinary)的注册信息，如FatBinary在节点主机内存偏移位置、空间大小以及对应的GPU设备编号等；③ 记录核函数以及GPU全局变量信息及其所属的FatBinary编号；④ 给目标GPU访问代理传递参数，启动核函数，开始计算过程；⑤ 为目标节点GPU和本地主机申请、释放内存空间，传输数据。此外，在GPU应用程序结束阶段，抽象层还需要注销FatBinary信息，并释放其所占用的内存空间。以上各项操作需由各GPU访问代理以及节点本地CUDA运行时配合完成。
3.2 GPU访问代理 GPU访问代理是衔接抽象层与节点本地CUDA运行时的重要部件。GPU访问代理与其所服务的GPU应用程序具有相同的生命周期，随着GPU应用程序的启动而启动，并在完成GPU计算任务之后退出。每个GPU访问代理同时只为一个特定GPU应用程序提供服务，当新的GPU应用程序启动时，系统根据参数配置，在指定的一个或者多个节点上启动数量不等的GPU访问代理。应用程序不同，其所拥有的GPU访问代理在集群系统中的数量与分布也不同。对于具体的GPU应用程序，GPU访问代理的数量与分布由用户或者上层作业调度系统指定。
GPU访问代理是核函数调用以及数据传输的最终执行者，GPU访问代理基于MPI方式在抽象层与节点本地CUDA运行时之间执行核函数调用、参数传递以及数值拷贝等操作。在系统初始化阶段，GPU访问代理还需要完成FatBinary、GPU核函数以及GPU全局变量在其所属节点环境的注册工作，为GPU计算任务创建执行环境。鉴于同一节点上的不同GPU可能会服务于不同的GPU应用程序，该节点上会出现不同GPU访问代理隶属于不同的GPU应用程序的情况。
3.3 节点本地CUDA运行时 节点本地CUDA运行时直接继承原有CUDA运行时，服务于所有对本地GPU资源的访问请求。抽象层维护集群系统可用GPU资源的全局状态信息，而节点本地GPU运行时则只负责维护节点本地可用GPU资源的状态信息，并保持与抽象层资源信息的一致性。
3.4 数据传输 在虚拟化GPU计算平台下，一个典型的GPU程序运行流程如图 5所示。主机与GPU的交互主要包括核函数调用以及数据传输2类操作。对于数据密集型的GPU应用程序，每次计算过程可能需要一到多次数据传输，这些操作均通过CUDA API实现。CUDA API调用需要由抽象层、通信层以及节点本地CUDA运行时3部分共同完成，涉及数据在不同组件、不同节点之间的传输，因此，数据传输性能对应用程序的性能会产生重要的影响，是系统设计要考虑的重点问题。拟采用流水化通信技术，实现节点间数据的高效传输。
 |
| 图 5 GPU应用程序运行流程简图 Fig. 5 Simplified execution flowchart of GPU program |
| 图选项 |
4 流水化通信技术 一次GPU计算过程可分为3个执行步骤：
1) 将输入数据由主机内存拷贝到GPU内存。
2) 启动GPU核函数，开始GPU计算过程。
3) 将计算结果由GPU内存拷贝到主机内存。
大多计算任务往往需要多次循环执行以上3个步骤。最新的GPU架构配备2个复制引擎，支持数据双向并行传输，因此理论上3个步骤可以并行执行，在整个计算任务的循环执行过程中，考虑采用多执行流模型，将3个执行步骤流水化，充分发挥系统性能。
对于虚拟化CUDA运行时环境，数据传输又可以分为2个步骤，即GPU应用程序与目标GPU访问代理之间的数据传输以及目标GPU访问代理与目标GPU之间的数据传输。因此，一次完整的计算过程可以划分5个执行步骤，其流水线时间框图如图 6所示，各步骤对应的操作如下：
 |
| 图 6 GPU计算任务流水线 Fig. 6 Pipeline of GPU computing task |
| 图选项 |
步骤1?GPU应用程序将数据传输到目标GPU访问代理。
步骤2?目标GPU访问代理将数据拷贝到目标GPU内存。
步骤3?启动核函数，目标GPU开始计算过程。
步骤4?将计算结果由目标GPU内存拷贝到目标GPU访问代理。
步骤5?将计算结果由目标GPU访问代理传输到GPU应用程序。
理想情况下，各步骤执行时间相同，而实际运行过程中，各步骤执行时间因应用程序以及系统状态的不同而发生变化。以上计算过程的流水化由虚拟化CUDA运行时的抽象层与节点本地CUDA运行时自动实现，不需要用户程序作出任何特殊设计或修改。其中步骤1~步骤2、步骤4~步骤5的流水化由抽象层实施，而步骤2~步骤4的流水化则由目标节点本地CUDA运行时实施。如图 7所示，抽象层采用异步数据传输方式，对于每次数据传输，会首先创建专用数据传输线程并立即返回执行其他操作或者下一次数据传输。数据传输线程与目标GPU访问代理建立连接以执行数据传输。GPU访问代理端监听到数据传输请求之后也会创建专用数据传输线程，与抽象层所创建的线程共同完成数据传输工作。数据传输完毕之后，各数据传输线程退出。为了实现步骤1~步骤2、步骤4~步骤5的并行流水化，GPU访问代理在数据传输的同时开启新的线程执行与本地GPU内存之间的数据拷贝工作，并采用多缓冲区机制，实现二者的并行执行。
 |
| 图 7 虚拟化CUDA运行时数据传输流程 Fig. 7 Data transmitting flow of virtualized CUDA run-time system |
| 图选项 |
5 虚拟化GPU计算平台的性能实验 5.1 实验原理与方法 虚拟化GPU计算平台的实现，一方面使得GPU应用程序可以访问其他节点上GPU资源，提升计算性能。另一方面，由于虚拟化技术引入了额外的软件栈以及节点通信开销，一定程度上影响了系统整体性能的提升。本实验拟基于典型的GPU应用程序，测试虚拟化GPU计算平台的计算与通信性能。
计算性能的对比在计算平台与应用规模2个维度展开。
计算平台主要分为2类：
1) 节点本地GPU计算平台：应用程序的核函数只在节点本地GPU上运行。
2) 虚拟化GPU计算平台：应用程序的核函数在集群系统全局范围内的GPU上运行。
应用程序的规模的变化主要体现在其所处理的数据规模的变化。有关通信性能及开销的实验对比分析也在计算平台、数据规模2个维度展开。
5.2 实验环境 本实验集群环境配备4个节点，节点之间基于InfiniBand(IB)网络互联，IB网卡控制器型号为Mellanox ConnectX-3 Double-Port 4X QDR，实测最大带宽约为3600MB/s。每个节点配置2颗Intel(R) Xeon(R) E5-2690处理器，标称主频为2.90GHz，每颗处理器为8核32线程。单个节点内存容量为160GB，频率为1066Hz。此外，每个节点配备8块Tesla K20M GPU卡，每个GPU拥有2496颗流处理器以及5GB内存。节点操作系统环境为Ubuntu 14.04 LTS，CUDA以及MPI环境分别为CUDA 6.4、MVAPICH2 2.1。
5.3 实验内容与分析
5.3.1 通信性能 由于虚拟化GPU计算环境引入了节点通信开销，因此通信性能是考量计算平台性能的重要指标。流水化通信技术实现对节点通信开销的隐藏，并充分利用IB带宽。实验测量本地主机到目标GPU内存的异步传输带宽。按不同的传输缓冲区设置，实验被分为6组，其传输缓冲区大小依次设置为64KB，128KB，…，2MB不等。每组实验的传输带宽如图 8所示。
 |
| 图 8 虚拟化CUDA运行时数据传输带宽 Fig. 8 Data transmitting bandwidth of virtualized CUDA run-time system |
| 图选项 |
在每组实验中，数据传输带宽受限于传输缓冲区大小、数据传输量以及IB的带宽上限。在传输缓冲区大小固定的情况下，系统的数据传输带宽随着数据传输量的增加而呈线性增长趋势，直至数据传输量达到缓冲区容量的上限或者传输带宽达到IB的带宽上限。在达到IB带宽上限之前，传输缓冲区越大，传输带宽所能达到的上限值越大。实验表明，当传输缓冲区达到1MB时，数据传输带宽达到IB带宽上限值。在到达传输带宽上限之前，增加缓冲区大小或者数据传输量能有效提升IB带宽的利用率，并隐藏虚拟化CUDA运行时所带来的开销。当传输缓冲区以及数据传输量均超过1MB时，系统对虚拟化CUDA运行系统开销的隐藏能力达到上限，IB带宽的利用率趋于饱和，传输速度为3550MB/s，基本达到IB的传输带宽的实测上限值3650MB/s。
图 9与图 10分别针对矩阵乘法以及FFT计算2种典型GPU应用程序展开数据传输延迟实验。矩阵乘法为计算密集型应用，而FFT则为数据密集型应用。在不影响性能评估的前提下，本实验仅仅分析由GPU应用程序节点到目标节点GPU的单向数据传输延迟，实验对比在如第5.1节所述的2类平台之间展开。为了突出通信流水化所带来的性能提升效果，虚拟化GPU计算平台上的实验又分为流水化传输和非流水化传输2类，因此最终实验数据分为3组。
 |
| 图 9 矩阵乘法数据传输延迟 Fig. 9 Data transmitting latency of matrix multiplication |
| 图选项 |
 |
| 图 10 FFT数据传输延迟 Fig. 10 Data transmitting latency of FFT |
| 图选项 |
在虚拟化GPU计算平台中，数据传输过程一般由节点间传输、目标节点主机内存到GPU内存传输两部分组成，而传统GPU计算平台下的数据传输仅仅需要完成主机内存到本地GPU内存传输过程。因此，如果采用非流水化数据传输，由于引入了额外的控制开销以及节点间传输，虚拟化GPU计算平台下的传输延迟大于传统GPU计算平台下的本地传输延迟。而采用流水化数据传输机制之后，目标节点主机内存到GPU内存的传输隐藏了节点间传输延迟以及相关控制开销，传输过程的总体延迟显著降低。实验结果表明，采用流水化通信技术之后，虚拟化GPU计算平台的数据传输延迟降低50%~70%。
在本实验环境中，由于IB传输带宽低于PCIE带宽，因此采用流水化通信技术的虚拟化GPU计算平台的数据传输相对于传统GPU计算平台的本地数据传输具有更大的延迟，系统的数据传输性能受限于节点间的IB互联带宽。而在图 9与图 10中，虚拟化GPU计算平台的流水化数据传输反而具有较低的延迟，这主要得益于DMA技术在IB带宽传输中的应用，这在计算性能实验部分也有所体现。在实际应用中，为了提升节点间的数据传输性能，需要采用具有更高带宽的IB互联网络。
5.3.2 计算性能 计算性能实验环节评测GPU应用程序的单次计算过程从启动到结束的总体延迟，该延迟由主机内存到目标GPU内存的传输延迟、目标GPU代码执行时间以及目标GPU内存到主机内存的传输延迟3部分构成。数据传输是构成整体计算过程的不可获取的重要组成部分，随着数据传输所占比例的不同，节点间数据传输以及其开销对GPU应用程序的性能影响也各不相同。表 1与表 2分别为矩阵乘法与FFT的总体计算延迟，与通信性能实验类似，计算性能的实验也在3类平台分别展开，即节点本地GPU计算平台、基于流水化通信技术的虚拟化GPU计算平台以及非流水化的虚拟化GPU计算平台。
表 1 矩阵乘法计算延迟 Table 1 Total computing latency of matrix multiplication
| 矩阵规模/行、列 | 计算延迟/s | ||
| 本地平台 | 虚拟化流水平台 | 虚拟化非流水平台 | |
| 1024 | 0.0135 | 0.0131 | 0.0175 |
| 2048 | 0.0867 | 0.0846 | 0.1019 |
| 3072 | 0.2620 | 0.2565 | 0.3029 |
| 4096 | 0.5960 | 0.5849 | 0.6806 |
| 5120 | 1.1333 | 1.1192 | 1.2874 |
| 6144 | 1.9270 | 1.9087 | 2.1512 |
| 7168 | 3.0309 | 3.0047 | 3.2794 |
| 8192 | 4.4760 | 4.4430 | 4.7193 |
| 9216 | 6.3196 | 6.2937 | 6.6417 |
| 10240 | 8.6168 | 8.5922 | 9.0155 |
| 11264 | 11.4213 | 11.3951 | 11.9786 |
| 12288 | 14.7529 | 14.7424 | 15.6143 |
| 13312 | 18.6737 | 18.6943 | 19.6530 |
| 14336 | 23.2603 | 23.3639 | 24.2306 |
| 15360 | 28.5631 | 28.8291 | 29.6420 |
| 16384 | 34.5847 | 34.9069 | 35.8820 |
表选项
表 2 FFT计算延迟 Table 2 Total computing latency of FFT
| FFT计算规模/行、列 | 计算延迟/ms | ||
| 本地平台 | 虚拟化流水平台 | 虚拟化非流水平台 | |
| 8 | 0.1014 | 0.2759 | 0.2167 |
| 16 | 0.1396 | 0.3135 | 0.3191 |
| 64 | 0.4128 | 0.6905 | 1.0005 |
| 256 | 1.7061 | 2.5051 | 3.0628 |
| 512 | 2.7434 | 3.4342 | 6.0090 |
| 1024 | 4.9513 | 5.6387 | 12.4230 |
| 2048 | 9.8512 | 10.6143 | 26.1070 |
| 4096 | 20.6565 | 20.5740 | 49.3056 |
| 8192 | 41.1518 | 39.8459 | 102.3965 |
表选项
在虚拟化GPU计算平台下，由于矩阵乘法计算为计算密集型应用，因此流水化数据传输技术对计算性能的提升有限，而FFT计算为数据密集型应用，流水化数据传输技术对计算性能的提升作用显著。实验数据显示，采用流水化数据传输技术的虚拟化GPU计算平台能够提供与本地GPU计算平台等同的计算性能。在实际应用中，在算法允许的情况下，可以将GPU应用程序需要处理的输入数据划分为多个片段，依次传输到GPU内存并展开计算，将计算与数据传输流水化，从而提高系统性能。
6 结 论 本文面向集群环境，设计并实现了一种新型的虚拟化GPU计算平台，将多节点多GPU资源抽象，形成统一的编程视图，使得GPU应用程序可以无差别地访问集群系统上的任一GPU资源。
1) 与基于MPI编程的多节点多GPU应用程序不同的是，原有单节点多GPU应用程序在无需修改的情况下可以直接运行于虚拟化GPU计算平台，实现对多节点多GPU的访问，增加了应用程序的可移植性。同时，由于通信层基于MPI接口实现，屏蔽了底层硬件接口的差异性，系统具有更好的硬件平台普适性。
2) 虚拟化GPU计算平台使得GPU应用程序摆脱了单个节点上GPU资源的限制，可以充分利用集群系统多个节点上的GPU资源，从而提升GPU代码的并行度，对于GPU应用程序具有良好的加速潜力。
3) 基于流水化通信技术，本系统隐藏了节点间数据传输所带来的延迟以及控制开销。实验表明，虚拟化GPU计算平台可以提供与原有GPU计算平台等同的通信性能，因此在多数情况下GPU应用程序的整体性能不会因为系统引入了额外的软件栈以及通信环节而下降。
系统性能达到了预期目标，具有良好的应用前景。
参考文献
| [1] | KIVITY A,KAMAY Y,LAOR D,et al.KVM:The Linux virtual machine monitor[EB/OL].Proceedings of the Linux Symposium,Ottawa[2015-11-01].https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf. |
| [2] | BARHAM P,DRAGOVIC B,FRASER K,et al.Xen and the art of virtualization[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles.New York: ACM,2003:164-177. |
| [3] | NextION2800-ICA-Flexible and manageable I/O expansion and virtualization[EB/OL].Austin:NEXTIO[2015-11-01].http://www.nextio.com/docs/NextIO20N2800-ICAIOConsolidationApplianceProductBriefv0.18.pdf. |
| [4] | SHREINER D. OpenGL programming guide[M].7th ed.Boston: Addison-Wesley Professional, 2009: 1-28. |
| [5] | BLYTHE D. The direct 3D 10 system[J].ACM Transactions on Graphics, 2006, 25(3): 724–734.DOI:10.1145/1141911 |
| [6] | NVIDIA.CUDA C programming guide[EB/OL].Santa Clara:NVIDIA[2015-11-01].https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html. |
| [7] | KHRONOS OpenCL Working Group.OpenCL 2.0 specification[EB/OL].OR:Khronos[2015-11-01].http://www.khronos.org/registry/cl/specs/opencl-1.2.pdf. |
| [8] | DOWTY M, SUGERMAN J. GPU virtualization on VMware's hosted I/O architecture[J].ACM SIGOPS Operating Systems Review, 2009, 43(3): 73–82.DOI:10.1145/1618525 |
| [9] | LAGAR-CAVILLA H A,TOLIA N,SATYANARAYANAN M,et al.VMM-independent graphics acceleration[C]//VEE'07:Proceedings of the 3rd International Conference on Virtual Execution Environments.New York:ACM,2007:33-43. |
| [10] | SHI L,CHEN H,SUN J.vCUDA:GPU accelerated high performance computing in virtual machines[C]//23rd IEEE International Symposium on Parallel and Distributed Processing (IPDPS'09).Piscataway,NJ:IEEE Press,2009:418-428. |
| [11] | GUPTA V,GAVRILOVSKA A,SCHWAN K,et al.GViM:GPU-accelerated virtual machines[C]//Proceedings of the 3rd ACM Workshop on System-level Virtualization for High Performance Computing.New York:ACM,2009:17-24.http://cn.bing.com/academic/profile?id=2067231500&encoded=0&v=paper_preview&mkt=zh-cn |
| [12] | GIUNTA G,MONTELLA R,AGRILLO G,et al.A GPGPU transparent virtualization component for high performance computing clouds[C]//16th International Euro-Par-Conference on Parallel Processing.Berlin:Springer,2010:379-391. |
| [13] | KEGEL P,STEUWER M,GORLATCH S.dOpenCL:Towards a uniform programming approach for distributed heterogeneous multi-/many-core systems[C]//2012 IEEE 26th International Parallel and Distributed Processing Symposium Workshops & PhD Forum (IPDPSW).Piscataway,NJ:IEEE Press,2012:174-186. |
| [14] | BARAK A,BEN-NUN T,LEVY E,et al.A package for OpenCL based heterogeneous computing on clusters with many GPU devices[C]//2010 IEEE International Conference on Cluster Computing Workshops and Posters (CLUSTER WORKSHOPS).Piscataway,NJ:IEEE Press,2010:1-7. |
| [15] | DUATO J,PEA A J,SILLA F,et al.rCUDA:Reducing the number of GPU-based accelerators in high performance clusters[C]//2010 International Conference on High Performance Computing and Simulation (HPCS).Piscataway,NJ:IEEE Press,2010,6:224-231. |
| [16] | PEA A J, REAO C, SILLA F, et al. A complete and efficient CUDA-sharing solution for HPC clusters[J].Parallel Computing, 2014, 40(10): 574–588.DOI:10.1016/j.parco.2014.09.011 |
