CN116348849A - 呼吸操作数窗口以利用图形处理单元中的旁路 - Google Patents

Abstract

处理单元(例如，图形处理单元(GPU))的寄存器文件架构包括处理流水线和操作数收集器组织，处理流水线和操作数收集器组织在架构上配置为支持旁路寄存器文件访问，并且替代地在同一指令窗口内的指令之间直接传递值。处理单元包括或利用寄存器文件(RF)。处理流水线和操作数收集器组织在架构上配置为利用来自寄存器文件(RF)的寄存器访问的时间局部性，以改善寄存器文件的访问延迟和功率消耗。

Description

呼吸操作数窗口以利用图形处理单元中的旁路

技术领域

本文中描述的各种实施方式大体上涉及计算平台，并且尤其涉及经改善的寄存器文件(RF)架构(例如，GPU处理流水线(pipeline)和操作数收集器组织的架构)，其在架构上配置为利用寄存器访问寄存器文件(RF)的时间局部性来旁路寄存器文件访问并且促进对RF的访问延迟和/或功率消耗的改善。

背景技术

图形处理单元(GPU)已经出现作为用于大量应用领域中的数据密集型应用的重要计算平台。它们通常集成在所有规模的计算平台中，从移动设备和嵌入式系统到高性能企业级云服务器。图形处理单元使用大量多线程架构，该多线程架构利用执行线程组之间的细粒度切换来隐藏数据访问的延迟。

图形处理单元一直在增加能量使用，因此它是可以实现的最大计算能力的重要限制。任何系统的峰值性能基本上受到其可以消耗的功率量和其可以耗散的热量的限制。因此，GPU设计的每瓦特性能直接转化为使用该设计的系统的峰值性能。

为了支持线程之间的快速上下文切换，GPU投资于大寄存器文件(RF)以允许每个线程始终维持其上下文(在硬件中)。寄存器文件(RF)是GPU中的关键结构，并且其组织或架构实质上影响GPU的整体性能和能量效率。作为示例，从2008年至2018年，几代NVIDIAGPU的寄存器文件的大小已经从特斯拉(Tesla)(2008)到Volta(2018)增加了几乎十倍到20MB，使得它成为更关键和重要的组件。

指令通常从寄存器文件数据结构得到/读取/获得其输入数据(称为源操作数)。为了检索每个源操作数的值，当前GPU需要对寄存器文件进行一个单独的读访问，这对寄存器文件端口施加不必要的压力。

能够提供改善的RF架构(例如，GPU中的改善的RF)将是有帮助的。

能够提供便于对寄存器文件的访问延迟和/或功耗进行改善的RF架构将是有帮助的。

附图说明

图1是示出用于提供或改善图形处理单元(GPU)的寄存器文件架构的示例方法100的流程图。

图2A示出GPU架构200的示例性实施方式，呼吸操作数窗口(Breathing OperandWindows(BOW))，其在架构上配置为仅克服冗余读取，在本文中也被称为BOW-R。BOCX是分配给翘曲(Warp)X的旁路操作数收集器(Bypassing Operand Collector)。

图2B示出与具有转发逻辑支持(右)的较宽旁路操作数收集器(BOC)单元250相比的基线操作数收集器单元(左)。

图2C示出GPU架构300的另一个示例实施方式，GPU架构300提供处理流水线和操作数收集器组织，本文中称为BOW-WR，在架构上配置为克服冗余写入和读取。

图3是代码片段的示例，其示出诸如本文中描述的架构(例如，BOW-R和BOW-WR)中的旁路操作(连同编译器支持)。

图4是示出与使用不同指令窗口的基线BOW-R相比，由BOW-WR实现的每周期指令(IPC)改善的条形图。

图5是示出BOW-WR的寄存器文件(RF)动态能量归一化到基线的条形图。

具体实施方式

在内核执行期间，对寄存器文件结构的频繁访问导致GPU功耗中的相当大的开销，并且在发生端口冲突时当访问被串行化时引入延迟。例如，端口冲突(在寄存器文件存储体中以及在收集寄存器操作数的操作数收集器单元中)在发布指令时引起延迟，因为寄存器值被读取以准备执行。

我们已经观察到，在对寄存器的访问中存在高度的时间局部性：在短指令窗口内，经常重复地访问相同的寄存器。在连续指令的短窗口中经常多次访问寄存器，因为值被增量计算或更新并且随后使用。

本文中描述的示例性实施方式和实现方式涉及新的GPU架构(技术)，旁路操作数收集器(Breathing Operand Windows(BOW))，其利用寄存器访问的时间局部性来改善寄存器文件的访问延迟和功耗。BOW架构可以例如以GPU处理流水线和操作数收集器组织(例如，如本文所述)的形式或利用GPU处理流水线和操作数收集器组织(例如，如本文所述)来实施。

减少寄存器访问的机会被表征为(或可以被表征为)根据所考虑的指令窗口的大小，并且寄存器操作数(例如，在GPU计算中)的循环读取和更新可以被建立/识别并且用于提供支持旁路寄存器文件访问并且替代地直接在同一指令窗口内的指令之间传递值的增强型GPU处理流水线和操作数收集器组织。结果，寄存器读取和寄存器写入访问的大部分可以通过直接从一个指令转发到下一指令而旁路寄存器文件。这种操作数旁路通过消除来自RF的寄存器访问(读取和写入两者)而减少了动态访问能量，并且通过减少对寄存器文件存储体的端口争用和其它访问延迟而改善了总体性能。在其它实施方式和实现方式中，通过消除仅用于(仅旁路)寄存器读取的寄存器访问来部署操作数旁路。可以利用编译器优化来帮助引导操作数的写回目的地，这取决于它们是否将被重用来进一步减少写业务量。

我们已经观察到，寄存器经常在指令的短窗口中被多次访问，因为值被增量计算或更新并且随后被使用。结果，寄存器读取和寄存器写入访问的大部分可以旁路寄存器文件，并且替代地操作数直接从一个指令转发到下一指令。这种操作数旁路通过从RF中消除寄存器访问(在一些实现方式中，包括读取和写入)而减少动态访问能量，并且通过减少对寄存器文件存储体的端口争用和其它访问延迟而改善总体性能。

在GPU执行模型中，内核是通常从CPU(或如果支持动态并行，则直接从另一内核)发布的工作单元。内核是GPU应用功能，由编程器编译器分解成块网格，每个块映射到应用到通常并行的大数据的相应部分的计算的部分。具体而言，内核被分解为线程块(TB，也称为协作线程阵列或CTA)，其中每个线程块被分配来处理数据的部分。然后将这些TB映射到流式传多处理器(SM)以供执行。然后将在SM上执行的线程一起分组为线程组(NVIDIA术语中的翘曲(warp)，或AMD术语中的波阵面)，以便调度它们的发布和执行。选择和发布翘曲指令以供SM中的翘曲调度器(通常是2个或4个调度器，取决于GPU的生成)执行。分配给相同的翘曲调度器的翘曲竞争该调度器的发布带宽。

翘曲中的所有线程以锁步方式(单指令多线程，或SIMT模型)执行指令。大多数GPU指令使用寄存器作为其源操作数和/或目的操作数。因此，指令将访问寄存器文件(RF)以加载用于其所有线程的源操作数，并且将在执行之后将任何目的地操作数写回RF。每个SM中的RF通常被组织成多个单端口寄存器存储体，以便支持大的存储器带宽，而不需要大的多端口结构的成本和复杂性。分组的设计允许多个并发操作，只要它们针对不同的存储体。当多个操作目标在同一存储体中注册时，存储体冲突发生并且操作被串行化，从而影响整体性能。

BOW重新架构GPU执行流水线以利用操作数旁路机会。具体地，在基线设计中，我们考虑在指令窗口内重用的操作数：增加旁路机会的关键是仔细选择指令窗口大小以捕获寄存器时间重用机会，同时保持可接受的转发开销。为了便于旁路，操作数收集器专用于每个翘曲，使得它可以在专用于每个翘曲的简单高性能缓冲结构中保持用于该翘曲的活动寄存器的集合。每当指令需要寄存器操作数时，BOW首先检查操作数是否已被缓冲，使得它可以直接使用它，而无需从RF存储体加载它。如果操作数不存在于操作数收集器单元中，则将产生对RF的读取请求，该请求被发送到仲裁器单元。在基线BOW中，在指令完成执行之后，所计算的结果被写回操作数收集器单元以及寄存器文件(即，透写(write through)配置)。这种组织支持操作数读取的重用，并且避免了当操作数收集器从窗口中滑出时需要额外路径以启用将值从操作数收集器写回RF。基于我们的实验和观察，具有3个指令的窗口大小的BOW在我们所有的基准上将物理寄存器读取访问减少59％。在示例实施方式/实现方式中，窗口大小是固定的，并且在设计中被定义。考虑开销来确定/选择窗口大小，并且可以从诸如例如2到7个指令的窗口大小范围中选择窗口大小。然而，对于每次写入仍被写入到RF的实现，不支持写入旁路。

为了能够利用写入旁路的机会，并且参考图2C(其示出提供处理流水线和操作数收集器组织的GPU架构，该处理流水线和操作数收集器组织在架构上配置为克服冗余写入和读取)，我们引入了BOW-WR，这是一种改善的设计，其使用写回原理来克服BOW中存在的冗余写入。具体地，改善的设计仅将任何更新的寄存器值写回操作数收集器。当指令滑出当前窗口外部时，只有当它没有被窗口中的后续指令再次更新时(在这种情况下，由于更新是瞬时的，第一次写入已经被旁路)，它的更新的寄存器值才被写回RF。如上所述，BOW-WR将RF与写业务量的一些屏蔽开，但不捕获所有写入旁路机会，并且保持一些冗余和低效的写入行为。考虑以下两种情况：

(1)不必要的操作数收集器(OC)写入：当值将不再被重用时，首先将其写入OC，并且然后写入RF，导致冗余更新。替代地，这样的值被直接写入到RF。

(2)不必要的RF写入：当更新的寄存器值不再是活动的(即，在它被更新之前它将不会被再次读取)时，当指令滑出活动窗口时，它将不必要地被写回RF。在这种情况下，优选不将该值写回RF。

直接在架构中捕获这些机会中的任一个取决于程序的后续行为。因此，为了利用在BOW-WR中消除这些冗余写回的机会，编译器配置和任务化以执行活性分析(livenessanalysis)，并且将每个目的地寄存器分类为这三个组之一：那些将只被写回寄存器文件存储体的组(以处理上面的情况1)；将只被写回操作数收集器的操作数(处理情况2)；并且最后，首先需要驻留在操作数收集器中的操作数，并且然后由于它们更长的使用期，需要被写回寄存器文件存储体以供以后使用(这是编译器提示之前的BOW-WR的默认行为)。通过使用指令中的两个比特对每个指令的写回策略进行编码，这些编译器提示被传递到该架构。这种编译器优化不仅使对寄存器文件的写入访问量基本上最小化并且解决冗余写回问题，而且由于寄存器操作数的重要部分是瞬时的，因此减小了寄存器文件的有效大小，在指令窗口外部不需要(52％，窗口大小为3)：因此，对于这样的值，完全避免了在RF中分配寄存器。

关于实现方式，基线BOW(和BOW-WR)所引起的主要成本是增加操作数收集器的数目(使得每个翘曲有一个专用的)以及每个操作数收集器的大小的成本，以使其能够在窗口中保持寄存器值活动。关于每个操作数收集器(OC)的大小，基线设计将附加条目添加到每个操作数收集器以将操作数保持在活动窗口内(窗口中每个指令4个寄存器)。在基线设计中，这在所有OC上对于窗口大小为3增加了大约36KB的临时存储，这是重要的(但仍然仅是现代GPU的RF大小的大约14％)。为了减少这种开销，我们通过实验观察到，这种最坏情况的大小基本上超过了旁路缓冲器的平均有效占用。因此，我们为BOW-WR提供了更小的缓冲结构。然而，由于在最坏的情况下可以超过可用的缓冲，我们已经重新设计(架构配置)OC，以便在必要时允许值的逐出。另外，窗口大小被限制为预定的固定窗口大小，并且即使在缓冲结构中有足够的缓冲空间，指令也不会被旁路超出窗口大小。这种选择的原因是便于编译器分析，并且考虑可用的缓冲区大小，在编译器中正确地标记BOW-WR中的写回目标。在没有这种简化假设的情况下，如果其在所有重复使用发生之前被逐出，则可能需要保存由编译器标记的不写回RF的条目。因此，我们能够以小于2％的性能降低将存储大小降低50％。考虑到其它开销(诸如修改的互连)，BOW需要增加总芯片上面积的0.17％的面积。

呼吸操作数窗口

在本节中，我们概述了BOW-WR的设计，并且介绍和讨论了一些编译器和微架构的优化，以改善重用的机会以及减少开销。BOW包括三个主要组件(或由三个主要组件组成)：(1)旁路操作器收集器(BOC)，其增加有用于活动寄存器操作数的存储器，以启用指令之间的旁路。每个BOC可以专用于单个翘曲，这简化了缓冲空间管理，因为每个缓冲器仅由单个翘曲访问。BOC的大小由指令窗口大小确定，在该指令窗口大小内可以旁路；(2)修改的操作数收集器逻辑，其考虑可用的寄存器操作数并且旁路可用的操作数的寄存器读取(而基线操作数收集器从RF提取所有操作数)，例如嵌入BOC中的逻辑，其可以将值从一个指令“转发”到另一个指令；以及(3)修改的写回路径和逻辑，其启用由执行单元产生或从存储器加载到BOC(以启用将来的数据从一个指令转发到另一个指令)以及加载到基线设计中的寄存器文件的引导值(用于在当前活动窗口之外进一步使用)。在改善的BOW-WR中，利用编译器辅助提示进一步优化写回逻辑。

A.BOW架构概述

图2A和图2B提供了本文中描述的BOW架构的概略概述，并且突出了架构的主要改变和添加。设计以新的操作数收集器单元添加为中心，称为旁路操作数收集器(BOC)250(与本文中的示例实施方式有关)，其允许GPU旁路RF访问。在图2A中，每个BOC被分配给单个翘曲(BOC0至BOC31)。虽然基线架构中的操作数收集器具有三个条目以保持单个指令的源操作数的数据(图2B，左)，但是BOW加宽操作数收集器以启用存储源寄存器值和目的地寄存器值，用于后续指令的使用(图2B，右)。另外，BOC 250中的转发逻辑260在架构上配置为检查所请求的操作数是否已在BOC中，因此将被发送到下一指令。类似于基线架构，并且为了避免使互连网络更复杂，BOC(每个)可以具有单个端口以接收来自寄存器文件存储体的操作数。然而，BOC内的转发逻辑在架构上配置为在发布指令时允许转发在转发缓冲器中可用的多个操作数。在基线设计中，我们保守地保留BOC中每个指令的四个条目以匹配操作数的最大可能数目，该操作数是三个源操作数加上一个目的地。很少需要这种保守大小，这允许为BOC提供基本上较小的存储。

当指令窗口在指令中滑动时，用于相同翘曲的指令以程序顺序被调度到所分配的BOC。当在窗口末端的指令x被插入到BOC 250中时，转发逻辑260检查指令x所需的操作数中的任一个是否在当前窗口中已经可用，然后从窗口中逐出最老的指令(当前窗口中的第一指令)及其操作数，以便为下一个指令留出空间，当窗口移动时，该下一个指令将变得可用。重要的是要注意，指令窗口是滑动的；每次操作数被指令使用时，其对于其后的窗口大小指令保持活动。如果在此窗口中再次访问它，则它在BOC中的存在在我们所称的扩展指令窗口中扩展。在分支发散的情况下，BOC等待直到确定下一指令为止。来自不同BOC的指令以循环方式被发布到执行单元。一旦指令的所有源操作数准备就绪(其可能已经在活动窗口内直接转发并且不向寄存器文件发送读取请求)，则指令被分派并且被发送到执行单元。当指令的执行结束时，其计算结果被写回所分配的BOC(稍后由窗口中的下一指令使用)。在基线BOW中，该值也被写回寄存器文件(如果有潜在的稍后使用，则通过当前窗口之外的指令使用)。这里注意到，到目前为止，在我们的设计中只增加了从执行单元到BOC的路径，因为从执行单元到寄存器文件的路径已经在基线架构中建立。虽然这种透写策略使复杂性最小化，但是它遭受大量冗余的写回(到BOC以及寄存器文件)，这是在BOW-WR中解决的低效率。

请注意，在其之间存在RAW(写后读取)或WAW(写后写入)依赖关系的两个依赖指令永远不能在同一BOC内的准备发布指令之中。记分板逻辑在向操作数收集级发布指令之前检查这些种类的依赖性(这实际上是在翘曲调度器调度指令时完成的)。在BOC中的一个具有指令意指它已经通过了依赖性检查，并且其寄存器操作数存在于BOC或寄存器文件中。对于独立的指令，不存在旁路的延迟：两者都可以开始执行，并且甚至无序完成。

BOW-WR：编译器引导写回

BOW利用读取旁路机会，但不能旁路任何可能的写入操作，因为为了简单起见，每个计算的值不仅被写入RF，而且被写入BOC，遵循透写策略。然而，写入旁路的机会是重要的：经常在单个窗口内重复更新值。例如，考虑$r1由图3的行4、行5和行6中的指令更新；它只需要在最后写入之后在RF中被更新。

BOW-WR方法使用写回原理旁路，以实现写入旁路。在最简单的情况下，它总是将计算结果写入BOC，以提供读取旁路和写入旁路的机会。当更新的操作数滑出当前活动窗口时，转发逻辑检查它是否已经被活动窗口内的后续指令再次更新。如果是，则将旁路写入操作，从而允许在相同的指令窗口内进行多次写入的合并。在我们的前面的示例(图3)中，当指令4和指令5滑出活动窗口时，它们更新的$r1被丢弃，因为在每种情况下，$r1在窗口内再次被更新。当指令6滑出时，该值被写回(因为指令7和指令8都不更新$r1)。BOW-WR(写回而不是透写)的主要成本是需要建立从BOC到RF的新路径。

虽然使用写回原理显着地减少了对寄存器文件的冗余写入量(下面的表I)，但是它不能旁路所有这样的写入操作；在许多情况下，当操作数滑出活动窗口时，它从BOC被写回寄存器文件，而实际上它不会被稍后的指令再次使用(操作数不再是活动的)。由于所计算的操作数总是被写回BOC，所以出现了另一个低效的源；如果在活动窗口中不再需要这些操作数，则它们可以被直接写入RF，从而消除对BOC的写入。

本文中的实施方式可以被认为是GPU的(文件寄存器)微架构或提供GPU的(文件寄存器)微架构：若干级的微架构，即(或包括)RF和执行单元(其是RF之后的下一级)。在前面段落中的任何一种情况下，微架构都不具有足够的信息来识别写回的最佳目标，因为它取决于程序的未来行为，该程序的未来行为在作出写回决定的点处通常是不可见的，从而导致冗余写入。在示例实施方式/实现方式中，为了便于消除这些冗余写入，编译器用于分析程序和指导写回目标选择。程序是运行在GPU上的内核(在设备上运行的函数)。作为示例，编译器(例如，在NVIDIA GPU的情况下的Nvidia Cuda编译器(NVCC))配置和分配以执行活性分析和依赖性检查，以确定来自指令的输出数据是否应该仅被写回寄存器文件存储体(当它将不在指令窗口中被再次使用时)、仅被写回旁路操作数收集器(对于将在窗口中被完全消耗并且在其之后不再存在的瞬时值)、或两者(这是没有编译器提示的默认行为)。活性分析检查值的使用期(如果后续指令将使用该值，则该值是活动的。另一方面，该值在上次被读取的点之后是死的)。当我们避免将值写回RF时，我们降低了RF上的压力并且避免了对于仍然在使用的操作数的不必要的写入的成本。类似地，当我们将数据写入将不被使用的BOC时，我们支付了这种写入的额外成本，只为稍后必须将该值再次保存到RF。令人感兴趣的机会还出现在窗口内完全产生和消耗的瞬时值不再需要被分配RF中的寄存器。我们已经发现，许多操作数是瞬时的，这导致了减小有效RF大小的实质机会。编译器引导的优化产生了避免不必要的写入和最小化能量使用的益处。表I示出在不同版本的BOW中对图3中的代码的RF的所需写入访问次数(注意，BOW透写与未修改的GPU相同)。

表I：图3中所示的用于代码片段的寄存器文件的写入操作的数目。突出显示的结果：

性能：图4显示了使用不同的指令窗口，通过BOW-WR与基线相比实现的归一化的每周期指令(IPC)改善。作为旁路大量的读取和写入操作的结果，端口争用降低(在寄存器文件存储体以及BOC上)，导致更好的性能。值得注意的是，我们观察到了所有基准的IPC改善。平均而言，BOW-WR有三个指令窗口，能使IPC提高13％。

RF能量：图5示出对于BOW-WR归一化到基线GPU的RF的动态能量。在每个条形图的顶部上的小段代表由上述设计增加的结构的开销。图5中的动态能量节省是由于减少了对寄存器文件的访问次数，因为BOW-WR屏蔽了RF免受不必要的读取和写入操作。具体地，在考虑到开销增加1.8％之后，具有3个指令的窗口大小的BOW-WR将RF动态能量消耗减少55％。

因此，参照图1，在示例性实施方式中，用于提供或改善处理单元(例如，图形处理单元(GPU)的)的寄存器文件架构的方法100包括：在102处，根据所考虑的指令窗口的大小，表征(或识别)减少来自处理单元的寄存器文件(RF)的寄存器访问的机会，以及建立(或识别)由处理单元执行的(一组)计算的寄存器操作数的循环读取和更新；并且，在104处，利用所表征的机会和所建立的循环读取和更新来向处理单元提供处理流水线和操作数收集器组织，该处理流水线和操作数收集器组织在架构上配置为支持旁路寄存器文件访问，并且替代地在同一指令窗口内的指令之间直接传递值。例如，处理单元是(或包括)图形处理单元(GPU)。在示例(例如，基线)实施方式/实现方式中，处理流水线和操作数收集器组织在架构上配置为支持旁路寄存器文件访问，仅用于从RF读取。在其它示例实施方式/实现方式中，处理流水线和操作数收集器组织在架构上配置为支持旁路寄存器文件访问，用于从RF读取和写入到RF两者。因此，在示例实施方式/实现方式中，方法100还包括，在106处，利用处理流水线和操作数收集器组织来支持：旁路寄存器文件访问，仅用于从RF读取；或旁路寄存器文件访问，用于从RF读取和写入到RF两者。在其他示例实施方式/实现方式中，方法100还包括，在108处，利用编译器优化，包括(目的地)寄存器的活性分析和分类，以：基本上最小化对寄存器文件的写入访问量，消除冗余写回，以及通过避免将RF中的寄存器分配给瞬时寄存器操作数，减小寄存器文件的有效大小。

为了结束这个部分，我们已经观察到寄存器值在GPU工作负载中非常接近地被重复使用。我们在本文中描述了独特地利用这种行为在附近指令之间直接转发数据的技术和方法，从而屏蔽了高能耗的和端口受限的寄存器文件的许多访问(具有指令窗口大小为3的59％的访问)。本文中描述的BOW-WR设计具有旁路读取和写入操作数的能力，并且利用编译器提示来最优地选择写回操作数目标。此外，对于编译器提示，它们编码成指令的比特在编译时发生。通常，首先用编译器编译程序。(输入到编译器是程序，例如kernel.cu，并且编译过程的输出是可以在GPU上执行的可执行二进制)。在编译过程期间，任务编译器进行活性分析，并且将定义值将被写入(到BOC、寄存器文件或两者)的位置的信息(即编译器提示)被注入或被编码到可执行二进制中。BOW-WR将RF动态能量消耗降低55％，同时将性能提高11％，额外存储具有12KB的适度开销(RF大小的4％)。

虽然本文中已经描述了示例性实施方式，但是，显然，对于本领域技术人员来说，在获得本文中描述的主题的一些或全部优点的情况下，可以对这些实施方式进行各种修改、更改和改变。因此，所公开的实施方式旨在包括所有这样的修改、更改和改变，而不脱离如本文中所描述的技术和方法的范围和精神。

Claims (18)

1.一种图形处理单元(GPU)的寄存器文件架构，包括：

具有寄存器文件(RF)的处理流水线和操作数收集器组织，所述处理流水线和所述操作数收集器组织在架构上配置为支持旁路寄存器文件访问，并且替代地在指令窗口内的指令之间直接传递值。

2.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为利用来自所述RF的寄存器访问的时间局部性，以改善所述RF的访问延迟和功率消耗。

3.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为根据所考虑的指令窗口的大小，以减少来自所述RF的寄存器访问。

4.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为利用由所述GPU执行的计算的寄存器操作数的循环读取和更新的缓冲值，以消除来自所述寄存器文件的冗余访问。

5.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为消除冗余写回。

6.如权利要求1所述的寄存器文件架构，其中，所述操作数收集器进一步在架构上配置为仅将任何更新的寄存器值写回到所述操作数收集器。

7.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为考虑在指令窗口内重新使用的操作数，以支持旁路寄存器文件访问，并且替代地在所述指令窗口内的指令之间直接传递值。

8.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为利用高的时间操作数重用，以旁路必须对所述寄存器文件的读取及写入重用的操作数。

9.如权利要求1所述的寄存器文件架构，其中，所述处理流水线包括旁路操作器收集器(BOC)，所述旁路操作器收集器增加有用于活动寄存器操作数的存储器，以启用指令之间的旁路以及控制所述旁路的逻辑。

10.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织包括操作数收集器逻辑，所述操作数收集器逻辑在架构上配置为考虑可用的寄存器操作数并且旁路可用的操作数的寄存器读取。

11.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织包括执行单元、旁路操作数收集器(BOC)和写回路径和逻辑，所述写回路径和逻辑在架构上配置为启用由所述执行单元产生或从存储器加载到所述BOC的引导值，以启用将来的数据从一个指令转发到另一个指令。

12.如权利要求1所述的寄存器文件架构，其中，所述指令窗口具有包括多个指令的指令窗口大小。

13.如权利要求1所述的寄存器文件架构，其中，所述处理流水线和所述操作数收集器组织在架构上配置为利用在接收到的指令中编码的编译器提示以控制值将被写入的位置。

14.一种用于提供或改善图形处理单元(GPU)的寄存器文件架构的方法，所述方法包括：

根据所考虑的指令窗口的大小，表征减少来自图形处理单元(GPU)的寄存器文件(RF)的寄存器访问的机会，并且建立由所述GPU执行的计算的寄存器操作数的循环读取和更新；以及

利用所表征的机会和所建立的循环读取和更新，以向所述处理单元提供处理流水线和操作数收集器组织，所述处理流水线和所述操作数收集器组织在架构上配置为支持旁路寄存器文件访问，并且替代地在指令窗口内的指令之间直接传递值。

15.如权利要求14所述的用于提供或改善寄存器文件架构的方法，其中，所述处理流水线和所述操作数收集器组织在架构上配置为支持旁路寄存器文件访问，仅用于从所述RF读取。

16.如权利要求14所述的用于提供或改善寄存器文件架构的方法，其中，所述处理流水线和所述操作数收集器组织在架构上配置为支持旁路寄存器文件访问，用于从所述RF读取和写入到所述RF两者。

17.如权利要求14所述的用于提供或改善寄存器文件架构的方法，还包括：

利用编译器优化，包括寄存器的活性分析和分类，从而：

基本上最小化对所述寄存器文件的写入访问量，消除冗余写回；以及

通过避免将所述RF中的寄存器分配给瞬时寄存器操作数，减小所述寄存器文件的有效大小。

18.一种图形处理单元(GPU)，包括：

微架构，包括寄存器文件(RF)和具有处理流水线和操作数收集器组织的相关联逻辑，所述处理流水线和所述操作数收集器组织在架构上配置为支持旁路寄存器文件访问，并且替代地在指令窗口内的指令之间直接传递值。

Images