CN116775208A - 不需要硬件复位的执行软件在处理组件之间的灵活迁移 - Google Patents

Abstract

本公开涉及不需要硬件复位的执行软件在处理组件之间的灵活迁移。处理器的处理硬件被虚拟化以在一致的编程接口与特定硬件实例之间提供外观。当不需要支持一致的编程接口和/或不需要跨硬件布置(诸如集成电路)平衡硬件处理时，可以永久地或暂时地禁用硬件处理器组件。执行软件可以从一个硬件布置迁移到另一硬件布置，而无需复位硬件。

Description

不需要硬件复位的执行软件在处理组件之间的灵活迁移

相关申请的交叉引用

本申请涉及以下共同转让的共同未决的美国专利申请，这些专利申请中的每一个的全部内容通过引用合并于此：

·2022年3月10日提交的题目为“用于高效访问多维数据结构和/或其他大数据块的方法和装置(Method And Apparatus For Efficient Access To MultidimensionalData Structures And/Or Other Large Data Blocks)”的美国申请No.17/691,276；

·2022年3月10日提交的题目为“协作组阵列(Cooperative Group Arrays)”的美国申请No.17/691,621；

·2022年3月10日提交的题目为“分布式共享存储器(Distributed SharedMemory)”的美国申请No.17/691,690；

·2022年3月10日提交的题目为“虚拟化处理器中的硬件处理资源(VirtualizingHardware Processing Resources in a Processor)”的美国申请No.17/691,759；

·2022年3月10日提交的题目为“跨多个计算引擎的程序控制的数据多播(Programmatically Controlled Data Multicasting Across Multiple ComputeEngines)”的美国申请No.17/691,288；

·2022年3月10日提交的题目为“具有异步事务支持的硬件加速的同步(HardwareAccelerated Synchronization with Asynchronous Transaction Support)”的美国申请No.17/691,296；

·2022年3月10日提交的题目为“处理器和存储器中的快速数据同步(Fast DataSynchronization In Processors And Memory)”的美国申请No.17/691,303；

·2022年3月10日提交的题目为“高效矩阵乘法和与一组线程束相加(EfficientMatrix Multiply and Add with a Group of Warps)”的美国申请No.17/691,406；

·2022年3月10日提交的题目为“用于处理器中的线程组的可扩展负载平衡的技术(Techniques for Scalable Load Balancing of Thread Groups in a Processor)”的美国申请No.17/691,872；以及

·2022年3月10日提交的题目为“用于高效访问多维数据结构和/或其他大数据块的方法和装置(Method And Apparatus For Efficient Access To MultidimensionalData Structures And/Or Other Large Data Blocks)”的美国申请No.17/691,422。

技术领域

本文的技术涉及集成电路设计，并且更具体地，涉及解决与包括但不限于图形处理单元(GPU)的复杂芯片中的制造缺陷有关的问题。所述技术进一步涉及定义虚拟GPU处理集群，所述虚拟GPU处理集群是逻辑或物理电路的抽象，用于提供不同结构化的芯片之间的兼容性；GPU处理集群及其处理组件之间的灵活迁移；考虑跨集成电路基板的底层清除(floorswept)/禁用/非功能与全功能硬件的平衡；以及允许硬件在不需要时被选择性地关闭的动态处理资源禁用。

背景技术

总体GPU集成电路或芯片设计目标是提供最大性能和最大芯片制造产量。较大芯片具有较多电路，从而实现较高性能。但是由于制造缺陷的较高可能性，所以较大的芯片往往具有较低的产量，因为芯片上制造缺陷的数量大致与芯片面积成比例。

由于在制造复杂芯片(诸如GPU芯片)中所需的高容差，特定制造芯片的一些电路或操作有缺陷并不罕见。有时，缺陷对于芯片的运行是如此的重要，使得芯片需要被报废。然而，由于现代GPU芯片被设计为大规模并行，因此在许多情况下，缺陷仅影响并行功能块中的一者或一些，使得其他并行功能块完全可操作。

一种用于增加半导体制造产量的技术被称为“底层清除(floorsweeping)”。为了克服较大芯片上降低的产量，可以关闭、禁用或制作不可访问的有缺陷的电路，制作全功能芯片，但与无缺陷的芯片相比，具有较少的总功能电路。因此，“底层清除”是一种工艺或技术，通过该工艺或技术，存在于集成电路中的制造缺陷或其他错误可以被禁用和/或绕过或以其他方式变得不可访问(例如，诸如通过熔断保险丝来打开内部布线)，从而使得集成电路维持其所设计的功能中的一些或全部。每个芯片还可以包括片上可编程底层清除电路，该片上可编程底层清除电路能够响应于由芯片测试/编程设备外部施加的命令而在该芯片上实现底层清除。这种底层清除可以使得诸如GPU或CPU之类的集成电路能够维持一致的操作，尽管存在一个或更多个制造缺陷。参见例如US20150149713A1。偶尔地，为了跨多个芯片的一致性，还使用底层清除来永久地禁用超能力芯片的不需要的全功能部分，例如以降低功耗和发热。这在现有技术中有时完成，使得给定库存单位(“SKU”)产品标志符中的所有芯片具有相同数量的可访问/操作的TPC。

图1示出了在半导体晶圆或基板上制造的示例GPU芯片管芯。芯片管芯包括真正地数十亿的电路，这些电路一起工作以传递高性能计算和3D图形。从图1中可以得到芯片设计复杂程度如何的想法。例如，所示出的此特定芯片包括8个图形处理集群(GPC)，每GPC具有8个TPC(TPC＝纹理处理集群)、每个TPC具有2个SM(SM＝流式多处理器)、每个GPC具有16个SM、每个全GPU具有128个SM、每个SM具有64个FP32 CUDA核心、每个全GPU具有8192个FP32CUDA核心、每个SM具有4个张量核心、每个全GPU具有512个张量核心、6个HBM2堆栈、以及在628.4mm²的管芯大小上包括超过280亿个晶体管的十二个512位存储器控制器。在此特定芯片中，两个SM一起包括纹理处理器集群或TPC。这些TPC中的八个(并且因此这些SM中的十六个)包括被称为GPU处理集群(“GPC”)的较高级别块，并且这些GPC中的八个组成全GPU。还存在八个多实例GPU或MIG切片，其可独立地用作用于桌面基础设施的虚拟推理引擎和虚拟GPU。例如，参见：

https：//docs.nvidia.com/pdf/Ampere_Tuning_Guide.pdf；

https：//developer.nvidia.com/blog/nvidia-ampere-architecture-in-depth/；

NVIDIA A100张量核心GPU架构v1.0(NVIDIA 2020)；以及图29。

制造缺陷统计上可能发生在这种复杂性的管芯上。如果所发现的具有任何缺陷的任何芯片都被丢弃，则大多数芯片将被丢弃并且产量将非常低。例如，具有称为纹理处理集群或“TPC”的72个物理并行处理块的GPU设计将具有非常低的产量，如果该部分(part)的运输产品SKU要求所有72个TPC是有功能的话。然而，就像“十三个(baker’s dozen)”多于12个，只是在一些烘焙物品重量不足的情况下，假设芯片的产品SKU假定4个TPC是有缺陷的。然后，具有68个或更多个工作TPC的芯片可被包括在产品SKU中。这意味着具有72、71、70、69或68个良好TPC的芯片可作为68-TPC GPU在产品SKU下销售。

一些芯片制造商常规地具有来自一个芯片设计的多个产品SKU，其中，产品SKU具有不同数量的功能电路块。例如，在很多情况下，每个GPU芯片家族具有多个物理上不同的芯片设计，主要通过GPC和TPC的数量区分。对于每个芯片设计，制造商可以在产量(更多的底层清除意味着更高的产量)和性能(更多的底层清除意味着更低的性能)之间进行权衡。通常，尤其对于大型芯片，制造商对于给定的芯片设计可以具有多个SKU，其中，它们具有基本上不同的底层清除，从而使得性能差异不是细微的。由此，存在以特定产品SKU指定的所有芯片被要求具有一致的能力配置文件的重要场景。

特别地，如上所述，图1中示出的芯片被组织为具有某数量的GPC，每个GPC具有某数量的TPC，每个TPC具有某数量的SM处理器核心布置。例如，假设图1的物理芯片布局被设计成具有8个GPC，其中每个GPC具有9个TPC。然后，在4个TPC例如由于有缺陷而被关闭的情况下，产品SKU可具有每个具有8个TPC的4个GPC和每个具有9个TPC的4个GPC。这种“配置”的示例命名是8/8/8/8/9/9/9/9。在这种命名法中，GPC从最少的TPC排序(sort)到最多的TPC。在排序之后，GPC被从0至7编号为逻辑GPC。特别地，TPC可以具有物理TPC ID(例如，如布局在GPC基底上的物理TPC的连续编号)以及逻辑TPC ID(例如，在确定上述配置之后在GPC内分配给TPC的连续编号)。逻辑TPC ID编号可以遵循统一模式，例如，对于每个GPC中的第一操作TPC，它可以从0开始。

对于要包括在产品SKU中的芯片，哪些GPC具有8个TPC并不重要，因为在示例GPU设计中启动时间逻辑GPC编号过程可以通过指派逻辑GPC ID来将物理GPC从最少到最多TPC排序。由此，即使不同的物理TPC在不同的芯片中可能已经失效，这些差异也可以通过以下方式使用逻辑TPC ID和/或逻辑GPC ID来隐藏以提供跨产品SKU的一致性：(a)将SKU标准化成使用少于最大数目的物理TPC，(b)对这些部分(parts)进行测试和装仓(binning)，使得具有太多失效的TPC的各部分将不被包括在SKU中，以及(c)在上电/重启时动态地分配逻辑GPC ID。这样的一致性例如当GPU在高性能计算(HPC)和云计算中的使用需要将上下文从一个GPU迁移到另一GPU时是有用的，因为迁移通常需要在同一产品SKU中的GPU之间匹配配置文件。

图2A、图2B、图2C以图形方式示出了被设计和制造为具有8个逻辑GPC(标记为0-7)的GPU的三种不同配置，每个GPC具有9个TPC。在该图中，每个配置中的每个单元表示TPC。x轴用如以上所讨论的“逻辑”GPC ID标记，并且在每个逻辑GPC ID上方的竖直列中的块反映了每个GPC中的TPC的数目。该图还示出了那些TPC中的一些不佳。具体地，以暗交叉线示出的这些块是“死的”并且不能用于处理。

作为示例，图2A、图2B、图2C中所示的三个GPU配置中的每一个具有68个全功能TPC，其中4个失效的(failed)TPC以交叉线示出。可能存在这样的规则，即，具有多于4个失效的TPC的任何芯片不能被包括在特定产品SKU中。然后，所示出的三个示例配置之间的差异是如何跨芯片的GPC分布失效的TPC。在左手的配置中，GPC 0、1、2和3各自具有一个单个失效的TPC(8/8/8/8/9/9/9/9)-即，失效的TPC是分布式的，因此没有GPC具有多于一个失效的TPC。然而，由于制造缺陷基本上随机地发生，所以许多其他分布是可能的。例如，在右手的配置中，GPC0具有三个失效的TPC并且GPC1具有单个失效的TPC(6/8/9/9/9/9/9/9)。在中间的配置中，GPC0具有两个失效的TPC，并且GPC1和GPC2各自具有一个失效的TPC(7/8/8/9/9/9/9/9)。还有可能在两个GPC的每一个中都具有两个失效的TPC，并且在同一GPC中具有四个失效的TPC。注意，因为这些图反映逻辑GPC ID，所以对它们进行预先排序，所以失效的TPC全部出现在图的左侧，但是如果我们看物理GPC ID，失效的TPC可以在芯片上的任何地方。

目标是使这三个不同的芯片在软件和人类程序员而言看起来是“相同的”，即使它们在内部是相当不同的。这种布置的一个标准是看每个GPC内失效的TPC的数目。可以制定对于特定产品SKU是可接受的规则，GPC可以具有不超过一个失效的TPC。在这种配置文件匹配策略下，具有7/8/8/9/9/9/9/9(图2B)的配置的芯片不能被包括在具有8/8/8/8/9/9/9/9/9(图2A)的产品SKU中，即使功能TPC的总数匹配，因为每GPC配置文件的TPC不匹配。也就是说，逻辑GPC在它们的TPC计数中不是一对一匹配的。具体地，具有8/8/8/8/9/9/9/9的产品SKU将需要每个GPC具有至少8个功能TPC，所以具有7/8/8/9/9/9/9/9的配置的芯片将不符合该要求。

但不允许7/8/8/9/9/9/9/9芯片被包括在产品SKU中可以大大降低可用产量。丢弃具有68个全功能TPC的7/8/8/9/9/9/9/9芯片，仅仅是因为恰好不同地分布的四个非功能TPC潜在地是相当浪费的。随着更多硬件单元有缺陷，该问题变得更加严重——例如，图2C示出了再次具有68个全功能TPC的CPU芯片的6/8/9/9/9/9/9/9配置，但是这次其GPC之一仅具有6个全功能TPC。或考虑诸如5/9/9/9/9/9/9/9/9之类的示例，一旦其再次具有68个全功能TPC，但是其中所有四个失效的TPC都在同一GPC中。

当然，可以创建若干不同的产品SKU，并且取决于每GPC有多少TPC失效，将芯片“装仓”到那些不同的SKU中。这就像从农民市场上从“秒(seconds)”仓购买苹果或西红柿——消费者可能为能力较低的芯片支付较少的费用。但是，产品SKU的激增常常不是该问题的解决方案，因为它引起消费者混淆和后勤复杂化，并且还因为针对现代GPU编写的应用程序在要求各种上下文中的某一最小程度的并行性和性能方面比以往要求更高。具体来说，虽然能力较低的GPU芯片的市场可能有限，但许多应用程序现在需要将执行软件从数据中心中的一个芯片迁移到另一芯片的能力。因此需要更好的解决方案。

示例硬件背景

通过进一步的信息，图3和图4示出了现代GPU可以提供各种不同的硬件分区和层级。在这些示例中，GPU内的SM本身可分组成较大的功能单元。例如，GPU的图形处理集群(GPC)可包括多个纹理处理集群(TPC)(其中每一者可包括一个或更多个SM)和SM的附加阵列(例如，为了计算能力)以及其他支持硬件，例如用于实时光线追踪加速的光线追踪单元。

图3示出了被分区成多个GPU处理集群(“GPC”)的GPU硬件，每个GPU处理集群包括多个纹理处理集群(“TPC”)，每个纹理处理集群包括一个或更多个(例如，两个)流式多处理器(SM)，每个流式多处理器进而可以包括多个处理核心。GPC还可以包括未指派给TPC的另外的SM群。图4为示出GPC 208的阵列230如何由I/O单元205、主机接口206、前端212、可包括计算工作分配器(CWD)的任务/工作单元207、交叉开关210以及存储器接口分区单元215和关联的片上存储器220支持的框图。图4还示出了整个系统可以包括任意数量的这种多GPC处理单元202和经由内存桥105耦接到主机CPU的关联的存储器204。

每个SM又可被分区成多个独立的处理块，每个处理块具有一个或若干不同种类的核心(例如，FP32、INT32、张量等)、线程束调度器、分派单元和本地寄存器文件，如图5中所反映的。图5的现代SM的示例架构图包括高级计算硬件能力，该高级计算硬件能力包括许多并行数学核心，诸如除了纹理处理单元之外还包括多个张量核心。例如，截至目前，2017NVIDIA Volta GV100 SM被分区成四个处理块，每个具有16个FP32核心、8个FP64核心、16个INT32核心、用于深度学习矩阵算术的两个混合精度张量核心、L0指令高速缓存、一个线程束调度器、一个分派单元和64KB寄存器文件——并且将来的GPU设计可能继续该趋势。这种增加的计算并行性使得能够显著减少计算处理时间。如上所讨论的，每个TPC可包括一个或更多个SM。例如，在一个实施例中，每个TPC包括一对SM，但其他实施例可具有不同的布置。

图5A和图5B示出了一些GPU实现方式(例如，NVIDIA Ampere)可以如何启用作为“微GPU”(诸如μGPU0和μGPU1)操作的多个分区，其中，每个微GPU包括整个GPU的处理资源的一部分。当GPU被分区为两个或更多个单独的更小的μGPU以供不同客户端访问时，资源(包括物理存储器设备165，诸如本地L2高速缓存存储器)通常也被分区。例如，在一种设计中，耦合到μGPU0的第一半物理存储器设备165可以对应于第一组存储器分区位置，并且耦合到μGPU1的第二半物理存储器设备165可以对应于第二组存储器分区位置。GPU内的性能资源还根据该两个或更多个单独的较小处理器分区来分区。资源可包括二级高速缓存(L2)资源170和处理资源160。

此外，存在多实例GPU(“MIG”)特征(其与“微GPU”不同)，该特征允许将GPU安全地分区成用于CUDA^TM(“计算统一设备架构”)应用的许多单独的GPU实例，从而为多个用户提供单独的GPU资源以加速其相应的应用。例如，MIG在GPC边界上将GPU分成N个分区，典型地每分区8、4、2或1个GPC。对于具有多租户用例的云服务提供商(CSP)，除了为客户提供增强的隔离之外，MIG确保一个客户端不能影响其他客户端的工作或调度。使用MIG，每个实例的处理器具有穿过整个存储器系统的独立且隔离的路径——片上交叉开关端口、L2高速缓存库、存储器控制器和DRAM地址总线全部被唯一地指派给个体实例。这确保个体用户的工作负载能够以可预测的吞吐量和延迟、以相同的L2高速缓存分配和DRAM带宽来运行，即使其他任务正在颠簸(thrash)其自己的高速缓存或使其DRAM接口饱和。MIG可以对可用的GPU计算资源(包括流式多处理器或SM，以及诸如复制引擎或解码器之类的GPU引擎)进行分区，以便为诸如VM、容器或进程之类的不同客户端提供具有故障隔离的定义的服务质量(QoS)。MIG因此使得多个GPU实例能够在单个物理GPU上并行运行。参见例如https：//youtu.be/lw_YwPpMpSQ；

https：//www.nvidia.com/en-us/technologies/multi-instance-gpu/；以及

https：//docs.nvidia.com/datacenter/tesla/mig-user-guide/；以及图29。

图5C示出了多线程软件被组织为能够在不同硬件分区上并发运行的协作线程组或CTA。例如，每个CTA可以在不同的SM上运行，其中CTA的所有线程并发地在同一SM上运行。然而，在现有设计中，程序员希望同时启动的不同CTA可在不同时间在不同SM上结束运行。类似地，上述MIG特征使得相同或不同用户的不同程序能够在非干扰的基础上在相同的GPU硬件上同时运行。

关于此类现有GPU硬件架构和布置的更多信息，参见例如USP8,112,614；USP7,506,134；USP7,836,118；USP7,788,468；US10909033；US20140122809；林霍尔姆等人，“NVIDIA Tesla：统一图形和计算架构(NVIDIA Tesla:A Unified Graphics andComputing Architecture)”，IEEE Micro(2008)；

https：//docs.nvidia.com/cuda/parallel-thread-execution/index.html(2021检索的)；肖凯特等人，“Volta：性能和可编程性(Volta：Performance andProgrammability)”，IEEE Micro(38卷，第2期，2018年3/4月)，DOI：10.1109/MM.2018.022071134。

迁移挑战

企业越来越多地转向基于云的解决方案。例如，基于云的解决方案提供支持来自任何地方的新工作正常的企业所需的灵活性和简化的管理。随着NVIDIA GPU和软件的云采用，可能性是无限的。现代工作负载(包括人工智能(AI)、高性能计算(HPC)、数据科学和图形工作站)可以利用物理系统的性能从云得到支持。

高性能计算(HPC)云安装经常利用计算资源的虚拟化。在由NVIDIA虚拟GPU供电的虚拟化环境中，NVIDIA虚拟GPU(vGPU)软件与管理程序(hypervisor)一起被安装在虚拟化层处。该软件创建使得每个虚拟机(VM)共享安装在服务器上的物理GPU的虚拟GPU。对于要求更高的工作流，单个VM可利用多个物理GPU的功率。例如，安装可以包括许多节点，其中每个节点可以包括若干CPU和若干GPU。每个节点可支持多个虚拟机(VM)，其中每个VM运行其自己的操作系统(OS)的实例。这种GPU共享依赖于VDI软件来提供抽象层，该抽象层使客户端应用程序表现得好像它拥有它自己的物理、专用GPU，而服务器的GPU(和驱动程序)可以认为它正在响应一个主要主机。在服务器上运行的VDI管理程序拦截API调用并转换命令、绘制上下文和进程特定的地址空间，然后沿着传递到图形驱动器。软件可包括用于每个VM的图形或计算驱动器。由于在现有的基于云的解决方案中通常由CPU完成的工作现在被卸载到GPU，所以用户具有更好的体验。参见例如，埃雷拉，“Nvidia网格：具有工作站的视觉性能的图形加速的VDI(Nvidia Grid：Graphics Accelerated VDI With The VisualPerformance of A Workstation)(NVIDIA 2014年5月)；US20150067672；US20150009222；以及李石等人，“vCUDA：GPU加速的虚拟机高性能计算(vCUDA：GPU-Accelerated High-Performance Computing in Virtual Machines)，”计算机上的IEEE事务，第61卷，第6号，第804-816页，2012年6月，doi：10.1109/TC.2011.112。

HPC安装应当能够将VM从安装的一部分迁移到另一部分。例如，当节点被取下用于维护时，该节点上的所有VM被迁移到不同的节点。作为另一示例，整个机架可被断电，但仅在所有活动的VM已被迁移到不同机架之后。在迁移时，在迁移VM上运行的程序被抢先从一个或更多个CPU和一个或更多个GPU、存储器映像和上下文保存缓冲区移动到HPC安装中的不同位置，在此处VM可以再次开始运行。

在更基本的层面上，一些形式的迁移涉及取得在一个GPU芯片上运行的所有工作并且将其移动到另一个GPU芯片。这种类型的迁移通常需要跨源GPU芯片和目标GPU芯片的每GPC的TPC的统一配置文件。但是在云中，可能有几百甚至几千个GPU芯片，其可构成目标GPU芯片。这就是为什么在一些实施例中，在整个GPU产品SKU上希望每GPC配置文件的TPC的统一性。以此方式，统一性将跨具有相同SKU的任何GPU芯片而存在。

之前，为了允许VM在GPU之间迁移，要求每GPC的TPC的配置文件在产品SKU中的所有芯片上是一致的。例如，如果芯片布局具有8个GPC，其中每个GPC具有9个TPC，其中4个TPC由于有缺陷而关闭，则产品SKU可以具有每个具有8个TPC的4个GPC和每个具有9个TPC的4个GPC。我们的这种“配置”的命名法是8/8/8/8/9/9/9/9。注意，在该命名法中，GPC被从最少的TPC排序到最多的TPC。在排序之后，GPC被从0至7编号为逻辑GPC。对于要包括在产品SKU中的芯片，哪些GPC具有8个TPC无关紧要，因为启动时间逻辑GPC编号过程可以通过指派逻辑GPC ID来将物理GPC从最少到最多TPC排序。然而，在之前的设计中，具有7/8/8/9/9/9/9的配置的芯片不能被包括在具有8/8/8/8/9/9/9/9的产品SKU中，即使TPC的总数匹配，因为每GPC配置文件的TPC不匹配。也就是说，逻辑GPC在它们的TPC计数中不是一对一匹配的。每GPC配置文件的相同TPC使得迁移成为可能，因为在迁移源处的GPC上的被抢占的程序具有与迁移目的地处的GPC的一对一的TPC对应关系。因此，在过去，要求同一产品SKU中的GPU具有相同的每GPC配置文件的TPC。在过去，为了包括7/8/8/9/9/9/9/9和8/8/8/8/9/9/9/9芯片两者(两者均具有68个总TPC)，有必要将两个芯片降级至每GPC配置文件的“最差”公共TPC，即7/8/8/8/9/9/9/9(具有67个总TPC)。随着更多的硬件单元由于有缺陷而被关闭，该问题变得更加恶化。

使用以上引用的MIG特征，GPU实例被要求允许迁移，正如全GPU具有对迁移的要求一样。例如，具有配置7/9的2-GPC GPU实例需要迁移到具有配置8/8的2-GPC GPU实例或从具有配置8/8的2-GPC GPU实例迁移。这是迁移的另一示例，除了它应用于GPU实例而不是全GPU之外。

对于MIG，在将GPU划分为GPU实例时出现附加的复杂性。例如，当6/7/8/9/9/9/9/9GPU(总共66个TPC)被分成各自具有16个TPC的四个2-GPC GPU实例时，正在使用的TPC的数目从66个TPC减少到64个TPC。在现有设计中，改变正在使用的TPC的数目意味着进行完全复位。如果GPU当时没有运行任何东西(例如，在GPU实例上不存在VM)，则完全复位是可能的，但是当节点中存在多个GPU时，则整个节点很可能需要被复位。这潜在地是必须解决的大问题。此外，如果GPU已经被划分成两个4-GPC GPU实例，并且这两个GPU实例中的第二个不再使用，那么第二个GPU实例可以被进一步分成两个2-GPC GPU实例。然而，如果正在使用的TPC的总数需要改变，则存在问题，因为完全复位将破坏在两个4-GPC GPU实例中的第一个上运行的工作。

对于MIG存在附加问题：有时需要重新打包GPU实例。实质上，这是在一个GPU内的迁移。例如，如果GPU被划分为四个2-GPC GPU实例，则编号为0(使用GPC 0和1)、1(使用GPC2和3)、2(使用GPC 4和5)和3(使用GPC 6和7)，以供四个VM使用。然后，关闭使用GPU实例1和3的VM，使0和2仍然运行。然后，系统管理员想要创建4-GPC GPU实例，这应该是可能的，因为4个GPC未被使用。因此，需要进一步的改进。

附图说明

图1示出了示例GPU芯片布局。

图2A、图2B和图2C示出了三种不同的示例GPU芯片配置。

图3示出了示例现有技术GPU图形处理集群(GPC)。

图4示出了具有图形处理集群阵列的示例现有技术GPU硬件。

图5示出了示例流式多处理器。

图5A示出了示例现有技术μGPU分区。

图5B示出了示例现有技术μGPU分区。

图5C示出了映射到GPC上的示例现有技术层级。

图6A、图6B和图6C示出了多个芯片配置到公共产品SKU中的示例集合。

图7A、图7B和图7C示出了图6A、图6B和图6C配置中的“单例模式(Singleton)”的出现。

图8示出了具有两个TPC的示例虚拟GPC天际线(Skyline)，每个TPC用作单例模式。

图9示出了到图8的天际线上的示例CGA映射。

图10A和图10B示出了现有技术中的示例失效的迁移。

图11示出了使用虚拟GPC的示例成功迁移。

图12示出了示例GPU配置。

图13示出了如何将多个GPU配置收集到同一产品SKU中。

图13A示出了用于各种GPU配置的示例天际线。

图14示出了多个GPU实例的示例动态重新配置。

图14A、图14B和图14C示出了TPC的示例动态禁用。

图15示出了支持CSM地图的单例模式和天际线。

图16示出了支持CSM的单例模式和天际线可以如何组合在一起。

图17示出了示例单例模式编号方案。

图18示出了单例模式到天际线中的示例合并。

图18A示出了示例单例模式掩模。

图19示出了示例GPU测试器/编程器。

图20示出了示例GPU测试/编程过程。

图21A示出了包括CPU和具有计算工作分配器的GPU的系统的示例整体框图。

图21B示出了计算工作分配器的示例框图。

图21C-1是由图21A的CPU的示例启动命令生成的流程图。

图21C-2是计算工作分配器执行的示例启动过程的流程图。

图22示出了多个GPU实例的示例天际线划分。

图23是去往和来自虚拟GPC ID的示例转化的框图。

图24示出了灵活的TPC迁移。

图25A、图25B和图25C示出了示例多实例GPU。

图26示出了具有迁移的示例多实例GPU。

图26A-26D示出了示例灵活迁移。

图27示出了进一步的示例灵活迁移。

图28示出了示例屏障表组织。

图29示出了示例多实例GPU架构。

具体实施方式

期望在给定产品SKU中包括具有至少相同数量的TPC的所有芯片，而不管缺陷TPC如何跨各个芯片分布。本技术的示例非限制性实施例允许每GPC配置文件的不同的TPC被包括在同一产品SKU中以提供具体的技术和兼容性目标，诸如芯片间软件的迁移，从而增加产量。本技术提供了对芯片电路和功能的改进以提供这些和其他优点。

本说明书描述了产品SKU选择(GPU芯片可以在电路/物理硅级上在内部被不同地构造或配置并且仍作为“相同的”呈现给程序员和应用程序)；灵活的TPC迁移(因此TPC中的工作可以跨GPC迁移)；灵活的GPC迁移(允许在具有不同数量的GPC的GPU之间迁移)；协作组阵列(CGA)；天际线；具有虚拟GPC ID的虚拟GPC(vGPC)；产品SKU配置(更多的配置现在可以被包括在同一SKU中)；跨GPU芯片提供底层清除/禁用/非功能硬件与全功能硬件的平衡的测量的排列(除了配置)；排列-剔除(permutation-culling)底层清除规则以减少多μGPU之间的不平衡；以及动态TPC禁用，其提供具有不同数量的TPC的GPU实例之间的迁移兼容性并且使得GPC MIG实例更大，并且还允许在不需要时选择性地关闭硬件以便减少功耗和发热。

一些技术进步包括：

·具有每GPC配置文件的不同TPC的芯片可以包括在同一产品SKU中，但是对于使用CGA的程序员而言看起来是相同的

·新的虚拟GPC(vGPC)

·程序员看到与物理GPC的数目不同的GPC的数目(即，vGPC)。

·示例实施例区分处于多TPC CGA区域(即，能够运行需要多个TPC的软件)中的TPC与被用作单例模式的TPC。

CGA的新设计要求

与图5C中所示的不同，在新的GPU芯片设计中，我们引入了被称为协作组阵列(CGA)的新特征，该CGA保证了不能“适配”在单个SM上的一组执行线程块或CTA将仍然在一个GPC或其他硬件分区中同时运行。使用CGA，保证跨多个SM同时运行的CTA可以编程地更高效地共享数据和计算，从而允许跨多个SM的更多线程一起工作，由此增加吞吐量。参见上述2022年3月10日提交的题目为“协作组阵列(Cooperative Group Arrays)”的美国申请No.17/691,621。配置成运行GPC CGA的这种GPU提供硬件保证：GPC CGA中的所有CTA将在同一GPC上并发地运行。

CGA具有表示为其CTA数量的“大小”。如果每个CTA消耗SM中的大部分特定资源，则CGA“大小”可以被认为是其使用的流式多处理器(SM)的数量。例如，一些示例实施例具有每TPC特定数量(例如，两个)的SM，因此CGA的“大小”也可被认为是其使用的TPC的数量。CGA使用的TPC的数量可以是一和GPC中所有TPC之间的任何数量。这在确保能够在一个GPU芯片上运行的CGA也能够在不同的(非同一的)GPU芯片上运行方面产生了挑战。

CGA和产品SKU

在新的芯片家族中，我们希望在同一产品SKU中允许如图2所示的每GPC配置文件的不同TPC。例如，期望在同一产品SKU中包括不同的GPC配置，诸如7/9(即，一个GPC具有7个TPC，一个GPC具有9个TPC)和8/8(即，两个GPC各自具有8个TPC)。然而，如果考虑使用8个TPC的CGA，则8/8能够执行两个8-TPC CGA，而7/9仅能够执行一个8-TPC CGA。这是重要的，因为在源GPU上运行的给定GPC CGA的所有CTA在迁移到不同GPU或同一GPU内的不同物理位置时需要一起保持在同一GPC上。即，CGA在从一个GPC迁移到另一个GPC时需要保持在一起。可能已经针对先前上下文工作的迁移和兼容性(例如，其中不同SM上执行的CTA未被保证并发地运行)将不再必须与新的CGA编程模型一起工作。

此外，新的CGA编程模型将不同大小的CGA的可用性暴露给程序员。出于不同原因，对于同一产品SKU中的每个芯片，GPU的程序员视图应该是一致的。例如，要求基于CGA的程序员设计软件必须担心跨特定SKU的不同GPU芯片的不同配置可能不是合理的。然而，在没有本技术的情况下，如图2所示的每GPC配置文件的不同TPC为程序员提供了不一致的视图。

本技术解决了这些问题

本文的示例非限制性技术解决了这种不一致性问题。例如，它允许图6A、图6B、图6C的三个示例配置在芯片内的工作分配器看起来相同，使得工作相同地在三个所表示的GPU中的任何一个GPU上启动；并且这3个配置在程序员看起来也是相同的，使得填充GPU的优化对于SKU中的所有芯片是相同的。

简而言之，本文的示例非限制性实施例提供包括以下各项的解决方案：

(1)通过允许具有不同TPC/GPC配置文件的芯片在同一产品SKU中并且由此由要求跨具有那个产品SKU的若干个(或所有)芯片的一致的TPC/GPC配置文件的应用使用来增加芯片产量；以及

(2)向程序员和向将在GPU上运行的程序提供一致的视图，尽管TPC/GPC配置文件不同。

上述问题例如通过创新“虚拟GPC”(vGPC)来解决，其中，芯片可以提供的vGPC的数量大于(不同于)芯片内的逻辑GPC或作为芯片的设计和制造的一部分放置在硅上的物理GPC的数量。该vGPC构造允许GPU芯片中的所有GPC的集合对于负责启动GPC CGA的线程块(CTA)的计算工作分配器(CWD)“看起来相同”，并且对于程序员和对于在GPU上运行的应用程序也看起来相同(一致)，即使产品SKU中的各个芯片的内部结构可能非常不同。

灵活的TPC和GPC迁移

本文技术还提供以下灵活的迁移方案：

(1)灵活的TPC迁移(FTM)和灵活的GPC迁移(FGM)，它们通过允许在具有不同TPC/GPC配置文件的芯片之间(以及芯片内)迁移来增加芯片产量和总TPC计数，由此允许它们在同一产品SKU中，从而导致产量增加；以及

(2)动态TPC禁用(DTD)，其允许GPU被重新配置而不必进行完全复位，从而避免破坏GPU上的其他运行工作。另外，DTD避免必须将所有GPC降级到最小GPC的大小，从而使可用TPC的使用最大化，从而提供更大和更多数量的GPU实例。

示例非限制性虚拟GPC表示

参照图6A、图6B、图6C的示例GPU的图8(新)表示，x轴现在被重新标记为“虚拟GPCID”并且具有比芯片被设计成具有的原始更少(例如，八个)逻辑或物理GPC更多的(例如，十个)虚拟GPC。因此，x轴被重新标记为vGPC0-vGPC9。在这个示例中，芯片上的基于硬件的工作分配器现在将“看到”10个GPC而不是8个GPC。这10个GPC被称为“虚拟GPC”，因为它们是作为芯片设计的一部分的逻辑/物理GPC现实的基础技术的外观(facade)并且与之解耦的抽象。虚拟GPC是物理芯片结构的一种抽象——组织芯片的处理资源以用于与软件和软件开发商以可能与那些处理资源如何被模式化和布置在芯片的半导体基板上非常不同的方式进行交互。

每个芯片的硬件被修改以保持跟踪比实际存在于该芯片上的GPC更多的GPC(例如，固定的数目，诸如24，尽管实际上仅存在8个物理GPC)。并且对于开始于例如8的虚拟GPCID，芯片硬件“知道”虚拟GPC可以仅包含1个TPC，即“单例模式”TPC。

这种“单例模式”在图7A、7B、7C中示出，被表示为用字母“A”或“B”标记的TPC。这些“单例模式”是全功能TPC，其实际上通常紧密连接至物理GPC并与物理GPC相关联，该物理GPC在芯片硬件内包括多个这样的TPC。换言之，底层物理芯片设计不需要被制造为具有未互连至其他TPC的单独TPC。相反，这些“单例模式”通常选自与作为GPC的一部分的其他TPC完全互连的全功能TPC的群体，并且因此可以参与例如CTA跨GPC到多个TPC的并发启动。但是在示例实施例中，“单例模式”被抽象化，所以它们变成“自由代理”并且因此可以独立地用作它们自己的虚拟GPC。这种“自由代理”能力在软件兼容性、占用和灵活性方面提供巨大优势，这对装仓和产品SKU分类具有直接后果。

术语“单例模式”意味着其中具有单个元素的集合——在这种情况下，在其自己的虚拟GPC内只有一个TPC。在一个实施例中，每个TPC包含两个SM，并且因此单例模式TPC包括多个处理器(每个SM本身可以包含多个处理器)，但是在一些实施例中，该TPC被视为处理“单元”。在其他实施例中，单例模式可以包括单个SM、四个SM等。在一些实施例中，单例模式的处理“单元”可以是被测试和底层清除的同一处理“单元”和动态启用/禁用的同一处理“单元”(参见下文)。

这些单例模式来自哪里？考虑被设计成具有在8个物理GPC集群中组织的72个TPC的GPU。对于任何给定的芯片，这些TPC中的一些将会是好的，并且这些TPC中的一些可能是坏的。假设68个TPC是好的，并且四个TPC是坏的。作为测试的结果，四个坏的TPC可以作为如本文中所讨论的“底层清除”的一部分被永久地禁用和不可访问。那四个坏的TPC位于哪里？它们可以在芯片基板上的任何地方。有时，由于基板上的缺陷，它们将被分组在一起并且在物理上彼此靠近，但是在一般情况下，它们可以随机地分布在芯片基板上。

底层清除规则可同时对坏的TPC被允许在哪里强加约束(例如，一个物理GPC可具有多达三个坏的TPC，并且所有其余GPC可具有至多一个坏的TPC)，使得不满足此约束的芯片将不被包括在产品SKU中(它们可被包括在不同的产品SKU中，或者它们可被丢弃)。然而，底层清除通常将不同地影响每个芯片，使得由于底层清除过程和每个芯片包含的底层制造缺陷，被设计和制造为彼此相同的任何给定GPU芯片群体(population)将实际上在物理上彼此完全不同。一些可能是全功能的，但是许多将具有制造缺陷，这些制造缺陷需要放弃其上的电路并且使这些电路不可访问。尽管在硬件和物理结构上存在这些显著差异，但目标是使给定群体中的所有芯片在写为在其上运行的应用程序以及写那些应用程序的程序员“看起来是相同的”(即，呈现相同的技术接口)。这与外观或美学无关-这意味着例如所有这些芯片向为它们编写的基于CGA的应用程序呈现共同的技术接口，从而使得群体中的一个芯片内的技术上兼容的基于CGA的软件与群体中的所有其他芯片在技术上兼容，例如，在某种意义上，可以在一个芯片上运行的任何应用程序可以在任何其他芯片上运行。类似地，给定产品SKU中的芯片内的内部调度器应当能够成功地调度相同的工作，而不管芯片之间的硬件差异。

就硬件级的技术改进而言，在示例实施例中，在来自计算工作分配器的“系统管线”通信链路与芯片内的GPC之间存在全交叉开关。因此，芯片可将哪些GPC与哪些系统管线相配进行混合并匹配。在计算工作分配器与TPC之间还存在全交叉开关，其允许在由CWD使用的(虚拟)TPC ID与(物理)TPC ID之间的任何映射(在一个实施例中，不同ID约定(convention)之间的转换可由每个GPC中存在的称为M-管道控制器(“MPC”)的组件执行)。该基于硬件的映射有效地隐藏或掩盖(facade)了来自应用程序和应用程序编程器的底层清除的复杂性和芯片缺陷，从而呈现了基于虚拟GPC的接口，该虚拟GPC在结构、功能和操作能力方面在实际上是彼此显著不同或可能彼此显著不同的芯片群体上可以是统一的和一致的。

因此，芯片的硬件现在可以从72个TPC中的任何TPC创建虚拟GPC。这使得配置器能够选择“单例模式”并且将那些单例模式播种到虚拟GPC中，该虚拟GPC然后被映射到物理GPC中，以便使为一个底层清除芯片的每个虚拟GPC定义TPC的所得阵列与另一个底层清除芯片的所得阵列相同——即使这两个底层清除芯片实际上由于包括例如制造缺陷和响应底层清除的原因而包含非常不同的内部电路和关联的处理功能。在示例实施例中，这样的阵列是芯片处理能力的测量，并且具体定义每虚拟硬件分区/分组的处理核心或其他处理硬件的比率。因此，在一般情况下，这两个芯片在内部可以是完全不同的，而本技术允许这两个完全不同的芯片在程序员和对于应用程序看起来在它们呈现给旨在在其上运行的应用程序的技术接口和兼容性方面在技术上是“相同的”。

在一个实施例中，忽视具有图形能力的(graphic capable)GPC并且关注计算能力是为什么可以引入虚拟GPC ID的原因。然而，在一些实施例中，如果并非所有TPC都具有图形能力，则还提供具有图形能力的虚拟TPC掩模。这样的掩模可以用于图形应用程序的迁移。

同时，vGPC0-vGPC7一起定义多TPC CGA区域5000，该区域具有产品SKU中的所有芯片共用的每GPC配置文件的TPC。通过比较图8与图6A、图6B、图6C可以看出，图8为vGPC0-vGPC7定义的多TPC CGA区域5000对于所有图6A、图6B、图6C的配置是共同的，即，这对于同一产品SKU中的所有芯片将是共同的。同时，vGPC8和vGPC9各自包含“单例模式”(即，恰好一个TPC元素的集合)，该“单例模式”可以与任何逻辑GPC逻辑地关联，但是现在被抽象成其自己的虚拟GPC，使得其可以运行仅需要两个SM的CGA。

更详细地，我们将再次考虑具有8个GPC的GPU设计，每个GPC具有9个TPC。图6A、图6B、图6C示出了包括三个不同芯片配置的单个产品SKU，每个芯片配置具有68个TPC：(1)8/8/8/8/9/9/9/9(图6A)；(2)7/8/8/9/9/9/9/9(图6B)；以及(3)6/8/9/9/9/9/9/9(图6C)。GPC由竖直列的正方形表示，其中，每个正方形表示TPC(其进而包括一个或更多个SM-并且在一个示例中，恰好两个-SM)。非交叉线(白色)正方形是无缺陷的TPC，并且交叉线正方形是由于制造缺陷而关闭的有缺陷的TPC。GPC从最少到最多无缺陷的TPC进行排序，其中GPC用其逻辑GPC ID编号(参见沿x轴的数字)。本文中的示例技术允许图6A、图6B、图6C中的所有三个GPU配置在同一产品SKU中，从而增加芯片产量。

图6A、图6B、图6C中的非交叉线正方形示出了在所有三种配置中都良好的TPC。即，在这68个良好的TPC中，在三个配置中的每一个中，66个在所有三个配置中都是良好的。这66个非交叉线TPC的联合是TPC的集合，其中使用多于一个TPC的CGA可运行。我们将此称为“多TPC GCA区域”5000。该集合不包括接下来描述的虚线交叉线TPC。

对于三个配置中的每一个，图7A、图7B、图7C示出了表示“单例模式”TPC的标记为“A”和“B”的两个虚线交叉线正方形。这些“单例模式”是无缺陷的TPC。然而，如图7A、图7B和图7C所示，单例模式跨不同的配置不在相同的位置。例如，在图7A中，“A”和“B”单例模式都在逻辑GPC 0中发现；在图7B中，“A”单例模式在逻辑GPC3中并且“B”单例模式在逻辑GPC 0中；并且在图7C中，“A”单例模式在逻辑GPC 3中并且“B”单例模式在逻辑GPC 2中。此外，图7A、图7B、图7C的面向逻辑GPC的图示本身隐藏了底层物理现实的额外复杂性，其中那些单例模式中的每一个可以在芯片基板上它们各自的物理GPC内的任何地方。

单例模式可运行足够小以在单个TPC(例如，两个SM)上运行的CGA，但不能用于运行需要多个TPC(即，多于两个SM)的GPC-CGA。通常不能保证单例模式TPC(跨产品SKU)位于与任何其他TPC相同的GPC中，并且因此不能保证单例模式TPC能够以CGA可能需要的方式与其他TPC进行通信和互连(尽管如上所述，本技术确实包括当存在这样的分组/互连时可以利用这样的分组/互连的特征)。总之，保证多TPC CGA区域5000内的同一GPC中的TPC总是一起在GPC中，而不能保证单例模式TPC与任何其他TPC在同一GPC中。在GPU之间的迁移方面，CGA的引入使得作为源GPC中的CGA区域5000的一部分的TPC应当一起迁移并且在目的地中的CGA区域内执行工作。另一方面，在那个源GPC中的单例模式TPC可以或可以不移动到与CGA区域TPC相同的目的地GPC，并且尤其是不能保证单例模式TPC这样做。因此，在本文中的一些情况下，实施例提供了与每个单例模式的接口，作为能够进行被调整大小为适于单个TPC的处理能力的工作的其自己的虚拟GPC。

天际线

如以上所讨论的，图8的每虚拟GPC的TPC的布局或表示源自跨三个不同的图6A、图6B、图6C芯片配置的所有“良好”TPC的联合。具体地，这三个图6A、图6B、图6C的配置之间的“最低的共同点(lowest common denomiator)”是vGPC0具有6个功能TPC，vGPC 1-3各自具有8个功能TPC，并且vGPC 4-7各自具有9个功能TPC。由于其与城市天际线的模糊相似性，我们将如图8中所示的vGPC的集合的这种布局或表示称为“天际线(Skyline)”。“天际线”是声明处理器、处理芯片或其他处理布置的处理能力(诸如并发处理能力)的表示，包括(a)所声明数量的虚拟处理集群，以及(b)每个所声明的虚拟处理集群的所声明数量的处理器，其中，针对相同处理器、处理芯片或其他处理布置所声明的不同虚拟处理集群可以具有相同或不同的所声明数量的处理器。因此，在一个实施例中，天际线可表示并行处理器的组的集合，其中，每个组可具有不同数量的并行处理器(例如，每个vGPC可具有不同数量的TPC)。在一个实施例中，天际线因此声明一定数量的虚拟处理集群，该虚拟处理集群包括(i)包括多于一个处理器“单元”的虚拟处理集群和(ii)具有单例模式处理器单元的虚拟处理集群(其中处理器“单元”在一些实施例中可以包括一个或更多个硬件处理器，诸如被配置作为例如TPC的一对硬件处理器)。在一个实施例中，天际线将一个或更多个硬件处理器指定为在由虚拟GPC标识符(ID)指定的虚拟GPC内。在一个实施例中，“天际线”可以图形地表示为行和列的二维布置，诸如图8中所示，其中每个列表示所声明的虚拟处理集群，每个行表示给定所声明数量的处理器或处理单元，并且所声明的虚拟处理集群的排序从左到右将虚拟ID分配给虚拟处理集群。因此，图8的天际线中的列的数量是所声明的虚拟处理集群的数量，每列“高”多少表示对应的虚拟处理集群内所声明的处理器或处理单元的数量(非常像摩天大楼的高度表示建筑物的楼层的数量)，并且天际线中的块的总数指示处理器、处理芯片或其他处理布置的所声明数量的处理器或处理单元的总数。还注意，在如图8所示的一个实施例中，天际线遵循惯例，其中具有更少被声明的处理器单元的所声明的虚拟处理集群在具有更多被声明的处理器单元的被声明的虚拟处理集群的左边，除了包括单例模式的被声明的虚拟处理集群是最右边的。表达这种天际线信息的这种相同表示的许多其他方式是可能的，诸如例如在图8顶部的非图形符号串“6/8/8/8/9/9/9/9/1x2”(或例如十进制、十六进制或其他编号基础的“6888999911”)，其对每个处理集群内的所声明数量的虚拟处理集群(串长度)和所声明数量的处理器单元(值)进行编码，其中，基于符号串内的处理器单元集合的顺序，可针对每个所声明的该集合推理虚拟处理集群ID。在一个实施例中这个“天际线”定义软件和软件开发者用来定义对产品SKU内的芯片群体的工作分配的虚拟接口。在一个实施例中，对于产品SKU中的所有芯片，期望具有相同的天际线。因此，在一个实施例中，分配给特定处理器、处理芯片或其他处理布置的天际线声明小于或等于处理器、处理芯片或其他处理布置的实际硬件能力的数量。

在先前的芯片中，每个芯片内的计算工作分配器(CWD)基于逻辑GPC向TPC发送工作。为了程序员看到GPU的一致模型，新示例芯片设计中的CWD现在跨图6A、图6B、图6C中的所有配置提供相同的TPC/GPC集合。这可通过CWD将所有配置作为6/8/8/8/9/9/9/1/1进行处理来完成，6/8/8/8/9/9/1/1是一组10个虚拟GPC而不是8个逻辑GPC(如图6A、图6B、图6C中所示的那些)。

在以上命名中最后两个(“1”)条目是单例模式。在我们的命名中，不是用表示单例模式的“/1/1/1…”字符串结束配置，而是我们可以用1xN将其缩写，其中N是单例模式的数目(在一个实施例中，包含单例模式的每个虚拟GPC仅具有一个单例模式，并且因此可归因于单例模式的附加GPC的数目将是单例模式的数目)。例如，在图8中通过示例示出的6/8/8/8/9/9/9/1x2的配置或天际线具有两个单例模式。在图8的示例中，CWD“看到”10个GPC而不是被组织成产品SKU中的所有芯片共用的每GPC配置文件的多TPC CGA区域TPC的8个GPC。单例模式各自在他们自己的vGPC中，其中在天际线的右端的“1xN”表示N个单例模式。

图8中所示的天际线对于产品SKU中的所有芯片是相同的——这意味着可以在产品SKU中的一个芯片上运行的CGA的这个或任何集合或组合可以在产品SKU中的任何其他芯片上运行。具体地，对于SKU中的配置：

·多TPC CGA区域总是具有相同的形状和大小；

·单例模式的数目总是相同的；

·因此，天际线总是相同的。

换言之，程序员可以使用产品SKU的天际线来定义程序员为该产品SKU开发的基于CGA的软件。如果软件被设计成在天际线上运行，它将与具有该产品SKU的任何芯片兼容。此外，程序员可优化软件以利用天际线，例如，通过提供某数量的更小的2-SM CGA以及某数量的更大尺寸的CGA，正如天际线可容纳的以最大化TPC占用。

不同的SKU(其由底层清除/装仓(binning)规则定义)通常将具有不同的天际线，并且针对CGA占用的优化对于不同的SKU可能是不同的。例如，提供68个TPC的SKU和提供64个TPC的SKU将具有不同的天际线。然而，因为底层清除/装仓可基于各种不同的硬件划分或集群(例如，GPC的1/9的TPC、构成GPC的1/3的被称为CPC的TPC的组、整个GPC、多于一个GPC等)，所以不同的SKU也可具有相同的天际线。

从程序员的角度来看，单例模式TPC应当被视为不能与其他TPC一起参与CGA。然而，单例模式TPC可运行适合一个TPC的任何CGA。程序员始终看到同一产品SKU中的所有芯片的同一天际线，即使产品SKU内的底层物理和逻辑配置可能从一个芯片到另一个芯片完全不同。

如上所述，在一个示例中，不是所有的CGA都可以在单例模式上或在由单例模式组成的虚拟GPC上运行。可使用单例模式的CGA包括不需要比两个SM(即，一个TPC)提供的处理资源更多的处理资源的CTA。例如，在一个实施例中，每个SM可并发地运行K个CTA，其中K是与平台无关的值，例如在一个实施例中，该值可为10。这意味着在一个实施例中，基于单例模式TPC的vGPC可运行包括Kx2个CTA的GPC CGA。参见图9，其示出了具有恰好十五个8-SMCGA的示例启动“网格”，然后是具有较小的2-SM CGA的网格。在该示例中，15个8-SM CGA和8个2-SM CGA适合。

以上天际线示例是非常简单的情况。实际产品SKU天际线可能更复杂，例如，5/5/7/7/7/8/8/8/1x7或6/6/7/7/8/8/8/0/1x12，其中，配置的数量分别是20和17，远远太多以至于不能在简单的图中绘制。

使用vGPC和天际线定义/准则的示例GPC CGA迁移

迁移是兼容性的特殊情况，其中，将在一个芯片上运行的软件转移至在不同的芯片上运行。如本文中所讨论的，在一些上下文中的迁移包括中断运行软件、存储其状态和上下文、将软件传输至不同的芯片和/或同一芯片的不同部分、以及重新开始(resume)软件执行以在其停止的地方继续的附加技术挑战——全部都不需要将需要中断或终止在目的地芯片上运行的其他软件的硬件复位。

图10A、图10B和图11示出了迁移结果之前和之后的示例。图10A、图10B示出了在启动具有正好16个8-SM CGA的GPC CGA网格以及具有2-SM CGA的网格之后从具有逻辑GPC ID配置8/8/8/8/9/9/9/9的GPU芯片迁移至具有逻辑GPC ID配置6/8/9/9/9/9/9/9的GPU芯片的现有技术尝试。在源芯片中，16个8-SM CGA和4个2-SM CGFA适合8/8/8/8/9/9/9/9配置。如图10A、图10B所示，迁移是不可能的，因为在目标GPU中仅存在十五个8-SM CGA的空间。

相反，图11示出了从同一源GPU芯片到同一目标GPU芯片的迁移——但在这种情况下，每个芯片使用具有6/8/8/8/9/9/9/1x2的配置的vGPC技术进行配置——包括两个基于单例模式的虚拟GPC 8和9。图11示出了迁移不是问题并且起作用，因为它发生在vGPC ID空间中，vGPC ID空间在产品SKU上始终是一致的。迁移工作良好，因为vGPC天际线在源芯片和目的地芯片两者中是相同的——即使如图10A所示，两个芯片的底层物理和逻辑硬件功能非常不同。在一个实施例中，在给定SKU上始终存在完全一致的天际线，使得不管产品SKU中的哪两个芯片被选择作为源和目的地GPU，迁移都可以成功地发生。

如下文详细描述的，如果在对应于额外GPC的源芯片上没有状态信息(例如，如果源芯片具有比目的地芯片更少的GPC)，则可以合成目的地芯片上的附加GPC的状态/上下文信息。例如，在一个实施例中，源芯片GPC的状态信息可在目的地芯片中被复制以用于多个GPC(在一个实施例中，vGPC的数目借助于天际线在源和目标之间是恒定的，使得当物理GPC的数目不同时使用这样的状态合成/复制)。

示例天际线选择

图12示出了可以被选择以定义产品SKU的可感知的天际线选择的示例表格。一个或更多个具体的选择可以基于性能对比产量。同时，图13示出了不同的SKU可包括或包含不同数目的逻辑配置，并且一些SKU可包括大量不同的逻辑或物理配置。例如，配置5/5/5/6/7/7/7/0/1x14可以包括63个不同的芯片配置，vGPC技术将确保在GPU上运行的所有在程序员和基于CGA的应用程序“看起来是相同的”。本技术因此使得在内部具有根本不同结构的芯片能够作为“相同的”呈现给外界(例如，呈现给程序员)。

允许更多的TPC或其他硬件细分或集群被底层清除的SKU将涵盖芯片的更多变化——这意味着产量增加。但是这可能以性能为代价。在这样的情况下，性能下降，因为CGA启动不能利用SKU中的任何芯片的增加的相对性能，但是而是必须将所有芯片视为“相同的”，并且由于特定产品SKU中的“最低的共同点”提供了每GPC的减少数量的功能TPC，因此并行处理性能下降。由此，将SKU设计为包括更多配置变化将降低SKU中的任何芯片的值，但将导致可作为SKU的一部分销售的更多总芯片。例如参见图13A，其示出了各个GPU实例配置的示例天际线。本文的技术允许芯片制造商基于客户性能要求灵活地做出不同的决定。

排列(permutation)和平衡

虽然以上考虑将规定天际线，但是存在可以改变产品性能——跨GPC组的处理资源的平衡的又一个因素。在一些实施例中，GPC被一起分组成芯片的层次组织的附加级别。例如，芯片可以具有8个GPC，其中，GPC被组织为两个“微GPU”(缩写为μGPU)，其中每个微GPC具有4个GPC。期望的是定义在两个μGPU之间具有最大不平衡量(就TPC的数量而言)的SKU。不平衡对于MIG也是重要的。在此考虑中，“配置”可以包括从最少TPC到最多TPC的TPC/GPC的排序列表。例如，在总共62个TPC的情况下，一个可能的配置是：6/6/6/8/9/9/9/9。同时，“排列”可以包括GPU实例的排序列表(μGPU内的GPC的子集-例如GPU内的GPC的一半、GPC的四分之一、GPC的1/8等)，其中TPC/GPU实例被进一步排序。例如，以上配置具有四个排列(前四个数字反映在第一GPU实例内的经排序的TPC/GPC，并且第二四个数字反映在第二GPU实例内的经排序的TPC/GPC，并且GPU实例本身也被排序)：

6/6/6/8//9/9/9/9

6/6/6/9//8/9/9/9

6/6/8/9//6/9/9/9

6/6/9/9//6/8/9/9

注意，6/8/9/9//6/6/9/9不是排列，因为其没有被适当地排序(对于6/6/9/9//6/8/9/9，其将是冗余的)

底层清除/装仓规则可以减少SKU中的排列的数量。例如，“μGPU之间的8个TPC的最大不平衡”消除了6/6/6/8//9/9/9/9。6/6/6/8//9/9/9/9在其μGPU中具有26和36个TPC，因此其具有10个TPC的不平衡。这样的不平衡将增加产量(将需要从SKU中丢弃较少芯片或不将其装入SKU中)，但可能使性能降级。有可能消除某些排列(例如，具有正确配置但太不平衡的一些芯片)以随着牺牲产量而增加性能。SKU中包括较少排列通常将增加SKU对于某些用途(诸如MIG)的性能，因为跨SKU中的芯片的芯片能力存在较少的不平衡。

具体地，NVIDIA先前引入了允许GPU在空间上被细分成多个更小的GPU实例的多个实例GPU(“MIG”)特征，每个GPU实例可以运行操作系统的不同实例(或在一个OS下的单独容器)。GPU实例的“大小”是GPU实例中的GPC的数量。作为示例，8-GPC GPU可分成四个2-GPCGPU实例，或分成一个4-GPC GPU实例和两个2-GPC GPU实例。然而，通常需要或在过去通常需要相同大小的GPU实例具有相同数目的TPC。这允许在相同“大小”的GPU实例之间迁移上下文，类似于在整个GPU上运行的上下文的迁移。参见https：//www.nvidia.com/en-us/technologies/multi-instance-gpu/。这是由排列的数量测量的“平衡”问题出现的地方。具体而言，在其中芯片内的所有相等大小的GPU实例以及对于SKU中的所有芯片将具有相同数量的TPC的情况下，在SKU中包括具有更多排列的芯片可导致GPU实例之间的性能降低。

这里是两个示例：

示例A：

允许具有10个TPC最大不平衡的6/6/6/8/9/9/9/9(忽略其他配置)

6/6/6/8//9/9/9/9(26+36，10个TPC的不平衡)

6/6/6/9//8/9/9/9(27+35，8个TPC的不平衡)

6/6/8/9//6/9/9/9(28+34，6个TPC的不平衡)

6/6/9/9//6/8/9/9(29+33，4个TPC的不平衡)

4-GPC GPU实例的尺寸为26个TPC

示例B：

允许8个TPC最大不平衡的6/6/6/8/9/9/9/9(忽略其他配置)

6/6/6/9//8/9/9/9(27+35，8个TPC的不平衡)

6/6/8/9//6/9/9/9(28+34，6个TPC的不平衡)

6/6/9/9//6/8/9/9(29+33，4个TPC的不平衡)

4-GPC GPU实例的尺寸为27个TPC

对于MIG“两半(Halves)”，示例B比示例A更好，但是产量将更低。其他示例将适用于四分之一、八分之一等。注意，这些特定划分大小是示例性的。

排列增加了可以包含在迁移中的对的总数，并且还对MIG的GPU实例具有大的影响。细微地，存在以下情况：对于一组配置，并非所有可能的排列都被允许。继续该示例，我们可以将两个μGPU之间的最大不平衡约束为最大两个TPC，这将导致从SKU中排除排列6/8/9/9/9/9/9/9，因为其跨GPU实例的不平衡是三个TPC。

虽然示例实施例结合这种MIG特征是有用的，但所描述的技术可以用于其他上下文，包括具有可以划分“后端”的计算资源的“前端”接口的任何架构。在这样的架构中，可以通过诸如存储器/高速缓存分区、诸如副本的添加引擎的分配、视频解码/编码、jpeg解码、光流等之类的各种技术来提供划分的资源之间的隔离。本技术在一些实施例中还允许单个同时的多个上下文引擎(例如，其可以包括多个GPC)的时间切片，其中两个或更多个上下文共享引擎。所描述的技术进一步允许在多个这种引擎之间的负载平衡，其中，在两个或更多个引擎上可以平衡3个或更多个进程。

动态TPC禁用(DTD)

返回参见图2、图2B、图2C的三个配置，在MIG的对应SKU中分离芯片的先前方式是通过将所有GPC减少到6个TPC来制作8个实例。这意味着将不使用20个TPC。但是从性能角度来看，关闭20个功能TPC是不期望的。在此布置中，GPU的一半将具有24个TPC，GPU的四分之一将具有12个TPC，且GPU的八分之一将具有6个TPC。

相比之下，使用新的vGPC技术，有可能制作8个实例并且随着重新配置的进行而选择性地启用/禁用TPC。由此，每一半GPU具有32个TPC，每一四分之一GPU具有15个TPC，且每一八分之一GPU具有6个TPC。在这种情况下，这些半个和四分之一比在现有布置中好得多。此解决方案还可避免重新配置GPU芯片同时允许芯片的未使用部分在不需要时关闭且在需要时返回开启可能需要的完全复位，且还可用于动态地重新配置GPU的硬件分区，使得不同数目的用户和/或应用程序可根据需要利用不同大小的硬件/处理分区。

图14示出了在使用虚拟GPU的全GPU、两个半个GPU实例、四个四分之一GPU实例以及八个1/8GPU实例之间的这种MIG过渡(transition)。在图14的图表中，具有大间隔的竖直交叉线的方框(如图例中所指示的)示出了TPC，这些TPC通过软件(“软底层清除”)动态地、选择性地暂时“关闭”，以便在每个GPC实例中具有相同数量的活动TPC。这有助于在GPU实例之间迁移上下文。这种动态的、选择性的禁用不是典型的“底层清除”，因为不存在永久的TPC禁用，其方式是硬件变得“知道”被底层清除的TPC不存在，TPC输出被箝位至某些定义的固定水平，并且TPC因此被有效地从电路中切断并且使其不可访问。而是，这种类型的选择性禁用是动态且可逆的，由软件控制，且正执行，不是因为正关闭的TPC存在任何错误，而是用于平衡GPU实例之间的TPC的数目，使得单个GPU可动态地细分以对于软件来说看起来包括若干较小的相同(或以其他方式指定的)芯片(即，各自具有相同或以其他方式指定的处理资源的多个GPU实例)。

一些实施例提供额外的硬件以根据需要选择性地开启和关闭TPC，而无需复位芯片。一些实施例使用的简单方法是在选择性基础上动态地、选择性地、临时地禁用/启用向TPC发送工作，而无需“底层清除的”TPC、对它们通电和断电、使它们不可访问等。此类方法等同于告知其他电路动态禁用TPC仍然存在，但不应被使用。因为没有工作被发送至动态禁用的TPC，所以它们的存在对迁移不产生任何障碍。以此类推，就像酒店仅通过不让客人停留在客房中，而是继续加热、清洁和支持客房来关闭一定数量的客房。通过继续支持具有状态更新的动态禁用TPC等，工作分配器电路能够在任何时间重新启用它们，而无需以可能需要硬件复位的更重大的方式来重新配置硬件。

更详细地，图14示出了具有三个单例模式和总数为68个TPC的示例单个GPU配置。当将GPU重新配置为两个GPU实例时，每一半GPU也将具有天际线(在此情况下为8/8/8/5/1x3)，因为单例模式可相对于GPC处于不同位置。如果GPU被分割成四等分(即，四个GPU实例)，则发生相同的事情(即，对于总共14个TPC，所有四个细分具有相同的天际线8/5/1x1)，因为单例模式相对于GPC仍然可以在不同的位置。迁移可能因此要求单例模式在MIG实例内的GPC之间移动。此外，每个GPU实例将具有其自己的天际线，并且跨GPU实例的统一天际线有助于在每个GPU实例中维持相同数量的TPC。

图14A-14C示出了在动态TPC禁用(DTD)下被禁用的TPC。该图的左侧是将被划分成两个4-GPC GPU实例的6/8/9/9/9/9/9/9配置。在从左图到中间图的转换中，四个TPC被动态地禁用。在从中间图到右图的转换中，创建两个4-GPC GPU实例，两者都具有32个TPC。

在一个实施例中，在无需执行完全复位的情况下完成动态TPC禁用(“DTD”)。创新地，计算工作分配器(CWD)420被编程为不向禁用的TPC发送工作，但TPC保持功能性。该动态禁用可以在GPU的一部分上执行，而GPU的另一部分忙于做工作。被禁用的TPC仍然接收状态更新，但是决不做任何工作，因为CWD被编程为决不向它们发送任何工作。底层清除本身对TPC禁用听起来很好，直到设计者面对如何处理TPC消失的问题，该问题改变了如何枚举逻辑GPC，这改变了对TPC的所有访问类别，诸如工作分配、寄存器访问、以及潜在地更多(例如，在一些架构中的存储器选项)，同时几十个正交过程正在使用受底层清除变化影响的共享资源。由此，在如本文所述的仅禁用对特定TPC的调度的示例实施例中使用的技术可解决将另外需要根据特定架构来解决的大量挑战，例如：

·需要禁用TPC的任何机制应该保证没有机密的用户状态能够跨禁用边界泄漏。例如，如果底层清除“钳位(clamp)”被接合并且然后软件撕下上下文，则TPC中的状态将被保持。因此，需要提供进一步的机制来清除状态，诸如扫描链复位、通过存储器内建自测试(“MBIST”)清除、异步/同步复位、或者在重新启用之后提供状态清除的硬件保证——引入机密状态泄露的机会。相反，通过仅禁用对特定TPC的调度，TPC接收所有命令以清除上下文之间的状态并保留相同的威胁图。

·一旦该上下文被重新启用，任何这样的禁用机制都应该提供一种保持/恢复引擎状态的方式。该状态是这样的时钟门控启用的上下文无关的状态。如果底层清除钳位被启用并且如上所述应用复位，则将需要用于恢复或复位域以便跨底层清除启用而保持状态的机制。相反，仅通过不分发工作，TPC接收和执行所有功率状态和功率状态更新。

·任何这样的禁用机制应当提供处理被禁用的TPC的带外(“OOB”)管理的方式。如果使用底层清除，则这意味着禁用对TPC的寄存器访问。存在命令总线和/或软件可以处理这一点的各种方式，但是将需要改变硬件/软件。相反，通过使TPC被启用但未调度，寄存器访问或其他OOB访问简单地工作。

·任何这样的禁用机制应当被设计成不引起毛刺。例如，异步地应用一个示例GPU架构中的底层清除钳位——这意味着来自TPC的信号可改变值，使得不满足单个循环时间约束。在之前的硬件中，做出改变，并且然后围绕边界的所有逻辑被复位——清除任何毛刺。这迫使先前架构中的复位。有可能以各种方式对底层清除信号进行定时/重定时以解决这个问题，但是将再一次需要硬件改变。通过使TPC被启用但未调度，毛刺问题不存在，因为底层清除信号未被修改。

DTD的一方面是提供比在没有DTD的情况下可能的GPU实例更大的GPU实例。例如，在过去，图6A、图6B、图6C中的三个配置将需要将所有GPC中的TPC的数量减少到仅6个，总共48个正在使用的TPC(即，2个GPU实例，每个具有24个TPC)。DTD允许相同配置使用总共64个TPC(即，2个GPU实例，每个具有32个TPC)。

DTD的另一个示例方面是提供比没有DTD更多的GPU实例。例如，在过去的设计中，7-GPC GPU可以仅具有一个“半”实例，该实例具有4个GPC。对于DTD，7-GPC可以具有具有4个GPC的一“半”以及具有3个GPC另一“半”，只要在每个“半”中的TPC的总数是相等的并且天际线是相等的。

图14B和图14C示出了这些概念中的一些概念。使用动态TPC禁用，现在有可能改变每GPC的TPC的数量而无需复位(例如，一半使用64，四分之一使用56)。此外，比较图14B和图14C，可以看出，现在可以在七个8-TPC“八分之一”(56个TPC)与八个6-TPC“八分之一”(48个TPC)之间进行选择。相反，现有技术方法不允许这种灵活性。

对计算工作分配器的示例改进

本技术提供对与调度工作到特定TPC相关的CWD 420电路的进一步改进。每个GPU芯片中的计算工作分配器(CWD)包括用于使vGPC和天际线工作的不同创新。这些创新包括用于确定哪些TPC需要被当作单例模式的装置，以及用于处理单例模式的特殊情况硬件。

在一个实施例中，虚拟TPC ID是在“底层清除”之后在GPC内分配给TPC的基元引擎共享(“PES”)知晓的编号(参见下文)。如本领域技术人员已知的，PES用于实现DirectX的Direct 3D StreamOut功能。参见例如https：//devblogs.microsoft.com/pix/hardware-counters-in-gpu-captures/。虚拟TPC ID编号可以遵循统一的模式，例如在每个GPC中对于第一PES的第一非底层清除的TPC从0开始，将下一个ID分配给下一个PES中的非底层清除的TPC，等等。这有效地确保连续的虚拟TPC ID将在不同的PES中，并且将帮助PES平衡的工作分配。

以下表格示出了针对两种不同的底层清除配置的物理TPC ID、逻辑TPC ID与虚拟TPC ID之间的示例映射：

表I

表II

物理TPC ID	GPC0逻辑TPC ID	GPC0虚拟TPC ID
			0	0	0
1	1	3
			2	2	5
3	3	1
			4	4	4
5	5	6
			6	坏的/底层清除的	-
7	坏的/底层清除的	-
			8	6	2

在示例实施例中，GPM使用物理TPC ID来索引MPC和PE(参见图23)，并且TPC使用其逻辑TPC ID来映射其TPC上下文图像以用于上下文保存/恢复。更详细地，图23示出了在一个实施例中，CWD 420(其从主机CPU接收启动命令)基于虚拟GPC ID和虚拟TPC ID向硬件处理资源发出启动命令。交叉开关提供来自芯片上的CWD 420和任何/所有物理GPC的这种启动命令的灵活的通信传输。在每个GPC内，称为“GPMPD”的电路将虚拟GPC ID和虚拟TPC ID转换成物理TPC ID，该物理TPC ID寻址或选择适当的一个或更多个TPC处理电路。每个TPC包括MPC(多管道控制器)和基于物理TPCID接收和处理的PE引擎块。PE块基于如由“PD”寄存器块通知的逻辑GPC ID和逻辑TPC ID保存用于迁移和其他目的的上下文和状态，该“PD”寄存器块为GPMPD提供逻辑GPC ID与虚拟GPC ID之间的映射。

在先前设计中，CWD 420基于SM-ID(即，通过在所有GPC之间交错虚拟TPC ID而获得的全局TPC ID)将计算工作发送到GPM。本技术提供了通过按照TPC计数的降序对GPC编号而获得的新的“虚拟GPC ID”，即，具有最低数量的底层清除的TPC(意味着最高数量的起作用的TPC)的GPC被指派为具有最低的虚拟GPC ID。为了解决具有相同数量的TPC的两个GPC之间的联系，可以使用逻辑GPC ID(较低的逻辑GPC ID将接收较低的虚拟GPC ID)。

CWD 420现在可以根据两个ID来查看GPU：可迁移TPC ID+虚拟GPC ID。可迁移TPCID可以与用于虚拟GPC ID 0-7的前述实现方式中的虚拟TPC ID相同(如图23所示)。对于虚拟GPC ID 8-23，这个值可以总是0。因此，当我们在虚拟GPC 8～23中需要用于TPC的虚拟TPC ID时，它可以从‘0’转换成原始的虚拟TPC ID。可以将CWD的虚拟TPC ID称为“可迁移TPC ID”，以针对虚拟GPC ID 8-23进行这种区分。

在CWD 420内存在用于将工作调度到给定TPC上的某数量的电路。因为在GPC或其他硬件分区内存在许多TPC，所以大量的芯片基板面积专用于这种每TPC调度。此外，为了适应上述MIG创新(在一个实施例中，其可将GPU划分为多个(例如，多达8个)可独立操作的GPU实例部分)，GPU现在需要八个CWD 420电路(八个GPU实例中的每一个一个电路)。此外，一个示例GPU实现能够支持N个单例模式和相关联的N个虚拟GPC(例如，其中N可以等于16，作为一个示例以提供vGPC8、cGPC9、…vGPC23)。

实现CWD 420的直接方式将是构建CWD 420以支持可在GPU芯片上提供的最大数目的TPC，GPU芯片包括各自支持单例模式TPC的附加虚拟GPC。然而，这种实现方式可能需要大量的芯片面积。

在另一示例实现中，向CWD 420内的每TPC子单元提供映射。参见图15，图15示出了到将vGPC提供给多达某数量N的单例模式TPC的第一部分3002的映射，以及将vGPC提供给作为多TPC CGA区域的一部分提供给定产品SKU的多达某数量Q的TPC的第二部分3004的映射。

图16示出了第一部分3002与第二部分3004相组合。在组合表示中，存在可以用作单例模式的16个TPC和56个非单例模式TPC。在示出的实例中，因为单例模式实际上嵌入在芯片的物理GPC电路内并且与该电路内的其他TPC互连，所以示出的16个TPC中的每一个可被指派为充当单例模式或者它们可被指派为充当来自vGPC0-vGPC7的虚拟GPC内的TPC。不需要任何单例模式，并且天际线将利用作为物理GPC的一部分的TPC建立得更高。因此，图15和图16中的交叉线块可以被指派为虚拟GPC 8-23，或者它们可以具有由虚拟GPC 0-7内的M0-8表示的模块化TPC ID。在这个具体示例中，GPC内的单例模式和非单例模式TPC的总和不能超过72个。然而，图16中所示的两个区域的形状对于构建GPU是非常有用的。被制造为具有较少缺陷的芯片可用产品SKU指定，产品SKU在区域3004内限定较多TPC且在区域3002内限定较少单例模式。在这种情况下，如图16所示，使用混合单元或“混合模式”单元3006，TPC3002中的一些可被配置为单例模式或者被配置为作为多TPC CGA区域的一部分的TPC(并且因此能够执行将占用多于一个TPC的CGA的CTA)。因此，在该示例中，只有TPC 3002可被配置为单例模式以支持该特定天际线，但是可被配置为单例模式的每个处理器可替代地被映射到GPU中的其他vGPC。如果支持单例模式的TPC用于代替地参与多TPC GCA区域，则天际线可以减少可支持的单例模式计数。

在此可以注意到，在一个实施例中，如果GPC与CGA兼容，收集可被一起配置为单例模式以形成新的多TPC虚拟GPC的多个处理器可能是不可能的。具体地，如在上面标识的共同未决的共同转让的专利申请中所描述的，在一些实施例中硬件为CGA提供的并发处理保证要求在运行GPC CGA的GPC中的各个TPC之间的某些基于硬件的协作(例如，同步、数据位置、消息传递互连等)。这样，将存在能够在天际线的多TPC CGA区域内的TPC上运行但不能在单例模式TPC上运行的CGA。同时，图16中所示的单例模式可以在物理上位于芯片上的任何GPC电路中，这意味着在一般情况下，它们以提供协作保证TPC需要参与运行GPC CGA的方式彼此互连。另一方面，对于基于非CGA的CTA或者在具有不同约束的其他实现方式中，该约束可能不存在。

在该特定示例中，混合的“混合模式”交叉线中的TPC 3006不被用作单例模式，因为需要它们是产品SKU的多TPC CGA区域的一部分。在一个实施例中，TPC作为单例模式或多TPC GPC的一部分的这种配置是通过需要多少单例模式来满足特定产品SKU的要求来通知的。在这两种情况下，TPC将被映射到虚拟GPC，但是被配置为单例模式的每个TPC将被映射到它自己的专用vGPC，而未被配置为单例模式的TPC将与其他TPC一起被映射到包含多个TPC的vGPC。

这种CWD可重配置CSM映射提供了一种机制，其中有限数量的模块(CSM)具有被配置为映射至单例模式TPC或作为非单例模式组的一部分的TPC的灵活性。相比于使每个CSM支持单例模式和非单例模式TPC，该实现方式节省了相当大的面积。

在一个实施例中，可以如图17中所示以固定顺序填充单例模式。例如，如果GPU芯片被编程用于6个单例模式，则得到如图18所示的vGPC标记。其余的芯片和软件不需要知道CWD 420内部的该映射；不需要其他单元的改变，并且支持迁移。然而，以上暗示在一些实施例中，产品SKU的天际线被认为还包括单例模式计数。该单例模式计数可表示为多位掩模，其指示GPU芯片上的CWD 420的哪些具有单例模式能力的CSM被启用以支持单例模式以及哪些不被启用-注意，这些支持单例模式的CSM中的每一个可被配置为静态映射到GPU中的任何物理TPC。此掩模可嵌入在GPU芯片的固件/硬件中，在芯片测试/装仓时闪存(flash)，且用于编程CWD 420电路的组合逻辑。参见图18A单例模式掩模布局的图示，其中掩模中的位与单TPC vGPC 8-21(在一些实施例中可使用附加的vGPC 22、23)一一对应。

图19和图20示出了示例芯片编程布置和流程图。在所示的示例中，使用芯片测试器/编程器4052对所制造的芯片进行测试(框4002)。当连接至芯片测试器/编程器4052的处理器4054基于执行存储在非暂时性存储器4056中的、使用众所周知的常规测试/锻炼算法来测试和锻炼芯片的程序控制指令来确定所制造的芯片4050是否具有足够的缺陷，从而使得其不满足任何产品SKU的最小功能要求(决策框4006的“否”出口)、或其是否符合产品SKU天际线(决策框4006的“是”出口)。如果芯片缺陷太大，则丢弃/毁坏芯片(4060)。注意，可以有多个产品SKU。丢弃的芯片可被保存以供将来包括在较低性能的SKU中。否则，处理器4054控制测试器/编程器4052向芯片写入底层清除指令，以便在有缺陷的硬件部分周围熔断某些保险丝，从而使得那些部分不可访问(框4008)。此外，基于使用一个或更多个存储的产品SKU定义(例如存储在存储器4056中的天际线)进行底层清除之后的芯片配置之间的比较，处理器4054闪存芯片内的单例模式掩模(参见图18A)以指示哪些TPC被启用以支持单例模式(框4008)。然后用产品SKU对芯片进行标记(框4010)——该产品SKU将芯片与该特定产品SKU的天际线相关联。如本文所描述的，任何给定的芯片通常可以被分类在许多不同的产品SKU中，并且处理器4054因此可以在对芯片进行分类、对芯片进行底层清除并闪存芯片的单例模式掩模时将客户需求考虑在内。

高级计算工作分配器的示例硬件实现方式

在这种GPU芯片的示例中，制造过程用于在半导体基板上创建某数量Q(例如，总共72个)的物理TPC，其中物理TPC被聚类为物理GPC(例如，8个GPC，每个包括9个TPC)。类似地，GPU芯片的CWD 420可被制造为具有Q个CSM调度电路——每个TPC具有一个CSM调度电路，CSM和TPC之间具有一对一对应关系。在CWD 420内，每个SM或TPC由被称为CSM的每SM硬件电路表示。CSM包含在TASK_ASSIGN、STATE_SYNC和CTA_LAUNCH之间进行选择的任务选择状态机。此外，GPU的CWD 420可被制造为具有R个附加CSM调度电路——芯片可能需要容纳的最大数量的单例模式中的每一个一个附加CSM调度电路。然而，这样的布置将占据相当大量的有效面积(real estate)。

因此，在一个实施例中，CWD 420的每个CSM部分可被构造成以两种可选模式运行：调度单例模式TPC或调度作为多TPC CGA区域的一部分的TPC。然而，在任何给定产品SKU中的大部分CSM将永远不会被调用来调度单例模式TPC。因而，CWD 420内的(Q-R)CSM可被构造为操作为单模式CSM以调度TPC的工作，该TPC是多TPC CGA区域的一部分，并且CWD 420内的剩余R个CSM可被构造为双模式电路，该双模式电路可调度单例模式(第一模式)的工作或替代地调度具有单例模式能力的TPC的工作，该TPC与至少一个其他TPC分组以形成多TPC CGA区域(第二模式)。这样的模式可以由上面讨论的单例模式掩模来控制，特别是当单例模式以相对于天际线的预定模式如所示地放置时。

在图21A、图21B、图21C-1和图21C-2中所示的一个或更多个实施例中，使用主计算工作分配器(“CWD”)硬件电路420在GPU上启动CGA，同时提供CGA的所有CTA可以同时启动的基于硬件的保证并且还实现上述虚拟GPC映射。这样的布置实现了非功能TPC的底层清除，同时确保双模式CSM将连接到将被分配为单例模式的每个TPC，而不管哪些非功能TPC被底层清除。所得设计不仅节省了芯片面积，而且由于CSM电路和CWD电路的其余部分之间的距离减小而增加了性能。

此外，在一个实施例中，CWD 420电路被设计成根据GPU的底层清除配置作为“全宽度”或“部分宽度”工作分配器来操作。如图22所示，全宽度CWD 420支持16个单例模式加上额外的非单例模式TPC，半宽度CWD支持12个单例模式加上额外的非单例模式TPC。在又一实施例中，四分之一宽度的CWD支持7个单例模式加上额外的非单例模式TPC。这种布置节省了基板面积并且还使用可用的基板面积来增加最需要的功能——在更加重底层清除的GPU中提供附加的单例模式。单个GPU芯片可具有这些CWD电路的多个不同版本，以提供功能性的组合。

例如，一个版本被称为“完整”构建，并且支持将工作分配给完美GPU中的所有72个TPC。另一个被称为“减少”并且支持将工作分配到GPU中的最多36个TPC。这可起作用，因为CWD经由PRI寄存器编程理解‘虚拟TPC’命名空间，PRI寄存器编程将CWD的GPU中的TPC的视图与‘逻辑’或‘物理(和对应的被底层清除)’视图解耦合。

一些示例实施例提供了一种爬行(ramchain)特征——一种用于从执行着色器程序的SM复制内部管线寄存器和存储器状态到上下文状态存储的基于环的后门访问机制。参见例如US20140184617。在一个实施例中，上面讨论的两个版本可以经由爬行新特征(称为“子类”)进行上下文切换，其中，爬行查询可以指定其试图切换和/或恢复CWD中的状态的哪个子集——对于CWD，这些被称为CWD_CORE和CWD_EXTRA——其中，CWD_CORE是存在于CWD的cwd_full和cwd_reduced构造中的“核心”状态。CWD_EXTRA状态仅存在于cwd_full构造中。

对于MIG特征，仅一个物理MIG控制器(内部称为“系统管线(syspipe)”，其一个示例实施例具有syspipe0至syspipe7实例)需要支持对GPU中的所有8个GPC的“未分区的”调度。所有其他系统管线需要最多支持“1/2”MIG实例，因此仅系统管线0(实例的选择基本上是任意的)需要支持“cwd_full”版本，并且所有其他系统管线(系统管线1至系统管线7)仅具有由“cwd_reduced”提供的物理支持，以便在GPU中仅调度总完美TPC的1/2。该工作分配器的物理实现方式的这种“缩小”的结果导致GPU的面积和功率节省。

关于爬行子类，由于在一个实施例中我们有两个TPC类别-具有gf能力以及仅仅计算(即，非对称资源)，因此示例实现可以具有作为TPC单元的两种类型的MPC。我们可以有状态需要从gfx MPC-＞计算MPC迁移的场景(在源和目标TPC应该具有相同SM_ID的计算应用中)。因此变得有必要具有在MPC中分离出gfx和计算状态的能力，所述MPC具有gfx能力，因此有可能在运行计算应用时仅保存和恢复计算状态，而在运行图形应用时保存和恢复gfx和计算状态两者。爬行是在上下文切换/迁移期间帮助保存和恢复状态的预先存在的硬件。本文中的技术将子类的概念添加到爬行-这是在单元中组织和标记状态的方法，以便可独立地选择用于保存和恢复。在该示例中，具有gfx能力的MPC具有计算状态，其使用默认子类来标记并且因此总是被保存和恢复。此外，其具有使用仅在运行gfx应用时被保存和恢复的gfx子类来标记的gfx状态。

灵活的迁移

如以上所讨论的，本文的技术允许将每GPC配置文件的不同TPC包括在同一产品SKU中，以增加产量和TPC计数。但是每GPC配置文件的不同的TPC对于迁移引起巨大的问题。这个问题通过与灵活的TPC迁移(FTM)相关的进一步改进来解决。具体地，在一些实施例中，当将工作从源GPU芯片迁移到目标GPU芯片时，由源GPU芯片的给定GPC执行的所有工作可以不必保持在一起。相反，给定GPC的特定TPC在源GPU上执行的工作可以在迁移之后由目标GPC的两个或更多个TPC执行。因此，在每TPC的基础上而不是在每GPC的基础上省去并重新开始工作。TPC的工作拆分到两个TPC例如可能在原始执行上下文中TPC是大CGA组的一部分并且具有图形功能的情况下发生。相反，如果目标GPU在GPC上仅具有大的CGA组而没有图形，则在一些实施例中不可能将原始TPC的图像放置在既是大的CGA的一部分又具有图形能力的特定TPC上。但是现在假设不同的情况，其中源GPC物理地具有单例模式和大的CGA两者。如果在目标上不存在具有相同CGA大小和相同数量的单例模式的GPC，那么源GPC的CGATPC和单例模式可能需要在目标上分离，以避免不可迁移的场景。

图24示出了图6A、图6B、图6C、图7A、图7B、图7C和图8中所示的配置之间的示例灵活迁移。该组非单例模式(多TPC CGA区域3000)跨逻辑GPC直接迁移(即，这些TPC不改变)，但单例模式可在逻辑GPC之间移动。更确切地，当完成上下文保存并且然后恢复到具有不同配置的GPU时，在单例模式上运行的挂起的工作可以从一个逻辑GPC移动到不同的逻辑GPC。在图24的示例中，在最左边的配置中，单例模式A在逻辑GPC 0中，但是其工作迁移到中心配置中的逻辑GPC 3/从中心配置中的逻辑GPC 3迁移，并且还可以移动到最右边的配置中的逻辑GPC 2/从最右边的配置中的逻辑GPC 2迁移。

在现有芯片中，TPC上下文状态基于每GPC被保存。在本技术中，为了促进FTM，在每TPC的基础上保存TPC上下文状态。保留虚拟GPC ID也是有利的。此外，除了每TPC状态之外，还存在不是任何TPC状态的一部分或在任何TPC中的每GPC状态，因此必须特别注意。

除了FTM之外，本技术还提供了灵活的GPC迁移(FGM)，其处理迁移源和目的地GPU具有不同数量的GPC的情况。例如，迁移可以在配置6/9/9/9/9/9/9/0与5/7/8/8/8/8/8/8之间，其中，“0”指示被底层清除掉的GPC(即，整个GPC被视为非功能的)。FGM的创新包括为在源GPU中不存在的GPC生成GPC状态。

图25A、图25B、图25C示出了相同的三个68-TPC配置，但是其中每个都被分成两个4-GPC GPU实例。六个4-GPC GPU实例中的每GPC配置文件的TPC为：四个8/8/8/8；一个7/8/8/9；以及一个6/8/9/9。迁移必须能够发生每GPC配置文件的这些4-GPC TPC中的任何两个。当多个GPU实例在使用，并且完成GPU上的工作的迁移时，所有GPU实例被独立地迁移，并且在源GPU上运行GPU实例的软件可被分发到目的地GPU上的不同目的地GPU实例并在目的地GPU上的不同目的地GPU实例上重新开始。

图25中的4-GPC GPU实例各自具有两个单例模式。并且，正如对于完整的GPU迁移情况，GPU实例情况在迁移源和目的地处具有相同数量的单例模式和非单例模式。图26示出了关于在六个4-GPC GPU实例之间如何迁移单例模式和非单例模式的一些选择。

图26、图26A-26D示出了一个实施例中的示例灵活迁移。在图26A的迁移示例中，迁移与虚拟GPC ID匹配，因此逻辑到物理映射是任意的。在此处所示的实例中，GPC在逻辑GPC空间中从左到右，并且较低的数字在虚拟GPC空间中。在该示例中，标记为“图形TPU”的块是支持图形的TPC的子集。在一个实施例中，具有图形能力的一个GPC(GPC0)被给予逻辑GPC0。这是对先前描述的天际线规则的修改，其表明GPC被从最小到最大排序。因此，GPC 0具有图形，并且其余的GPC如前排序。参见以下关于图形迁移的讨论。

图26B示出了在迁移中，TPC可以在逻辑GPC ID内移动。

图26C和图26D示出了来自GPC[0]的计算状态可以转到不同的逻辑GPC。

图27示出了一些SKU可以底层清除整个GPC。在这个示例中，在SKU中不使用虚拟GPC ID 7，即使对于具有8个GPC的芯片也是如此。当从7个GPC迁移到8个GPC时，从7-GPC上下文图像产生用于第8个GPC的状态。

进一步的计算工作分配器改进以支持迁移

CWD 420还包括其他创新，以便使DTD、FTM和FGM适当地起作用并且因此支持迁移。这些包括用于确定哪些TPC需要被当作单例模式的装置，以及用于处理单例模式的特殊情况硬件。创新的技术区别是：

·TPC能够被动态地禁用

o提供比先前芯片架构更多的GPU实例

o提供比先前芯片架构更大的GPU实例

·在一个芯片上一起在GPC中的TPC可以迁移到在另一个芯片上的多个GPC

o以前，GPC中的TPC一起迁移

·一起在GPC中的TPC可以移动至同一芯片中的多个GPC

·TPC状态基于每TPC被存储，而不是基于每GPC被存储

o在同一源GPC中的TPC可以迁移至不同的目的地GPC

o允许具有每GPC配置文件的不同TPC的芯片被包括在同一产品SKU中，因为HPC安装需要迁移

·微代码使用指向TPC状态的指针以允许保存的TPC工作根据需要被混洗

·对于FGM，产生用于另外不存在的GPC的GPC状态

基于SM_ID的TPC上下文保存/恢复

在过去，GPC中的TPC的状态被保存在与该GPC相关联的上下文缓冲区的区域中。此外，该状态使用该TPC的逻辑TPC ID在该GPC中进行索引，该GPC不再与灵活的TPC迁移一起工作，因为TPC状态可能需要在具有不同逻辑TPC ID的不同GPC中的TPC之间移动。

本文的示例技术将所有TPC状态移出GPC而进入由唯一的预先存在的全局标识符SM_ID索引的分开的连续区域中。在CILP(计算抢占)期间，预期分配给在源中具有SM_ID‘n’的TPC的工作在目标中具有相同SM_ID‘n’的TPC上继续执行。通过使用基于SM_ID的索引，TPC状态恢复到目标中的正确TPC，而不管它在哪个GPC中或它具有哪个逻辑TPC ID。

GPC状态复制

随着底层清除规则的放松，我们可以具有在具有不同数量的GPC但具有相同数量的总TPC的GPU之间迁移的场景。

这种技术试图在两个方向上解决这个问题：

-当从更多的GPC向更少的GPC迁移时，来自该源的额外的GPC状态被自动跳过用于恢复，因为在目标中没有等效的GPC

-当从更少的GPC向更多的GPC迁移时，利用所有GPC单元的状态在迁移点处相同的事实-源中的任何GPC的状态也被恢复到目标中的额外GPC。

具有GFX能力的TPC和仅计算TPC的特殊处理

在一个示例实施例中，在整个GPU中可以仅存在具有图形能力的TPC的子集(例如，5个)。所有其他TPC仅是计算的并且不能处理图形工作。因此，当在这样的示例实施例中运行图形应用时，在迁移期间，源中的图形TPC的状态应当仅被恢复到目标中的图形TPC。注意，这要求TPC状态应当仅在具有相同SM_ID的TPC之间迁移的规则的例外，因为具有相同SM_ID的TPC可以是目标中的仅计算TPC，因此与正被恢复的图形TPC状态不兼容。本文中的技术寻求检测图形应用何时运行，并添加特殊固件逻辑以识别源和目标中的图形TPC以及它们之间的移动状态。这是源TPC的状态在一些实施例中可被拆分成多个目标TPC状态的示例。而且，目标中具有与源中具有图形能力的TPC相同的SM_ID的任何仅计算TPC使其状态从任何其他计算TPC恢复——利用当运行图形应用时在迁移点处预期计算管线是空闲的并且因此所有仅计算TPC状态被保证相同的事实。该技术因此解决了必须在不相同资源之间迁移的问题。

GPMPD屏障表

GPMPD是GPC单元，其在称为屏障表的结构中包含计算工作跟踪信息。参见图28。因此，这种屏障表可对于TPC迁移有用。屏障表中的条目与该GPC中的TPC相关联。因为GPC中的TPC可以在灵活的TPC迁移过程中移动到不同的GPC，所以需要能够在每TPC的基础上隔离该屏障表的条目。在一个实施例中，TPC迁移问题的解决方案是选取gpc_local_cga_id，使得它们在迁移期间永不改变。GPMPD接着可使用vgpc_id及gpc_local_cga_id索引到其屏障表中，两者在GPU迁移期间从未改变。从MPC接收的用于诸如屏障到达和cta_completion的事物之类的分组(packet)将包含gpc_local_cga_id作为新的字段。GPMPD从作为分组的源的TPC(即，从接收分组的物理TPC接口)推理vgpc_id。

如图28所示，示例技术将屏障表组织成可以独立于彼此被保存和恢复的每TPC组块(chunk)。再次使用SM_ID标记这些条目用于保存和恢复，因此确保当TPC状态在迁移期间移动到不同的GPC时，屏障表状态也移动到该GPC中的GPMPD。这些每TPC屏障表条目也使用上述爬行子类来标记，从而帮助隔离它们以用于保存和恢复的目的。

更详细地，GPM中的CGA屏障状态表的表条目数量增加，釆用如下：

一半的条目被TPC上的CGA使用，这将不会在GPC之间迁移；以及

条目的另一半用于逻辑表，每个可能的单例模式TPC一个逻辑表(在一个实施例中，屏障表不需要分成两半；相反，整个表可以分为N个TPC组块，并且N个爬行子类可以用于隔离它们以用于保存和恢复)。这些逻辑表在爬行(被扩展为具有新的状态类别)上被单独地寻址。表格图像也在上下文图像中被置于每TPC状态。为了迁移，对于单例模式TPC，在GPC之间混洗TPC上下文图像。在一个实施例中，微代码通过使用SM_ID对这些每TPC屏障表组块进行标记来执行混洗，使得多TPC CGA的屏障表组块将被单独地保存并恢复到同一目标GPC。因此，单例模式TPC的组块将被单独地保存并且恢复到单例模式被灵活地迁移到的GPC。

另外，向gpc_local_cga_id添加比特，以区分单例模式和非单例模式。对于单例模式，包括虚拟GPC ID(其在整个GPU上是唯一的)和多比特屏障ID。

对TPC的计算工作节流

在MIG模式中，由于底层清除的差异和选择GPC以形成同时的多个上下文(“SMC”)引擎(参见例如US 20210073035)，在产品线中跨GPU的TPC的总数或每GPC的TPC计数上存在差异。现有技术已经试图通过“软”底层清除来解决这个问题，其中，使用保险丝块中的寄存器来底层清除一些良好的TPC，因此确保产品线中的所有GPU上的类似大小的SMC引擎上的恒定TPC计数。对“软”底层清除的任何改变需要全芯片复位，尤其是在MIG用例下，全芯片复位是破坏性的，因为同一GPU上的不同用户将中断其工作。再次，现有技术通过保持“软”TPC底层清除不改变并且因此次优地使用GPU中的可用TPC来解决这个问题。

代替尝试保持TPC的数量恒定，本文的技术相反旨在保持用于工作的TPC的数量恒定。在不改变任何底层清除的情况下，本文的技术改为对计算工作分配器420中的寄存器进行编程以仅将工作分发到可用TPC的子集。由此，当从较高数量的TPC迁移到较低数量的TPC时，源中的额外的TPC已经被以编程方式被排除用于工作分发，并且因此不具有需要被恢复的活动状态。对这些寄存器的任何重编程仅需要局部复位并且不是破坏性的。此外，这允许最大化GPU中可用的TPC的使用。

处理在源和目标之间的不同数量的TPC

示例非限制性技术提供固件来处理具有不同数量的TPC的源与目标之间的迁移。从较多到较少的迁移通过跳过源中的额外TPC状态的恢复来处理，因为无论如何，这些TPC被排除用于工作。当从较少到较多迁移时，固件禁用目标中的额外TPC的恢复，并且它们继续保持在初始化状态。再次，对于目标中的工作分配，这些额外的TPC将被以编程方式排除。在另一个实施例中，当从较少TPC迁移至较多TPC时，可以将用于应用程序的原始TPC的状态克隆至多个目标TPC。

示例改进的CWD电路实现方式

在本文的实施例中，CWD 420包括寄存器、组合逻辑和硬件状态机。关于用于调度工作的示例GPU CWD和MPC的更多信息，参见例如该专利公开和相关描述的20200043123，特别是图7。其功能被扩展/增强以提供阴影状态模拟的CGA启动能力，以确认资源可用于启动CGA中的所有CTA。如果CGA的所有CTA不能同时启动，则CWD 420不启动CGA的任何CTA，而是等待，直到相关GPU硬件域的足够资源变得可用，使得CGA的所有CTA可被启动，从而它们并发运行。在示例实施例中，CWD420使用多级工作分配架构支持多级CGA的嵌套(例如，GPU-CGA内的多个GPC-CGA)，以在关联的硬件亲和性/域上提供CGA启动。

更详细地，图21A中示出的CWD 420在使用模拟技术确定CGA的所有CTA可以适合在指定硬件域中可用的硬件资源之后发起CGA中的CTA。以这种方式，一个示例模式中的CWD420确保在启动CGA的任何CTA之前，跨所有GPC或其他相关硬件域有足够的资源用于CGA的所有CTA。在一个实施例中，启动CGA的CTA的算法可从传统(非CGA)网格启动借用一些技术，同时首先确认CGA的所有CTA可以确保它们将同时运行的方式启动。

图21A示出CWD 420的基本架构，CWD 420包括负载平衡器422、资源跟踪器(TRT)425(0)、425(1)、...425(N-1)、TPC启用表430、本地存储器(LMEM)块索引表432、信用计数器434、任务表436和优先级排序的任务表438。每个TRT 425(0)，425(1)，…425(N-1)与对应的TPC 340(0)，340(1)，…340(N-1)通信。关于这些结构的传统操作的更多细节，参见例如USP10,817,338；US20200043123；US20150178879；以及USP10,217,183。在此示例中，CWD被增强以提供新的每TPC的GPC编号等。

在一个实施例中，CWD 420从与GPU协作的CPU 212接收用于在CPU 212上执行的各种进程的任务。在示例实施例中，由GPU执行的每个计算任务可以对应于CGA(尽管非CGA任务也可以被容纳)。在CPU 212上执行的每个进程或应用可以发出这样的任务。例如，CPU212可以执行存储在诸如全局存储器之类的非暂时性存储器中的一个或更多个程序，以生成命令GPU启动CGA网格的CGA启动命令。

在操作中，CPU 212执行为GPU生成“网格启动”(和其他)命令的驱动程序(参见图21C-2)。网格启动命令具有定义由GPU执行的CGA网格的关联的状态参数。关于CPU可如何使用例如面向线程的编程环境(诸如来自NVIDIA^TM的CUDA^TM编程环境)来启动网格的背景，参见例如USP7,937,567；USP9,513,975；以及USP9,928,109。CPU 212还布置将由SM执行的线程被存储在例如全局存储器中，使得GPU的直接存储器存取硬件可通过系统的存储器管理单元(MMU)检索线程以供SM执行(见图21A)。

示例CGA启动命令

在示例实施例中，从CPU 212到CWD 420的启动命令可以指定CGA网格，该CGA网格包括复合线程块和CGA的不同维度的枚举。作为一个示例，CGA网格启动命令可以指定运行10240个CGA，其中每个CGA是8个CTA，其中每个CTA具有256个线程，其中每个线程具有(需要)64个寄存器，并且其中每个CTA分配128KB的共享存储器，等等。这些数字被编码成如{10240，8，256，64，128}的启动命令，并且是硬件工作分配器CWD 420在SM上启动线程或CTA时处理的信息。CPU 212将这样的启动命令发送到GPU内的调度器410(图21C-2，框558)。

使用以上技术，应用程序可以在GPC或其他硬件分区中启动许多小的CGA，但数量随着CGA大小的增长而减小。在某一点(取决于硬件平台)，CGA都不能适合在GPC或其他硬件分区中，这可能损害代码便携性。如果假设每个平台具有具有4个TPC的至少一个GPC，则保证在未来架构上的兼容性的最大CGA大小是8个CTA。给定的应用程序可以基于查询平台来动态调整CGA大小，以根据1)CTA资源需求和2)每CGA的CTA数量来确定能够在GPU中并发运行的CGA数量。

GPU CGA调度和启动

在示例实施例中，GPU内的调度器410从CPU 212接收任务并将它们发送到CWD 420(图21C-1，框502、504)。CWD 420从多个CGA查询和启动CTA。在一个实施例中，一次对一个CGA进行操作。对于每个CGA，CWD 420模拟CGA中所有CTA的启动，递增“启动”寄存器来存储模拟的启动。如果在模拟中启动CGA的所有CTA之前SM或硬件域中的其他处理器中的所有空闲槽用尽，则CWD 420终止启动，并可稍后再次尝试。相反，如果对于CGA中的所有CTA存在足够的空闲槽，则CWD420从在模拟启动过程中累积的“启动”寄存器生成sm_mask(该sm_mask数据结构存储用于在用于CGA启动的相关硬件域中的每个SM上运行的多个CTA的预留信息)，并且移动到下一CGA。硬件分配CGA序列号，并将其附加到每个sm_mask。它还将CGA的end_比特附加到最后一个比特以防止来自不同CGA的sm_mask的交错。

示例CGA启动分组

基于成功的模拟启动，CWD 420向GPC(SM)发送诸如以下的启动分组(其指定虚拟GPC ID)。这样的启动分组可以例如包括以下字段：

向所有SM广播启动分组允许SM内的所有MPC观察CGA/CTA启动的整个序列。通过观察CGA和CTA的流，每个SM的MPC(网格当前被指派给该MPC)能够冗余地并且独立地执行光栅化。广播亦为lmem_blk_idx分组，其承载自CWD 420至SM的lmem_blk_idx(参见图21A的LMEM块索引表432)。

在一个实施例中，在CGA启动期间，在负载平衡之后，CWD将CTA发射到元组<可迁移TPC ID,虚拟GPC ID>。GPM解码这个元组并且将其与实际的“物理”TPC ID相关。在一个实施例中，新的CWD PRI-NV_PGRAPH_PRI_CWD_VGPC_MTPC_ID是SM_ID到<虚拟GPC ID,可迁移TPCID>的映射，并且可以正向和反向形式存储以加速运行时的转换。对于虚拟GPC ID 8～23，新的NV_PGRAPH_PRI_CWD_SM_ID_SINGLETON_TPC可以提供从<虚拟GPC ID,可迁移TPC ID>到SM_ID的反向映射。在一个实施例中，虚拟GPC ID 0～7可以接收传统CTA和CGA，而虚拟GPC ID 8～23仅可以接收传统CTA和1-TPC大小的CGA。此外，CWD的唯一TPC(由<虚拟GPCID,可迁移TPC ID>表示)被转换成元组<逻辑GPC ID,虚拟TPC ID>，同时将TPC请求向上游发送到前端(FE)，如图23所示，用于通信回到主机CPU。

在一个实施例中，当CWD执行负载平衡时，虚拟GPC 8-23中的16个TPC优先于虚拟GPC 0-7。因此，对应于虚拟GPC 8-23的CSM被映射到低于GPC 0-7中的TPC的WD快照状态索引。WD快照状态的较低索引是更高优先级，因此单TPC CGA将偏好使用GPC 8-23并且为多TPC CGA保留GPC 0-7。换言之，CWD负载平衡算法将尝试将较小的CGA指派给可“适合”在那些单例模式上的单例模式，并且保留非单例模式虚拟GPC用于需要启动多于一个TPC的CGA。

多级统一工作分配器

图21B示出了在一个实施例中，CWD 420包括用于分发CGA工作的若干级别的工作分配器(WD)。例如，在GPU CGA由GPC CGA构成的情况下，CWD 420可以实现两级工作分配器：

·GPU2GPC工作分配器420a

·多个GPC2SM工作分配器420b(0)，420b(1)，420b(2)，...。

第一级420a跨GPC分配GPC CGA。第二级(GPC到SM工作分配器420b)将CTA分配到GPC内的SM。

在GPU到GPC级别之前或高于其的另一个级别可以用于将μGPU CGA分配给μGPU(在一个实施例中，当存在μGPU时，GPU由μGPU构成，μGPU由GPC构成，并且GPC由TPC或SM构成)。特别地，GPU2GPC WD 420a将GPU CGA的可能大量(1个或更多个)成分GPC CGA分配到相应的GPC2SM工作分配器(图21C-2，块506)。GPC2SM工作分配器420b各自将GPC CGA的CTA分配到GPC内的SM(使用例如负载平衡模式或多播模式，如下所述)。图21B的统一工作分配器(UWD)420a/420b保证GPU CGA中的所有GPC CGA可以一起启动，并且每个GPC CGA中的所有CTA可以一起启动。

在支持CGA的更深嵌套的其他实施例中，这个UWD可以被扩展到所需要的任何数量的级别。更详细地，在一个实施例中，CWD 420可包括或激活需要这种功能的CGA网格的分层三级统一工作分配器(UWD)：

·GPU2SM工作分配器(GPU2SM WD)处理CTA和由CTA组成的GPU CGA。

·GPU2GPC工作分配器(GPU2GPC WD)协调GPC CGA和由GPC CGA构成的GPU CGA的负载平衡。它会谈到最低级别的工作分配器-GPC2SM WD

·GPC2SM工作分配器(GPC2SM WD)处理GPC CGA的实际负载平衡。在UWD中存在N个GPC2SM WD，GPU中的每个虚拟GPC一个GPC2SM WD。

在一个实施例中，UWD因此知道每TPC层级的GPC，以便促进CGA的空间亲和性(例如，来自GPC CGA的所有CTA将在同一GPC上启动)。

如上所述，在GPU芯片测试时，每个个体GPU芯片被分类到特定产品SKU中并且然后被底层清除以禁用(在这种情况下永久地关闭)故障电路。这种底层清除涉及向芯片内的底层清除配置电路写入(参见图5B和例如US20150200020)。此外，CWD被编程为将其自身配置为用于芯片的特定底层清除天际线，包括多个单例模式以及可能生效的任何动态TPC禁用。

在一个示例实施例中，通过提供诸如以下的寄存器接口来简化CWD编程，该寄存器接口响应于用于动态(重新)配置的单个寄存器戳(poke)而提供自配置：

在一些实施例中，为了适应MIG，以两种配置构建CWD：具有8个GPC加上所有16个单例模式支撑的全CWD、以及具有4个GPC加上12个单例模式支撑的减小的CWD。

其他示例实现方式

以上实现方式使用“单例模式”TPC的概念——即，分配给其自己的专用虚拟GPC的TPC。然而，在其他实施例中，可能期望将这样的TPC组合成“双例模式(dualtons)”。在这样的变化中，两个TPC一起分配给每个虚拟GPC。在许多TPC被底层清除的产品SKU中，双例模式可能具有一些益处。双例模式可支持较大的CGA(例如，在一个实施例中，在基于单例模式的虚拟GPC的情况下，双例模式将支持GPC CGA内的CTA，所述GPC CGA跨四个SM而不是两个SM并发地运行。然而，组成双例模式的两个TPC需要能够彼此通信，从而它们支持分布式共享存储器、彼此之间进行消息传递等，并且因此可支持物理GPC可支持的全组功能。这也意味着可能存在一些TPC，这些TPC可以充当单例模式但是不能与另一TPC配对为双例模式，并且因此将需要在仅双例模式的实现方式中被底层清除。也可能提供一种混合实现方式，其支持双例模式和单例模式两者，以便以附加的CWD复杂性为代价来减少附加的必要底层清除。

尽管本文中的技术对于分类成共同的产品SKU(被设计成相同但由于制造缺陷而结果是不相同的一组芯片)特别有用，但该技术还可用于在被设计成具有不同功能和配置的芯片之间提供兼容性。

以上示例可以指代特定芯片配置，诸如8个GPC，每个GPC包括9个TPC，每个TPC包括2个SM，但是这种配置是非限制性的并且仅通过示例的方式呈现。不同的芯片可以具有不同数量的GPC、TPC和SM，和/或它们可以使用与GPC、TPC和SM不同地命名和构造的硬件分区和处理核。因此，本文中的技术不限于这种实现细节。

以上描述将GPU集成电路指示符称为“产品库存单位”或“产品SKU”。这种产品SKU的示例是发现印制或冲压在集成电路上的ASIC代码“XY102-300-A1”。在这种情况下，“XY102”例如可以指系列号(“Y”)和用于该代(例如，“102”)的项目的进度表。产品SKU的号码“300”部件可以指例如芯片的特征集、处理能力和/或其他技术规范。被冲压或以其他方式标记或指定用于不同产品SKU的芯片通常被客户认为是不同的技术产品。因此，与指定为“XY102-300-A1”的芯片相比，指定为“XY102-225-A1”的芯片可具有不同的规范/处理能力。除非另有具体说明，否则本文中的技术不限于本领域的技术人员可用术语“产品SKU”而可以扩展到例如任何名称或称呼，诸如型号、特征描述符、对处理规范的引用、或结合芯片、其封装、或其被或将被并入的产品使用的任何组合的其他指定符，用于供应/订购、仓储或其他目的，这些目的反映或定义就芯片的技术能力、功能、特征集、规范、兼容性或其他技术方面或特性而言的预期。

出于所有目的，本文所引用的所有专利、专利申请和出版物均通过引用结合在此，如同明确阐明一样。

虽然已经结合目前被认为是最实际和优选的实施例描述了本发明，但应理解的是，本发明并不限于所公开的实施例，而是相反，本发明旨在覆盖包括在所附权利要求的精神和范围内的各种修改和等效布置。

Claims (20)

1.一种在集成电路之间灵活地迁移软件的方法，包括：

挂起多线程软件进程在第一集成电路上的执行；

保存所述第一集成电路的上下文；

在第二集成电路上恢复所述上下文，所述第二集成电路与所述第一集成电路具有不同的每处理器集群配置文件的处理器；以及

重新开始所述多线程软件进程在所述第二集成电路上的执行。

2.根据权利要求1所述的方法，其中重新开始执行包括：重新开始在所述第二集成电路的与之前在所述第一集成电路上一直执行所述软件进程的处理器相比不同数量的处理器上的执行。

3.根据权利要求2所述的方法，其中基于每处理器实施挂起和重新开始。

4.根据权利要求1所述的方法，其中挂起和重新开始包括将执行第一单例模式迁移到执行第二单例模式。

5.根据权利要求4所述的方法，其中所述第一单例模式和所述第二单例模式具有不同的物理和/或逻辑标识符。

6.根据权利要求1所述的方法，其中基于每处理器实施保存和恢复。

7.根据权利要求6所述的方法，其中所述保存和恢复保留虚拟处理器标识符。

8.根据权利要求7所述的方法，还包括：保存和恢复GPC状态信息。

9.根据权利要求6所述的方法，还包括：当重新开始执行包括重新开始在所述第二集成电路上的比在所述第一集成电路上挂起的更多处理器上的执行时，合成每处理器状态信息。

10.根据权利要求1所述的方法，其中在第一数量的GPC上实施挂起执行，并且在不同于所述第一数量的GPC的第二数量的GPC上实施重新开始执行。

11.根据权利要求1所述的方法，还包括：通过维持对所述第二集成电路上的处理器的状态更新但不将任何工作发送到所述第二集成电路上的处理器，来动态地禁用所述第二集成电路上的处理器。

12.一种集成电路，包括：

N个处理器；

工作分配器电路，其可操作地耦合至所述N个处理器，所述工作分配器被配置为重新开始挂起的处理以从不同的集成电路迁移工作；以及

电路，其被配置为取决于所述不同的集成电路上的实施所述工作的处理器的数量是N、大于N还是小于N而恢复状态信息、跳过恢复状态信息或合成状态信息。

13.根据权利要求12所述的集成电路，其中针对所选择的处理器，所述电路不跳过恢复状态信息或合成状态信息。

14.根据权利要求12所述的集成电路，还包括屏障表，所述屏障表被配置为跟踪每处理器块中的能够独立于彼此而被保存和恢复的计算工作。

15.根据权利要求14所述的集成电路，其中利用处理器ID和提供内部管线寄存器和存储器状态到上下文状态存储的基于环的复制的子类中的至少一个来标记所述每处理器块。

16.根据权利要求14所述的集成电路，其中所述每处理器块被指定为单例模式或非单例模式。

17.根据权利要求14所述的集成电路，其中所述每处理器块用虚拟GPC标识符来指定。

18.一种集成电路，包括：

多个处理器；以及

工作分配器电路，其可操作地耦合至所述多个处理器，所述工作分配器电路被配置为动态地、暂时地排除所述多个处理器中的所选择的处理器接收迁移的工作，以便维持实施所述工作的恒定数量的处理器，而无需实施所述多个处理器中的任何处理器的硬件复位。

19.根据权利要求18所述的集成电路，其中选择性地排除是对所述多个处理器中的一些处理器实施的，而所述多个处理器中的其他处理器继续执行工作。

20.根据权利要求18所述的集成电路，其中所述工作分配器电路利用每硬件集群的改变的数量的处理器来实现迁移。