而GPU（图形处理器单元）作为计算机的一个很重要的组成部分，其浮点运算和并行运算速度可以比CPU都强。但是在虚拟的技术中， QEMU对GPU虚拟的支持，很长时间都是纯粹的软件模拟，并没有充分利用硬件GPU的资源，性能大大折扣。

GPU密集工作性负载，对高性能GPU虚拟化的需求越来越强烈。如：

• 3D/2D 图形加速

           游戏
           VDI

• Media Transcoding

           视频会议, CDN

• 高性能计算(GPGPU)OpenCL/CUDA
         Geometric computing, Scientific computing, Machinelearning
         Bioinformatics, Finance, Medical industry,Meteorology
         Personalized medicine, drugdiscovery，Big Dataanalytics

顺应潮流，这几年， NVIDIA、AMD和intel相继推出自己的基于硬件的虚拟化解决方案。

AMD: 其GPU虚拟化解决方案是完全基于业界标准的SR-IOV(单根输入输出虚拟化)。这是由PCI SIG组织开发的一种规范，为设备的硬件虚拟化应用提供了标准化方法。其能够允许多达15个虚拟化桌面共享同一个图形处理器，其最终用户就能够同等地访问GPU，无论他们是何种工作负载，而且不会有任何性能上的损失。

SR-IOV标准允许一个GPU给多个虚拟机共享使用，因此为每一个用户都提供了虚拟化的性能进行设计、创造并且执行他们的工作负载，而没有一个用户会占据整个GPU。由于硬件的复杂性，目前支持的GPU厂商只有AMD。

NVIDIA：没有像AMD那样使用的基于硬件的GPU虚拟化技术。其虚拟化方案是称为Grid桌面虚拟化技术，该技术是基于它最新的Tesla GPUs的。NVIDIA的虚拟化方案比较有意思的一个特色是可以虚拟出几种不同model的虚拟显卡。 FloridaAtlantic University基于NVIDIA GPU 虚拟化方案的VDI已经有几年历史了，他们称，可以使用8-12个虚拟化桌面同时共享一个GPU 板卡。

做为intel的员工，今天的重点还是要介绍intel自己的GPU解决方案。Intel有三种GPU虚拟化的方法。

• API转发（GVT-S）
  将openGL或者DirectX的API转发给host上的Graphics Driver上。
  优点：性能佳、可以共享。
  缺点：功能滞后。

• 直通设备(GVT-d)
  利用VT-d将显卡直通给虚拟机。
  优点：性能佳、功能完备。
  缺点：不能共享。

• 完全GPU虚拟化(GVT-g)
  优点：性能佳、功能完备、可以共享

Intel的完全虚拟化解决方案包括软件和硬件方案。可以将GPU直通给多个虚拟机，可以在性能，功能，共享方面达到很好的平衡。

由于在共享和性能方面的平衡，intel的GVT-g 是很值得推荐的。

KVMGT 是Intel® 完全GPU虚拟化（GraphicsVirtualization Technology GVT-g) 的KVM实现，是VGT-g的纯软件方案。其mediatedpass-through相当于软件实现的GPU分时复用，不同于SR-IOV。

KVMGT从intel的broadwell处理器开始支持。

其性能：

• 3D性能可以达到host的80%以上。

• 2D性能可以达到host的70%以上。

• Media解码能力可以到host的90%以上。

• Media转码能力可以到host的80%以上。

KVMGT支持的Features

• 可以运行native的driver。

• DirectX*11.1

• OpenGL*4.2

• OpenCL*1.2

• MediaSDK16.2

• DirectX*12

支持的不同操作系统的guest数量：

• MultipleVMs up to 7

• SupportUbuntu* Guest

• SupportWindows* 7 x32/x64

• SupportWindows* 8 x32/x64

• GuestWindows* 10 x64

目前支持的远程显示协议：

目前，Openstack 对于AMD的GPU虚拟化是应该支持的。因为AMD每个SRIOV的GPU可以作为PCI设备pass-through到guest。

Citrix 提出了2个版本的方案支持Nvidia和 XENGT（VGT-G的XEN实现）。

第一个版本是基于on-demand的方案，社区感觉有些复杂。之后他们提出了一个新的方案，pre-define的方案。pre-define的方案，预先定义虚拟的GPU（VGPU），定义好之后，数量不能修改了，并且通过openstack的代码，做hack，将每个pre-define的VGPU作为SRIOV设备，并且每个设备分配一个虚拟的PCI  BDF号，该BDF号只有Openstack可见。社区比较倾向这个方案，但是还没有得到approve， upstream还需要时日。

对于KVMGT，可以在Citrix实现基础上，比较容易的实现。

对于企业来说，如果业务需求，需要GPU的虚拟化，自己完全可以很快的基于Openstack实现自己私有的GPU虚拟化方案，没有必要依赖社区。

对于不想做开发的企业，我们会做一个KVMGT的demo，可以参考我们。

此外我们在巴塞罗那的峰会，提交的一个KVMGT的topic，《enabling GPU virtualization in Openstack》，感兴趣的同行可以支持一下。

谢谢。

QA

1、2vm的时候，每个vm能跑到native的多少性能？比如3dmark11

答：2个VM我们一般是统计性能之和。每个VM 3dmark11的数据大概是native的vm的分数一半多一点

2、enabling GPU virtualization in Openstack这东西在那里能看到？

答：现在可以看到摘要，也可以投票，https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/

3、intel的显卡是集成在主板芯片上的吧？

答：Intel目前的显卡是和CPU集成的，不是在主板上。

4、多谢专家的介绍,请问windows 客户操作系统需要安装什么样的驱动,在哪里可以获取; 对spice的支持怎么样,虚拟的GPＵ和spice是怎么整合的,谢谢

答：windows的驱动直接从Intel官网下载，跟裸机上跑的驱动是一样的。KVMGT发布时候会给定一个驱动版本号，那个是QA经过测试的版本

5、你好，从Intel的角度看，现在kvmgt是处于什么状态，demo，beta，还是可商用？另外对于spice协议支持的代码什么地方可以获取？谢谢。

答：SPICE的支持目前处在POC阶段。可以用但是性能并不好，原因是对VM的每次屏幕刷新需要一次拷贝。这一块有优化的解决办法，我们正在做.

6、主板集成的显卡，能用KVMGT么？最多能带多少VM?

答：KVMGT只支持Intel的GPU，从Haswell开始，更老的用不了，以后upstream的代码从Broadwell开始支持

7、GVT-d现在已经upstream了吗？

答：redhat最近有一个博客详细描述GVT-d的支持，在VFIO里，可以看下。http://vfio.blogspot.com/2016/07/intel-graphics-assignment.html

8、直播云这个词现在经常听到。是否用到这个技术，

答：“直播云”或“视频云”，也许会是潜在的应用，目前应该是以bare metal机器为主我猜。

9、gpu对网络的优化有没有改善 ？

答：这个可能跟GPU的虚拟化并没有特定的关系，gpu不负责网络优化。如果想在固定带宽内做数据压缩，intel有QAT技术，支持硬件的压缩。

10、GPU可以实现在kvm下面动态调整显存吗？或者说指定对应虚拟机的显存

答：我们目前是只支持静态显存设置，是在启动VM之前。动态显存是个很好的问题，目前没有支持，看需求。

11、对CPU有限制吗？比如skylake的Pentium的GPU可以用GVT-d吗？

答：唯一的要求是有GPU。GVT-d就是指的VT-D，支持VT-D的机器都可以

12、这类显卡的视频处理是否只是并发4路，如果是的话，与1:7 VMs不匹配啊

答：并发路数应该与VM个数没有关系的。可以起7个VM，每个里面处理多路并发

13、我想问的是：(GVT-g)的方式是不是这样的，VM里面看到的是整个物理的GPU，访问方式是利用pass-through直接对GPU进行访问，但是要多个VM同时访问的话，这个调度是在hypervisor来调度、还是VM的驱动来调度？还是GPU的硬件来调度？

答：KVMGT是完全由软件调度的。显存的访问是pass-through的。KVMGT内部对显存做了partition。这是个好问题

14、请问我的物理机上如果有多块显卡，我如何分配指定给特定的虚拟机呢？

答：向OpenStack请求启动虚拟机是通过选择flavor来确定CPU，RAM，DISK的，我们的计划也是在Flavor中的extra_spec里面实现GPU类型的选择。所以GPU的分配是在虚拟机启动的时候由nova选择的。

15、请问我的物理机上如果有多块显卡，我如何分配指定给特定的虚拟机呢？

答：KVMGT只支持Intel的集成显卡，不会遇到多块显卡的问题

问：这样啊！那这个技术对于机器学习有帮助吗？

答：对于机器学习目前IntelGen graphics的运算能力还有差距，并不是Intel主推的机器学习平台

16、不同的VM之间做context switch的时候，GPU的pipeline是不是要完全flush？这个context是i915的驱动来管理的吗？

答：我们目前switch的时间点是GPU idle，就是说当前VM所发的任务跑完了。context的管里是一个实现问题。我们目前的实现里面：guest的context是做了shadow，影子context是由i915管理

17、VM内的多路并发没问题，但性能不足下的多路，浪费调度资源，设计合理性方面是否需要慎重考虑

答：是的，确实是。虚拟机之间的调度是存在性能损耗的

18、KVMGT什么时候可以upstream？

答：KVMGT目前正在进行upstream。我们主要的代码是改在kernel i915驱动里面。其中有一部分是驱动本身的扩展，更主要的一部分是虚拟gpu模型。目前第一部分已经upstream了，第二部分会作为英特尔GPU驱动的一个子模块，目标是今年upstrem到linux kernel，

19、openstack和Citrix虚拟化那个好，用户交付来说

答：OpenStack可以提供更全面的公有云，私有云和混合云的解决方案，提供计费，租户管理，网络，存储个类服务，和Citrix的关注点有所不同。

openstack 是云计算，原则上可以支持各种GPU虚拟化技术。 对于用户交付来说，Citrix应该是商业软件，他们应该交付好些吧。

20、gt技术3d画面是不是只是放在显存里没有export出来？有没有可能直接吧显存里渲染好的画面送到硬件视频编码给host上的协议服务端？能支持7个vgpu是并行的吗还是只是用某种方式分享一个物理gpu的时间片？听说intel的芯片带了视频编码硬件 这个和gpu部分是一起的还是一个独立的部分 也就是说用硬件视频编码的同时3d渲染的性能会不会下降？

 答：也是很好的问题。3D渲染出来的结果是可以直接做硬件编码的。这也是我们SPICE优化想做的事情 ，Intel有硬件编解码的fix function，与3D渲染有一定的并发性。但是3D和media操作还是有共用的单元，存在相互影响，KVMGT对GPU运算单元是分时共享。不是并发的。