CN101218562B

CN101218562B - 一种多处理器方法和装置

Info

Publication number: CN101218562B
Application number: CN2006800175211A
Authority: CN
Inventors: T·凯利; J·坎贝尔; D·戈特瓦尔特
Original assignee: ATI Technologies ULC
Current assignee: ATI Technologies ULC
Priority date: 2005-05-27
Filing date: 2006-05-26
Publication date: 2011-06-29
Anticipated expiration: 2026-05-26
Also published as: US20060267992A1; WO2006126090A3; EP1891518B1; US8427486B2; US20120098840A1; WO2006126090A2; US8054314B2; EP1891518A2; CN101218562A

Abstract

描述了一种用于向多个VPU的系统中的多个视频处理单元(VPU)应用非均匀属性的系统和方法。该系统中的各个VPU协作，以便生成将要显示的帧。在各个实施例中，组合或合并或合成由系统中的不同VPU所输出的数据，以便生成将要显示的帧。在负载平衡模式中，该系统中的每个VPU执行作为渲染同一帧的操作的一部分的不同任务，并且由此典型情况下执行不同的命令。在各个实施例中，通过形成用于由系统中的所有VPU执行的单个命令缓冲器，来增强所述系统的效能，即便每个VPU在命令缓冲器中具有要执行的一组不同的命令。

Description

一种多处理器方法和装置

交叉引用

本申请涉及以下美国专利申请：

与本申请同时提交的、由Arcot J.Preetham、Andrew S.Pomianowski和Raja Koduri发明的美国申请号为11/140,156的“Antialiasing Method and System”；

与本申请同时提交的、由Philip J.Rogers、Jeffrey Cheng、DmitrySemiannokov和Raja Koduri发明的美国申请号为11/139,917的“Multiple Video Processing Unit(VPU)Memory Mapping”；

与本申请同时提交的、由Raja Koduri、Timothy M.Kelley和Dominik Behr所发明的美国申请号为11/140,114的“FrameSynchronization in Multiple Video Processing Unit(VPU)Systems”；

与本申请同时提交的、由Syed Athar Hussain、James Hunkins和Jacques Vallieres所发明的美国申请号为11/139,744的“SynchronizingMultiple Cards in Multiple Video Processing Unit(VPU)Systems”；

与本申请同时提交的、由James Hunkins和Raja Koduri所发明的美国申请号为11/140,165的“Compositing in Multiple Video ProcessingUnit(VPU)Systems”；

与本申请同时提交的、由Jonathan L.Campbell和Maurice Ribble所发明的美国申请号为11/139,893的“Dynamic Load Balancing inMultiple Video Processing Unit(VPU)Systems”；

于2005年5月27日提交的、由Yaoqiang(George)Xie和RoumenSaltchev所发明的美国申请号为11/140,040的“Computing Device withFlexibly Configurable Expansion Slots，and Method of Operation”。

在此将每个上述申请的内容全部引用以供参考。

技术领域

本发明属于图形和视频处理领域。

背景技术

图形和视频处理硬件和软件逐年继续地变得更加有能力并且更加易于获得。图形和视频处理电路典型情况下存在于计算机系统中的附加卡(add-on card)上，但是也可以位于主板本身上。图形处理器负责创建由监视器所显示的图像。在早期的基于文本的个人计算机(PC)中，这是一个相对简单的任务。然而，现代有图形能力的操作系统的复杂性已经显著地增加了要显示的信息量。实际上，现在要由系统的主处理器或中央处理器(CPU)来进行图形处理是不切实际的。结果，显示动作典型情况下已经被移交给越来越智能的图形卡，所述图形卡包括被称为图形处理单元(graphics processing units，GPU)或视频处理单元(VPU)的专用的协处理器。

在理论上，可以由计算机系统利用已知方法来生成非常高质量的复杂视频。然而，在大部分计算机系统中，质量、速度和复杂度受成本的限制。例如，当存储器需求和计算复杂度增加时，成本增加。一些系统是在远高于正常成本限制的情况下创建的，诸如用于军事飞行模拟器的显示系统。这些系统常常是非常少量生产的整体上一种类型一台(one-of-a-kind)的计算机系统。然而，以可接受的速度生成高质量的复杂视频对于相当“高端”的消费者级系统来说也可能会迅速变得价格高得惊人。因此创建还能够大量生产同时还具有不断改进的整体质量和能力的VPU和VPU系统是一个正面临的挑战。

另一挑战是创建这样一种VPU和VPU系统：其可以输送可接受的更高质量的视频、不要求过多的存储器、以所期望的速度操作、并且可与现有的计算机系统无缝兼容。

发明内容

依照本发明的第一方面，一种多处理器系统，包括：

多个专用处理器，用于执行相关处理任务的不同部分；和

驱动器，其被耦合来控制每个所述处理器，包括：分送用于使每个所述处理器执行所述相关任务的一部分的一组命令，其中，该组命令包括将要由每个处理器执行的所有命令，并且其中，该组命令包括将要由所述多个处理器中的子集执行的被断定(predicated)命令的至少一个子集，所述被断定命令子集在用于识别将要执行所述命令子集的处理器子集的断定(predication)命令之后。

依照本发明的第二方面，提供了一种系统，包括多个处理器，所述多个处理器每一个均可配置为接收用于指示该处理器执行任务的数据和命令。优选地是，所述数据和命令形成命令缓冲器。

依照本发明的第三方面，提供了一种系统，包括：多个处理器，所述多个处理器每一个均可配置为接收用于指示该处理器执行任务的一组命令和数据；以及至少一个驱动器，可配置为构建该组命令和数据，使得所述多个处理器中的每一个接收相同的一组命令和数据，并且每个处理器执行所述任务的不同部分。

依照本发明的第四方面，提供了一种视频处理卡，可配置为接收来自视频应用程序的视频数据，并且创建将由多个视频处理单元(VPU)执行的单个命令缓冲器以产生帧数据。优选地是，所述视频处理卡包括VPU，其是所述多个VPU之一。

依照本发明的第五方面，提供了一种视频处理单元(VPU)，可配置为接收命令缓冲器，所述命令缓冲器包括将要由所述VPU执行的命令和将要由其它VPU执行的命令，其中，所述VPU只执行将要由该VPU执行的命令。

依照本发明的第六方面，一种多处理器方法，包括：

构建与处理任务相关的一组共用的命令和数据；

在多个处理器的每一个中接收该组共用的命令和数据；并且

所述多个处理器中的各个处理器对该组共用的命令和数据进行不同的解释，以便执行所述处理任务的指定部分。

依照本发明的第七方面，一种多个视频处理单元(VPU)处理方法，包括：

形成单个命令缓冲器，其包括用于所述多个VPU中每一个的命令和数据，其中，所述命令和数据与将要由所述多个VPU共享的任务相关，并且其中，所述单个命令缓冲器被形成为，使其由所述多个VPU中的每一个独立地进行解释；

使所述单个命令缓冲器可同时用于所述多个VPU中的每一个，从而使得所述多个VPU中的每一个同时执行所述单个命令缓冲器中的各自的命令。

依照本发明的第八方面，一种用于在多个视频处理单元(VPU)的系统中产生命令缓冲器的方法，包括：

汇编一组命令和数据，其包括被断定执行命令，所述被断定执行命令在想要将要由所述多个VPU中少于全部数量的处理器执行的命令之前，其中，所述多个VPU中的每一个接收所述命令缓冲器中相同组的命令和数据。

依照本发明的第九方面，提供了一种多个视频处理单元(VPU)的方法，包括：

接收来自视频应用程序的视频数据；并且

产生用于由所述多个VPU执行所述视频应用程序的命令和数据，其中，所述命令和数据包括单个命令缓冲器，所述单个命令缓冲器包括可由所述多个VPU中的每一个进行解释以指示适用于相应VPU的命令和数据的特定子集的信息。

依照本发明的第六到第九方面中的任何一个所述的方法可以由在介质上所存储的计算机程序来实现。

依照本发明的第六到第九实施例中任何一个方法所创建的数字图像也在本发明的范围内。

通过参考来加以结合

这里通过在相同程度上进行参考来结合在此说明书中所提及的所有公布和专利申请，就好像每个相应公布或专利申请被专门地且分别地表明为通过参考进行结合。

附图说明

图1是依照一个实施例的视频处理系统的框图；

图2是依照一个实施例的视频处理系统的更详细的框图；

图3是依照一个实施例，包括向多个VPU的系统中的多个视频处理单元(VPU)应用非均匀属性的一个视频处理系统中的各个组件的框图；

图4是依照一个实施例的命令缓冲器执行过程的流程图；

图5是用于构建与依照图4的过程所执行的命令缓冲器类似的命令缓冲器的流程图；

图6A是依照一个实施例的命令缓冲器的示意图；

图6B是由依照一个实施例的系统中的一个VPU看来的图6A的命令缓冲器的示意图；

图6C是由依照一个实施例的系统中的另一VPU看来的图6A的命令缓冲器的示意图；

图7是依照一个实施例的命令缓冲器执行过程的流程图；

图8是用于构建与依照图7的过程所执行的命令缓冲器类似的命令缓冲器的流程图；

图9是依照一个实施例的视频处理系统的各个组件的框图；

图10是视频处理系统的更详细的框图，所述视频处理系统是与依照一个实施例的图8的视频处理系统类似的配置；

图11是依照一个实施例的单卡视频处理系统的示意图；

图12是依照一个实施例的单卡视频处理系统的示意图；

图13是依照一个实施例的双卡视频处理系统的示意图；

图14是依照一个实施例的双卡视频处理系统的示意图；

图15是依照一个实施例的连结模块(interlink module，IM)的框图；

图16是用于图示依照一个实施例的各个负载平衡模式的图；

图17是依照一个实施例的连结模块(IM)的路径控制逻辑的框图；

图18是依照一个保护装置(dongle)实施例的I2C路径的框图；

图19是依照一个实施例的连结模块(IM)的I2C路径的框图；以及

图20是在依照一个实施例的VPU卡上的I2C路径的框图。

具体实施方式

这里描述了一种用于视频处理的改进的系统和方法。实施例包括具有至少一个图形处理单元(GPU)或视频处理单元(VPU)的一种视频处理系统。如这里所用，GPU和VPU是可交换的术语。在各个实施例中，在并行的VPU之间共享渲染任务，以便以最小的成本增加来提供改进的性能和能力。系统中的各个VPU协作生成将要显示的帧。在各个实施例中，组合或合并或合成由系统中的不同VPU所输出的数据，以便生成将要显示的帧。在一个实施例中，所述系统是可编程的，从而使得各种操作模式是可选择的，这些操作模式包括各种合成模式，以及在多个VPU之间的各种任务共享或负载平衡(loadbalance)模式。在负载平衡模式中，系统中的每个VPU执行渲染同一帧的操作的一部分的不同任务，由此在典型情况下执行不同的命令。在各个实施例中，通过形成用于由系统中的所有VPU执行的单个命令缓冲器，来增强所述系统的效能，即便是每个VPU在该命令缓冲器中可以具有要执行的一组不同的命令的情况下也是如此。这避免了与为每个VPU形成并管理独立的命令缓冲器相关联的低效率和额外开销。例如，如果依照传统方法必须为系统中的每个VPU构建两个命令缓冲器，则有效的可用命令缓冲器空间可能会除以VPU的数量。另一缺点在于，命令缓冲器使用率实际上也会乘以同一数量。实施例还通过以与VPU的数量相关的一个因素(factor)减少驱动器的写入量，来提供更快速的性能。所描述实施例的另一优点在于，通常会减少高速缓存器未命中。例如，不必为每个唯一的命令切换命令缓冲器，如驱动器正为每个VPU构建不同的命令缓冲器的情况。相反，驱动器对一个命令缓冲器连续地工作就好象所述系统只有一个VPU一样。

图1是依照实施例的视频处理系统100的框图。所述系统100包括应用程序102。应用程序102是要求视频处理能力的最终用户应用程序，诸如视频游戏应用程序。应用程序102与应用程序编程接口 (API)104通信。几个API可用于在视频处理环境中使用。API被开发为在诸如应用程序102之类的应用软件与运行所述应用程序的视频硬件之间的中介物。随着新的芯片组甚至全新的硬件技术不断出现，应用程序开发者很难考虑并利用最新的硬件功能。为每种可预见的硬件组专门编写应用程序也是不可能的。API防止应用程序必须过于具体到硬件。应用程序可以依照标准化格式向API而不是直接向硬件输出图形数据和命令。可用API的例子包括DirectX(来自Microsoft)和OpenGL(来自Silicon Graphics)。

API 104可以是用于运行视频应用程序的多个可用API中的任何一个。API 104与驱动器106进行通信。驱动器106典型情况下由视频硬件的制造商编写，并且驱动器106将从API接收的标准代码转换为硬件所理解的本地格式。驱动器允许来自例如应用程序、进程或用户直接设置的输入。这种设置包括用于选择操作模式的设置，所述操作模式包括用于多个VPU中每一个的操作模式和用于合成来自多个VPU中每一个的帧数据的模式，如这里所描述。例如，用户可以经由用户接口(UI)来选择设置，所述用户接口包括利用如这里所描述的视频处理硬件和软件向用户所提供的UI。

在一个实施例中，视频硬件包括两个视频处理单元：VPU A 108和VPU B 110。在其它实施例中，可以有少于或多于两个的VPU。在各个实施例中，VPU A 108和VPU B 110是完全相同的。在各个其它实施例中，VPU A 108和VPU B 110不是完全相同的。下面将非常详细地描述包括视频处理系统的不同配置的各个实施例。

驱动器106向VPU A 108和VPU B 110发出命令。同时向VPU A108和VPU B 110发出的命令用于处理将要显示的同一帧。VPU A 108和VPU B 110均执行用于处理该帧的一系列命令。驱动器106可编程地命令VPU A 108和VPU B 110以依照各种模式来渲染帧数据。例如，驱动器106可编程地命令VPU A 108和VPU B 110渲染帧数据的特定部分。作为替代，驱动器106可编程地命令VPU A 108和VPUB 110中的每一个渲染帧数据的同一部分。

当VPU A 108和VPU B 110中的任何一个完成执行用于该帧的命令时，该帧数据被发送到合成器114。合成器114选择性地包括在连结模块112中，如下面更完整地描述。VPU A 108和VPU B 110协作生成将要显示的帧。在各个实施例中，在合成器114中组合或合并或合成来自VPU A 108和VPU B 110中每一个的帧数据，以产生将要被渲染到显示器130的帧。如这里所用，术语组合、合并、合成、混合或连结指的都是如这里所描述的IM 112和/或合成器114的相同能力。

图2是依照实施例的系统200的框图。系统200包括可以存在于有视频能力的计算机系统的各个组件上的组件或元件。在一个实施例中，应用程序202、驱动器204和共享存储器205存在于主机系统上，而其余组件存在于专用于视频的组件上，所述专用于视频的组件包括一个或多个视频卡，但是本发明并不局限于此。所示出的任何组件可以存在于任何地方，或者作为选择，各个组件可以经由有线或无线网络来远程访问其它组件。应用程序202是要求视频处理能力的最终用户应用程序，诸如视频游戏应用程序。应用程序202与应用程序编程接口(API)204通信。API 204可以是可用的图形或视频或3D API(包括DirectX(来自Microsoft)和OpenGL(来自Silicon Graphics))中的任何一个。

API 204与驱动器206通信。驱动器206是为系统200专门编写的，驱动器206将从API 204所接收的标准代码转换为VPU组件所理解的本地格式，下面将更完整地进行解释。

在一个实施例中，系统200还包括两个VPU：VPU A 208和VPUB 210。本发明不局限于两个VPU。如这里所描述的本发明的各个方面可以在进行了对于本领域技术人员显而易见的修改之后采用一个VPU来实行。然而，在大多数情况下，所述系统在一个VPU的情况下将会没有采用一个以上VPU的情况高效。各个实施例还包括两个以上的VPU。在进行了对于本领域技术人员显而易见的修改后，可以实现具有两个以上VPU的系统，并且在大多数情况下可能会比具有两个VPU的系统提供更好的效能。在各个实施例中，VPU A 208和VPU B 210可以在一个或多个视频卡上，所述视频卡均包括视频处理器以及其他的相关硬件。如下面将进一步解释，本发明并不局限于此。例如，一个以上的VPU可以位于一个卡或板上。然而，如这里所提及，VPU旨在至少包含视频处理器。

VPU A 208和VPU B 210通过相应的环形缓冲器(ring buffer)A222和B 224接收来自驱动器206的命令和数据。所述命令指示VPUA 208和VPU B 210对该数据执行各种操作，以便最终生成用于显示器230的渲染帧。

驱动器206可以访问共享存储器205。在一个实施例中，共享存储器205或系统存储器205是计算机系统上的存储器，其可由计算机系统总线上的其它组件访问，但是本发明并不局限于此。

在一个实施例中，共享存储器205、VPU A 208和VPU B 210都可以访问共享通信总线234，由此可以访问所述总线234上的其它组件。在一个实施例中，共享通信总线234是外围组件接口快速(peripheral component interface express，PCIE)总线，但是本发明并不局限于此。

在以下文献中具体地描述了PCIE总线，这里通过将其全部引用加以结合以供参考：

PCI Express^TM，Base Specification，修订版1.1，2005年3月28日；

PCI Express^TM，Card Electromechanical Specification，修订版1.1，2005年3月28日；

PCI Express^TM，Base Specification，修订版1.a，2003年4月15日；和

PCI Express^TM，Card Electromechanical Specification，修订版1.0a，2003年4月15日。

所有上述文献的版权为PCI-SIG所有。

在一个实施例中，VPU A 208和VPU B 210经由总线234使用对等(peer-to-peer)协议来直接互相通信，但是本发明并不局限于此。在其它实施例中，在VPU A 208和VPU B 210之间可以有直接的专用通信机制。

VPU A 208和VPU B 210均具有分别可用的本地视频存储器226和228。在各个实施例中，其中一个VPU作为主VPU，而其它VPU作为从VPU，但是本发明并不局限于此。在其它实施例中，所述多个VPU可以是在另一组件的中央控制下的对等体。在一个实施例中，VPU A 208充当主VPU并且VPU B 210充当从VPU。

在一个这种实施例中，各种协调和组合功能由连结模块(interlinkmodule，IM)212来执行，所述连结模块212与VPU A 208位于同一个卡上。这被示为用实线封闭的IM 212。在这种实施例中，VPU A 208和VPU B 210经由总线234相互通信，总线234用于传送VPU之间的通信(例如，命令和控制)和数据。例如，当VPU B 210向VPU A208上的IM 212传送输出帧以便进行合成时(例如图1所示)，该帧经由总线234进行传送。

在各个其它实施例中，IM 212并不在VPU卡上，而是一个VPUA 208和VPU B 210均与其进行通信的独立组件。这种实施例包括“保护装置(dongle)”中的IM 212，该“保护装置”易于被连接到VPUA 208和VPU B 210。这在图中由虚线封闭的IM 212表示。在这种实施例中，VPU A 208和VPU B 210经由IM连接232来至少执行一些通信。例如，VPU A 208和VPU B 210可以使用总线234来传送命令和控制信息，并且经由IM连接232来传送诸如帧数据之类的数据。

存在作为本发明不同实施例所设想的系统200的许多配置。例如，如下所述的图9-14只图示了一些实施例。

图3是与系统200类似的多个VPU(也被称为多VPU)的系统300的框图，但是图3示出了该系统的不同元件。应用程序302、API304和共享存储器305的功能均与先前参考相应元件所描述的相同。依照实施例，驱动器306形成或产生或构建命令缓冲器390，其被发送到VPU A 308和VPU B 310中每一个。该实施例提供了一种用于向多个VPU提供非均匀属性(例如，渲染状态，绘制或渲染命令等)的高效手段。驱动器306可以产生一个命令序列，并且可以向诸如VPU A 308和VPU B 310之类的多个VPU提交相同的命令序列，该命令序列由通用的(非某个VPU专用的)属性以及专用于一个或多个VPU的属性组成。每个VPU适当地解释该通用的(非某个VPU专用的)命令序列。此外，每个VPU适当地解释任何专用于该VPU的命令序列并且“忽略”所有并未专用于该VPU的其它非通用的属性。从而，如下面所进一步描述，非均匀的属性被应用于在多个VPU的系统中的多个视频处理单元(VPU)。

VPU A 308和VPU B 310均具有各自的命令处理器CP A 391和CP B 393。CP 391和393取出并解释命令缓冲器390中的命令序列。每个CP都是用于命令处理的专用固定功能硬件与基于软件程序的执行的组合。存在用于每个CP的一组微代码，以及小的微引擎(microengine ME)或执行引擎，所述小的微引擎或执行引擎用于执行由驱动器306预先加载的微代码序列。微代码决定对于命令分组来说执行什么代码(例如，通过基于OPCODE的跳转表来决定)，并且它还包括操作或代码的序列，所述序列被执行以解释该命令中数据。由相应的视频流水线392和394按照CP 391和393的指示来执行命令。在各个系统操作模式中，如这里所进一步描述，在合成器314中合成VPU A 308和VPU B 310的输出。

如这里所描述的实施例不局限于基于微代码的处理引擎实现方式。例如，实施例还包括硅上的固定功能逻辑。

作为VPU的初始化步骤的一部分，加载所述微代码。通常，对于每个完全相同的VPU来说，加载相同的微代码图像(image)。即对于在完全相同的操作环境中的任何两个完全相同的VPU来说，加载相同的微代码图像。与常规的作法相比，这里所描述的实施例包括在系统300中的每个VPU上加载不同的ME微代码图像，这允许每个VPU的CP ME将自身与其它VPU(或VPU组)区分开来。

ME具有通过将可编程数量个的数据元素(例如，命令缓冲器中的32比特DWORD)作为NOP(无操作，或不操作)处理来将其忽略的能力。

在所述系统和方法的另一方面中，以微代码实现一种算法，该算法可以确定给定的命令序列是否与执行该微代码的VPU相关。此外，如果所述命令序列是相关的，则所述算法可以处理该命令序列，或者如果所述命令序列是无关的，则将其忽略。即，所述算法向每个VPU的ME提供了一种手段，根据专用于该VPU的断定结果而采用被断定方式来处理命令序列。

在所述系统和方法的又一方面中，用驱动器所实现的算法允许构造单个命令序列，该单个命令序列由通用(非某个VPU专用的)命令以及想要由一个或多个特定VPU而不是其它VPU进行处理的命令组成。即，为驱动器306提供了一种算法，该算法能够根据驱动器对于一个或多个目标VPU的选择，利用该断定来构造被断定命令序列。

对于用于向在一个多个VPU的系统中的多个视频处理单元(VPU)应用非均匀属性的系统和方法的各个实施例也进行了考虑。将要更详细地描述两个实施例。现在将参考图3-6描述这些实施例中的一个。驱动器306构建由多个分组所组成的命令缓冲器390。所述分组包括DWORD粒度的命令和/或数据信息。DWORD是32比特的数据元素。

当驱动器306构建命令缓冲器390时，它确定哪些命令是被断定命令。驱动器306在想要用于一个或多个特定VPU的一个或多个被断定命令之前，紧邻着放置一个特殊的“被断定执行命令”。此命令也被称为PRED_EXEC命令。该PRED_EXEC命令包括：用于表示VPU选择的比特字段；和2)后续被断定命令序列的长度。当CP A 391或CP B 393遇到PRED_EXEC时，它把在该命令中的VPU选择与对该VPU而言唯一的预编程VPU ID相比较。如果VPU选择与其VPUID相匹配，则该VPU会处理后续命令并执行它们。然而如果VPU选择并不与其VPU ID相匹配，则该VPU就“跳过”接下来的N个命令，其中，N被编程到分组首部中。数据中的接下来的N个DWORD被忽略。该长度被编程到分组中，因此会忽略多达在PRED_EXEC分组中所指定长度的后续分组。

在一个实施例中，设备ID存在于被加载到每个CP的专用微代码图像中，但是本发明并不局限于此。在其它实施例中，并不使用设备ID来识别由哪个VPU执行所述被断定命令。相反，可以使用其它数据或值来识别由哪个VPU执行所述被断定命令。所述数据或值可以存储在系统300中的任何地方。

PRED_EXEC命令告诉该VPU要忽略多少个32比特的数据元素(DWORD)。在命令具有可变大小但是所具有的粒度为一个DWORD的一个实施例中，将其转换为忽略多少命令。例如还可以对命令进行计数。然而，因为所述命令的长度是可变的，所以如果对DWORD进行计数则可以简化CP的操作。

表1示出了依照实施例的一个PRED_EXEC分组的格式。

表1

序号	字段名	描述
			1	[HEADER]	该分组的首部字段
2	[DEVICE_SELECT\|EXEC_COUNT]	DEVICE_SELECT：[31:24]-用于选择一个或多个设备的比特字段：将要在这些设备上执行后续被断定分组，EXEC_COUNT：[22:0]-后续多个被断定分组的DWORD的总数量。此计数约束将会由该设备选择所断定的分组。

PRED_EXEC分组包括VPU选择(DEVICE_SELECT)和后续命令长度(EXEC_COUNT)。把分组中的特定VPU选择与该VPU的VPU ID相比较。如果匹配，则有效地终止该PRED_EXEC命令，并且允许执行后续命令。如果VPU ID和VPU选择相匹配，则在该PRED_EXEC分组中后面的命令长度在该VPU的PRED_EXEC分组解释中被忽略，从而使得命令序列中的下一个DWORD(其是新命令的首部)被解释并执行。

然而，如果VPU ID和VPU选择并不匹配，则在PRED_EXEC分组中所提供的命令长度有效地延长了该PRED_EXEC分组；其被作为NOP来处理，并且将在EXEC_COUNT中所指定数量的后续DWORD丢弃。所述数量对应于在专用于一个VPU或另一VPU的后续命令序列中所具有的DWORD数量。

在一个实施例中，设备ID是在CP中的微代码图像中的设备掩码，因为在设备掩码微代码图像和PRED_EXEC分组的DEVICE_SELECT字段中都存在八个比特，所以支持多达八个不同的设备。所述微代码执行DEVICE_SELECT比特字段与设备掩码比特字段的逐个比特的AND运算。如果AND运算的结果不为零，则PRED_EXEC分组正常结束，以便允许后续分组被执行。

如果AND运算的结果为零，则微代码向ME寄存器加载EXEC_COUNT-1。这使得ME把后续分组作为当前PRED_EXEC分组的一部分来处理。然后所述微代码把这些EXEC_COUNT DWORD作为NOP来处理。

图4是依照一个实施例，在一个VPU中执行具有PRED_EXEC的命令分组的流程图。在411中，把VPU的设备ID与DEVICE_SELECT相比较。如果设备ID与DEVICE_SELECT相匹配，则在413中，VPU的CP读取EXEC_COUNT。如同在417中所示，CP然后使VPU执行由EXEC_COUNT所指定数量的命令。如前所述，在一个实施例中，这实际上是多个DWORD。当已经执行了所指定数量的命令时，在421中，由CP取出下一分组。

如果在411设备ID与DEVICE_SELECT不相匹配，则在415中，VPU的CP读取EXEC_COUNT。如同在419中所示，CP然后使VPU忽略由EXEC_COUNT所指定数量的命令。如前所述，在一个实施例中这实际上是多个DWORD。然后在421中，CP取出下一个分组。

驱动器306知道存在几个VPU，并且它根据各种因素来知道驱动器想要在每个VPU上执行哪些操作。例如，如在这里所描述，驱动器指示在VPU之间的负载平衡。当驱动器在命令缓冲器序列中放置了对所有VPU来说是共用的命令时，驱动器不必进行除了依照正常方式构造命令缓冲器之外的任何附加工作。如果作为替代，驱动器使给定操作或属性组以特定的VPU为目标，则驱动器如现在参考图5所描述那样来构建命令缓冲器。如果如在511中所示，命令被断定，则如同在513中所示，驱动器把PRED_EXEC首部置于命令流中的一个或多个被断定命令之前。在一些情况下，驱动器知道受到该断定影响的DWORD的数量。如果在515中知道DWORD的数量，则在517中，驱动器在PRED_EXEC分组中放置命令长度，作为EXEC_COUNT。如果在515中，不知道DWORD的数量，则在523中，驱动器继续把被断定命令增加到缓冲器中的命令流中。在525中，驱动器确定对于特定的VPU来说是否存在更多的被断定命令。如果存在更多的这种命令，则在523中，驱动器继续把被断定命令添加到缓冲器中的命令流中。如果没有更多的这种命令，则在519中，驱动器确定所涉及的DWORD的数量。然后在517，驱动器在PRED_EXEC分组中放置命令长度，作为EXEC_COUNT。该过程返回到511中，以确定下一个命令是否被断定，并且该过程重复进行。

在给定的命令缓冲器内存在多个序列，所述序列在共用的命令、VPU A所特有的命令和VPU B所特有的命令之间交替，包括状态数据和诸如绘制或渲染之类的操作。当命令缓冲器完成时，驱动器向两个VPU(或向系统中的每个VPU)发送该相同的命令缓冲器。驱动器仍然跟踪每个VPU何时完成该命令缓冲器。驱动器不必跟踪用于相同操作组的两个不同的命令缓冲器。相反，相同的命令缓冲器在不同的VPU上产生不同的行为组。

应用程序302指示何时形成命令缓冲器并且它们中有什么。驱动器306开始根据来自应用程序302的内容来构建命令缓冲器。驱动器306可以在执行之前构建命令缓冲器。命令缓冲器被发送到环形缓冲器中(例如在图2中所示)，因此驱动器306可以“走到前面”并且在先前的命令缓冲器的执行完成之前发送将要执行的命令缓冲器。

图6A是由驱动器306所形成的命令缓冲器的图。该命令缓冲器包括共用数据和被断定数据。在设备专用属性的列表之前，示出了两个PRED_EXEC分组首部，所述设备专用属性包括用于设备A的长度为LA的属性和用于设备B的长度为LB的属性。

图6B示出了设备A对于图6A的命令序列的视图。图6C示出了设备B对于图6A的命令序列的视图。设备A和B中每一个将想要用于另一个设备的被断定命令“看作”NOP。所有其它命令均被视为可执行的命令。

现在将参考图7和8来描述另一实施例。在此实施例及其变式中，为每个VPU定义专用的被断定分组类型。所述分组由该分组想要用于的VPU来识别。在每个VPU上加载不同的微代码，以便解释在NOP或“实操作(real operation)”(例如寄存器写入)之前的分组首部。表2概括了名称为DEVICE_0_REGISTER_WRITE和DEVICE_1_REGISTER_WRITE的两个这种分组。

表2

分组名称	描述
		DEVICE_0_REGISTER_WRITE	将一个或多个连续的寄存器写入到设备0。在设备0上，会发生该寄存器写入。在设备1上，会忽略该寄存器写入。
DEVICE_1_REGISTER_WRITE	将一个或多个连续的寄存器写入到设备1。在设备1上，会发生该寄存器写入。在设备0上，会忽略该寄存器写入。

DEVICE_0_REGISTER_WRITE被设备0解释为可执行的命令，并且被设备1解释为NOP从而被忽略。类似地，DEVICE_1_REGISTER_WRITE被设备1解释为可执行的命令，并且被设备0解释为NOP从而被忽略。

表3示出了用于依照实施例的DEVICE_REGISTER_WRITE分组的格式。

表3

序号	字段名称	描述
			1	[HEADER][#DWORDS]	分组的首部字段。包含DWORD计数
2	[BASE_INDEX[12:0]]	典型情况下，此DWORD是用于要执行的设备专用寄存器写入的分组首部[BASE_INDEX[12:0]]对应于字节地址位[14:2]。从而使得BASE_INDEX是DWORD存储器映射地址。BASE_INDEX字段宽度最大支持到DWORD地址:0x7FFF
			3	REG_DATA_1	这些比特对应于为相关寄存器所定义的比特。注意REG_DATA_x的后缀代表从1到N的整数
…
			N+2	REG_DATA_N

首部包括用于告知分组长度(多少个DWORD)的信息。首部后面是VPU地址，或者硬件中的寄存器偏移，用于指示在该分组中要写入的第一个寄存器。然后是一个或多个DWORD的数据序列。所述数据的第一个DWORD被写入到基地址或寄存器偏移地址。下一个DWORD被写入到下一个偏移寄存器，对于数据的后面的多个DWORD依此类推。

如果VPU不“匹配”，则ME通过把它们作为NOP进行“忽略”，来跳过多达N+2个DWORD。

图7是依照实施例的DEVICE_REGISTER_WRITE分组的执行流程图。该流程图图示了从被指定为“设备0”的VPU观点看来的过程。在711中，VPU确定分组OPCODE是否表明所述分组是用于设备0的。如果所述OPCODE表明所述分组是用于设备0的，则在713中读取DWORD计数。在717中，读取BASE_INDEX以便确定在哪里写入数据的第一个DWORD。在718中，把分组中的下一个DWORD写入到当前地址。对于第一次写入操作来说，当前地址由BASE_INDEX来表明。然后在719中使该写入地址增加。如果在721中，根据在713中所读取的DWORD计数确定所写入的DWORD是要被写入的最后一个DWORD，则在723中，所述设备取出下一个分组。如果所写入的DWORD不是要被写入的最后一个DWORD，则在718中将下一个DWORD写入到当前地址。

如果在711中，所述设备根据OPCODE确定所述分组并不是用于设备0，则在725中读取DWORD计数。假定DWORD计数＝X，则接下来的X个DWORD被该设备忽略，并且在723中取出下一分组。

图8是用于构建用来依照图7的过程执行的命令缓冲器的流程图。在811中，在专用于设备0的任何寄存器写入之前紧邻着放置DEVICE_0_REGISTER_WRITE分组首部。在813中，在专用于设备1的任何寄存器写入之前紧邻着放置DEVICE_1_REGISTER_WRITE分组首部。在815中，为设备0和1共用的任何寄存器写入放置正常的寄存器写入分组。在817中，向两个设备发送该共用的命令缓冲器。在图8中，所示出的操作次序并不受限制。由附图标记811、813和815所指定的操作可以依照任何次序出现，并且在构建一个命令缓冲器的过程中可以出现多次。另外，设备的数量不是必须为两个，而是在其它实施例中可以大于二。

图9是依照一个实施例的系统900的各个组件的框图。系统900包括主VPU卡952和从VPU卡954。主VPU卡952包括主VPU908，并且从VPU卡954包括从VPU B 910。在一个实施例中，VPU 908和910均经由PICE总线934来通信。在一个实施例中，PCIE总线 934是被划分成两个X8 PCIE总线935的X16总线。VPU A 908和B910中的每一个都被连接到总线935。在一个实施例中，VPU A 908和VPU B 910只经由总线935通信。在一个候选实施例中，VPU A 908和VPU B 910部分经由总线935并且部分经由专用卡间连接937来通信。在其它实施例中，VPU A 908和VPU B 910专门地经由连接937来通信。

主VPU卡952包括IM 1512。在VPU A 908和VPU B 910经由总线935通信的一个实施例中，每个VPU按照驱动器的指示来处理帧数据。作为图9中的一个例子，系统900在如下所述的“剪裁(scissoring)”负载平衡模式下执行视频处理。主VPU A 908产生输出909并且从VPU B 910产生输出911。输出909和911被输入到IM912以便合成，如下面进一步描述。在一个实施例中，从VPU B 910经由如同点划线路径963所示的总线935和934将其输出911传送到IM 912。在一个实施例中，从VPU B 910经由如同点划线路径961所示的专用卡间连接937将其输出911传送到IM 912。IM 912组合所述输出909和911以便生成用于显示的帧。此帧被IM 912经由连接器941输出到显示器930。

主VPU卡952包括连接器940和941。从VPU卡954包括连接器942和943。连接器940、941、942和943是本领域中公知的用于发送所需信号的连接器。例如，在一个实施例中，连接器941是数字视频输入(digital video in，DVI)连接器。可以有多于或少于在00 900中所示出的连接器数量。

在一个实施例中，这里所描述的各个配置可由用户来配置，以便使用任意数量个可用的VPU进行视频处理。例如，系统900包括两个VPU，但是在穿越(pass-through)模式下，用户可以选择只使用一个VPU。在这种配置中，其中一个VPU可以是有效的，而另一个可能是无效的。在这种配置中，如这里所描述的任务共享或负载平衡可能是不可用的。然而，所启用的VPU可以执行常规的视频处理。从VPU卡B 954到显示器930的点划线路径965表示在穿越模式中可以单独使用从VPU B 910进行视频处理。类似地，在穿越模式中可以单独使用主VPU A 908进行视频处理。

图10是系统1000的更详细的框图，所述系统1000是与依照一个实施例的图9的系统相类似的配置。所述系统1000包括两个VPU卡，主VPU卡1052和从VPU卡1054。主VPU卡1052包括主VPUA 1008，并且从VPU卡1054包括从VPU B 1010。

主VPU卡1052还包括接收器1048和发送器1050，其在一个实施例中用于接收和发送TDMS信号。在一个实施例中，双重连接器1045是DMS连接器。主卡还包括用于向显示器输出数字视频信号的DVI连接器1046，所述数字视频信号包括帧数据。主VPU卡1052还包括视频数模转换器(DAC)。如同所示，连结模块(IM)1012连接在VPU 1008和发送器以及接收器之间。VPU A 1008包括集成的收发器(被标记为“集成”)和数字视频输出(DVO)连接器。

从VPU卡1054包括两个DVI连接器1047和1048。从VPU B1010包括DVO连接器和集成收发器。作为经由PCIE总线(未示出)进行通信的候选实施例，主VPU卡1052和从VPU卡1054经由专用的卡间连接1037来通信。

图11-14是系统配置的其他实施例的图。图11是依照一个实施例的单卡系统1100的图。所述系统1100包括“超级卡(supercard)”或“巨卡(monstercard)”1156，其包括一个以上的VPU。在一个实施例中，超级卡1156包括两个VPU，主VPU A 1108和从VPU B 1110。超级卡1156还包括IM 1112，IM 1112包括用于组合或合成来自两个VPU的数据的合成器，如下面所进一步描述。在其它实施例中还可以用专用的卡上VPU间连接来进行VPU间通信(未示出)。在一个实施例中，主VPU A 1108和从VPU B 1110均被连接到X8 PCIE总线1135，所述X8 PCIE总线1135源自X16 PCIE总线1134。

所述系统1100包括这里所描述的多个VPU(还被称为多VPU)的功能中的全部功能。例如，主VPU A 1108按照驱动器的指示来处理帧数据，并且向IM 1112输出所处理的帧数据1109。从VPU B 1110按照驱动器的指示来处理帧数据，并且输出所处理的帧数据1111，所述帧数据1111被传送到IM 1112以进行组合或合成。如前面参考图 900所述，所述传送经由PCIE总线1134或经由专用的VPU间连接(未示出)来执行。无论哪种情况，都将所合成的帧从IM 1112输出到显示器1130。

在穿越模式中，还可以禁止多VPU能力并且使用其中一个VPU来独自执行视频处理。这例如由短划线路径1165来示出，所述短划线路径1165图示了被连接到显示器1130以输出用于显示的帧数据的从VPU B 1110。在穿越模式中，主VPU A 1108还可以通过在路径1166上输出帧数据来单独工作。

图12是依照一个实施例的单卡系统1200的图。所述系统1200包括“超级卡”或“巨卡”1258，其包括一个以上的VPU。在一个实施例中，超级卡1258包括两个VPU，主VPU A 1208和从VPU B1210。超级卡1258还包括IM 1212，IM 1212包括用于组合或合成来自两个VPU的数据的合成器，如这里所描述。在其它实施例中，还可以用专用的卡上VPU间连接来进行VPU间通信(未示出)。在一个实施例中，主VPU A 1208和从VPU B 1210均经由卡上桥(on-cardbridge)1281连接到X16 PCIE总线1234。

所述系统1200包括这里所描述的多VPU功能中的全部功能。例如，主VPU A 1208按照驱动器的指示来处理帧数据，并且向IM 1212输出所处理的帧数据1209。从VPU B 1210按照驱动器的指示来处理帧数据，并且输出所处理的帧数据1211，所述帧数据1211被传送到IM 1212以进行组合或合成。如前面参考图900所述，所述传送经由PCIE总线1234或经由专用的VPU间连接(未示出)来执行。无论哪种情况，都将所合成的帧从IM 1212输出到显示器(未示出)。

在穿越模式中，还可以禁止多VPU能力并且使用其中一个VPU来独自执行视频处理。这例如借助短划线路径1265来示出，所述短划线路径1265图示了被连接到输出端以便传送要显示的帧的从VPUB 1210。在穿越模式中，主VPU A 1208还可以通过在路径1266上输出帧数据来单独工作。

图13是依照一个实施例的双卡系统1300的图。所述系统1300包括两个对等的VPU卡1360和1362。VPU卡1360包括VPU A 1308，并且VPU卡1362包括VPU 1310。在一个实施例中，VPU A 1308和VPU 1310是完全相同的。在其它实施例中，VPU A 1308和VPU B1310不是完全相同的。VPU A 1308和VPU 1310均被连接到从X16PCIE总线1334划分出来的X8 PCIE总线1335。VPU A 1308和VPU1310还均被连接，以便经由卡连接器向连结模块(IM)1312输出数据。在一个实施例中，IM 1312是“保护装置”中的集成电路，所述“保护装置”可被容易地连接到VPU卡1360和VPU卡1362。在一个实施例中，IM 1312是一个专门设计成包括这里所描述的所有合成功能的集成电路。IM 1312合并或合成由VPU A 1308和VPU 1310所输出的帧数据并且向显示器1330输出可显示的合成帧。

图14是依照一个实施例的双卡系统1400的图。所述系统1400类似于系统1300，但是被配置为在旁路模式下操作。系统1400包括两个对等体VPU卡1460和1462。VPU卡1460包括VPU A 1408，并且VPU卡1462包括VPU B 1410。在一个实施例中，VPU A 1408和VPU 1410是完全相同的。在其它实施例中，VPU A 1408和VPU B1410不是完全相同的。VPU A 1408和VPU B 1410均被连接到从X16PCIE总线1434划分出来的X8 PCIE总线1435。VPU A 1408和VPU1410还均被经由卡连接器连接，以便向连结模块(IM)1412输出数据。在一个实施例中，IM 1412是“保护装置”中的集成电路，所述“保护装置”可被容易地连接到VPU卡1460和VPU卡1462。在一个实施例中，IM 1412是一个专门设计成包括这里所描述的所有合成功能的集成电路。IM 1412还可配置为在穿越模式下操作，在所述穿越模式下，一个VPU独自操作而其它VPU未被启用。在这种配置中，如这里所描述的合成可能是不可用的。然而，启用的VPU可以执行常规的视频处理。在图14中，VPU A 1408被启用并且VPU B 1410被禁止，但是在旁路模式中任何一个VPU可以工作，以便向显示器1430输出。

例如在图9-14中，如这里所示的配置目的是作为可能实施例的非限制性例子。其它配置也在如权利要求所定义的本发明的范围之内。例如，其它实施例包括在计算设备上安装或并入的第一VPU，所述计算设备诸如个人计算机(PC)、笔记本计算机、个人数字助理(PDA)、TV、游戏控制台、手持式设备等。第一VPU可以是集成VPU(也称为集成图形处理器或IGP)或者为非集成VPU。第二VPU被安装或并入到坞站(docking station)或外部封装单元。第二VPU可以是集成VPU或非集成VPU。

在一个实施例中，坞站专用于支撑第二VPU。第二VPU和第一VPU如这里所描述的进行通信，以便如所描述地协作执行视频处理并且生成输出。然而在这种实施例中，第二VPU和第一VPU经由一根或多根电缆或者易于连接和分离的其它机制来进行通信。这种实施例对于使计算设备能够通过与另一VPU协作来显著地增强其能力来说是特别有用的，所述计算设备在物理上可能很小并且具有有限的视频处理能力。

本领域普通技术人员应当理解，其他候选实施例可以包括在单片(single die)上的多个VPU(例如，单片上的两个VPU)，或者在单个硅芯片上有多个核心。

图15是依照一个实施例的连结模块(IM)1512的框图。所有渲染命令都由系统中的每个VPU取出。在依照这里所描述的任何一个多VPU配置中，在VPU执行了所取出的命令之后，IM 1512合并来自多个VPU的像素和控制线的流，并且输出单个数字视频输出(DVO)流。

IM 1512包括主输入端口，用于接收来自主VPU的DVO流。在诸如在图13和14中所示出的那些配置的“保护装置”配置中，主VPU输入可以来自TDMS接收器。作为替代，在例如图9和10中所示的多卡配置中，主VPU输入可以来自主VPU卡上的主VPU。同步寄存器1502接收来自主VPU的DVO数据。

IM 1512还包括从输入端口，用于接收来自从VPU的DVO流。在诸如在图13和14中所示出的那些配置的“保护装置”配置中，从VPU输入可以来自TDMS接收器。作为替代，在例如图11和12中所示的“超级”VPU卡配置中，从VPU输入可以来自“超级”VPU卡结构上的从VPU。IM 1512包括从端口上的FIFO 1504，以便帮助在主VPU和从VPU之间同步输入流。

来自主VPU和从VPU的输入数据被传送到扩展模式混合器1514以及多路复用器(MUX)1516。IM 1512可配置为在多种合成模式下操作，如这里所描述。当如下面所进一步描述的，通过扩展模式混合器1514，或者通过只选择非黑色像素进行显示，来组合由两个VPU所处理的帧的一部分时，整个帧都准备好进行显示。

控制逻辑确定IM 1512在哪种合成模式下操作。根据所述合成模式，扩展模式混合器或MUX会输出最终数据。当使用MUX时，控制逻辑决定哪个像素(主或从)通过所述MUX，该控制逻辑包括黑色寄存器1506和MUX路径逻辑与黑色比较器1508。数据被输出到TDMS发送器1518或DAC 1520。

使用黑色寄存器来允许软件设置已经进行了伽马调节的最终黑色值。

在一个实施例中，在多个VPU以及IM 1512之间的组件间通信包括多种I2C总线和协议。

如表4所示，通过I2C寄存器比特1524和TMDS控制比特1522的组合，来设置包括多种合成模式在内的多种操作模式。

表4：操作模式和控制比特

类别
					主	子	I2C比特	TMDS Cntr比特	注释
穿越	Slave(从)	INTERLINK_ENABLE＝0CONTROL_BITS_2:Bit3＝x	n/a	使用第一I2C访问来确定路径
					穿越	Master(主)	INTERLINK_ENABLE＝0CONTROL_BITS_2:Bit3＝x	n/a	使用第一I2C访问来确定路径
连结	AFR_MANUAL	INTERLINK_ENABLE＝1CONTROL_BITS_2:Bit3＝0	AFR_MAN_ON^* ＝0AFR_AUTO^*＝1	xAFR_MAS状态改变控制下一个数据路径
					连结	AFR_AUTO	INTERLINK_ENABLE＝1CONTROL_BITS_2:Bit3＝0	AFR_MAN_ON^* ＝0AFR_AUTO^*＝0

连结	BLACKING	INTERLINK_ENABLE ＝1 CONTROL_BITS_2:Bit 3＝0	AFR_MAN_ON^* ＝1 AFR_AUTO^*＝x	使用黑色像素来确定数据路径
					连结	SuperAA	INTERLINK_ENABLE ＝x CONTROL_BITS_2:Bit 3＝1	n/a	CONTROL_BITS_2:Bit 4-7决定扩展模式

依照一个实施例，存在经由IM 1512的两个独立的数据路径。来自各个VPU的两个输入像素流中任意一个，通过MUX 1516(在穿越模式或“标准”连结模式中)进行处理，或者在扩展模式中通过混合器1514进行处理。在一个实施例中，所述扩展模式包括超级抗锯齿模式或“SuperAA模式”，如在一并待决的美国专利申请序号尚未分配、题目为“Antialiasing System and Method”中所描述，在此通过全部引用加以结合以供参考。

在MUX 1516中，选择来自VPU A或VPU B中任意一个的仅一个像素通过，并且不涉及任何像素处理。在扩展模式混合器1514中，在逐个像素基础上进行处理。在SuperAA模式中，例如，对所述像素进行处理、平均在一起、并且再次进行处理。在一个实施例中，处理步骤包括使用一个或多个查找表来产生中间或最终结果。

由I2C寄存器比特和控制比特来确定在MUX 1516路径与混合器1514路径之间的选择。例如，如果出现以下条件则选择混合器1514路径：

ENABLE_INTERLINK＝1(I2C寄存器)

并且CONTROL_BITS_2：Bit 3和Bit 4＝1(ExtendedModes和SuperAA)

(否则MUX)。

在一个实施例中，IM具有三个端口，两个输入端口和一个输出端口。

输出端口结构被划分成两个部分。通过24比特的单数据速率(single data rate，SDR)接口来驱动DAC。利用双倍数据率(doubledata rate，DDR)接口来驱动TMDS；12引脚接口用于TMDS单个链路，并且24引脚接口用于TMDS双重链路。I2C控制比特寄存器确定此结构。

存在三个主要的像素时钟域。主输入和从输入都参与到其自己的独立域上。IM使用DVO时钟域来用于所有内部路径和最终输出。DVO时钟在穿越模式中由有效的输入端口产生，并且在连结模式中来自主输入时钟。

主输入总线(数据和控制)在其进入DVO时钟域中时通过同步器，引入了2-4个时钟延迟。从输入总线(数据和控制)进入FIFO，FIFO在其输出端上被同步到DVO时钟域。两个路径的输出都被路由到MUX或扩展模式混合器，然后所述MUX或扩展模式混合器输出单总线宽度的数据输出。

在从穿越模式中，从FIFO被设置为穿越模式，而在连结模式中，它被用作为标准FIFO。对于从穿越模式来说，控制比特与像素数据一起通过FIFO。在连结模式中，sAFR_MAS与所述数据一起通过，并且忽略来自从输入端口的控制比特。

使用DDR时钟的I/O被划分成双倍宽总线(例如，12比特的DDR输入在内部变为24比特)。这是为了避免必须以全时钟速度通过IM。

在一个实施例中，在IM上存在一个FIFO，位于从通道上。在单个TMDS模式中，24比特的像素数据流过FIFO，并且在双重TMDS模式中，48比特的数据流过所述FIFO。当在穿越模式中处于从路径时，还通过此FIFO传送从端口的控制比特。当在连结模式中时，忽略所述控制比特，并且与像素数据并行地传递sAFR_MAS比特，而不是控制比特。

当在单链路TMDS模式中时(CONTROL_BITS：Dual_Link_Mode比特＝0)，并不对双重链路的额外的24比特数据使用时钟，以便节省功率。

当加电时，FIFO应当被设置为空。当ENABLE_INTERLINK比特切换到1时或者如果CONTROL_ONESHOTS：FIFO_Clear比特被设置为1，也清除FIFO。

从FIFO具有两个标记(watermark)(寄存器FIFO_FILL， FIFO_STOP)。IM根据FIFO有多满以及这些寄存器中的值，来驱动SlavePixelHold引脚。如果在使用中从FIFO具有FIFO_FILL或很少的条目，则SlavePixelHold应当下降。如果在使用中从FIFO具有FIFO_STOP或更多的条目，则SlavePixelHold应当升高。

“负载平衡”指的是工作怎样被驱动器划分以便由多个系统VPU来处理。在各个实施例中，依照IM 1512的多个合成模式之一，来合成每个VPU所输出的处理数据，所述模式这里也被称作为“连结模式”和“合成模式”。IM 1512支持用于在许多VPU之间进行负载平衡的许多方法，包括超贴面(super-tiling)、剪裁(scissoring)以及交替帧渲染(alternate frame rendering，“AFR”)，所有这些方法都是“变黑(blacking)”的组件。下面将描述这些模式。图16是用于图示由所述系统执行的各个负载平衡模式的图。来自系统中各个VPU的帧数据依照一种负载平衡模式来处理并且在合成器114中合成(例如图1所示)，如在此所述，以便产生可显示的帧。

对于超贴面来说，软件驱动器控制确定贴面大小并且在图像数据和黑色贴面之间交替，以便在主和从VPU之间完全绘制每个帧。IM1512遍历非黑色像素(图像数据)，在主输入和从输入之间创建超贴面类型的划分。如果想要的话，可以针对每对主和从帧来动态地调节贴面大小。超贴面可以把显示屏划分为棋盘图案，其中每个方块/贴面例如为32x32个像素。在多VPU系统的第一VPU上渲染图像贴面，而在第二VPU上渲染黑色贴面。超贴面为在渲染帧中的像素处理提供了细粒的负载分享、相对于其它负载平衡方法的更为均匀的像素负载分布、以及不太复杂的驱动实现方式。

剪裁把显示屏划分为两个部分，并且此划分可以是水平或垂直的。虽然当考虑软件实现和数据传输的灵活性时，水平划分可能更方便，然而垂直划分可以提供更好的负载平衡。在多个VPU的设备环境中，剪裁在利用3D渲染使数据传输并行化方面提供了优化机会。剪裁还支持从VPU(用于执行大部分数据转送)比主VPU进行更少量的工作的方法，由此使在主和从VPU之间的动态负载平衡方案便于进行。

剪裁包括垂直划分屏幕变黑控制和水平划分屏幕变黑控制。在垂直划分屏幕变黑控制的情况下，驱动器确定由主和从VPU分别输出帧的哪一端，从而使得在两个VPU之间完全绘制每个帧。每个VPU所不处理的帧部分被驱动器清除为黑色。然后IM 1512按照主和从VPU之间的垂直划分连结两个帧。所述划分不必是对屏幕的均匀划分(例如，每个VPU渲染50％)，其可以针对每对主从帧来动态地调整。

在水平划分屏幕变黑控制的情况下，软件驱动器确定主和从VPU分别输出帧的上或下部分中的哪一个部分。然后驱动器进行清除以便把没有保持有效帧缓冲器数据的部分变为黑色，并且IM 1512按照对输入的水平划分，对所述输入进行混合。所述划分不必是对屏幕的均匀划分(例如，每个VPU渲染50％)，其可以针对每对主从帧来动态地调整。

交替帧渲染(“AFR”)在帧级别上执行负载平衡。这里所提及的“帧”包括在发出显示缓冲器交换/翻转命令之前由应用程序所发出的渲染命令的序列。AFR通常根据IM 1512的交替输入，来把每个新的帧传送到输出端。一个VPU渲染偶数帧，而另一个VPU渲染奇数帧，但是实施例不受此限制。AFR允许对于整个3D流水线进行性能扩展，并且对于许多情况而言避免了渲染到纹理(render-to texture)的卡到卡(card-to-card)的数据传送。

一个实施例的IM 1512可以在人工控制、具有自动VSync切换的人工控制或变黑控制之下执行AFR。当使用人工控制时，驱动器为在下一个VSync之后的帧手动选择IM 1512的输入。采用使用具有VSync切换的人工控制的AFR，并且在下一垂直消隐(verticalblank)之后，IM 1512将耦合到主VPU的输入端选择为输出源，然后在每个VSync时自动地在主和从VPU之间进行切换。使用变黑控制，驱动器交替从主和从VPU发送完全绘制的帧和被清除为黑色的帧；结果，IM 1512在主和从帧之间切换。

其它合成策略是可用的并且不受IM 1512的限制。例如，扩展连结模式也是可用的，其超出了手动AFR和变黑模式的负载分享使用。这些模式虽然不是用于通过在多个VPU之间共享处理来净化速度增益的标准连结，但是通过把功能从VPU卸载到IM 1512上，提高了系统的质量和/或速度。作为扩展状态的一个例子，一个实施例的IM1512支持除了手动AFR和变黑模式之外的先前所提及的“SuperAA”模式。

再次参照图15，IM 1512支持多种输入模式以及单或双重链路TMDS宽度，这取决于输入连通性。IM 1512还包括计数器，用于监视在两个输入端的HSyncs和VSyncs之间的相位差。计数器可以包括像素/帧计数器，用于帮助匹配在这两个输入流上的时钟。

参照表5，在一个实施例中，IM 1512具有三个计数器1510。每个计数器都使主像素时钟递增，并且使用其中一个VSyncs来进行锁存和清除。

如果发生对I2C计数器的读取，则拖延对该寄存器的更新，直到在所述读取完成之后。如果发生对寄存器的写入，则延迟所述读取，直到所述写入完成为止。读取延迟只有几个IM内部时钟，因此对软件来说是透明的。

表5：IM计数器

计数器名称	比特	时钟	描述
				CLKS_PER_FRAME_CTR	22	主像素	每1个从帧的主时钟数量-使用从VSync来确定帧边缘-每个从VSync把此计数锁存到CLKS_PER_FRAME并复位此计数器
S2M_VSYNC_PHASE_CTR	11	主像素	在从VSync和主VSync之间显示的行数-在每个主VSync，被锁存到S2M_VSYNC_PHASE
				S2M_HSYNC-PHASE_CTR	12	主像素	在从HSync和主HSync之间显示的像素数-在每个主HSync，被锁存到S2M_HSYNC_PHASE-每个从HSync把计数复位为0

可以采用如上所述的多种配置来使用IM 1512。在这里被称作为“保护装置”的一种配置中，IM 1512接收两个独立的TMDS输出，其每一个均来自两个独立的VPU，并且IM 1512通过两个TMDS接收器把它们传递到所述保护装置上。然后独立的接收器把两个DVO 流直接输出到保护装置的IM 1512中。IM 1512把两个所接收的输入混合到单个输出流中。然后来自IM 1512的输出DVO信号被馈送到TMDS发送器或经由DAC进行馈送，TMDS发送器和DAC都是通过在保护装置上的标准DVI-I连接器来驱动的。

在这里被称为“卡上”配置的另一配置中，IM 1512直接从存在于与IM 1512相同的卡上的两个VPU接收两个DVO信号流。与保护装置配置相对比，该卡上配置在VPU和IM 1512之间并不使用TMDS发送器或接收器。IM 1512把两个接收的输入混合到单个输出流中。然后来自IM 1512的输出DVO信号被馈送到TMDS发送器或经由DAC馈送，TMDS发送器和DAC例如都通过标准的DVI-I连接器来驱动。

在IM 1512输入端上接收的输入流这里可以被称作“主输入”和“从输入”，并且是分别从主和从VPU接收的。主和从VPU可以在两个独立的卡上或在单个“超级”卡上。任何一个VPU可以都可以作为主或从VPU。

主VPU被用作主时钟，并且将从时钟同步(“synced”)到该主时钟。除正常的卡初始化过程之外，不调节或调谐主时钟。从VPU被调节为略在主VPU之前运行，以便实行同步和FIFO等待时间。从VPU使用较大的FIFO，以便补偿在两个VPU的像素时钟速率之间的偏差，而主VPU路径只使用浅的FIFO，以便把主输入时钟域同步到内部DVO时钟域。在主和从VPU之间的流控制包括：两个VPU的初始同步，然后是对从VPU进行调节以便与主VPU相匹配。流控制包括：响应于IM 1512内的计数器，经由IM 1512或驱动器动作所产生的像素拖延信号进行的时钟调节。

如上所述的IM 1512支持多种操作模式，包括穿越模式和各个连结模式，如表1中所图示。如这里所描述，通过I2C寄存器比特和TMDS控制比特的组合来设置这些操作模式。

穿越模式是直接把IM 1512的输入传递到输出(监视器)的模式。借助初始切换I2C时钟，来在上电时选择所使用的输入端口。可以通过把ENABLE_INTERLINK寄存器从“1”切换回到“0”然后切换期望端口的I2C时钟，来再次改变路径。

连结模式包括多种模式，在这些模式中，IM 1512依照各种组合把从主和从VPU接收的输入耦合到输出。实施例的双重VPU连结模式包括但不局限于双重AFR连结模式(Dual AFR Interlink Mode)和双重变黑连结模式(Dual Blacking Interlink Mode)。

双重VPU连结模式是通过手动AFR控制或通过变黑模式来使用两个VPU的模式。在这些模式中，在操作期间对两个IM 1512端口连续地进行输出。

双重AFR连结模式包括在两个输入端口之间交替IM 1512输出源的模式。一旦根据VSync而开始，它可以由IM 1512驱动器手动进行，或者自动地进行。双重AFR连结模式的控制包括使用以下比特/状态：AFR_MAN_ON^*＝低；AFR_AUTO^*＝高或低；AFR_MAS(用于控制此时哪个卡正在输出，或者用于设置要自动切换的第一个卡)。

图17示出了IM的路径控制逻辑。oClk是输出像素时钟。oClk是直接根据来自从端口的sClk，在从通路(passthru)中产生的。在连结或主穿越模式中，oClk是根据来自主端口的、具有相同计时的mClk直接产生的。oClk：mDE简单地是被同步到oClk时域中的主端口的mDE信号。

双重变黑连结模式包括多种模式，在这些模式中，两个VPU并行进行输出，并且IM 1512通过为任何VPU的不应当被输出的任何像素发送黑色像素值，而借助于以逐个像素为基础选择像素来形成输出。双重变黑连结模式的控制包括使用以下比特/状态：AFR_MAN_ON^*＝高。

AFR_MAN_ON^*是通过主TMDS控制比特总线在第二个比特上发送的。其用mClk进行时钟计时，并且是在mVSync的上升沿之后、在mDE的上升沿之前一个时钟。响应于此的动作在该mDE的有效周期的第一个像素命中MUX之前进行。除了此具体时间之外，不对AFR_MAN_ON^*进行直接响应。

当AFR_MAN_ON^*有效(LOW)并且ENABLE_INTERLINK被设置为1并且ExtendedModes比特为0时，则按照如下，通过xAFR_MAN比特来控制所述的由像素MUX所设置的路径。

I2C寄存器反映在结果动作发生之后的结果。其并不直接反映所时钟计时的比特。

AFR_AUTO^*是通过从TMDS控制比特总线在第二个比特上发送的。其用sClk进行时钟计时，随后被同步到mClk。在mVSync的上升沿之后、mClk升高之前的时钟中，将其锁存。然后，响应于此的动作在与有效mDE相关联的第一个像素命中MUX之前发生，并且只有在AFR_MAN_ON^*在相同的锁存点上为低时才发生。

当AFR_AUTO^*和AFR_MAN_ON有效并且ENABLE_INTERLINK被设置为1并且扩展连结模式无效时，则由像素MUX所设置的路径最初被设置为主路径。然后，在mVSync的上升沿之后在mDE的每个上升沿自动切换所述路径，直到AFR_AUTO^*被置为无效为止。

在mLCTL[1]，根据主端口来设置mAFR_MAS，并且在sLCTL[1]，根据从端口来设置sAFR_MAS。这两个比特控制当在连结模式、手动AFR时，哪个路径由像素MUX设置。

mAFR_MAS用mCLK来直接进行时钟计时。sAFR_MAS用sClk计时来进行时钟输入，随后被同步到mClk。这两个比特在mDE的上升沿之前的上升时钟边沿被锁存。然后这两个被锁存的比特进入用于检测比特改变状态的逻辑块。根据I2C寄存器比特，在VSync或HSync的上升沿之后，如果一个比特被检测到其状态发生了改变，则当在AFR_MANUAL连结模式中时，所述逻辑设置像素MUX，以便匹配所切换比特的路径。在任何其它时间所述MUX在AFR_MANUAL连结模式期间不会改变。

如果两个比特在同一更新时间帧内切换，则设置主路径。

与其它控制比特不同，I2C寄存器反映了进入用MClk进行时钟计时的MUX控制逻辑块种的独立的被同步的比特，而不是在同步状态之后的比特。

关于在实施例的IM 1512中的数据和控制路径，双重VPU连结模式在路由模式中工作，所述路由模式包括穿越、双重/单个输入、AFR手动连结和双重输入变黑连结。这些路由模式描述了来自两个接收器的哪些数据和控制线路经由发送器或DAC发送到IM 1512之外。表6示出了在一个实施例中，按照IM 1512的路由选择模式的数据、控制和时钟路由。

所述时钟是像素时钟，内部控制线是在TMDS发送器和接收器(和IM 1512)之间连接的线路，并且外部控制线路是不由诸如I2C和热插拔之类的TMDS电路处理的线路。从像素拖延信号在IM 1512和从DVI VSync引脚之间直接游走。

表6

路由模式	时钟	内部控制	旁路控制	数据	注释
						穿越	主或从	主或从	主或从	主或从	通过第一I2C时钟切换来设置
AFR手动	主或从	主或从	主或从	主或从	由AFR_MAN控制比特来设置
						变黑	主	主	主	主或从	根据黑色像素来连结数据

当在单个VPU模式中使用IM 1512时，并且在驱动器为双重VPU模式设置了IM 1512和VPU之前，出现穿越。在加电时，IM 1512默认MUX把所有数据和控制线路直接从主VPU传递到所述IM 1512的输出端。一旦IM 1512发现一个输入TMDS I2C时钟发生切换，它就把MUX设置为把该特定通道传递到输出端。这包括时钟和所有控制信号，而不管它是来自主还是从VPU。这就允许IM 1512在BIOS上电操作期间，甚至在驱动器知道存在IM 1512之前，就把系统的默认视频卡直接连接到监视器。

在双重VPU连结模式中，一旦加载了驱动器，则所述驱动器可以检测IM 1512是否存在以及存在到IM 1512的一个连接还是两个连接。通过经由每个VPU的端口读取IM 1512的I2C ID寄存器，来进行该检测。驱动器可以按照在每个端口上所读取的IM 1512 ID寄存器的第0个比特的值，来确定哪个所发现的连接是主连接，以及哪个所发现的连接是从连接。

如果只发现一个连接，则IM 1512留在穿越模式中。如果发现两个到IM 1512的连接，则驱动器接管屏幕控制，设置IM 1512的MUX以便从主端口输出，并且将连接到主端口的VPU作为主VPU。从此端口来驱动时钟，直到掉电或者到IM 1512的输入连接之一被断开。

一个实施例的MUX是通过包括穿越初始状态、AFR人工控制和变黑控制的机制来设置的。通过TMDS CNTR比特来设置这些模式以及用于每个模式的特定控制，并且IM 1512在下一垂直消隐期间作出响应。根据I2C控制比特设置，在下一个HSync或下一个VSync时，主/从切换(AFR_MAS)可以锁存/出现。

除了使用TDMS控制寄存器之外，驱动器还使用I2C控制寄存器来控制并监视IM的功能。

I2C寄存器用于进行控制和监视，控制和监视不需要在每帧都进行或更快的进行不必发生什么。寄存器可以对于IM的主和从端口而言都可用。

对于更为动态的控制来说，I2C控制寄存器用于设置不同的多VPU模式，并且用于手动地切换IM数据路径。

在视频处理系统的一个实施例中，使用集成电路间(Inter-Intergrated Circuit，I2C)总线来实现用于IM的集成电路间通信。I2C是典型情况下用于连接集成电路(IC)的总线。I2C是多主总线，这意味着可以把多个IC连接到同一总线，并且每一个IC通过发起数据传送来作为主装置。

图18是用于保护装置1870上的IM 1812的实施例的图，其示出了各个I2C路径。保护装置1870接收来自主VPU A和从VPU B的数据。在一个实施例中，主VPU A和从VPU B存在于一个或多个VPU卡上。在一个实施例中，对于IM 1812来说存在三个独立的I2C总线。存在来自两个输入端口中的每一个的I2C总线，所述输入端口是主输入端口和从输入端口。第三I2C总线从IM 1812去往发送器，以及任何已连接的输出设备，诸如面板和/或阴极射线管(CRT)。

两个输入I2C总线都经由DVI主和从输入端口馈送到保护装置1870中，并且在两个独立通道上直接馈送到IM 1812中。

图19是依照一个实施例的IM 1512内的I2C路径的图。IM 1512 包括主标识(ID)I2C寄存器和从ID I2C寄存器。IM 1512还包括SDC切换传感器、MUX及其它I2C寄存器。

VPU A或VPU B中的任何一个可以通过各自的输入端口来直接访问ID寄存器，而不考虑I2C总线所有权。

IM 1512具有一组寄存器，该组寄存器可以在特定的I2C设备地址上由I2C访问。所有其它地址通过IM 1512而传送到I2C输出端口上。

主ID寄存器和从寄存器均具有同一内部地址，但是只可从它们各自的I2C总线(从或主)来访问。

除了IM_xxx_ID寄存器(偏移0)和I2C_Reset寄存器之外，使用一种先出现先服务(first com，first serve)的仲裁机制，按照I2C的逐个周期的基础，来对I2C总线进行仲裁。

对于多字节寄存器的读取周期来说，保持所有权直到读取最后的字节为止。软件驱动器确保依照从底到顶的顺序来完全读取所有字节。如果依照从底到顶顺序没有完全读取所有字节，则所述总线可以会保持锁定并且工作情况可以变为是未定义的。

对于通过IM 1512传递到外部设备的访问来说，IM 1512不理解页面寻址或者任何周期，所述周期要求与先前访问中的任何动作的相关性(延续一个以上I2C停止比特的周期)。因此，增加寄存器的比特(CONTROL_BITS_2：比特0：I2C_CLOCK)。如果需要多I2C访问，则软件会设置此寄存器比特。当此寄存器比特被设置时，总线被专门地给予该端口，直到所述比特被复原为止，此时恢复自动仲裁。在两个端口试图设置此比特的情况下，则标准的仲裁方法确定哪个端口获得访问，并且发送否定应答(negative acknowledgement，NACK)信号以便让该请求者知道没有成功。

在I2C总线由于一些意外原因而被锁定的情况下使用特殊的I2C_Reset寄存器。对此寄存器的任何读取，不管I2C总线的所有权如何，都会始终强迫I2C状态机复位并释放I2C总线所有权，将其恢复到自动仲裁。

对于其它I2C寄存器来说，按照先出现先服务方式来动态地仲裁 I2C总线所有权。用于首先利用时钟和起始比特来访问其它寄存器的输入端口，在当前I2C周期的持续时间内获得所有权(即，直到下一停止比特为止)。对于IM 1512上的多字节读取寄存器(计数器)来说，从所读取的第一个字节开始维持所述所有权，直到已经读取了寄存器的最后字节为止。

如果在总线已经被许可给另一输入端口之后开始I2C访问，则响应于该访问尝试而发送否定应答(NACK)信号。待读取的数据未被定义，并且写入被丢弃。

IM 1512支持对访问离开IM 1512的单个非页面类型的I2C访问。为了允许在多个相关类型的I2C周期期间锁定I2C总线，如果输入端口把I2C_LOCK比特(I2C_CONTROL_2：比特0)设置为1，则把I2C总线保持到该端口的所有权中直到同一端口把同一比特设置回0。此寄存器遵循相同的先出现先服务的仲裁协议。

如果从任何一个端口读取I2C_RESET寄存器(不要求仲裁或所有权)，则I2C状态机被复位并且任何I2C所有权被清除。

图20是依照一个实施例，用于主VPU A和IM 2012处于同一VPU卡2052上的配置的I2C总线路径的图。VPU卡2052例如可以是图11的系统的一部分。VPU卡2052包括主VPU 2008、IM 2012、DVI发送器和可选的DVI发送器。存在三个I2C总线(主、从和连结)，如所示的进入和离开IM 2012。在一个实施例中，连结I2C总线是主I2C总线或从I2C总线的继续，这取决于哪个总线被首先被访问。

所有IM 2012 I2C寄存器都可以用于从或主I2C端口。如果I2C总线目前由其它路径使用，则使用标准的NACK进行响应。IM 2012设备ID是一个例外，其能够同时由任何一个端口来访问。

为了选择性地验证I2C周期是否已经成功地完成，所有写入寄存器都必须可被写回的。由于IM 2012上的I2C寄存器没有超时，所以这与在各种常规视频卡上所使用的现有I2C访问方法相匹配。不是必须要进行读回来验证写入。

每当IM 2012 I2C得到停止比特时，IM 2012 I2C复位其状态机 (未示出)。依照已知的I2C协议，在每个I2C周期的开始和结束时发生。

CONTROL_ONESHOTS寄存器(未示出)具有与其它读取/写入寄存器不同的行为。一旦被写入，IM 2012就把其结果锁存到内部控制比特。在CONTROL_ONESHOTS寄存器本身在下次读取此寄存器时被清除(允许对所述写入进行确认)。

一旦IM 2012完成了所请求功能并且CONTROL_ONESHOTS寄存器的相应比特被清除，则CONTROL_ONESHOTS比特的内部拷贝被IM 2012自动清除。IM 2012不会重新锁存内部版本直到I2C版本被手动清除为止。

IM具有可以被I2C所访问的一组寄存器。IM_MASTER_ID和IM_SLAVE_ID寄存器具有相同的内部地址，但是只可从它们自己的I2C总线(例如，从或主)进行访问。

其余的寄存器一次只能从一方(主或从)来进行访问。

为了验证I2C周期是否已经成功地完成，所有写入寄存器还必须可被写回，以便验证所更新的值。由于IM上的I2C寄存器没有超时，所以这与在各种现有视频卡上所使用的I2C访问的常规方法一致。如果需要的话，则不必进行读回来验证所述写入。

每当IM I2C得到停止比特，则复位其状态机。这在每个I2C周期的开始和结束时按照每个I2C协议发生。

CONTROL_ONESHOTS寄存器具有与其它读取/写入寄存器不同的行为。一旦被写入，IM就把其结果锁存到内部控制比特。在此寄存器的下次读取时CONTROL_ONESHOTS被清除(允许对所述写入的确认)。

一旦IM完成了所请求功能并且CONTROL_ONESHOTS寄存器的相应比特被清除，则CONTROL_ONESHOTS比特的内部拷贝被IM自动清除。

例如在诸如图13和14中的保护装置配置中，通过TMDS接口把TMDS控制比特发送到IM中。软件(驱动器)把VPU内的寄存器设置为想要的控制比特值，并且所述结果到达保护装置上的TMDS 接收器并被锁存到IM中。AFR_MAN_ON^*和AFR_AUTO^*在TMDSVSync的上升沿被锁存。此时不发送任何像素数据。根据在I2CControl_Bits寄存器的第5个比特中的设置，来在HSync或VSync的上升沿锁存AFR_MAS。

如果interlink_mode未启用(I2C寄存器设置)，则忽略该比特直到它被启用并将在下一VSync其作用。

如果interlink_mode被启用，则根据情况，在VSync或HSync之后在刚好下一像素数据从IM中出来时发生作用。

如果是在穿越模式中，则所使用的Syncs来自有效路径。如果是在AFR_MANual或变黑连结模式中，则所使用的Syncs始终来自主路径。

本发明的上述方面可以被实现为编程到任何种类电路中的功能，所述电路包括但不局限于可编程逻辑器件(PLD)，诸如现场可编程门阵列(FPGA)、可编程阵列逻辑(PAL)器件、电可编程序逻辑与存储设备、以及基于标准单元的设备、以及专用集成电路(ASIC)和完全定制的集成电路。用于实现本发明方面的其它可能选择包括：具有存储器(诸如电可擦可编程只读存储器(EEPROM))的微控制器、嵌入式微处理器、固件、软件等。此外，可以在微处理器中实现本发明的各个方面，所述微处理器具有基于软件的电路仿真、离散逻辑(顺序的和组合的)、定制器件、模糊(神经)逻辑、量子器件和以上任何器件类型的混合。当然，可以采用各种组件类型来提供基础的器件技术，例如，像互补金属氧化物半导体(CMOS)之类的金属氧化物半导体场效应晶体管(MOSFET)技术、像发射极耦合逻辑(ECL)之类的双极技术、聚合物技术(例如，硅共轭聚合物和金属共轭聚合物-金属结构)、混合的模拟与数字、等等。

除非上下文清楚地要求否则遍及说明书和权利要求，词“包括”、“包含”等将依照相容意义来解释，而不是排除或穷举意义；即在“包括但不限于”的意义上。使用单数或复数的词还分别包括复数和单数。另外，词“这里”、“在此”、“以上”、“以下”和类似输入的词当在本申请中使用时，指的是本申请的整体而不是本申请的任何特定部分。当就两个或多个项的列表使用词“或”时，该词覆盖了此词的所有以下解释：列表中的任何项、列表中的所有项和所述列表中项的任何组合。

本发明所举例说明的实施例的上述描述，并不意图对本发明进行穷举或将其限制为所公开的形式。虽然，为了说明性目的描述了本发明的具体实施例和例子，然而相关领域内分技术人员将认识到，在本发明的范围内可以进行各种等效的修改。这里所提供的本发明教导可以应用于其它系统，而不仅是用于包括如上所述的图形处理或视频处理的系统。

例如，按照在此的描述而生成的视频图像可以被输出到各种显示设备，包括用于显示运动图像的计算机显示器和用于打印静态图像的打印机。

所描述的各种操作可以在各种体系结构中实行，并且可以与所描述的内容相比不同地分布。作为一个例子，在分布式系统中，服务器可以执行一些或所有渲染处理。另外，尽管这里描述了许多配置，然而都并不意在是限制性或排他性的。例如，还可以在包括集成图形处理器(IGP)或视频处理器以及分立式图形或视频处理器的系统中实现本发明，这些处理器协作以生成要显示的帧。在各个实施例中，如所描述来合并或合成由集成和分立处理器中的每一个所处理的帧数据。此外，还可以在包括一个或多个IGP器件与一个或多个分立图形或视频处理器的组合的系统中实现本发明。

在未示出的其它实施例中，VPU的数量可以大于二。

在其它实施例中，这里所描述的一些或所有硬件和软件能力可以存在于打印机、照相机、电视、手持式设备、移动电话或其它设备中。这里所描述的视频处理技术可以被应用为从视频序列中构造动画的过程的一部分。

可以组合上述各个实施例中的元素和动作，以便提供其他实施例。按照上述详细说明，可以对本发明进行这些及其它改变。

通过进行整体参考，将在此所引用的所有美国专利申请结合于此。

通常在附带的权利要求中，所使用的术语不应当被解释为把视频处理方法及其系统限制为在说明书和权利要求中所公开的具体实施例，而是应当解释为包括根据这些权利要求进行工作以提供视频处理的任何处理系统。因此，视频处理方法和系统并不受此公开的限制，而且作为替代，所述视频处理方法和系统的范围将完全由权利要求来确定。

虽然在附带的权利要求中依照特定的权利要求形式给出了用于视频处理的方法和设备的某些方面，但是发明人意在给出采用任何数量的权利要求形式的用于视频处理的方法及其设备的各个方面。例如，虽然仅仅将用于视频处理的方法和设备的一个方面陈述为将其具体化在计算机可读介质中，然而其它方面同样也可以被具体化到计算机可读介质中。因此，发明人保留在提交本申请之后增加附加权利要求的权力，以便追求这种用于视频处理的方法和设备的其它方面的附加要求形式。

Claims

1.一种多处理器方法，包括：

构建与处理任务相关的一组共用的命令和数据；

在多个处理器中的每一个中接收该组共用的命令和数据；并且

所述多个处理器中的各个处理器对该组共用的命令和数据进行不同的解释，以便执行所述处理任务中的指定部分，

其中，该组共用的命令和数据包括被断定命令的子集，该被断定命令子集在用于识别将要执行该被断定命令子集的处理器子集的断定命令之后。

2.如权利要求1所述的方法，还包括：

所述多个处理器中的每一个执行想要由该处理器执行的命令子集；并且

所述多个处理器中的每一个忽略并非想要由该处理器执行的命令子集。

3.如权利要求1到2所述的方法，其中，构建与处理任务相关的该组共用的命令和数据的步骤包括：

确定命令是否被断定，其中，被断定命令想要由所述多个处理器中少于总数量个的处理器来执行；并且

如果确定所述命令被断定，则把断定首部插入到该组共用的命令和数据中，所述断定首部用于表明一个或多个后续命令想要由所述多个处理器中少于总数量个的处理器来执行。

4.如权利要求3所述的方法，还包括：

确定是否知道想要由所述多个处理器中少于总数量个的处理器来执行的后续命令的数量；并且

如果知道所述数量，则把所述数量插入到所述断定首部中。

5.如权利要求3所述的方法，还包括：

如果不知道所述数量，则添加后续被断定命令到该组共用的命令和数据中；

确定是否存在其他后续被断定命令；

如果没有更多其他后续被断定命令，则确定所述数量；并且

把所述数量插入到所述断定首部中。

6.如权利要求1到5中任何一项所述的方法，其中，该组共用的命令和数据包括多个命令分组，并且其中，解释步骤包括：确定分组类型是否是为特定处理器所定义的类型。

7.如权利要求6中任何一项所述的方法，还包括：如果所述分组类型是为特定处理器所定义的，则该特定处理器执行在该分组中的命令。

8.如权利要求1到5中任何一项所述的方法，其中，构建该组共用的命令和数据的步骤包括：

把设备标识符首部插入到命令分组中，其中，所述设备标识符首部指示特定处理器；并且

把多个命令插入在所述设备标识符首部之后。

9.一种装置，包括：

用于构建与处理任务相关的一组共用的命令和数据的模块；

用于在多个处理器中的每一个中接收该组共用的命令和数据的模块；并且

用于所述多个处理器中的各个处理器对该组共用的命令和数据进行不同的解释，以便执行所述处理任务中的指定部分的模块，

10.一种装置，包括：

用于构建与处理任务相关的一组共用的命令和数据的模块；

用于使该组共用的命令和数据可用于多个处理器中的每一个的模块；以及

用于对于所述多个处理器中的每一个，依照不同的方式解释该组共用的命令和数据，使得所述多个处理器中的每一个执行所述处理任务的预先指定部分的模块。

11.一种装置，包括：

用于接收与视频处理任务相关的一组共用的命令和数据的模块，其中，该组共用的命令和数据包括将要由不同处理单元执行的命令和数据的子集；

用于解释该组共用的命令和数据，从而只使用特定的子集来执行所述视频处理任务的预先指定部分的模块。