基于存储器的旗语的制作方法
【专利说明】基于存储器的旗语
[0001] 领域
[0002] 本公开内容涉及在不同的处理引擎之间同步操作的领域，且尤其涉及使用旗语 (semaphore)和存储器寄存器的信令。
[0003] 背景
[0004] 开发了允许在GPU (图形处理单元）中执行通用操作的计算技术。GPU具有为图形 处理优化的大量简单并行处理管线。通过把要求许多相似的或相同的并行计算的通用操作 移植到GPU，可以比在CPU (中央处理单元）上更快地执行这些操作，同时减少了对CPU的处 理需求。这可以在提高性能的同时减少功耗。
[0005] GPU具有为执行不同的功能而优化的若干不同处理引擎。这些引擎可以包括： blitter(位图映射）引擎、渲染引擎、视频解码引擎、视频编码引擎和视频增强引擎，以及 其他。每一引擎处理在由分离的调度处理器调度的上下文内的命令。调度处理器把各上下 文指派给每一引擎，并且管理与每一上下文相关联的命令流的执行。
[0006] 然而，GPU的处理引擎、命令缓冲器和命令流化器必须协调中间值和命令在不同的 引擎之间的传输。当一个引擎正在产生将在由另一引擎执行的命令中使用的值时，必须使 用某种机制来确保该值已经准备好可供消费者使用。在各引擎之间的协调可以消耗显著资 源，那么这些资源就不能用来执行命令。
[0007] 附图简述
[0008] 作为示例而非限制在附图的各图中阐释本发明的各实施例，附图中，相同标号表 示相似的元素。
[0009] 图1是根据本发明的一种实施例带有命令流化器和信号的图形处理单元的一部 分的框图。
[0010] 图2A是根据本发明的一种实施例使用断言允许位执行批缓冲器的处理流程图。
[0011] 图2B是根据本发明的一种实施例刷新断言寄存器中的值的处理流程图。
[0012]图3是根据本发明的一种实施例带有断言允许位寄存器的运算逻辑单元的硬件 逻辑图。
[0013] 图4是适于与本发明的一种实施例一起使用的图形处理单元的一部分的框图。
[0014]图5是适于与本发明的一种实施例一起使用的计算机系统的框图。
[0015] 详细描述
[0016] 本发明涉及例如在图形渲染电路中使用基于存储器的信令来在存储器访问的生 产者/消费者模型的引擎之间同步。可以在软件调度模式中使用基于存储器的旗语，代替 基于寄存器的旗语，用于在多个引擎和宿主CPU(中央处理单元）上运行的多个上下文之间 通信。多个引擎可以包括：blitter引擎、渲染引擎、视频解码引擎、视频编码引擎和视频增 强引擎，以及其他。
[0017] 旗语可以用来在数据消费者和数据生产者之间传输不同类型的信息。旗语可以包 含地址、参数和值。旗语命令可以被用来使用旗语。在生产者/消费者模型中，旗语数据可 以被存储在存储器中。为了减少存储器访问延迟时间，可以使用智能方式来确定何时及如 何从存储器采样旗语数据。
[0018] 通过包括旗语故障时的上下文切换策略，可以增强旗语的使用。也可以向软件提 供可编程性接口。除了软件辅助之外，可以向调度器软件提供硬件辅助，以便做出对由于旗 语故障而被切换掉的上下文的有效重新调度的判决。
[0019] 当在旗语等待不成功之际切换掉上下文时，可以在PPHWSP (per process hardware status page，每进程硬件状态页面）或类似的存储器空间中更新旗语等待命令。 PPHWSP是图形存储器中被指派给具体上下文的暂存空间。每一上下文可以具有其自己的 PPHWSP，或者，暂存空间可以由多于一个的上下文共享。这种暂存空间可以用作在硬件和软 件之间的通信装置，且可以被硬件和软件用作临时存储。在重新调度由于旗语等待而被切 换掉的上下文之前，调度器可以读取PPHWSP，以便在把等待条件提交给硬件之前重新评估 等待条件。这允许调度器改善硬件利用率且在重新提交期间避免不必要的上下文切换。
[0020] 如下面更详细地描述的，存储器位置中的数据可以被用作用于在上下文之间通信 以便同步的邮箱。在此提及的同步可以涉及第二上下文等待第一上下文以便在第二上下文 开始执行之前清除第一上下文的依赖性。例如在典型的生产者/消费者模型中，在消费者 开始进行之前，消费者等待生产者发送完成信号。使用例如下面所描述的MI_SEMAPH0RE_ SIGNAL (MI_旗语_信号）命令和MI_SEMAPHORE_WAIT (MI_旗语_等待）命令，可以实现这 种同步。
[0021] 下面的示例使用上下文来管理对硬件资源的操作。可以给每一上下文指派唯一 ID (标识），贯穿上下文的寿命，通过该唯一 ID标识上下文。也把上下文指派给该上下文将 在其上运行的引擎，该引擎是上下文将使用的硬件资源。指派可以基于上下文开始时的工 作量类型或基于上下文的任何唯一要求。可以固定上下文ID和指派，以使得在首次指派它 之后两者都不改变。
[0022] 图1是图形处理单元（GPU) 10的通用框图。在这一示例中，GPU包括五个引擎，即 渲染引擎16、blitter引擎18、视频编码引擎20、视频解码引擎22和视频增强引擎24。每 一引擎被连接到其自己的命令流化器（command streamer :CS) 13、17、19、21、23。各引擎也 可以拥有到存储器和其他资源（未示出）的其他连接。每一命令流化器20包括等待模块 14、信号接口 15和存储器接口。存储器接口连接到内部或外部共享存储器，例如图5的存 储器525。在这些命令流化器之间进行用于旗语信令的通信。命令流化器都耦合到消息信 道12,且消息信道耦合到调度器控制器（SHM) 11。调度器控制器在此备选地称为调度器、 控制器、微处理器和SHM。取决于特定实现，调度器控制器可以采用这些形式或其他形式中 的任何一种。
[0023] 正如所示出的，从生产者（在所阐释的示例中是blitter引擎）通过其 blitterCS17把旗语信号32发送给消费者引擎（在所阐释的示例中是渲染引擎）。这样的 信号可以是从任何引擎到任何引擎，但在这一示例中被示出为来自blitter引擎。由消息 信道12在各命令流之间运载信号。消费者引擎16通过其命令流化器用信号确认30来应 答。
[0024] 然后，渲染引擎把旗语信号中的上下文ID与其当前上下文中的上下文ID进行比 较。如果匹配，那么调用等待引擎14,且如果等待引擎正在等待旗语等待，那么在等待之后， 等待引擎将重新采样由生产者提供的数据并且重新评估条件。
[0025] 在Sig/Match/Fwd (信号/匹配/转发）框15和等待反馈单元文件（WAIT fub) 14 之间提供被称为"上下文匹配"的通信信道34。当从生产者CS(在这里是blitter引擎） 接收到信号时，消费者CS(在这里是渲染引擎）把所接收的上下文ID与当前上下文id进 行匹配，并把该信号转发15给等待反馈单元文件14。如果等待反馈单元文件是保持在等待 命令状态时，则它在该等待周期之后通过存储器接口再次获取存储器值以便进行另一次评 估。
[0026] 等待反馈单元文件14、17、19、21、23是下面更详细地描述的执行MI_SEAMPH0RE_ WAIT命令的逻辑。它读取存储器内容且评估条件。然后，基于轮询模式或信号模式，等待反 馈单元文件重新采样命令中的存储器位置，直到满足该条件。图5示出存储器位置可存取 的存储器接口 515。
[0027] 在上下文ID不匹配时，把旗语转发信号28发送给SHM，SHM用旗语转发确认来 应答。这允许把各资源分配给渲染引擎。这允许调度器注意从命令调度器接收的上下文ID 是否匹配由于旗语等待已经退役的现有上下文。然后，命令调度器将把退役上下文移动到 准备好以供在下次机会时重新提交。
[0028] 在上下文ID不匹配时，然后，把旗语转发信号发送给SHM。SHM用旗语转发确认 应答。这允许把各资源分配给渲染引擎。在本描述中，可互换地使用生产者和源，且可互换 地使用消费者和目标。在两个术语之间存在任何差异的范围内，本文的描述同等地适用于 两者。
[0029] 图2A是示出在源引擎102、目标引擎104和微控制器106处执行的操作的处理流 程图。在作为生产者的示例的源引擎中，该处理在112处以使用旗语信令的信号处理开始。 在114,源引擎等待信用量可供其上下文使用。在信用量变得可用时，源引擎将接收上下文 ID和引擎分配。然后，在116处把这些发送给目标引擎104。然后，在11，源引擎使得其信 用量计数递减，已经在116处把信用量用于上下文，且在120处源引擎旗语信号处理结束。
[0030] 如上所述，通过声明已经更新了存储器中其旗语中的一个，旗语信令允许生产者 上下文告知消费者上下文