CN108776949B - 用于图形处理环境中的存储器管理的设备和方法 - Google Patents

Abstract

本申请涉及并描述了用于图形处理环境中的存储器管理的设备和方法。例如，设备的一个实施例包括：第一多个图形处理资源，用于执行图形命令并处理图形数据；第一存储器管理单元(MMU)，用于将第一多个图形处理资源通信地耦合至系统级MMU以用于访问系统存储器；第二多个图形处理资源，用于执行图形命令并处理图形数据；第二MMU，用于将第二多个图形处理资源通信地耦合至第一MMU；其中第一MMU被配置为具有至系统级MMU的直接连接的主MMU，且第二MMU包括被配置成用于向第一MMU发送存储器事务的从MMU，第一MMU服务存储器事务、或代表第二MMU将存储器事务发送至系统级MMU。

Description

用于图形处理环境中的存储器管理的设备和方法

技术领域

本发明总体上涉及计算机处理器领域。更具体地，本发明涉及用于图形处理环境中的存储器管理的设备和方法。

相关技术的说明

最近在图形处理器单元(GPU)虚拟化方面取得了快速的进展。虚拟化图形处理环境被用于例如媒体云、远程工作站/桌面、可互换虚拟仪器 (IVI)、富客户机虚拟化等等。某些架构通过俘获与仿真来执行完整GPU 虚拟化，以对全功能虚拟GPU(vGPU)进行仿真，同时通过传递对性能关键的图形内存资源来提供接近原生的性能。

随着GPU在服务器中支持3D、媒体和GPGPU工作负载的重要性日益增加，GPU虚拟化正变得越来越普遍。如何虚拟化来自虚拟机(VM)的 GPU内存访问是关键设计因素之一。GPU拥有自己的图形存储器：专用视频存储器或共享系统存储器。当系统存储器用于图形时，客户机物理地址 (GPA)需要在被硬件访问之前转换为主机物理地址(HPA)。

为GPU执行转换有多种方法。一些实施方式通过硬件支持来执行转换，但是可以仅向一个VM传递GPU。另一解决方案是针对转换构建阴影结构的软件方法。例如，阴影页表采用某些架构来实现，诸如在上文提及的完整的GPU虚拟化解决方案中，所述架构可以支持多个VM共享物理GPU。

在一些实施方式中，客户机/VM存储器页由主机存储器页支持。虚拟机监视器(VMM)(有时称为“管理程序”)使用例如扩展页表(EPT) 从客户机物理地址(PA)映射到主机PA。可以使用多种存储器共享技术，诸如内核同页合并(KSM)技术。

KSM将具有相同内容的多个VM的页合并到带有写入保护的单个页中。也就是说，如果(从客户机PA1映射到主机PA1的)VM1中的存储器页具有与(从客户机PA2映射到主机PA2的)VM2中的另一个存储器页相同的内容，则可以仅使用一个主机页(如HPA_SH)来支持客户机存储器。也就是说，VM1的客户机PA1和VM2的PA2都映射到带有写入保护的 HPA_SH。这样可以节省用于系统的存储器，对于客户机的只读存储器页(诸如代码页和零页)特别有用。利用KSM，一旦VM修改了页内容，就可以使用写入时复制(COW)技术来移除共享。

中介传递用于虚拟化系统中的装置性能和共享，其中，单个物理GPU 作为多个虚拟GPU呈现给具有直接DMA的多个客户机，而客户机访问的特权资源仍然是被俘获与仿真的。在某些实施方式中，每个客户机可以运行原生GPU驱动程序，并且装置DMA直接进入存储器，而无需管理程序的干预。

附图说明

结合以下附图，从下面的详细描述中可以更好地理解本发明，其中：

图1是具有处理器的计算机系统的实施例的框图，所述处理器具有一个或多个处理器核和图形处理器；

图2是处理器的一个实施例的框图，所述处理器具有一个或多个处理器核、集成存储器控制器、以及集成图形处理器；

图3是图形处理器的一个实施例的框图，所述图形处理器可以是分立式图形处理单元、或者可以是与多个处理核集成的图形处理器；

图4是用于图形处理器的图形处理引擎的实施例的框图；

图5是图形处理器的另一实施例的框图；

图6是包括进程要素阵列的线程执行逻辑的框图；

图7展示了根据实施例的图形处理器执行单元指令格式；

图8是图形处理器的另一实施例的框图，所述图形处理器包括图形流水线、媒体流水线、显示引擎、线程执行逻辑、以及渲染输出流水线。

图9A是框图，展示了根据实施例的图形处理器命令格式；

图9B是框图，展示了根据实施例的图形处理器命令序列；

图10展示了根据实施例的数据处理系统的示例性图形软件架构；

图11展示了根据实施例的可以用于制造集成电路以执行操作的示例性IP核开发系统；

图12展示了根据实施例的可以使用一个或多个IP核来制造的示例性片上系统集成电路；

图13展示了可以使用一个或多个IP核来制造的片上系统集成电路的示例性图形处理器；

图14展示了可以使用一个或多个IP核来制造的片上系统集成电路的附加示例性图形处理器；

图15展示了示例性图形处理系统；

图16展示了全图形虚拟化的示例性架构；

图17展示了包括虚拟图形处理单元(vGPU)的示例性虚拟化图形处理架构；

图18展示了具有IOMMU的虚拟化架构的一个实施例；

图19展示了一个实施例，在所述实施例中，图形处理在服务器上执行；

图20示出其中多个图形分片包括缓冲和仲裁电路的一个实施例；

图21示出根据一个实施例的多组缓冲器；

图22示出根据本发明的一个实施例的方法；

图23示出服务分片的不同组的主和从存储器管理单元；

图24示出根据本发明的一个实施例的方法；

图25示出使用进程地址空间标识符(PASID)值来对大数量的图形处理单元(GPU)寻址的一个实施例；

图26示出根据本发明的一个实施例的方法；

图27示出客户机基址寄存器(BAR)和主机BAR的示例性排列；

图28示出从页表条目到主机物理地址空间的示例性映射；

图29将单级图形转换表与多级转换表进行比较；以及

图30示出其中某些虚拟机被分配单级图形转换表且其它VM被分配多级转换表的一个实施例。

具体实施方式

在以下描述中，出于解释的目的，阐述了许多具体的细节以便提供对以下所述的本发明的实施例的透彻理解。然而，对于本领域技术人员而言，可以在不具有这些具体细节中的一些具体细节的情况下实践本发明的实施例将是明显的。在其它实例中，以框图的形式示出了公知的结构和装置以避免模糊本发明的实施例的基本原理。

示例性图形处理器架构和数据类型

系统概述

图1是根据实施例的处理系统100的框图。在各种实施例中，系统100 包括一个或多个处理器102和一个或多个图形处理器108，并且可以是单处理器桌面系统、多处理器工作站系统、或具有大量处理器102或处理器核 107的服务器系统。在一个实施例中，系统100是用于移动式、手持式、或嵌入式装置的片上系统(SoC)集成电路内并入的处理平台。

系统100的实施例可包括或并入基于服务器的游戏平台、游戏控制台，包括游戏与媒体控制台、移动游戏控制台、手持式游戏控制台、或在线游戏控制台。在一些实施例中，系统100是移动电话、智能电话、平板计算装置或移动互联网装置。数据处理系统100还可包括可穿戴装置(诸如智能手表可穿戴装置、智能眼镜装置、增强现实装置、或虚拟现实装置)、与所述可穿戴装置耦合、或者集成在所述可穿戴装置中。在一些实施例中，数据处理系统100是电视或机顶盒装置，所述电视或机顶盒装置具有一个或多个处理器102以及由一个或多个图形处理器108生成的图形界面。

在一些实施例中，所述一个或多个处理器102各自包括用于处理指令的一个或多个处理器核107，所述指令在被执行时执行系统和用户软件的操作。在一些实施例中，一个或多个处理器核107中的每个处理器核被配置成用于处理特定的指令集109。在一些实施例中，指令集109可以促进复杂指令集计算(CISC)、精简指令集计算(RISC)、或经由超长指令字(VLIW) 的计算。多个处理器核107可以各自处理不同的指令集109，所述指令集可以包括用于促进对其它指令集进行仿真的指令。处理器核107还可以包括其它处理装置，如数字信号处理器(DSP)。

在一些实施例中，处理器102包括高速缓存存储器104。取决于架构，处理器102可以具有单个内部高速缓存或内部高速缓存的多个级。在一些实施例中，在处理器102的各部件当中共享高速缓存存储器。在一些实施例中，处理器102还使用外部高速缓存(例如，3级(L3)高速缓存或末级高速缓存(LLC))(未示出)，可以使用已知的高速缓存一致性技术来在处理器核107当中共享外部高速缓存。另外地，寄存器堆106包括在处理器102中，所述处理器可以包括用于存储不同类型的数据的不同类型的寄存器(例如，整数寄存器、浮点寄存器、状态寄存器、和指令指针寄存器)。一些寄存器可以是通用寄存器，而其它寄存器可以特定于处理器 102的设计。

在一些实施例中，处理器102与处理器总线110耦合，所述处理器总线用于在处理器102与系统100内的其它部件之间传输通信信号，例如地址、数据、或控制信号。在一个实施例中，系统100使用示例性‘中枢’系统架构，包括存储器控制器中枢116和输入输出(I/O)控制器中枢130。存储器控制器中枢116促进存储器装置与系统100的其它部件之间的通信，而I/O控制器中枢(ICH)130经由本地I/O总线提供与I/O装置的连接。在一个实施例中，存储器控制器中枢116的逻辑被集成在所述处理器内。

存储器装置120可以是动态随机存取存储器(DRAM)装置、静态随机存取存储器(SRAM)装置、闪存存储器装置、相变存储器装置、或具有合适的性能用作处理存储器的某个其它存储器装置。在一个实施例中，存储器装置120可作为系统100的系统存储器进行操作，以存储数据122和指令121，以供在一个或多个处理器102执行应用或进程时使用。存储器控制器中枢116还与可选的外部图形处理器112耦合，所述可选的外部图形处理器可以与处理器102中的一个或多个图形处理器108通信，从而执行图形和媒体操作。

在一些实施例中，ICH 130使得外围部件经由高速I/O总线连接至存储器装置120和处理器102。I/O外围部件包括但不限于音频控制器146、固件接口128、无线收发器126(例如，Wi-Fi、蓝牙)、数据存储装置124 (例如，硬盘驱动器、闪存存储器等)、以及用于将传统(例如，个人系统2(PS/2))装置耦合至所述系统的传统I/O控制器140。一个或多个通用串行总线(USB)控制器142连接多个输入装置，诸如键盘和鼠标144 组合。网络控制器134还可以与ICH 130耦合。在一些实施例中，高性能网络控制器(未示出)与处理器总线110耦合。应当理解，所示出的系统 100是示例性的而非限制性的，因为还可以使用以不同方式配置的其它类型的数据处理系统。例如，I/O控制器中枢130可以集成在一个或多个处理器 102内，或者存储器控制器中枢116和I/O控制器中枢130可以集成在分立式外部图形处理器(诸如外部图形处理器112)内。

图2是处理器200的实施例的框图，所述处理器具有一个或多个处理器核202A至202N、集成存储器控制器214、以及集成图形处理器208。图 2的具有与此处任何其它附图中的元件相同的参考号(或名称)的那些元件可采用与在本文中其它地方描述的方式相类似的任何方式进行操作或起作用，但不限于这些。处理器200可包括多达且包括由虚线框表示的附加核 202N的附加核。处理器核202A至202N各自包括一个或多个内部高速缓存单元204A至204N。在一些实施例中，每个处理器核还可以访问一个或多个共享的高速缓存单元206。

内部高速缓存单元204A至204N和共享高速缓存单元206表示处理器 200内的高速缓存存储器层级结构。所述高速缓存存储器层级结构可以包括每个处理器核内的至少一级指令和数据高速缓存以及一级或多级共享中级高速缓存，诸如2级(L2)、3级(L3)、4级(L4)、或其它级的高速缓存，其中，最高级的高速缓存在外部存储器之前被分类为LLC。在一些实施例中，高速缓存一致性逻辑维持各高速缓存单元206与204A至204N 之间的一致性。

在一些实施例中，处理器200还可以包括一组一个或多个总线控制器单元216和系统代理核210。一个或多个总线控制器单元216管理一组外围总线，诸如一个或多个外围部件互连总线(例如，PCI、PCI Express)。系统代理核210提供对各处理器部件的管理功能。在一些实施例中，系统代理核210包括一个或多个集成存储器控制器214用于管理对各外部存储器装置(未示出)的访问。

在一些实施例中，处理器核202A至202N中的一个或多个处理器核包括对同步多线程的支持。在这种实施例中，系统代理核210包括用于在多线程处理过程中协调和操作核202A至202N的部件。另外，系统代理核210 还可以包括功率控制单元(PCU)，所述功率控制单元包括用于调节处理器核202A至202N的功率状态的逻辑和部件以及图形处理器208。

在一些实施例中，处理器200附加地包括用于执行图形处理操作的图形处理器208。在一些实施例中，图形处理器208耦合至共享高速缓存单元 206集以及系统代理核210，所述系统代理核包括一个或多个集成存储器控制器214。在一些实施例中，显示控制器211与图形处理器208耦合以便将图形处理器输出驱动到一个或多个耦合的显示器。在一些实施例中，显示控制器211可以是经由至少一个互连与图形处理器耦合的单独模块，或者可以集成在图形处理器208或系统代理核210内。

在一些实施例中，基于环的互连单元212用于耦合处理器200的内部部件。然而，可以使用替代性互连单元，诸如点到点互连、切换式互连、或其它技术，包括本领域众所周知的技术。在一些实施例中，图形处理器 208经由I/O链路213与环形互连212耦合。

示例性I/O链路213表示多个I/O互连中的多个种类中的至少一种，包括促进各处理器部件与高性能嵌入式存储器模块218(诸如eDRAM模块) 之间的通信的封装I/O互连。在一些实施例中，处理器核202A至202N中的每个处理器核以及图形处理器208将嵌入式存储器模块218用作共享末级高速缓存。

在一些实施例中，处理器核202A至202N是执行相同指令集架构的均质核。在另一实施例中，处理器核202A至202N在指令集架构(ISA)方面是异构的，其中，处理器核202A至202N中的一者或多者执行第一指令集，而其它核中的至少一者执行所述第一指令集的子集或不同的指令集。在一个实施例中，处理器核202A至202N就微架构而言是同质的，其中，具有相对较高功耗的一个或多个核与具有较低功耗的一个或多个功率核耦合。另外，处理器200可以实现在一个或多个芯片上或者被实现为具有除其它部件之外的所展示的部件的SoC集成电路。

图3是图形处理器300的框图，所述图形处理器可以是分立式图形处理单元、或者可以是与多个处理核集成的图形处理器。在一些实施例中，图形处理器经由到图形处理器上的寄存器的映射I/O接口并且利用被放置在处理器存储器中的命令与存储器进行通信。在一些实施例中，图形处理器300包括用于访问存储器的存储器接口314。存储器接口314可以是到本地存储器、一个或多个内部高速缓存、一个或多个共享外部高速缓存、和/ 或到系统存储器的接口。

在一些实施例中，图形处理器300还包括显示控制器302，所述显示控制器用于将显示输出数据驱动到显示装置320。显示控制器302包括用于显示器的一个或多个重叠平面的硬件以及多层视频或用户接口元件的组成。在一些实施例中，图形处理器300包括用于编码、解码、或者向、从或在一个或多个媒体编码格式之间进行媒体代码转换的视频编解码器引擎306，包括但不限于：运动图像专家组(MPEG)(诸如MPEG-2)、高级视频编码(AVC)格式(诸如H.264/MPEG-4AVC)、以及电影与电视工程师协会(SMPTE)421M/VC-1、和联合图像专家组(JPEG)格式(诸如JPEG、以及运动JPEG(MJPEG)格式)。

在一些实施例中，图形处理器300包括块图像传送(BLIT)引擎304 以便执行二维(2D)栅格化器操作，包括例如，位边界块传送。然而，在一个实施例中，使用图形处理引擎(GPE)310的一个或多个部件执行2D 图形操作。在一些实施例中，GPE 310是用于执行图形操作的计算引擎，所述图形操作包括三维(3D)图形操作和媒体操作。

在一些实施例中，GPE 310包括用于执行3D操作的3D流水线312，诸如使用作用于3D图元形状(例如，矩形、三角形等)的处理功能来渲染三维图像和场景。3D流水线312包括可编程且固定的功能元件，所述可编程且固定的功能元件在到3D/媒体子系统315的元件和/或生成的执行线程内执行各种任务。虽然3D流水线312可以用于执行媒体操作，但是GPE310 的实施例还包括媒体流水线316，所述媒体流水线具体地用于执行媒体操作，诸如视频后处理和图像增强。

在一些实施例中，媒体流水线316包括固定功能或可编程逻辑单元以便代替、或代表视频编解码器引擎306来执行一种或多种专门的媒体操作，比如视频解码加速、视频去接口、以及视频编码加速。在一些实施例中，另外，媒体流水线316还包括线程生成单元以便生成用于在3D/媒体子系统 315上执行的线程。所生成的线程对3D/媒体子系统315中所包括的一个或多个图形执行单元执行对媒体操作的计算。

在一些实施例中，3D/媒体子系统315包括用于执行3D流水线312和媒体流水线316生成的线程的逻辑。在一个实施例中，流水线向3D/媒体子系统315发送线程执行请求，所述3D/媒体子系统包括用于仲裁并将各请求分派到可用的线程执行资源的线程分派逻辑。执行资源包括用于处理3D和媒体线程的图形执行单元阵列。在一些实施例中，3D/媒体子系统315包括用于线程指令和数据的一个或多个内部高速缓存。在一些实施例中，所述子系统还包括共享存储器(包括寄存器和可寻址存储器)以便在线程之间共享数据并用于存储输出数据。

图形处理引擎

图4是根据一些实施例的图形处理器的图形处理引擎410的框图。在一个实施例中，图形处理引擎(GPE)410是图3所示的GPE 310的一个版本。图4的具有与此处任何其它附图中的元件相同的参考号(或名称)的那些元件可采用与在本文中其它地方描述的方式相类似的任何方式进行操作或起作用，但不限于这些。例如，展示了图3的3D流水线312和媒体流水线316。媒体流水线316在GPE 410的一些实施例中是可选的，并且可以不显式地地包括在GPE 410内。例如以及在至少一个实施例中，单独的媒体和/或图像处理器被耦合至GPE410。

在一些实施例中，GPE 410与命令流送器403耦合或包括所述命令流送器，所述命令流送器向3D流水线312和/或媒体流水线316提供命令流。在一些实施例中，命令流送器403与存储器耦合，所述存储器可以是系统存储器、或内部高速缓存存储器和共享高速缓存存储器中的一个或多个高速缓存存储器。在一些实施例中，命令流送器403从存储器接收命令并将这些命令发送至3D流水线312和/或媒体流水线316。所述命令是从存储用于3D流水线312和媒体流水线316的环形缓冲器获取的指示。在一个实施例中，另外，环形缓冲器还可以包括存储多批多命令的批命令缓冲器。用于3D流水线312的命令还可以包括对在存储器中存储的数据的引用，诸如但不限于用于3D流水线312的顶点和几何数据和/或用于媒体流水线316 的图像数据和存储器对象。3D流水线312和媒体流水线316通过经由各自流水线内的逻辑执行操作或者通过将一个或多个执行线程分派至执行单元阵列414来处理所述命令。

在各种实施例中，3D流水线312可以通过处理指令并将执行线程分派给图形核阵列414来执行一个或多个着色器程序，诸如顶点着色器、几何着色器、像素着色器、片段着色器、计算着色器或其它着色器程序。图形核阵列414提供统一的执行资源块。图形核阵列414内的多用途执行逻辑 (例如，执行单元)包括对各种3D API着色器语言的支持，并且可以执行与多个着色器相关联的多个同时执行线程。

在一些实施例中，图形核阵列414还包括用于执行诸如视频和/或图像处理的媒体功能的执行逻辑。在一个实施例中，除了图形处理操作之外，执行单元还包括可编程以执行并行通用计算操作的通用逻辑。通用逻辑可以与图1的(多个)处理器核107或图2中的核202A至202N内的通用逻辑并行地或结合地执行处理操作。

由在图形核阵列414上执行的线程生成的输出数据可以将数据输出到统一返回缓冲器(URB)418中的存储器。URB 418可以存储多个线程的数据。在一些实施例中，URB 418可以用于在图形核阵列414上执行的不同线程之间发送数据。在一些实施例中，URB 418可以另外用于图形核阵列上的线程与共享功能逻辑420内的固定功能逻辑之间的同步。

在一些实施例中，图形核阵列414是可缩放的，使得所述阵列包括可变数量的图形核，这些图形核各自具有基于GPE 410的目标功率和性能等级的可变数量的执行单元。在一个实施例中，执行资源是动态可缩放的，从而可以根据需要启用或禁用执行资源。

图形核阵列414与共享功能逻辑420耦合，所述共享功能逻辑包括在图形核阵列中的图形核之间共享的多个资源。共享功能逻辑420内的共享功能是向图形核阵列414提供专用补充功能的硬件逻辑单元。在各种实施例中，共享功能逻辑420包括但不限于采样器421、数学422和线程间通信 (ITC)423逻辑。另外，一些实施例实现共享功能逻辑420内的一个或多个高速缓存425。在给定的专用功能的需求不足以包含在图形核阵列414 中的情况下实现共享功能。相反，所述专用功能的单个实例被实现为共享功能逻辑420中的独立实体并且在图形核阵列414内的执行资源之间共享。在图形核阵列414之间共享并包括在图形核阵列414内的精确的一组功能在各实施例之间变化。

图5是图形处理器500的另一实施例的框图。图5的具有与此处任何其它附图中的元件相同的参考号(或名称)的那些元件可采用与在本文中其它地方描述的方式相类似的任何方式进行操作或起作用，但不限于这些。

在一些实施例中，图形处理器500包括环形互连502、流水线前端504、媒体引擎537以及图形核580A至580N。在一些实施例中，环形互连502 将图形处理器耦合至其它处理单元，包括其它图形处理器或者一个或多个通用处理器核。在一些实施例中，图形处理器是集成在多核处理系统内的多个处理器之一。

在一些实施例中，图形处理器500经由环形互连502接收多批命令。传入命令由流水线前端504中的命令流送器503来解译。在一些实施例中，图形处理器500包括可缩放执行逻辑，以用于经由(多个)图形核580A至 580N执行3D几何处理和媒体处理。对于3D几何处理命令，命令流送器 503将命令供应至几何流水线536。针对至少一些媒体处理命令，命令流送器503将命令供应至视频前端534，所述视频前端与媒体引擎537耦合。在一些实施例中，媒体引擎537包括用于视频和图像后处理的视频质量引擎 (VQE)530以及用于提供硬件加速的媒体数据编码和解码的多格式编码/ 解码(MFX)533引擎。在一些实施例中，几何流水线536和媒体引擎537 各自生成执行线程，所述执行线程用于由至少一个图形核580A提供的线程执行资源。

在一些实施例中，图形处理器500包括可扩展线程执行资源表征模块核580A至580N(有时被称为核分片)，各个可扩展线程执行资源表征模块核具有多个子核550A至550N、560A至560N(有时被称为核子分片)。在一些实施例中，图形处理器500可以具有任意数量的图形核580A至580N。在一些实施例中，图形处理器500包括图形核580A，所述图形核至少具有第一子核550A和第二子核560A。在其它实施例中，图形处理器是具有单个子核(例如，550A)的低功率处理器。在一些实施例中，图形处理器500 包括多个图形核580A至580N，所述图形核各自包括一组第一子核550A 至550N和一组第二子核560A至560N。所述一组第一子核550A至550N 中的每个子核至少包括第一组执行单元552A至552N和媒体/纹理采样器 554A至554N。所述一组第二子核560A至560N中的每个子核至少包括第二组执行单元562A至562N和采样器564A至564N。在一些实施例中，每个子核550A至550N、560A至560N共享一组共享资源570A至570。在一些实施例中，所述共享资源包括共享高速缓存存储器和像素操作逻辑。其它共享资源也可以包括在图形处理器的各实施例中。

执行单元

图6展示了线程执行逻辑600，所述线程执行逻辑包括在GPE的一些实施例中采用的处理元件阵列。图6的具有与此处任何其它附图中的元件相同的参考号(或名称)的那些元件可采用与在本文中其它地方描述的方式相类似的任何方式进行操作或起作用，但不限于这些。

在一些实施例中，线程执行逻辑600包括着色器处理器602、线程分派器604、指令高速缓存606、包括多个执行单元608A至608N的可扩展执行单元阵列、采样器610、数据高速缓存612、以及数据端口614。在一个实施例中，可缩放执行单元阵列可以通过基于工作负荷的计算需求来启用或禁用一个或多个执行单元(例如，执行单元608A、608B、608C，608D，一直到608N-1和608N中的任一个)来动态地缩放。在一个实施例中，所包括的部件经由互连结构而互连，所述互连结构链接到部件中的每个部件。在一些实施例中，线程执行逻辑600包括通过指令高速缓存606、数据端口 614、采样器610、以及执行单元阵列608A至608N中的一者或多者到存储器(如系统存储器或高速缓存存储器)的一个或多个连接件。在一些实施例中，每个执行单元(例如，608A)是能够执行多个同步硬件线程同时针对每个线程并行地处理多个数据元素的独立可编程通用计算单元。在各种实施例中，执行单元608A至608N的阵列是可缩放的以包括任意数量的单独执行单元。

在一些实施例中，执行单元608A至608N主要用于执行着色器程序。着色器处理器602可以处理各种着色器程序并且经由线程分派器604分派与着色器程序相关联的执行线程。在一个实施例中，线程分派器包括用于对来自图形和媒体流水线的线程发起请求进行仲裁并且在一个或多个执行单元608A至608N上实例化所请求的线程的逻辑。例如，几何流水线(例如，图5的536)可以将顶点处理、镶嵌或几何处理线程分派至线程执行逻辑600(图6)进行处理。在一些实施例中，线程分派器604还可处理来自执行着色器程序的运行时间线程生成请求。

在一些实施例中，执行单元608A至608N支持指令集(所述指令集包括对许多标准3D图形着色器指令的原生支持)，从而使得以最小的转换执行来自图形库(例如，Direct 3D和OpenGL)的着色器程序。这些执行单元支持顶点和几何处理(例如，顶点程序、几何程序、顶点着色器)、像素处理(例如，像素着色器、片段着色器)以及通用处理(例如，计算和媒体着色器)。执行单元608A至608N中的每一个都能够执行多发布单指令多数据(SIMD)，并且多线程操作能够在面对较高等待时间的存储器访问时实现有效的执行环境。每个执行单元内的每个硬件线程都具有专用的高带宽寄存器堆和相关的独立线程状态。对于具有整数、单精度浮点运算和双精度浮点运算、SIMD分支功能、逻辑运算、超越运算和其它杂项运算的流水线，执行是每个时钟的多发布。在等待来自存储器或共享功能之一的数据时，执行单元608A至608N内的依赖性逻辑使等待线程休眠，直到所请求的数据已返回。当等待线程正在休眠时，硬件资源可能会专门用于处理其它线程。例如，在与顶点着色器操作相关联的延迟期间，执行单元可以执行像素着色器、片段着色器或包括不同顶点着色器的另一种类型的着色器程序的操作。

执行单元608A至608N中的每个执行单元在数据元素阵列上进行操作。数据元素的数量是“执行大小”、或指令的信道数。执行信道是执行数据元素访问、掩蔽、和指令内的流控制的逻辑单元。信道的数量可以与针对特定图形处理器的物理算术逻辑单元(ALU)或浮点单元(FPU)的数量无关。在一些实施例中，执行单元608A至608N支持整数和浮点数据类型。

执行单元指令集包括SIMD指令。各种数据元素可作为压缩数据类型存储在寄存器中，并且执行单元将基于元素的数据大小来处理各种元素。例如，当在256位宽的向量上进行操作时，所述256位的向量存储在寄存器中，并且所述执行单元作为四个单独64位压缩数据元素(四倍字长(QW) 大小的数据元素)、八个单独32位压缩数据元素(双倍字长(DW)大小的数据元素)、十六个单独16位压缩数据元素(字长(W)大小的数据元素)、或三十二个单独8位数据元素(字节(B)大小的数据元素)在所述向量上进行操作。然而，不同的向量宽度和寄存器大小是可能的。

一个或多个内部指令高速缓存(例如，606)包括在所述线程执行逻辑 600中以便高速缓存所述执行单元的线程指令。在一些实施例中，一个或多个数据高速缓存(例如，612)被包括用于高速缓存在线程执行过程中的线程数据。在一些实施例中，采样器610被包括用于为3D操作提供纹理采样并且为媒体操作提供媒体采样。在一些实施例中，采样器610包括专门的纹理或媒体采样功能，以便在向执行单元提供采样数据之前在采样过程中处理纹理或媒体数据。

在执行过程中，所述图形和媒体流水线经由线程生成和分派逻辑向线程执行逻辑600发送线程发起请求。一旦一组几何对象已经被处理并被栅格化成像素数据，则着色器处理器602内的像素处理器逻辑(例如，像素着色器逻辑、片段着色器逻辑等)被调用以便进一步计算输出信息，并且使得结果被写入到输出表面(例如，色彩缓冲器、深度缓冲器、模板缓冲器等)。在一些实施例中，像素着色器或片段着色器计算各顶点属性的值，所述各顶点属性跨栅格化对象被内插。在一些实施例中，着色器处理器602 内的像素处理器逻辑然后执行应用编程接口(API)供应的像素或片段着色器程序。为了执行着色器程序，着色器处理器602经由线程分派器604将线程分派至执行单元(例如，608A)。在一些实施例中，像素着色器602 使用采样器610中的纹理采样逻辑来访问存储器中所存储的纹理图中的纹理数据。对纹理数据和输入几何数据的算术运算计算每个几何片段的像素颜色数据，或丢弃一个或多个像素而不进行进一步处理。

在一些实施例中，数据端口614提供存储器访问机制，供线程执行逻辑600将经处理的数据输出至存储器以便在图形处理器输出流水线上进行处理。在一些实施例中，数据端口614包括或耦合至一个或多个高速缓存存储器(例如，数据高速缓存612)从而经由数据端口高速缓存数据以供存储器访问。

图7是框图，展示了根据一些实施例的图形处理器指令格式700。在一个或多个实施例中，图形处理器执行单元支持具有多种格式的指令的指令集。实线框展示了通常包括在执行单元指令中的部件，而虚线包括可选的部件或仅包括在指令子集中的部件。在一些实施例中，所描述和展示的指令格式700是宏指令，因为所述宏指令是供应至执行单元的指令，这与从指令解码产生的微操作相反(一旦所述指令被处理)。

在一些实施例中，图形处理器执行单元原生地支持采用128位指令格式710的指令。64位压缩指令格式730可用于基于所选指令、指令选项和操作数数量的一些指令。原生128位指令格式710提供对所有指令选项的访问，而一些选项和操作限制在64位指令格式730中。64位指令格式730 中可用的原生指令根据实施例而不同。在一些实施例中，使用索引字段713 中的一组索引值将指令部分地压缩。执行单元硬件基于索引值来参考一组压缩表，并使用压缩表输出来重构采用128位指令格式710的原生指令。

针对每种格式，指令操作码712限定了所述执行单元要执行的操作。执行单元跨每个操作数的多个数据元素来并行地执行每条指令。例如，响应于添加指令，执行单元跨每个颜色通道执行同步添加操作，所述颜色通道表示纹理元素或图片元素。默认地，执行单元跨操作数的所有数据信道执行每条指令。在一些实施例中，指令控制字段714使能控制某些执行选项，诸如信道选择(例如，预测)以及数据信道排序(例如，混合)。针对采用128位指令格式710的指令，执行大小字段716限制了将并行执行的数据信道的数量。在一些实施例中，执行大小字段716不可用于64位压缩指令格式730。

一些执行单元指令具有多达三个操作数，包括两个源操作数(src0 720、src1722)以及一个目标操作数718。在一些实施例中，执行单元支持双目的地指令，其中，这些目的地之一是隐式的。数据操作指令可以具有第三源操作数(例如，SRC2 724)，其中，指令操作码712确定源操作数的数量。指令的最后一个源操作数可以是与所述指令一起传递的立即数(例如，硬编码)值。

在一些实施例中，128位的指令格式710包括访问/寻址模式字段726，所述访问/寻址模式字段例如限定了是使用直接寄存器寻址模式还是间接寄存器寻址模式。当使用直接寄存器寻址模式时，直接由指令中的位来提供一个或多个操作数的寄存器地址。

在一些实施例中，128位指令格式710包括访问/地址模式字段726，其指定指令的地址模式和/或访问模式。在一个实施例中，访问模式用于限定针对指令的数据访问对齐。一些实施例支持访问模式，包括16字节对齐访问模式和1字节对齐访问模式，其中，访问模式的字节对齐确定了指令操作数的访问对齐。例如，当在第一模式中时，指令可以使用字节对齐寻址以用于源操作数和目的地操作数，并且当在第二模式中时，指令可以使用16字节对齐寻址以用于所有的源操作数和目的地操作数。

在一个实施例中，访问/地址模式字段726的地址模式部分判定指令是使用直接寻址还是间接寻址。当使用直接寄存器寻址模式时，指令中的位直接提供一个或多个操作数的寄存器地址。当使用间接寄存器寻址模式时，可以基于指令中的地址寄存器值和地址立即数字段来计算一个或多个操作数的寄存器地址。

在一些实施例中，基于操作码712位字段对指令进行分组从而简化操作码解码740。针对8位的操作码，第4、5、和6位允许执行单元确定操作码的类型。所示出的精确操作码分组仅是示例性的。在一些实施例中，移动和逻辑操作码组742包括数据移动和逻辑指令(例如，移动(mov)、比较(cmp))。在一些实施例中，移动和逻辑组742共享五个最高有效位(MSB)，其中，移动(mov)指令采用0000xxxxb的形式，而逻辑指令采用0001xxxxb的形式。流控制指令组744(例如，调用(call)、跳(jmp)) 包括采用0010xxxxb形式(例如，0x20)的指令。杂项指令组746包括指令的混合，包括采用0011xxxxb形式(例如，0x30)的同步指令(例如，等待(wait)、发送(send))。并行数学指令组748包括采用0100xxxxb 形式(例如，0x40)的按分量的算术指令(例如，加(add)、乘(mul))。并行数学组748跨数据信道并行地执行算术运算。向量数学分组750包括按照0101xxxxb形式(例如，0x50)的算术指令(例如，dp4)。向量数学组对向量操作数执行算术运算，诸如点积运算。

图形流水线

图8是图形处理器800的另一个实施例的框图。图8的具有与此处任何其它附图中的元件相同的参考号(或名称)的那些元件可采用与在本文中其它地方描述的方式相类似的任何方式进行操作或起作用，但不限于这些。

在一些实施例中，图形处理器800包括图形流水线820、媒体流水线 830、显示引擎840、线程执行逻辑850、以及渲染输出流水线870。在一些实施例中，图形处理器800是包括一个或多个通用处理核的多核处理系统内的图形处理器。图形处理器受到至一个或多个控制寄存器(未示出)的寄存器写入的控制或者经由环形互连802经由发布至图形处理器800的命令被控制。在一些实施例中，环形互连802将图形处理器800耦合至其它处理部件，诸如其它图形处理器或通用处理器。来自环形互连802的命令通过命令流送器803被解译，所述命令流送器将指令供应至图形流水线820 或媒体流水线830的单独部件。

在一些实施例中，命令流送器803引导顶点获取器805的操作，其从存储器读取顶点数据并执行命令流送器803所提供的顶点处理命令。在一些实施例中，顶点获取器805将顶点数据提供给顶点着色器807，所述顶点着色器对每个顶点执行坐标空间转换和照明操作。在一些实施例中，顶点获取器805和顶点着色器807通过经由线程分派器831向执行单元852A至 852B分派执行线程来执行顶点处理指令。

在一些实施例中，执行单元852A至852B是具有用于执行图形和媒体操作的指令集的向量处理器阵列。在一些实施例中，执行单元852A至852B 具有附接的L1高速缓存851，其专用于每个阵列或在阵列之间共享。高速缓存可以被配置为数据高速缓存、指令高速缓存、或单个高速缓存，所述单个高速缓存被分区为包含不同分区中的数据和指令。

在一些实施例中，图形流水线820包括用于执行3D对象的硬件加速镶嵌的镶嵌部件。在一些实施例中，可编程的外壳着色器811配置镶嵌操作。可编程域着色器817提供对镶嵌输出的后端评估。镶嵌器813在外壳着色器811的方向上进行操作并且包含专用逻辑，所述专用逻辑用于基于粗糙几何模型来生成详细的几何对象集合，所述粗糙几何模型作为输入被提供至图形流水线820。在一些实施例中，如果未使用镶嵌，则可以对镶嵌部件 (例如，外壳着色器811、镶嵌器813、域着色器817)进行旁路。

在一些实施例中，完整的几何对象可以由几何着色器819经由被分派至所述执行单元852A至852B的一个或多个线程来处理、或者可以直接行进至剪裁器829。在一些实施例中，几何着色器在整个几何对象(而非顶点或者如图形流水线的先前级中的顶点补丁)上进行操作。如果禁用镶嵌，则几何着色器819从顶点着色器807接收输入。在一些实施例中，几何着色器819可由几何着色器程序编程以便在镶嵌单元被禁用时执行几何镶嵌。

在栅格化之前，剪裁器829处理顶点数据。裁剪器829可以是固定功能的裁剪器或者具有裁剪和几何着色器功能的可编程裁剪器。在一些实施例中，渲染输出流水线870中的栅格器和深度测试部件873分派像素着色器以将几何对象转换为其每像素表示。在一些实施例中，像素着色器逻辑包括在线程执行逻辑850中。在一些实施例中，应用可对栅格器和深度测试部件873进行旁路并且经由流出单元823访问未栅格化的顶点数据。

图形处理器800具有互连总线、互连结构、或某个其它的互连机制，所述互连机制允许数据和消息在所述图形处理器的主要部件之中传递。在一些实施例中，执行单元852A至852B和(多个)相关联的高速缓存851、纹理和媒体采样器854、以及纹理/采样器高速缓存858经由数据端口856 进行互连，以便执行存储器访问并且与所述处理器的渲染输出流水线部件进行通信。在一些实施例中，采样器854、高速缓存851、858以及执行单元852A至852B各自具有单独的存储器访问路径。

在一些实施例中，渲染输出流水线870包含栅格化器和深度测试部件873，其将基于顶点的对象转换为相关联的基于像素的表示。在一些实施例中，栅格器逻辑包括用于执行固定功能三角形和线栅格化的窗口器/掩蔽器单元。相关联的渲染高速缓存878和深度高速缓存879在一些实施例中也是可用的。像素操作部件877对数据进行基于像素的操作，然而在一些实例中，与2D操作(例如，利用混合的位块图像传送)相关联的像素操作由2D引擎841执行、或者在显示时间由显示控制器843使用重叠显示平面来代替。在一些实施例中，共享的L3高速缓存875可用于所有的图形部件，从而允许在无需使用主系统存储器的情况下共享数据。

在一些实施例中，图形处理器媒体流水线830包括媒体引擎837和视频前端834。在一些实施例中，视频前端834从命令流送器803接收流水线命令。在一些实施例中，媒体流水线830包括单独的命令流送器。在一些实施例中，视频前端834在将所述命令发送至媒体引擎837之前处理媒体命令。在一些实施例中，媒体引擎837包括用于生成线程以用于经由线程分派器831分派至线程执行逻辑850的线程生成功能。

在一些实施例中，图形处理器800包括显示引擎840。在一些实施例中，显示引擎840在处理器800外部并且经由环形互连802、或某个其它互连总线或机构与图形处理器耦合。在一些实施例中，显示引擎840包括2D 引擎841和显示控制器843。在一些实施例中，显示引擎840包含能够独立于3D流水线而操作的专用逻辑。在一些实施例中，显示控制器843与显示装置(未示出)耦合，所述显示装置可以是系统集成显示装置(如在膝上型计算机中)、或者经由显示设备连接器附接的外部显示装置。

在一些实施例中，图形流水线820和媒体流水线830可配置用于基于多个图形和媒体编程接口执行操作并且并非专用于任何一种应用编程接口 (API)。在一些实施例中，图形处理器的驱动程序软件将专用于特定图形或媒体库的API调用转换为可由图形处理器处理的命令。在一些实施例中，为全部来自Khronos Group的开放图形库(OpenGL)、开放计算语言 (OpenCL)和/或Vulkan图形和计算API提供了支持。在一些实施例中，也可以为微软公司的Direct3D库提供支持。在一些实施例中，可以支持这些库的组合。还可以为开源计算机视觉库(OpenCV)提供支持。如果可做出从未来API的流水线到图形处理器的流水线的映射，则具有兼容3D流水线的未来API也将受到支持。

图形流水线编程

图9A是展示了根据一些实施例的图形处理器命令格式900的框图。图 9B是框图，展示了根据实施例的图形处理器命令序列910。图9A中的实线框展示了一般包括在图形命令中的部件，而虚线包括任选的或仅包括在所述图形命令的子集中的部件。图9A的示例性图形处理器命令格式900 包括用于标识所述命令的目标客户机902、命令操作代码(操作码)904、以及用于所述命令的相关数据906的数据字段。一些命令中还包括子操作码905和命令大小908。

在一些实施例中，客户机902限定了处理命令数据的图形装置的客户机单元。在一些实施例中，图形处理器命令解析器检查每个命令的客户机字段以便调整对命令的进一步处理并将命令数据路由至合适的客户机单元。在一些实施例中，图形处理器客户机单元包括存储器接口单元、渲染单元、 2D单元、3D单元、和媒体单元。每个客户机单元具有对命令进行处理的相应处理流水线。一旦命令被客户机单元接收到，客户机单元就读取操作码904以及子操作码905(如果存在的话)从而确定要执行的操作。客户机单元使用数据字段906内的信息来执行命令。针对一些命令，期望有显式的命令大小908来限定命令的大小。在一些实施例中，命令解析器基于命令操作码自动地确定命令中的至少一些命令的大小。在一些实施例中，经由双倍字长的倍数对命令进行对齐。

图9B中的流程图示出了示例性图形处理器命令序列910。在一些实施例中，以图形处理器的实施例为特征的数据处理系统的软件或固件使用所示出的命令序列的版本来启动、执行并终止图形操作集合。仅出于示例性目的示出并描述了样本命令序列，如实施例并不限于这些特定命令或者此命令序列。而且，所述命令可以作为一批命令以命令序列被发布，从而使得图形处理器将以至少部分同时的方式处理命令序列。

在一些实施例中，图形处理器命令序列910可以以流水线转储清除命令912开始以便使得任一活跃图形流水线完成针对所述流水线的当前未决命令。在一些实施例中，3D流水线922和媒体流水线924不同时进行操作。执行流水线转储清除以使得活动图形流水线完成任何未决命令。响应于流水线转储清除，用于图形处理器的命令解析器将停止命令处理直到活跃绘画引擎完成未决操作并且使得相关的读高速缓存失效。可选地，渲染高速缓存中被标记为‘脏(dirty)’的任何数据可以被转储清除到存储器中。在一些实施例中，流水线转储清除命令912可以用于流水线同步或者用在将图形处理器置于低功率状态之前。

在一些实施例中，当命令序列需要图形处理器在流水线之间显式地地切换时，使用流水线选择命令913。在一些实施例中，在发布流水线命令之前在执行情境中仅需要一次流水线选择命令913，除非所述情境要发布针对两条流水线的命令。在一些实施例中，在经由流水线选择命令913的流水线切换之前正好需要流水线转储清除命令912。

在一些实施例中，流水线控制命令914配置用于操作的图形流水线并且用于对3D流水线922和媒体流水线924进行编程。在一些实施例中，流水线控制命令914配置活跃流水线的流水线状态。在一个实施例中，流水线控制命令914用于流水线同步并且用于在处理一批命令之前清除来自活跃流水线内的一个或多个高速缓存存储器中的数据。

在一些实施例中，用于返回缓冲器状态的命令916用于配置返回缓冲器的集合以供相应的流水线写入数据。一些流水线操作需要分配、选择、或配置一个或多个返回缓冲器，在处理过程中所述操作将中间数据写入所述一个或多个返回缓冲器中。在一些实施例中，图形处理器还使用一个或多个返回缓冲器以便存储输出数据并且执行跨线程通信。在一些实施例中，配置返回缓冲器状态916包括选择返回缓冲器的大小和数量以用于流水线操作集合。

命令序列中的剩余命令基于用于操作的活跃流水线而不同。基于流水线判定920，所述命令序列被定制用于以3D流水线状态930开始的3D流水线922、或者在媒体流水线状态940处开始的媒体流水线924。

用于配置3D流水线状态930的命令包括用于顶点缓冲器状态、顶点元素状态、常量颜色状态、深度缓冲器状态、以及有待在处理3D图元命令之前配置的其它状态变量的3D状态设置命令。这些命令的值至少部分地基于使用中的特定3D API来确定。在一些实施例中，3D流水线状态930命令还能够选择性地禁用或旁路掉特定流水线元件(如果将不使用那些元件的话)。

在一些实施例中，3D图元932命令用于提交待由3D流水线处理的3D 图元。经由3D图元932命令传递给图形处理器的命令和相关联参数将被转发到所述图形流水线中的顶点获取功能。顶点获取功能使用3D图元932 命令数据来生成多个顶点数据结构。所述顶点数据结构被存储在一个或多个返回缓冲器中。在一些实施例中，3D图元932命令用于经由顶点着色器对3D图元执行顶点操作。为了处理顶点着色器，3D流水线922将着色器执行线程分派至图形处理器执行单元。

在一些实施例中，经由执行934命令或事件触发3D流水线922。在一些实施例中，寄存器写入触发命令执行。在一些实施例中，经由命令序列中的‘前进’(‘go’)或‘剔除’(‘kick’)命令来触发执行。在一个实施例中，使用流水线同步命令来触发命令执行以便通过图形流水线转储清除命令序列。3D流水线将针对3D图元来执行几何处理。一旦完成操作，则对所产生的几何对象进行栅格化，并且像素引擎对所产生的像素进行着色。对于这些操作，还可以包括用于控制像素着色和像素后端操作的附加命令。

在一些实施例中，当执行媒体操作时，图形处理器命令序列910跟随在媒体流水线924路径之后。一般地，针对媒体流水线924进行编程的具体用途和方式取决于待执行的媒体或计算操作。在媒体解码过程中，特定的媒体解码操作可以被卸载到所述媒体流水线。在一些实施例中，还可对媒体流水线进行旁路，并且可使用由一个或多个通用处理核提供的资源来整体地或部分地执行媒体解码。在一个实施例中，媒体流水线还包括用于通用图形处理器单元(GPGPU)操作的元件，其中，所述图形处理器用于使用计算着色器程序来执行SIMD向量运算，所述计算着色器程序与渲染图形图元不是显式地相关的。

在一些实施例中，以与3D流水线922相似的方式对媒体流水线924 进行配置。将用于配置媒体流水线状态940的一组命令分派或放置到命令队列中，在媒体对象命令942之前。在一些实施例中，用于媒体流水线状态的命令940包括用于配置媒体流水线元件的数据，所述媒体流水线元件将用于对媒体对象进行处理。这包括用于在媒体流水线内配置视频解码和视频编码逻辑的数据，诸如编码或解码格式。在一些实施例中，用于媒体流水线状态的命令940还支持将一个或多个指针用于包含一批状态设置的“间接”状态元件。

在一些实施例中，媒体对象命令942将指针供应至媒体对象以用于由媒体流水线进行处理。媒体对象包括存储器缓冲器，所述存储器缓冲器包含待处理的视频数据。在一些实施例中，在发布媒体对象命令942之前，所有的媒体流水线状态必须是有效的。一旦流水线状态被配置并且媒体对象命令942被排队，则经由执行944命令或等效的执行事件(例如，寄存器写入)来触发媒体流水线924。然后可以通过由3D流水线922或媒体流水线924提供的操作对来自媒体流水线924的输出进行后处理。在一些实施例中，以与媒体操作类似的方式来配置和执行GPGPU操作。

图形软件架构

图10展示了根据一些实施例的数据处理系统1000的示例性图形软件架构。在一些实施例中，软件架构包括3D图形应用1010、操作系统1020、以及至少一个处理器1030。在一些实施例中，处理器1030包括图形处理器 1032以及一个或多个通用处理器核1034。图形应用1010和操作系统1020 各自在数据处理系统的系统存储器1050中执行。

在一些实施例中，3D图形应用1010包含一个或多个着色器程序，所述一个或多个着色器程序包括着色器指令1012。着色器语言指令可以采用高级着色器语言，诸如高级着色器语言(HLSL)或OpenGL着色器语言 (GLSL)。所述应用还包括可执行指令1014，所述可执行指令采用适合用于由通用处理器核1034执行的机器语言。所述应用还包括由顶点数据限定的图形对象1016。

在一些实施例中，操作系统1020是来自微软公司的 操作系统、专用UNIX式操作系统、或使用Linux内核变体的开源UNIX式操作系统。操作系统1020可以支持图形API 1022，诸如Direct3D API、OpenGL API或Vulkan API。当Direct3D API正在使用时，操作系统 1020使用前端着色器编译器1024以将HLSL中的任何着色器指令1012编译成较低级的着色器语言。所述编译可以是即时(JIT)编译，或者所述应用可执行着色器预编译。在一些实施例中，在对3D图形应用1010进行编译的过程中，将高级着色器编译成低级着色器。在一些实施例中，着色器指令1012以中间形式提供，诸如由Vulkan API使用的标准便携式中间表示(SPIR)的版本。

在一些实施例中，用户模式图形驱动程序1026包含后端着色器编译器 1027，所述后端着色器编译器用于将着色器指令1012变换成硬件专用的表示。当在使用OpenGL API时，将采用GLSL高级语言的着色器指令1012 传递至用户模式图形驱动程序1026以用于编译。在一些实施例中，用户模式图形驱动程序1026使用操作系统内核模式功能1028来与内核模式图形驱动程序1029进行通信。在一些实施例中，内核模式图形驱动程序1029 与图形处理器1032进行通信以便分派命令和指令。

IP核实施方式

至少一个实施例的一个或多个方面可以由存储在机器可读介质上的代表性代码实现，所述机器可读介质表示和/或限定集成电路(诸如处理器) 内的逻辑。例如，机器可读介质可以包括表示处理器内的各个逻辑的指令。当由机器读取时，所述指令可以使机器制造用于执行本文所述的技术的逻辑。这类表示(称为“IP核”)是集成电路的逻辑的可重复使用单元，所述可重复使用单元可以作为对集成电路的结构进行描述的硬件模型而存储在有形、机器可读介质上。可以将硬件模型供应至在制造集成电路的制造机器上加载硬件模型的各消费者或制造设施。可以制造集成电路，从而使得所述电路执行与在此描述的实施例中的任一实施例相关联地描述的操作。

图11是展示了根据实施例的可以用于制造集成电路以执行操作的IP 核开发系统1100的框图。IP核开发系统1100可以用于生成可并入到更大的设计中或用于构建整个集成电路(例如，SOC集成电路)的模块化、可重复使用设计。设计设施1130可采用高级编程语言(例如，C/C++)生成对IP核设计的软件仿真1110。软件仿真1110可用于使用仿真模型1112来设计、测试并验证IP核的行为。仿真模型1112可以包括功能、行为和/或时序仿真。然后可由仿真模型1112来创建或合成寄存器传送级(RTL)设计1115。RTL设计1115是对硬件寄存器之间的数字信号的流动进行建模的集成电路(包括使用建模的数字信号执行的相关联逻辑)的行为的抽象。除了RTL设计1115之外，还可以创建、设计或合成逻辑电平或晶体管电平处的较低层次设计。由此，初始设计和仿真的具体细节可以发生变化。

可以由设计设施将RTL设计1115或等效方案进一步合成为硬件模型 1120，所述硬件模型可以采用硬件描述语言(HDL)或物理设计数据的某种其它表示。可以进一步仿真或测试HDL以验证IP核设计。可使用非易失性存储器1140(例如，硬盘、闪存、或任何非易失性存储介质)来存储 IP核设计以用于递送至第3方制造设施1165。可替代地，可以通过有线连接1150或无线连接1160来传输(例如，经由互联网)IP核设计。制造设施1165然后可以制造至少部分地基于IP核设计的集成电路。所制造的集成电路可被配置用于执行根据在此描述的至少一个实施例的操作。

示例性片上系统集成电路

图12至图14展示了根据本文所述的各种实施例的可以使用一个或多个IP核来制造的示例性集成电路和相关图形处理器。除了所展示的之外，还可以包括其它逻辑和电路，包括附加的图形处理器/核、外围接口控制器或通用处理器核。

图12是展示了根据实施例的可以使用一个或多个IP核来制造的示例性片上系统集成电路1200的框图。示例性集成电路1200包括一个或多个应用处理器1205(例如，CPU)、至少一个图形处理器1210，并且另外还可以包括图像处理器1215和/或视频处理器1220，其中的任一项都可以是来自相同或多个不同设计设施的模块化IP核。集成电路1200包括外围或总线逻辑，包括USB控制器1225、UART控制器1230、SPI/SDIO控制器 1235和I2S/I2C控制器1240。另外，集成电路还可以包括显示装置1245，所述显示装置耦合至高清晰度多媒体接口(HDMI)控制器1250和移动行业处理器接口(MIPI)显示界面1255中的一项或多项。可以由闪存子系统1260(包括闪存和闪存控制器)来提供存储。可以经由存储器控制器1265 来提供存储器接口以访问SDRAM或SRAM存储器装置。另外，一些集成电路还包括嵌入式安全引擎1270。

图13是展示了根据实施例的可以使用一个或多个IP核来制造的片上系统集成电路的示例性图形处理器1310的框图。图形处理器1310可以是图12的图形处理器1210的变体。图形处理器1310包括顶点处理器1305 和一个或多个片段处理器1315A至1315N(例如，1315A、1315B、1315C、 1315D，一直到1315N-1和1315N)。图形处理器1310可以经由单独的逻辑执行不同的着色器程序，使得顶点处理器1305被优化以执行顶点着色器程序的操作，而一个或多个片段处理器1315A至1315N执行片段(例如，像素)着色操作以用于片段或像素着色器程序。顶点处理器1305执行3D 图形流水线的顶点处理阶段并生成图元和顶点数据。(多个)片段处理器 1315A至1315N使用由顶点处理器1305生成的图元和顶点数据来产生显示在显示装置上的帧缓冲器。在一个实施例中，(多个)片段处理器1315A 至1315N被优化以执行OpenGL API中提供的片段着色器程序，这些片段着色器程序可以用于执行与Direct3D API中提供的像素着色器程序相似的操作。

另外，图形处理器1310还包括一个或多个存储器管理单元(MMU) 1320A至1320B、一个或多个高速缓存1325A至1325B和(多个)电路互连1330A至1330B。一个或多个MMU1320A至1320B为图形处理器1310 包括为顶点处理器1305和/或(多个)片段处理器1315A至1315N提供虚拟到物理地址映射，除了存储在一个或多个高速缓存1325A至1325B中的顶点或图像/纹理数据之外，所述虚拟到物理地址映射还可以引用存储在存储器中的顶点或图像/纹理数据。在一个实施例中，一个或多个MMU 1320A 至1320B可以与系统内的其它MMU包括与图12的一个或多个应用处理器 1205、图像处理器1215和/或视频处理器1220相关联的一个或多个MMU 同步，使得每个处理器1205至1220可以参与共享或统一的虚拟存储器系统。根据实施例，一个或多个电路互连1330A至1330B使得图形处理器1310 能够经由SoC的内部总线或经由直接连接来与SoC内的其它IP核交互。

图14是框图，展示了根据实施例的可以使用一个或多个IP核来制造的片上系统集成电路的附加示例性图形处理器1410。图形处理器1410可以是图12的图形处理器1210的变体。图形处理器1410包括图13的集成电路1300的一个或多个MMU 1320A至1320B、(多个)高速缓存1325A至 1325B和(多个)电路互连1330A至1330B。

图形处理器1410包括一个或多个着色器核1415A至1415N(例如， 1415A、1415B、1415C、1415D、1415E、1415F，一直到1315N-1和1315N)，所述一个或多个着色器核提供统一的着色器核架构，其中，单个核或类型或核可以执行所有类型的可编程着色器代码包括着色器程序代码以实现顶点着色器、片段着色器和/或计算着色器。存在的着色器核的确切数量可以在实施例和实施方式中变化。另外，图形处理器1410还包括核间任务管理器1405，所述核间任务管理器充当用于将执行线程分派给一个或多个着色器核1415A至1415N的线程分派器和用于加快分块操作以进行基于图块的渲染的分块单元1418，其中，场景的渲染操作在图像空间中被细分，例如以利用场景内的局部空间一致性或优化内部高速缓存的使用。

示例性图形虚拟化架构

本发明的一些实施例在利用全图形处理器单元(GPU)虚拟化的平台上实现。如此，下面提供本发明的一个实施例中采用的GPU虚拟化技术的概述，随后详细描述用于模式驱动的页表遮蔽的设备和方法。

本发明的一个实施例采用在客户机中运行原生图形驱动程序的完整 GPU虚拟化环境，以及实现客户机之间的良好性能、可扩缩性和安全隔离的中介传递。这个实施例向每个虚拟机(VM)提供虚拟全功能GPU，所述虚拟全功能GPU可以在大多数情况下直接访问性能关键型资源而不需要来自管理程序的干预，同时以最低的成本对来自客户机的特权操作进行俘获与仿真。在一个实施例中，具有完整GPU特征的虚拟GPU(vGPU)被呈现给每个VM。在大多数情况下，VM可以直接访问性能关键型资源，而不需要虚拟机管理程序的干预，同时对来自客户机的特权操作进行俘获与仿真，以提供VM之间的安全隔离。每个量子切换vGPU上下文，以在多个VM之间共享物理GPU。

图15展示了可以在其上实现本发明的实施例的高级系统架构，所述高级系统架构包括图形处理单元(GPU)1500、中央处理单元(CPU)1520、以及在GPU 1500和CPU 1520之间共享的系统存储器1510。渲染引擎1502 从系统存储器1510中的命令缓冲器1512获取GPU命令，以使用各种不同的特征来加速图形渲染。渲染引擎1504从帧缓冲器1514获取像素数据，然后将所述像素数据发送至外部监视器以进行显示。

某些架构使用系统存储器1510作为图形存储器，而其它GPU可以使用管芯上存储器。可以通过GPU页表1506将系统存储器1510映射到多个虚拟地址空间中。2GB全局虚拟地址空间称为全局图形存储器，可以从 GPU 1500和CPU 1520访问，通过全局页表被映射。本地图形存储器空间以多个2GB本地虚拟地址空间的形式被支持，但仅限于通过本地页表从渲染引擎1502进行访问。全局图形存储器大部分是帧缓冲器1514，但也用作命令缓冲器1512。在进行硬件加速时，对本地图形存储器进行大量的数据访问。具有管芯上存储器的GPU采用类似的页表机制。

在一个实施例中，CPU 1520通过生产者-消费者模型中的GPU特定命令来对GPU1500进行编程，如图15所示。根据如OpenGL和DirectX的高级编程API，图形驱动程序将GPU命令编程到命令缓冲器1512中，包括主缓冲器和批缓冲器。GPU 1500然后获取并执行命令。主缓冲器(环形缓冲器)可以将其它批处理缓冲器链接在一起。术语“主缓冲器”和“环形缓冲器”在下文中可互换使用。批处理缓冲器用于传递每个编程模型的大部分命令(多达～98％)。寄存器元组(头部、尾部)用于控制环形缓冲器。在一个实施例中，CPU 1520通过更新尾部来向GPU 1500提交命令，而GPU 1500从头部获取命令，然后在命令已经完成执行之后通过更新头部来通知CPU 1520。

如上所述，本发明的一个实施例在具有中介传递的完整GPU虚拟化平台中实现。因此，每个VM都配备有全功能GPU，以在VM内部运行原生图形驱动程序。然而，在以下三个方面具有重大挑战：(1)虚拟化整个复杂的现代GPU的复杂性，(2)由于多个VM共享GPU而导致的性能，以及(3)VM之间完全的安全隔离。

图16展示了根据本发明的一个实施例的GPU虚拟化架构，所述GPU 虚拟化架构包括在GPU 1600上运行的管理程序1610、特权虚拟机(VM) 1620以及一个或多个用户VM 1631至1632。在管理程序1610中运行的虚拟化存根模块1611扩展存储器管理以包括用于用户VM1631至1632的扩展页表(EPT)1614，以及用于特权VM 1620的特权虚拟存储器管理单元(PVMMU)1612，以实现俘获和传递策略。在一个实施例中，每个VM 1620、 1631至1632运行原生图形驱动程序1628，所述原生图形驱动程序可以如下所述利用资源分区直接访问帧缓冲器和命令缓冲器的性能关键型资源。为了保护特权资源，即I/O寄存器和PTE，来自用户VM1631至1632和特权VM 1620中的图形驱动程序1628的相应访问被俘获并且被转发至特权VM 1620中的虚拟化中介器1622用于仿真。在一个实施例中，如图所展示，虚拟化中介器1622使用超级调用来访问物理GPU 1600。

另外，在一个实施例中，虚拟化中介器1622实现与管理程序1610中的CPU调度器1616同时运行的GPU调度器1626，以在VM 1631至1632 之间共享物理GPU 1600。一个实施例使用物理GPU 1600来直接执行从VM 提交的所有命令，因此避免了对渲染引擎进行仿真的复杂性，所述渲染引擎是GPU内最复杂的部分。同时，帧缓冲器和命令缓冲器的资源传递使管理程序1610对CPU访问的干预最小化，而GPU调度器1626保证每个VM 量子都用于直接GPU执行。因此，所展示的实施例在多个VM之间共享 GPU时实现良好的性能。

在一个实施例中，虚拟化存根1611选择性地俘获或传递某些GPU资源的客户机访问。虚拟化存根1611操纵EPT 1614条目以选择性地向用户 VM 1631至1632呈现或隐藏特定地址范围，同时对于特权VM 1620使用PVMMU 1612中的保留位PTE，用于将客户机访问选择性地俘获或传递至特定的地址范围。在这两种情况下，俘获外围输入/输出(PIO)访问。所有被俘获的访问都被转发至虚拟化中介器1622进行仿真，而虚拟化中介器 1611使用超级调用来访问物理GPU 1600。

如上所述，在一个实施例中，虚拟化中介器1622对用于特权资源访问的虚拟GPU(vGPU)1624进行仿真，并且在vGPU 1624之间进行上下文切换。同时，特权VM 1620图形驱动程序1628被用于初始化物理装置并管理功率。一个实施例采用灵活发布模型，通过将虚拟化中介器1622实现为特权VM 1620中的内核模块，用于简化虚拟化中介器1622和管理程序1610之间的绑定。

分离的CPU/GPU调度机制经由CPU调度器1616和GPU调度器1626 来实现。这是因为GPU上下文切换的成本可能是CPU上下文切换的成本的1000倍以上(例如，～700us对～300ns)。另外，在计算机系统中CPU 内核的数量可能不同于GPU内核的数量。因此，在一个实施例中，GPU调度器1626与现有CPU调度器1616分开实现。分离调度机制导致需要并发访问来自CPU和GPU的资源。例如，当CPU正在访问VM1 1631的图形存储器时，GPU可能同时访问VM2 1632的图形存储器。

如上所述，在一个实施例中，在每个VM 1620、1631至1632内部执行原生图形驱动程序1628，所述原生图形驱动程序通过由虚拟化中介器 1622进行仿真的特权操作直接访问一部分性能关键型资源。分离调度机制导致下面描述的资源分区设计。为了更好地支持资源分区，一个实施例保留存储器映射I/O(MMIO)寄存器窗口以将资源分区信息传送给VM。

在一个实施例中，virt_info的位置和定义已经作为虚拟化扩展纳入硬件规范，因此图形驱动程序1628在原生处理扩展，并且未来的GPU生成遵循所述规范以实现向后兼容性。

虽然在图16中被展示为单独的部件，但是在一个实施例中，包括虚拟化中介器1622(及其vGPU实例1624和GPU调度器1626)的特权VM 1620 被实现为管理程序1610内的模块。

在一个实施例中，虚拟化中介器1622通过对特权操作进行俘获与仿真来管理所有VM的vGPU 1624。虚拟化中介器1622处理物理GPU中断，并且可以向指定的VM 1631至1632生成虚拟中断。例如，命令执行的物理完成中断可能会触发虚拟完成中断，并且被传递给渲染拥有者。对每个语义的vGPU实例进行仿真的想法很简单；然而，实施方式却需要大量的工程工作和对GPU 1600的深入理解。例如，某些图形驱动程序可以访问约 700个I/O寄存器。

在一个实施例中，GPU调度器1626实现粗粒度服务质量(QoS)策略。可以选择特定的时间量作为每个VM 1631至1632共享GPU 1600资源的时间分片。例如，在一个实施例中，选择16ms的时间量作为调度时间分片，因为所述值导致人类对感知图像变化的低感知度。还选择这种相对较大的量子，因为GPU上下文切换的成本是CPU上下文切换成本的1000倍以上，因此所述量子不能像CPU调度器1616中的时间分片那么小。来自VM 1631 至1632的命令被连续地提交给GPU 1600，直到客户机/VM耗尽其时间分片。在一个实施例中，GPU调度器1626在切换之前等待客户机环形缓冲器变为空闲，因为当今的大多数GPU是非抢占的，因此这可能影响公平。为了使等待开销最小化，可以通过跟踪命令提交以保证堆积命令在任何时间处于一定限度内来实现粗粒度流量控制机制。因此，所分配的时间分片与执行时间之间的时间漂移相对较小，因此实现了粗粒度QoS策略。

在一个实施例中，在渲染上下文切换时，在切换vGPU 1624之间的渲染引擎时，保存并恢复内部流水线状态和I/O寄存器状态，并且执行高速缓存/TLB转储清除。内部流水线状态对CPU不可见，但可以通过GPU命令进行保存和恢复。通过读取/写入渲染上下文中的寄存器列表可以实现保存/恢复I/O寄存器状态。现代GPU中包含的用于加速数据访问和地址转换的内部高速缓存和转换后备缓冲器(TLB)必须使用渲染上下文切换处的命令转储清除，以保证隔离性和正确性。在一个实施例中用于切换上下文的步骤是：1)保存当前I/O状态，2)转储清除当前上下文，3)使用附加命令来保存当前上下文，4)使用附加命令来恢复新的上下文，以及5)恢复新的上下文的I/O状态。

如上所述，一个实施例使用专用的环形缓冲器来承载额外的GPU命令。 (经审核的)客户机环形缓冲器可以被重新用于提高性能，但是直接将命令插入到客户机环形缓冲器是不安全的，因为CPU可能会继续使更多命令排队，从而导致被重写的内容。为了避免争用情况，一个实施例从客户机环形缓冲器切换到其自己的专用环形缓冲器。在上下文切换结束时，本实施例从专用环形缓冲器切换到新VM的客户机环形缓冲器。

一个实施例重新使用特权VM 1620图形驱动程序来初始化显示引擎，然后管理显示引擎以显示不同的VM帧缓冲器。

当两个vGPU 1624具有相同的分辨率时，仅切换帧缓冲器位置。对于不同的分辨率，特权VM可以使用硬件缩放器，这是现代GPU中的一项常见功能，可以自动地对分辨率进行缩放。两种技术都只需几毫秒。在许多情况下，可能不需要显示管理，例如当VM未显示在物理显示器上时(例如，当所述VM位于远程服务器上时)。

如图16所展示,一个实施例传递对帧缓冲器和命令缓冲器的访问以加速来自VM1631至1632的性能关键型操作。对于2GB大小的全局图形存储器空间，可以采用图形存储器资源分区和地址空间膨胀技术。对于本地图形存储器空间，每个图形存储器空间也都具有2GB的大小，由于本地图形存储器仅可由GPU 1600访问，所以可通过渲染上下文切换来实现每个 VM本地图形存储器。

如上所述，一个实施例在VM 1631至1632之间对全局图形存储器进行分区。如上所述，分离的CPU/GPU调度机制要求CPU和GPU同时访问不同VM的全局图形存储器，因此每个VM必须随时使用其自己的资源来呈现，从而导致全局图形存储器的资源分区方法。

图17展示了图形虚拟化架构1700的一个实施例的附加细节，所述图形虚拟化架构包括由管理程序1710管理的多个VM(例如VM 1730和VM 1740)，包括对GPU 1720中的全部GPU特征阵列的访问。在各实施例中，管理程序1710可以使得VM 1730或VM 1740能够将图形存储器和其它 GPU资源用于GPU虚拟化。基于GPU虚拟化技术，一个或多个虚拟GPU (vGPU)(例如vGPU 1760A和1760B)可以访问由GPU 1720硬件提供的全部功能。在各种实施例中，管理程序1710可以跟踪、管理如本文所述的vGPU 1760A和1760B的资源和生命周期。

在一些实施例中，vGPU 1760A-B可以包括呈现给VM 1730、1740的虚拟GPU装置，并且可以用于与原生GPU驱动程序交互(例如，如上文相对于图16所述)。然后，VM 1730或VM1740可以访问GPU特征全阵列并且用vGPU 1760A-B中的虚拟GPU装置来访问虚拟图形处理器。例如，一旦VM 1730被俘获在管理程序1710中，则管理程序1710可以操纵vGPU 实例(例如，vGPU 1760A)并且判定VM 1730是否可以访问vGPU 1760A 中的虚拟GPU装置。可以每个量子或事件切换vGPU上下文。在一些实施例中，可以每GPU渲染引擎(诸如，3D渲染引擎1722或位块传送器渲染引擎1724)发生上下文切换。定期切换允许多个VM以对VM的工作负荷透明的方式来共享物理GPU。

GPU虚拟化可以采取各种形式。在一些实施例中，可以利用装置传递来启用VM1730，其中，整个GPU 1720被呈现给VM 1730，如同它们是直接相连的。很像可以指定单个中央处理单元(CPU)核专供VM 1730使用，也可以指定GPU 1720专供VM 1730使用(例如，甚至在有限时间内)。另一个虚拟化模型是分时模型，其中，GPU 1720或其一部分可以以多路复用的方式由多个VM(例如，VM 1730和VM 1740)共享。在其它实施例中，设备1700还可以使用其它GPU虚拟化模型。在各实施例中，可以对与GPU 1720相关联的图形存储器进行分区，并且将其分配给管理程序1710 中的各vGPU 1760A-B。

在各实施例中，图形转换表(GTT)可以被VM或GPU 1720用于将图形处理器存储器映射到系统存储器或者用于将GPU虚拟地址转换为物理地址。在一些实施例中，管理程序1710可以经由阴影GTT来管理图形存储器映射，并且所述阴影GTT可以保持在vGPU实例(例如，vGPU 1760A) 中。在各实施例中，每个VM可以有相应的阴影GTT以用于保持图形存储器地址与物理存储器地址(例如，虚拟化环境下的机器存储器地址)之间的映射。在一些实施例中，阴影GTT可以被共享并且维持多个VM的映射。在一些实施例中，每个VM 1730或VM1740可以包括每进程GTT和全局 GTT两者。

在一些实施例中，设备1700可以将系统存储器用作图形存储器。可以通过GPU页表将系统存储器映射到多个虚拟地址空间中。设备1700可以支持全局图形存储器空间和每进程图形存储器地址空间。全局图形存储器空间可以是通过全局图形转换表(GGTT)进行映射的虚拟地址空间(例如， 2GB)。此地址空间的下部部分有时被称为可从GPU 1720和CPU(未示出)访问的开口。此地址空间的上部部分被称为仅可以被GPU 1720使用的高位图形存储器空间或隐藏图形存储器空间。在各实施例中，阴影全局图形转换表(SGGTT)可以被VM1730、VM 1740、管理程序1710或GPU 1720 用于基于全局存储器地址空间将图像存储器地址转换为对应的系统存储器地址。

在完全GPU虚拟化时，静态全局图形存储器空间分区方案可能面临可扩缩性问题。例如，对于2GB的全局图形存储器空间，可以为开口预留第一512兆字节(MB)虚拟地址空间，并且其剩余部分(1536MB)可以变成高位(隐藏)图形存储器空间。利用静态全局图形存储器空间分区方案，使能了完全GPU虚拟化的每个VM可以分配有128MB开口和384MB高位图形存储器空间。因此，2GB全局图形存储器空间仅可以容置最多四个 VM。

除了可扩缩性问题，具有有限图形存储器空间的VM还可能经受性能退化。有时，当媒介应用广泛地使用GPU媒介硬件加速时，可以在所述媒介应用的一些媒介繁重工作负荷中观察到严重的性能降级。作为示例，为了对一个信道的1080p H.264/高级视频编码(AVC)位流进行解码，可能需要至少40MB的图形存储器。因此，对10个信道的1080p H264/AVC位流进行解码，可能需要至少400MB的图形存储器空间。同时，可能需要留出一些图形存储器空间来进行表面合成/颜色转换，在解码过程中切换显示帧缓冲器等。在这种情况下，每个VM的512MB的图形存储器空间可能不足以让所述VM运行多视频编码或解码。

在各实施例中，设备100可以利用按需式SGGTT来实现GPU图形存储器过量使用。在一些实施例中，管理程序1710可以按需构建SGGTT，所述SGGTT可以包括对不同GPU部件的所有者VM的图形存储器虚拟地址的所有待使用转换。

在各实施例中，管理程序1710所管理的至少一个VM可以分配有多于静态分区的全局图形存储器地址空间以及存储器。在一些实施例中，管理程序1710所管理的至少一个VM可以分配有或者能够访问整个高位图形存储器地址空间。在一些实施例中，管理程序1710所管理的至少一个VM可以分配有或者能够访问整个图形存储器地址空间。

管理程序/VMM 1710可以用命令解析器1718来检测VM 1730或VM 1740所提交的命令的GPU渲染引擎的潜在存储器工作集。在各实施例中， VM 1730可以有对应的命令缓冲器(未示出)以用于保持来自3D工作负荷 1732或媒介工作负荷1734的命令。类似地，VM 1740可以有对应的命令缓冲器(未示出)以用于保持来自3D工作负荷1742或媒介工作负荷1744的命令。在其它实施例中，VM 1730或VM 1740可以有其它类型的图形工作负荷。

在各实施例中，命令解析器1718可以扫描来自VM的命令并且判定所述命令是否包含存储器操作数。如果是，则命令解析器可以例如从VM的 GTT中读取有关的图形存储器空间映射，并且然后将其写入SGGTT的特定于工作负荷的部分中。在对工作负荷的整个命令缓冲器进行扫描之后，可以生成或更新保持了与此工作负荷相关联的存储器地址空间映射的SGGTT。另外，通过扫描来自VM 1730或VM 1740的待执行命令，命令解析器1718还可以提高GPU操作的安全性(比如通过减轻恶意操作)。

在一些实施例中，可以生成一个SGGTT来保持所有VM的所有工作负荷的转换。在一些实施例中，可以生成一个SGGTT来保持例如仅一个 VM的所有工作负荷的转换。特定于工作负荷的SGGTT部分可以由命令解析器1718按需构建以用于保持特定工作负荷(例如，VM1730的3D工作负荷1732或VM 1740的媒介工作负荷1744)的转换。在一些实施例中，命令解析器1718可以将SGGTT插入到SGGTT队列1714中并且将相应工作负荷插入到工作负荷队列1716中。

在一些实施例中，GPU调度器1712可以在执行时间构建这种按需式 SGGTT。特定硬件引擎可以仅使用在执行时间分配给VM 1730的图形存储器地址空间的一小部分，并且GPU上下文切换很少发生。为了利用这种 GPU特征，管理程序1710可以用VM 1730的SGGTT来仅保持对各个GPU 部件(而非分配给VM 1730的全局图形存储器地址空间的整个部分)的执行和待执行转换。

GPU 1720的GPU调度器1712可以与设备1700中的CPU的调度器分离开。在一些实施例中，为了利用硬件并行性，GPU调度器1712可以分别对不同GPU引擎(例如，3D渲染引擎1722、位块传送器渲染引擎1724、视频命令流转化器(VCS)渲染引擎1726、以及视频增强型命令流转化器 (VECS)渲染引擎1728)的工作负荷进行调度。例如，VM 1730可以是 3D加强的，并且3D工作负荷1732在一个时刻可能需要被调度到3D渲染引擎1722。同时，VM 1740可以是媒介加强的，并且媒介工作负荷1744 可能需要被调度到VCS渲染引擎1726和/或VECS渲染引擎1728。在此情况下，GPU调度器1712可以分别调度VM 1730的3D工作负荷1732和VM1740的媒介工作负荷1744。

在各实施例中，GPU调度器1712可以追踪GPU 1720中的对应渲染引擎所使用的执行中的SGGTT。在此情况下，管理程序1710可以为每个渲染引擎保留SGGTT以用于追踪对应渲染引擎中的所有执行中的图形存储器工作集。在一些实施例中，管理程序1710可以保留单个SGGTT以用于追踪所有渲染引擎的所有执行中的图形存储器工作集。在一些实施例中，这种追踪可以基于单独的执行中SGGTT队列(未示出)。在一些实施例中，这种追踪可以基于SGGTT队列1714上的标记(例如，使用注册表)。在一些实施例中，这种追踪可以基于工作负荷队列1716上的标记(例如，使用注册表)。

在调度过程中，GPU调度器1712可以针对工作负荷队列1716中的待调度工作负荷来检查SGGTT队列1714中的SGGTT。在一些实施例中，为了调度特定渲染引擎的下一个VM，GPU调度器1712可以检查由此渲染引擎的VM使用的特定工作负荷的图形存储器工作集是否与由此渲染引擎执行的或待执行的图形存储器工作集冲突。在其它实施例中，这种冲突检查可以延伸至由所有其它渲染引擎利用执行中或待执行图形存储器工作集进行检查。在各实施例中，这种冲突检查可以基于SGGTT队列1714中的相应SGGTT或者基于管理程序1710所保留的SGGTT以用于追踪如在上文中所讨论的对应渲染引擎中的所有执行中图形存储器工作集。

如果不存在冲突，则GPU调度器1712可以将执行中和待执行图形存储器工作集集成在一起。在一些实施例中，也可以生成特定渲染引擎的执行中和待执行图形存储器工作集的所产生的SGGTT并且将其存储在例如SGGTT队列1714中或其它数据存储装置中。在一些实施例中，还可以生成并存储与一个VM相关联的所有渲染引擎的执行中和待执行图形存储器工作集的所产生的SGGTT，如果所有这些工作负荷的图形存储器地址不与彼此冲突的话。

在将所选VM工作负荷提交到GPU 1720之前，管理程序1710可以将相应SGGTT页写入GPU 1720中(例如，到图形转换表1750)。因此，管理程序1710可以使得此工作负荷能够利用全局图形存储器空间中的正确映射来执行。在各实施例中，所有这些转换条目均可以写入图形转换表1750 中，到下部存储器空间1754或上部存储器空间1752。在一些实施例中，图形转换表1750可以每VM包含单独的表以保持这些转换条目。在其它实施例中，图形转换表1750还可以每渲染引擎包含单独的表以适用于这些转换条目。在各实施例中，图形转换表1750可以至少包含待执行图形存储器地址。

然而，如果存在GPU调度器1712所确定的冲突，则然后，GPU调度器1712可以延迟此VM的调度，并且反而尝试着调度相同或不同VM的另一个工作负荷。在一些实施例中，如果两个或更多个VM可以尝试着使用同一图形存储器地址(例如，针对同一渲染引擎或两个不同的渲染引擎)，则可以检测到这种冲突。在一些实施例中，GPU调度器1712可以改变调度器策略以避免选择有可能与彼此冲突的渲染引擎中的一个或多个渲染引擎。在一些实施例中，GPU调度器1712可以悬置执行硬件引擎以减轻冲突。

在一些实施例中，如本文中所讨论的GPU虚拟化时的存储器过量使用可以与静态全局图形存储器空间分区方案共存。作为示例，下部存储器空间1754的开口仍可以用于所有VM的静态分区。上部存储器空间1752中的高位图形存储器空间可以用于存储器过量使用方案。与静态全局图形存储器空间分区方案相比，GPU虚拟化时的存储器过量使用可以使得每个 VM能够使用上部存储器空间1752中的整个高位图形存储器空间，这可以允许每个VM内的一些应用使用更大的图形存储器空间以获得改进的性能。

在静态全局图形存储器空间分区方案的情况下，最初要求保护存储器的大部分的VM在运行时仅可以使用一小部分，而其它VM可能处于缺乏存储器的状态。在存储器过量使用的情况下，管理程序可以按需为VM分配存储器，并且所节省的存储器可以用于支持更多VM。在基于SGGTT的存储器过量使用的情况下，在运行时仅可以分配待执行工作负荷所使用的图形存储器空间，这节省了图形存储器空间并且支持更多VM访问GPU 1720。

当前架构支持在云和数据中心环境中托管GPU工作负载。完整GPU 虚拟化是GPU云中使用的基本支持技术之一。在完整GPU虚拟化中，虚拟机监视器(VMM)，尤其是虚拟GPU(vGPU)驱动程序俘获并仿真客户机对特权GPU资源的访问，以实现安全性和多路复用，同时通过CPU 访问CPU等性能关键型资源，例如CPU访问图形存储器。GPU命令一旦被提交，将直接由GPU执行，无需VMM干预。因此，实现了接近原生性能。

当前系统使用GPU引擎的系统存储器来访问全局图形转换表(GGTT) 和/或每进程图形转换表(PPGTT)，以从GPU图形存储器地址转换为系统存储器地址。遮蔽机制可以用于客户机GPU页表的GGTT/PPGTT。

VMM可以使用与客户机PPGTT同步的阴影PPGTT。所述客户机 PPGTT具有写入保护功能，使得阴影PPGTT可以通过俘获和仿真其PPGTT 的客户机修改，与客户机PPGTT持续同步。目前，每个vGPU的GGTT在每个VM之间被遮蔽和分区，并且PPGTT被遮蔽并且在每个VM上被遮盖 (例如，基于每个进程)。由于GGTT PDE表保留在PCI bar0MMIO范围内，因此GGTT页表的阴影很简单。但是，PPGTT的阴影依赖于对客户机 PPGTT页表的写入保护，并且传统的阴影页表非常复杂(因此也是有漏洞的)并且效率低下。例如，CPU阴影页表在当前架构中的性能开销为～30％。因此，在这些系统中的一些系统中，使用了启蒙阴影页表，所述启蒙阴影页表修改客户机图形驱动程序用于协作识别用于页表页的页和/或在其被释放时修改客户机图形驱动程序。

本发明的实施例包括存储器管理单元(MMU)诸如I/O存储器管理单元(IOMMU)，以从客户机PPGTT映射的GPN(客户机页号)重新映射到HPN(主机页号)，而不依赖于低效率/复杂的阴影PPGTT。同时，一个实施例保留全局阴影GGTT页表用于地址膨胀。这些技术通常称为混合层地址映射(HLAM)。

在默认情况下，IOMMU不能用于某些中介传递架构，因为多个VM 只能使用单个二层转换。本发明的一个实施例利用以下技术来解决这个问题：

1.使用IOMMU在没有阴影PPGTT的情况下进行两层的转换。具体地讲，在一个实施例中，GPU从图形存储器地址(GM_ADDR)转换为GPN，并且IOMMU从GPN转换为HPN，而不是从GM_ADDR转换为HPN的阴影PPGTT，其中，对客户机PPGTT应用写入保护。

2.在一个实施例中，IOMMU页表针对每个VM进行管理，并且在切换vGPU时进行切换(或者可以部分地切换)。也就是说，当VM/vGPU 被调度时，加载对应的VM的IOMMU页表。

3.然而，在一个实施例中共享GGTT映射的地址，并且由于vCPU可以访问GGTT映射的地址(诸如，开口)，因此即使当所述VM的vGPU 未被调度时，所述全局阴影GGTT也必须保持有效。这样，本发明的一个实施例使用混合层地址转换，其保留全局阴影GGTT，但直接使用客户机 PPGTT。

4.在一个实施例中，对GPN地址空间进行分区以将GGTT映射的GPN 地址(其变成到IOMMU的输入，如GPN)移动至专用地址范围。这可以通过俘获和仿真GGTT页表来实现。在一个实施例中，从具有大偏移量的 GGTT修改GPN以避免在IOMMU映射中与PPGTT重叠。

图18展示了在一个实施例中采用的结构，其中，IOMMU 1830启用装置虚拟化。所展示的架构包括在管理程序/VMM 1820上执行的两个VM 1801、1811(但是本发明的基本原理可以用任意数量的VM来实现)。每个VM 1801、1811包括分别管理客户机PPGTT和GGTT 1803、1813的驱动程序1802、1812(例如，原生图形驱动程序)。所展示的IOMMU 1830包括用于实现本文所述的混合层地址映射技术的HLAM模块1831。需要注意的是，在所述实施例中，不存在阴影PPGTT。

在一个实施例中，在IOMMU映射中准备整个客户机VM(示例中的客户机VM 1811)的GPN到HPN转换页表1833，并且每个vGPU切换触发IOMMU页表交换。也就是说，当调度每个VM1801、1811时，其对应的GPN到HPN转换表1833被交换。在一个实施例中，HLAM 1831区分GGTT GPN和PPGTT GPN并且修改GGTT GPN，以使得所述GGTT GPN 在转换表1833中执行查找时不与PPGTT GPN重叠。具体地讲，在一个实施例中，虚拟GPN生成逻辑1832将GGTT GPN转换为虚拟GPN，然后所述虚拟GPN用于在转换表1833中执行查找以识别对应的HPN。

在一个实施例中，通过将GGTT移位指定的(可能大的)偏移量来生成虚拟GPN，以确保映射的地址不与PPGTT GPN重叠/冲突。另外，在一个实施例中，由于CPU可以随时访问GGTT映射地址(例如，开口)，因此全局阴影GGTT将总是有效并且保持在每个VM的IOMMU映射1833 中。

在一个实施例中，混合层地址映射1831解决方案将IOMMU地址范围区分成两部分：为PPGTT GPN到HPN转换保留的下部，以及为GGTT虚拟GPN到HPN转换保留的上部。由于GPN由VM/客户机1811提供，因此GPN应该在客户机存储器大小的范围之内。在一个实施例中，客户机 PPGTT页表保持不变，并且来自PPGTT的所有GPN通过工作负载执行直接发送至图形转换硬件/IOMMU。然而，在一个实施例中，来自客户机VM 的MMIO读取/写入被俘获，并且GGTT页表变化被捕获并且如本文所述地被改变(例如，向GPN增加大的偏移量，以便确保与IOMMU中的PPGTT 映射不重叠)。

远程虚拟化图形处理

在本发明的一些实施例中，服务器执行图形虚拟化，代表客户机虚拟化物理GPU并运行图形应用。图19展示了一个这样的实施例，其中，两个客户机1901至1902通过网络1910(诸如互联网和/或专用网络)连接至服务器1930。服务器1930实现虚拟化图形环境，其中，管理程序1960分配来自一个或多个物理GPU 1938的资源，将资源作为虚拟GPU 1934至1935呈现给VM/应用1932至1933。图形处理资源可以根据资源分配策略 1961进行分配，这可以使管理程序1960基于应用1932至1933的要求(例如，较高性能的图形应用需要较多的资源)、与应用1932至1933相关联的用户帐户(例如，某些用户为获得更高性能而支付额外费用)和/或系统上的当前负载来分配资源。所分配的GPU资源可以包括多组图形处理引擎，诸如3D引擎、块图像传输引擎、执行单元以及媒体引擎等等。

在一个实施例中，每个客户机1901至1902的用户在托管(多个)服务器1930的服务上具有账户。例如，所述服务可以提供订阅服务，以向用户提供远程访问在线应用1932至1933，诸如视频游戏、生产力应用、以及多玩家虚拟现实应用等。在一个实施例中，响应于来自客户机1901至1902 的用户输入1907至1908，在虚拟机上远程执行应用。尽管未在图19中展示，但是一个或多个CPU也可以被虚拟化并且用于执行应用1932至1933，其中，图形处理操作卸载到vGPU 1934至1935。

在一个实施例中，响应于图形操作的执行，vGPU 1934至1935生成一系列图像帧。例如，在第一人称射击游戏中，用户可以指定输入1907来在幻想世界中移动角色。在一个实施例中，所产生的图像被压缩(例如，通过压缩电路系统/逻辑，未示出)并且通过网络1910被流式传输至客户机 1901至1902。在一个实施方式中，可以使用视频压缩算法诸如H.261；然而，可以使用各种不同的压缩技术。解码器1905至1906对输入视频流进行解码，然后在客户机1901至1902的相应显示器1903至1904上对其进行渲染。

使用图19中所展示的系统，高性能图形处理资源诸如GPU 1938可以被分配到预订服务的不同客户机。在在线游戏实施方式中，例如，服务器 1930可以在新视频游戏被释放时托管所述新视频游戏。然后在虚拟化环境中执行视频游戏程序代码，并且将所产生的视频帧压缩并流式传输至每个客户机1901至1902。这种架构中的客户机1901至1902不需要大量的图形处理资源。例如，即使是具有解码器1905至1906的相对低功率的智能电话或平板电脑也将能够解压缩视频流。因此，最新的图形密集型视频游戏可以在能够压缩视频的任何类型的客户机上播放。虽然视频游戏被描述为一种可能的实施方式，但是本发明的基本原理可以用于需要图形处理资源的任何形式的应用(例如，图形设计应用、交互式和非交互式射线追踪应用、生产力软件、视频编辑软件等)。

有保证的转发进展

虚拟GPU实现中的存储器结构被GPU中的多种多样的图形处理资源(例如EU、采样器、着色器、数据端口等等)所共享。动态存储器结构供应逻辑利用仲裁政策将存储器结构带宽的一部分分配给这些资源中的每一个，该仲裁政策将该资源正在执行其功能的特定VM或应用作为考虑因素(例如根据与该VM/应用相关联的优先级)。

本发明的一个实施例实现智能排队机制，其中存储器结构的每个级处的队列被分配给特定的VM。如果下游队列对于特定VM而言是填满的，则仲裁器将阻止对于该VM的上游队列中的数据，从而防止一个VM的业务量阻止另一VM的业务量。

图20示出具有被划分成多个分片2010-2014的图形处理资源的GPU 2060的一个实施例。在一个实施例中，分片2010-2014和媒体引擎 2020-2021经由接口2022被多个VM共享，该接口还将分片2010-2014耦合至高速缓存和存储器子系统2070。每个分片2010-2014的资源在经由缓冲和仲裁逻辑2050可访问的连接点处耦合至存储器结构2051。在一个实施例中，每个分片可包括诸如3D处理引擎、blit引擎以及执行单元等等图形处理引擎的指定集合。取决于实现，每个分片2010-2014可包括相同数量和类型的图形处理引擎，或每个分片2010-2014可被分配不同数量和类型的图形处理引擎。

本发明的一个实施例使用多级排队技术以确保一个VM的被阻止的业务量将不会阻止另一VM的业务量。具体地，如图21所示，实现多级排队架构，其中仲裁器2150-2151经由一系列队列2101-2103、2111-2113、 2121-2123将分片2170-2171连接至存储器结构。接口2022包括存储器管理电路和逻辑(例如TLB、页走查逻辑等等)以用于代表高速缓存和存储器子系统2070内的分片2010-2014和媒体引擎2020-2021来实现存储器事务 (例如执行虚拟至物理存储器转换，等等)。在所示实施例中，每个仲裁器2150-2151位于一组上游队列和第二组下游队列之间。每个级的一个特定队列(例如队列2101、2111、2121)可被分配给特定的VM或应用。在一种实现中，仲裁器2150-2151将不会将业务量排入VM的上游队列(例如队列2111)中，除非其下游队列(例如队列2121)中的空间可用。

作为示例而非限制，如果队列2101、2111、2121正在存储用于VM0 的业务量，如果VM0的下游队列2121是满的(例如由于接口1322内的页错误引起)，则仲裁器2150将不会向上游队列2111添加新的业务量。替代地，仲裁器450将向可被分配给其它VM的队列2112-2113添加业务量。一旦下游队列2121具有可用空间，仲裁器2150就将再次在上游队列2111中存储业务量。在一种实现中，仲裁器2151可向仲裁器2150发送信号以通知仲裁器2150何时队列2121是满的，从而导致仲裁器2150不在队列 2111中排入更多业务量，而是替代地着重于在其它队列2112-2113中排入业务量。类似地，当队列2121中空间变得可用时，仲裁器2151将通知仲裁器2150它会开始在队列2111中排入业务量。

本发明的一个实施例支持虚拟通道，在虚拟通道中每个VM被分配用于访问存储器结构的不同的虚拟通道。在上述示例中，每个虚拟通道进而与诸如2101、2111、2121之类的队列的序列相关联。分片资源2170-2171被安排在多个队列之间并被在该系统中执行的多种多样的VM/应用共享。最终结果是，如果业务量在用于一个VM的一组队列中被阻止(例如作为接口 1322内的页错误的结果)，则用于其它VM的数据业务量仍可经由存储器结构1351被处理。

在图22中示出根据本发明的一个实施例的方法。该方法可在本申请中描述的图形处理架构的情境内实现，但并不限于任何特定架构。

在2201，将上游和下游队列的序列分配给每个VM/应用。注意，术语“上游”和“下游”是在相对意义下使用的——即一个队列相对于第一队列可能在上游，而相对于第二队列在下游。在一个实施例中，将单个队列分配给流中的处于每个级处的VM/应用。在2202，从每个下游队列向每个上游队列(或向控制给队列的输入的仲裁逻辑)提供反馈以指示队列使用。例如，可发送信号以指示上游队列是满的或接近于满。

如果在2203确定特定队列(例如队列N)是满的，则在2204阻止任何新的数据进入上游队列(例如队列N-1)。然后该过程从2202重复，或替代地，如果有新的或不同的VM/应用的集合，则在2201重复。一旦队列 N不再满，就可将新的业务量存储在队列N-1内。

利用多个分片的IOMMU实现

在包括多层图形处理资源(例如多组分片)的实现中，每个层(stack) 具有其自身的去往存储器结构的接口和其自身的存储器管理单元(MMU)。每个MMU可代表其层中的分片执行地址转换，并将最近访问的转换高速缓存在本地TLB中。在一些当前实现中，MMU中的每一个与中央输入/输出存储器管理单元(IOMMU)通信，以执行地址转换并确保地址转换的一致性。

本发明的一个实施例通过将一个MMU确立为“主”并将余下的MMU确立为“从”来确保MMU之间的协作。与IOMMU的所有通信通过该主来进行。

图23示出其中三组图形处理资源2370-2372经由单个IOMMU 2380执行存储器事务的一个实施例。图形处理资源2370-2372中的每一组包括多个分片2310-2314、2330-2334、2350-2354，每个分片可包括执行单元(EU)、采样器、3D引擎、栅格化器、像素着色器、遍历单元、或任何其它形式的图形处理资源的组合。图形处理资源中的每一组还包括媒体处理单元，即 2320-2321、2340-2341、2360-2361，并且具有专用存储器管理单元(MMU) 2322、2342、2362以用于执行诸如地址转换、页错误操作以及页走查(page walk)操作之类的存储器访问操作。每个MMU 2322、2342、2362可包括用于高速缓存虚拟至物理地址转换的本地TLB 2323、2343、2363和用于高速缓存数据和指令的一个或多个高速缓存2325、2345、2365。

在一种实现中，MMU 2322中的一个被指定为“主”，它代表被指定为“从”的其它MMU2342、2362与IOMMU 2380直接通信。来自从MMU 2342、 2362的存储器事务最初被发送给主MMU 2322，该主MMU将它们转发给IOMMU 以进行处理。因此，存在与IOMMU的单个联系点，从而简化协作并减少业务量。

在一个实施例中，可处理诸如地址转换之类的特定存储器管理操作而不访问IOMMU 2380。例如，如果MMU 2362需要存储在MMU 2342的TLB 2343 或MMU 2322的TLB 2323中的转换，则可将该转换提供给MMU而不与IOMMU 交互。类似地，如果特定分片需要存储在本地高速缓存2325、2345、2365 中的数据，则可取回该数据而不加载IOMMU 2380。因此，在一个实施例中，在将请求发送给IOMMU 2380之前，最初在内部(例如在MMU内或通过与其它MMU通信)尝试存储器管理操作。

在一个实施例中，将IO代码嵌入在每个事务的私有字段中，该私有字段唯一地标识该事务源自的MMU。发送给IOMMU 2380的事务和来自IOMMU 2380的响应将包括IO代码。MMU内的事务路由电路2324、2344、2364使用该IO代码来将响应从IOMMU 2380路由至作出请求的MMU。在一个实施例中，事务路由电路2324、2344、2364维持路由表或其它数据结构，该路由表或其它数据结构将MMU 2322、2342、2362中的每一个与其IO代码相关联。

如所提及，MMU 2322、2342、2362中的每一个分别包括其自身的TLB 2323、2343、2363，TLB 2323、2343、2363高速缓存最近利用的地址转换。在虚拟环境中，每个TLB条目可包括从虚拟客户机地址(GVA)到主机物理地址(HPA)的完整映射。因此，如果转换被存储在TLB中，则不需要标准的两级转换(即从GVA到客户机物理地址(GPA)和从GPA到HPA)。通过MMU 2322、2342、2362中的每一个之间的通信以及主MMU 2322与IOMMU 2380 之间的通信，使TLB 2323、2343、2363保持一致。

在图24中示出根据本发明的一个实施例的方法。该方法可在本申请中描述的图形处理架构的情境内实现，但并不限于任何特定架构。

在2401，将第一MMU指定为主，并将一个或多个其它MMU指定为从。如上所讨论，MMU中的每一个可被配置成服务来自多个图形处理分片的请求。在2402，从MMU接收来自其分片之一的存储器事务请求。如果在2203确定它能在本地服务该请求，则从MMU在2402自己生成响应。例如，从MMU可从其本地TLB访问地址转换或从其本地高速缓存访问数据。

如果该从MMU无法在本地服务该请求，则在2405，它将该请求转发给主MMU，并在该事务分组中包含该从MMU IO代码。主MMU可能能够自己服务该请求，或可将该请求发送给IOMMU。在2406，主MMU将该请求发送给 IOMMU，IOMMU可代表从MMU访问系统存储器并生成响应(例如包含所请求的数据)。在一个实施例中，该请求和该响应包括从MMU IO代码。主MMU在2407接收来自IOMMU的响应，并利用从MMU的IO代码将该响应路由给该从MMU。在2408，该从MMU将该响应转发给作出请求的分片。

以上描述的技术减少了MMU与IOMMU之间的业务量，因为可在本地服务许多存储器请求。此外，本发明的实施例减少了IOMMU用于服务多个MMU所需的物理通信行。

使用进程地址空间ID来管理虚拟图形处理单元

利用总线:设备:函数(Bus:Device:Function)值来枚举PCI高速设备，其中函数值被限制于0-7。作为结果，使用不同函数值来区分虚拟GPU(vGPU) 的当前实现被限制于8个vGPU。虽然有可能修改PCIe枚举方案内的设备值，但由于用于图形设备的新的设备值可能与其它设备冲突(例如，一般利用设备值2来枚举图形设备)，这将会复杂化。

本发明的一个实施例通过使用进程地址空间ID(PASID)来标识不同的vGPU以提供对附加的vGPU的支持。例如，鉴于PASID值是20位的，可对实际上无限数量的vGPU寻址。

图25示出在利用PASID来区分vGPU的一个实施例中采用的多级页表查找。根指针2501指向根表2512的基址。如所示，B:D:F枚举的B值(总线)被用作标识指向上下文表2513的基址的条目2502的偏移量。D(设备) 和F(函数)值然后被用作上下文表2513中的条目2503的偏移量。

在先前实现中，上下文表2513中的条目将指向PASID表2514和第二级页图4级(SLPML-4)表二者(如带有X的虚线所指示)。在本发明的一个实施例中，上下文表2513不会指向SL PML-4。而是说，PASID值2504 既用于标识在执行图形虚拟地址(GVA)至图形物理地址(GPA)映射时的第一级PML-4表，又用于标识在执行GPA至主机物理地址(HPA)映射时的第二级PML-4表。因此，在所示实施例中，上下文表2513中的条目2503 标识PASID表2514，且该PASID值被用作用于标识指向PML-4和SL PML-4 二者的条目2504的偏移量。该安排的一种益处在于PASID是20位值，从而提供2²⁰的寻址空间以用于标识大数量的不同的虚拟GPU(与受制于使用B:D:F枚举的8个vGPU的先前系统形成对比)。

在该实施例中，PASID的指定部分(例如N个连续位，或分布在该PASID 内的多个位)可用于标识用于特定vGPU的第一级和第二级表的集合。当然， vGPU标识符可按照多种多样的方式被存储在PASID中，同时仍然符合本发明的基本原理。

在图26中示出根据本发明的一个实施例的方法。该方法可在本申请中描述的图形处理架构的情境内实现，但并不限于任何特定架构。

在2601，每个vGPU与PASID内的位的特定集合或位的范围相关联。在2603，响应于对于图形虚拟地址(GVA)至主机物理地址(HPA)转换的地址转换请求，使用PASID的第一部分来标识包含GVA到图形物理地址(GPA) 的表(即“第一级”表)。使用该PASID的第二部分来标识包含GPA到HPA 转换的表(即“第二级”表)。

本发明的实施例显著简化了具有超过8个vGPU(8个vGPU是使用PCIe 枚举的现有限制)的虚拟化图形系统的配置。如上所描述，这可通过使用 PASID来对不同vGPU寻址、从而利用20位PASID所支持的极大的地址范围来实现。

客户机虚拟基址寄存器实现

一个实施例使用虚拟PCI高速基址寄存器(BAR)来将私有设备存储器暴露给操作系统(OS)和管理程序/VMM，从而在客户机虚拟机(VM)之间分配私有存储器，在虚拟化设备代表客户机访问私有存储器时实施这些分配。该设备可创建PCI基址寄存器(BAR_H)，并且VMM/管理程序将BAR和该设备(或函数)映射至VM(即BAR_主机→BAR_客户机)。如果硬件有理由单独地处理该BAR范围(例如绕过IOMMU、不同的控制配置、等等)，则确定该 BAR_G的客户机页。可使用真实的或仿真的寄存器以允许软件将BAR_G的客户机值自行报告给硬件。然后硬件可如下所述地检测并转换该范围内的客户机物理地址(GPA)。

本发明的一个实施例用于分配高带宽存储器(HBM)。当利用HBM的单个图形处理单元(GPU)由多个VM共享时，图形硬件和软件必须在VM之间分配HBM。实现多种技术以确保这些逐个VM的分配的内容被保护以免受其它VM访问，不论它们是否被给予对给定GPU的共享。

在本发明的一个实施例中，因为HBM代表真实物理存储器而不只是地址空间(即全局图形转换表(GGTT))，所以该分配方案处理的活动虚拟函数(VF)比最大数量少，且不浪费HBM。具体地，该实施例包括支持对于每个VF的可编程HBM大小分配(而不是简单地将HBM均匀地分成总共VF+1 个分区)的硬件。

一个实施例以2M的增量将HBM分配给VF。这与具有支持4K和2M页大小的页表的现有IOMMU设计兼容。然而，本发明的基本原理不限于任何特定的用于分配HBM的增量大小。

图27示出通过基址和限制值、逐个VF地将HBM灵活分配给共享单个图形设备的多个VM。具体地，在一个实施例中，通过将虚拟函数的VF HBMBAR 2704的大小调整为等于主机HBMBAR 2702的大小(例如2G)来实现可编程的HBM大小分配。然后可给每个单独的VF配给处于私有HBM 2701之内的将可通过其自身的VFn_HBMBAR_H来访问的范围VFn_HBMSIZE(例如，其中n在1与7之间以用于七个不同的虚拟函数)。示出了用于VF1的主机VBAR 2703(VF1_HBMBAR_H)、用于VF2的主机VBAR 2703(VF2_HBMBAR_H)以及用于VF3的主机VBAR 2703(VF3_HBMBAR_H)。该范围映射至开始于基址(0)并从那里延伸达VFn_HBMSIZE MB(如限制1、2和3指示符所指示的)的每个VFn_HBMBAR_H。这可能覆盖或可能不覆盖整个VFn_HBMBAR_H。如果不，则如图27所示，VFn_HBMSIZE 以上的区域映射至无效访问(即虚假页，对于每个VF是唯一的)，而不是映射至私有HBM存储器的任何其它部分或DRAM的其它部分。

在一个实施例中，对于每个单独的VF扩展上述的用于直通的HBM检测和绕过机制。为此目的，一个实施例包括对于每个VF的单独的 VFn_HBMBASE_G、VFn_HBMBASE_H以及VFn_HBMSIZE(G＝客户机且H＝主机)。仅VFn_HBMBASE_G可被客户机VM写入。其它值仅能由物理函数(例如下表中指示的函数0)来编程。

利用这些技术，软件可对于每个VF配置0与HBM的HBMSIZE之间。控制域中的物理函数(PF)软件管理私有HBM中的片段的安排。该PF软件确保VF相关的区域是不重叠的。它们可以毗邻，不过小的间隙可能稍后需要缩减以回收成有用的大小。

在一个实施例中，VMM/PF驱动程序可在VF上挂起VM的操作、修改该存储器映射、然后恢复该VM。该技术用于对于向VM的HBM分配进行重新平衡/调整大小，以用于缩减和整合由于VM关闭等等导致的HBM的小的自由范围。例如，在图27中，如果VM3被毁坏，则可将VM2范围下移至毗邻VM1。

在一种实现中，VMM/管理程序配给(provosioning)软件在启动被分配有VF的VM之前，通过PF驱动程序来传达用于特定VF接口的HBM分配。 PF软件确定用于该VF的VFn_HBMBASE_H和VFn_HBMSIZE的值。然后可在初始化期间使VFn_HBMSIZE可用，使得VM的VF内核模式驱动程序(KMD)能发现其HBMBAR内的可用于管理的HBM存储器的量。VF 可全部具有相同大小HBMBAR。一旦VMM/管理程序已经将该BAR映射至VM 的地址空间，该VM软件就报告返回观测到的HBMBAR的基址 (VFn_HBMBASE_G)以作为图形物理地址(GPA)。这可根据现有架构(例如PCI高速实现)中所实现的可缩放输入-输出虚拟化(IOV)框架、通过 VF->PF软件通道和/或仿真的存储器映射I/O(MMIO)寄存器来支持。

在一个实施例中，对于GPU内的每个引擎(例如每个渲染引擎、媒体引擎等等)实现这三个寄存器(VFn_HBMBASE_H,VFn_HBMBAR_G, VFn_HBMSIZE)，并且命令流送器(CS)在向引擎上加载新上下文时负责对它们编程。CS可从主机存储器中的上下文描述符加载该信息(但必须使该数据不能被客户机KMD或其它VM软件访问)。替代地，如果VF的总数量相对小(例如7个)，则图形仲裁器(GAM)可实现所有7组VF寄存器并相应地在它们之间选择，而不对CS有任何附加的依赖性(尽管该CS仍根据现有的SR-IOV要求向GAM提供引擎VF)。

图28示出特定示例，其根据利用VFs HBMBAR的访问的偏移量来执行对于引导I/O的虚拟化技术(VT-d)的绕过，或重引导至无效访问路径。在该实施例中，每个VF驱动程序继续使用全局图形转换表(GGTT)中的PTE_G和逐个进程的图形转换表(PPGTT)表2802(包括孔径)。在使用时，如(1) 处所指示，硬件对于在该引擎或显示上执行的VF执行对于VFn_HBMBAR_G和VFn_HBMSIZE的范围比较。在(2)处，当有在该范围内访问时，硬件对于该VF重映射至用于VFn_HBMBASE_H的偏移量如果计算出的偏移量大于VFn_HBMSIZE(在(3)处绕过VT-d之后，在(4) 处确定)，则在(6)处该访问被无效，且按照一种方式来处理以防止通过无效访问产生进入VM、离开VM或跨VM的任何数据泄露。如果偏移量在限制内，则在(5)处将该偏移量加到基址。如果如(1)处确定GPA PTE 不在HBMBAR_G的范围内，则在(7)处执行页走查，并在(8)处确定并存储HPA。

PTE_H必须/将仅仅会成为无效访问(6)，或落在对该VF分配的HBM的范围内(5)，并且在绕过被触发时不落在任何其它位置(3)。当PTE_G在 VM内的VFn_HBMBAR_G范围之外时，则它不会绕过通常的第二级IOMMU 走查，且因此VT-d将管理PTE_H的确定。

在大数量的VM上虚拟化图形转换表

随着分辨率和用于图形处理的VM的数量增加，图形转换表(GTT)将变得过载。当前的GTT具有大小限制(例如4GB)，这将不足以支持未来的实现。

在一个实施例中，代替1级GTT页表，使用多级页表，其中每个VM被分配有其自己的页表。然后可执行逐个VM的多级页走查。由于性能问题(例如撕裂tearing)，当前没有进行多级页走查。为了解决这些限制，本发明的实施例执行智能高速缓存和预转换以提高性能。

图29示出单级全局GTT 2900和多级全局GTT 2901之间的比较。在单级全局GTT2900中，在将GPA映射至HPA的表内,给每个VM分配图形物理地址空间的指定部分。作为对照，在多级全局GTT 2901中，如所示，给每个VM分配其自己的1级页表，其中每个条目指向2级页表。在一个实施例中，可智能地填充TLB以确保页易于可用。

在一些实施例中，图形处理单元(GPU)被可通信地耦合到主机/处理器和以加速图形操作、机器学习操作、模式分析操作、以及各种通用GPU (GPGPU)功能。GPU可通过总线或另一互连(例如，诸如PCIe或NVLink 的高速互连)被可通信地耦合到主机处理器/核。在其他实施例中，GPU可被集成在与核相同的封装或芯片上并通过内部处理器总线/互连(即，在封装或芯片的内部)被可通信地耦合到核。不管GPU被连接的方式，处理器核可以以工作描述符中包含的命令/指令的序列的形式将工作分配给GPU。 GPU然后使用专用电路/逻辑以高效地处理这些命令/指令。

在以下描述中，阐述了大量的具体细节以提供更加透彻的解释。然而，对于本领域技术人员而言，可以在不具有这些具体细节中的一个或多个的情况下实践本文所述的实施例将是明显的。在其它情况下，未对公知特征进行描述以避免模糊本发明实施例的细节。

在实施例中，术语“引擎”或“模块”或“逻辑”可以指以下各项、是以下各项的一部分或者包括以下各项：执行一个或多个软件或固件程序的应用专用集成电路(ASIC)、电子电路、处理器(共享处理器、专用处理器或组处理器)和/或存储器(共享存储器、专用存储器或组存储器)、组合逻辑电路、和/或提供所描述功能的其它合适部件。在实施例中，引擎或模块可以以固件、硬件、软件、或者固件、硬件和软件的任何组合来实现。

本发明的实施例可以包括以上已经描述的各步骤。这些步骤可以被具体化为机器可执行指令，所述机器可执行指令可以用于使通用或专用处理器执行这些步骤。可替代地，这些步骤可以由包含用于执行这些步骤的硬接线逻辑的特定硬件部件来执行，或者由程序化计算机部件和自定义硬件部件的任意组合来执行。

如本文所述，指令可以是指硬件的具体配置，例如被配置为用于执行某些操作或具有存储在非暂态计算机可读介质中实施的存储器中的预定功能或软件指令的专用集成电路(ASIC)。因此，可使用在一个或多个存储装置(例如，端站、网络元件等)上存储并执行的代码和数据来实现附图中示出的技术。这种电子装置使用计算机机器可读介质来存储和传送(在内部和/或利用网络上的其它电子装置)代码和数据，诸如非暂态计算机机器可读存储介质(例如，磁盘；光盘；随机存取存储器；只读存储器；闪存存储装置；相变存储器)以及暂态计算机机器可读通信媒体(例如，电、光、声或其它形式的传播信号—例如载波、红外信号、数字信号等)。

此外，这样的电子装置典型地包括耦合至一个或多个其它部件(例如，一个或多个存储装置(非暂态机器可读存储媒体)、用户输入/输出装置(例如键盘、触摸屏和/或显示器)、以及网络连接件)的一组一个或多个处理器。所述一组处理器和其它部件的耦合通常通过一个或多个总线和桥接器 (也被称为总线控制器)。承载网络通信量的存储装置和信号分别表示一个或多个机器可读存储介质和机器可读通信介质。因此，给定电子装置的存储装置典型地存储用于在那个电子装置的所述组的一个或多个处理器上执行的代码和/或数据。当然，可以使用软件、固件、和/或硬件的不同组合来实现本发明的实施例的一个或多个部分。贯穿本详细描述，出于解释的目的，阐述了大量的具体细节以便提供对本发明的透彻理解。然而，对于本领域技术人员而言将明显的是，可以在没有这些特定细节中的一些的情况下实践本发明。在某些实例中，未详细描述公知结构和功能以避免模糊本发明的主题。从而，本发明的范围和精神应根据以下权利要求来判定。

Claims (25)

1.一种用于存储器管理的设备，包括：

第一多个图形处理资源，用于执行图形命令并处理图形数据；

第一存储器管理单元MMU，用于将所述第一多个图形处理资源通信地耦合至系统级MMU以用于访问系统存储器；

第二多个图形处理资源，用于执行图形命令并处理图形数据；

第二MMU，用于将所述第二多个图形处理资源通信地耦合至所述第一MMU；

其中所述第一MMU被配置为具有至所述系统级MMU的直接连接的主MMU，且所述第二MMU包括被配置成用于向所述第一MMU发送存储器事务的从MMU，所述第一MMU服务存储器事务、或代表所述第二MMU将所述存储器事务发送至所述系统级MMU。

2.如权利要求1所述的设备，其特征在于，所述系统级MMU包括输入/输出存储器管理单元IOMMU。

3.如权利要求1或2所述的设备，其特征在于，所述第二MMU包括事务路由电路以用于将所述存储器事务路由至所述第一MMU，所述第一MMU包括事务路由电路以用于将所述存储器事务路由至所述系统级MMU。

4.如权利要求3所述的设备，其特征在于，所述第一MMU包括第一转换后备缓冲器TLB，且所述第二MMU包括第二TLB，其中在有来自所述第二多个图形处理资源之一的转换请求时，所述第二MMU首先尝试从所述第二TLB执行地址转换，且如果所述地址转换不在所述第二TLB中则将所述转换请求发送至所述第一TLB。

5.如权利要求4所述的设备，其特征在于，所述第一MMU用于：如果所述转换未被存储在所述第一TLB中，则经由所述系统级MMU来执行页走查操作。

6.如权利要求3所述的设备，其特征在于，ID代码被嵌入在每个存储器事务的字段中以唯一地标识存储器事务源自的MMU，所述第一MMU的事务路由电路用于使用从所述系统级MMU接收的响应中的所述ID代码来将所述事务路由至所述第二MMU。

7.如权利要求6所述的设备，其特征在于，所述第一MMU和所述第二MMU各自包括数据高速缓存，其中所述第二MMU将在从所述第一MMU请求所述数据之前确定所述第二多个图形处理资源所请求的数据是否被存储在所述第二MMU的数据高速缓存中。

8.如权利要求7所述的设备，其特征在于，所述第一MMU用于在从所述系统级MMU请求所述数据之前确定所述所请求的数据是否被存储在所述第一MMU的数据高速缓存中。

9.一种用于存储器管理的方法，包括：

在第一多个图形处理资源上执行图形命令并处理图形数据，所述第一多个图形处理资源经由第一存储器管理单元MMU耦合至系统级MMU以访问系统存储器；

在第二多个图形处理资源上执行图形命令并处理图形数据，所述第二多个图形处理资源经由第二MMU耦合至所述第一MMU；

将所述第一MMU配置成具有至所述系统级MMU的直接连接的主MMU；

将所述第二MMU配置成从MMU，所述从MMU被配置成用于将存储器事务发送至所述第一MMU；

在所述第一MMU处服务由所述第二MMU产生的存储器事务，如果所述第一MMU自己无法服务所述存储器事务，则所述第一MMU代表所述第二MMU将所述存储器事务发送至所述系统级MMU。

10.如权利要求9所述的方法，其特征在于，所述系统级MMU包括输入/输出存储器管理单元IOMMU。

11.如权利要求9或10所述的方法，其特征在于，所述第二MMU包括事务路由电路以用于将所述存储器事务路由至所述第一MMU，所述第一MMU包括事务路由电路以用于将所述存储器事务路由至所述系统级MMU。

12.如权利要求11所述的方法，其特征在于，所述第一MMU包括第一转换后备缓冲器TLB，且所述第二MMU包括第二TLB，其中在有来自所述第二多个图形处理资源之一的转换请求时，所述第二MMU首先尝试从所述第二TLB执行地址转换，且如果所述地址转换不在所述第二TLB中则将所述转换请求发送至所述第一TLB。

13.如权利要求12所述的方法，其特征在于，所述第一MMU用于：如果所述转换未被存储在所述第一TLB中，则经由所述系统级MMU来执行页走查操作。

14.如权利要求11所述的方法，其特征在于，ID代码被嵌入在每个存储器事务的字段中以唯一地标识存储器事务源自的MMU，所述第一MMU的事务路由电路用于使用从所述系统级MMU接收的响应中的所述ID代码来将所述事务路由至所述第二MMU。

15.如权利要求14所述的方法，其特征在于，所述第一MMU和所述第二MMU各自包括数据高速缓存，其中所述第二MMU将在从所述第一MMU请求所述数据之前确定所述第二多个图形处理资源所请求的数据是否被存储在所述第二MMU的数据高速缓存中。

16.如权利要求15所述的方法，其特征在于，所述第一MMU用于在从所述系统级MMU请求所述数据之前确定所述所请求的数据是否被存储在所述第一MMU的数据高速缓存中。

17.一种机器可读介质，具有存储于其上的程序代码，当由机器执行所述程序代码时，所述程序代码使所述机器执行以下操作：

在第一多个图形处理资源上执行图形命令并处理图形数据，所述第一多个图形处理资源经由第一存储器管理单元MMU耦合至系统级MMU以访问系统存储器；

在第二多个图形处理资源上执行图形命令并处理图形数据，所述第二多个图形处理资源经由第二MMU耦合至所述第一MMU；

将所述第一MMU配置成具有至所述系统级MMU的直接连接的主MMU；

将所述第二MMU配置成从MMU，所述从MMU被配置成用于将存储器事务发送至所述第一MMU；

在所述第一MMU处服务由所述第二MMU产生的存储器事务，如果所述第一MMU自己无法服务所述存储器事务，则所述第一MMU代表所述第二MMU将所述存储器事务发送至所述系统级MMU。

18.如权利要求17所述的机器可读介质，其特征在于，所述系统级MMU包括输入/输出存储器管理单元IOMMU。

19.如权利要求17所述的机器可读介质，其特征在于，所述第二MMU包括事务路由电路以用于将所述存储器事务路由至所述第一MMU，所述第一MMU包括事务路由电路以用于将所述存储器事务路由至所述系统级MMU。

20.如权利要求17或19所述的机器可读介质，其特征在于，所述第一MMU包括第一转换后备缓冲器TLB，且所述第二MMU包括第二TLB，其中在有来自所述第二多个图形处理资源之一的转换请求时，所述第二MMU首先尝试从所述第二TLB执行地址转换，且如果所述地址转换不在所述第二TLB中则将所述转换请求发送至所述第一TLB。

21.如权利要求20所述的机器可读介质，其特征在于，所述第一MMU用于：如果所述转换未被存储在所述第一TLB中，则经由所述系统级MMU来执行页走查操作。

22.如权利要求19所述的机器可读介质，其特征在于，ID代码被嵌入在每个存储器事务的字段中以唯一地标识存储器事务源自的MMU，所述第一MMU的事务路由电路用于使用从所述系统级MMU接收的响应中的所述ID代码来将所述事务路由至所述第二MMU。

23.如权利要求22所述的机器可读介质，其特征在于，所述第一MMU和所述第二MMU各自包括数据高速缓存，其中所述第二MMU将在从所述第一MMU请求所述数据之前确定所述第二多个图形处理资源所请求的数据是否被存储在所述第二MMU的数据高速缓存中。

24.如权利要求23所述的机器可读介质，其特征在于，所述第一MMU用于在从所述系统级MMU请求所述数据之前确定所述所请求的数据是否被存储在所述第一MMU的数据高速缓存中。

25.一种用于存储器管理的设备，包括：

用于在第一多个图形处理资源上执行图形命令并处理图形数据的装置，所述第一多个图形处理资源经由第一存储器管理单元MMU耦合至系统级MMU以访问系统存储器；

用于在第二多个图形处理资源上执行图形命令并处理图形数据的装置，所述第二多个图形处理资源经由第二MMU耦合至所述第一MMU；

用于将所述第一MMU配置成具有至所述系统级MMU的直接连接的主MMU的装置；

用于将所述第二MMU配置成从MMU的装置，所述从MMU被配置成用于将存储器事务发送至所述第一MMU；

用于在所述第一MMU处服务由所述第二MMU产生的存储器事务的装置，如果所述第一MMU自己无法服务所述存储器事务，则所述第一MMU代表所述第二MMU将所述存储器事务发送至所述系统级MMU。