CN101198988A - 在多个视频处理单元(vpu)的系统中的帧同步 - Google Patents
在多个视频处理单元(vpu)的系统中的帧同步 Download PDFInfo
- Publication number
- CN101198988A CN101198988A CNA2006800175207A CN200680017520A CN101198988A CN 101198988 A CN101198988 A CN 101198988A CN A2006800175207 A CNA2006800175207 A CN A2006800175207A CN 200680017520 A CN200680017520 A CN 200680017520A CN 101198988 A CN101198988 A CN 101198988A
- Authority
- CN
- China
- Prior art keywords
- vpu
- semaphore
- command
- register
- video
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
- G06T15/005—General purpose rendering architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
- G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2210/00—Indexing scheme for image generation or computer graphics
- G06T2210/52—Parallel processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Graphics (AREA)
- Controls And Circuits For Display Device (AREA)
- Image Processing (AREA)
- Multi Processors (AREA)
- Digital Computer Display Output (AREA)
Abstract
描述了一种用于在多个视频处理单元(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”;
与本申请同时提交的、由Timothy M.Kelley、Jonathan L.Campbell和David A.Gotwalt发明的美国申请号为11/140,163的“ApplyNon-Homogeneous Properties to Multiple Video Processing Units(VPUs)”;
与本申请同时提交的、由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系统:其可以输送可接受的更高质量的视频、不要求过多的存储器、以所期望的速度操作、并且可与现有的计算机系统无缝兼容。
发明内容
依照本发明的第一方面,一种系统包括:
系统存储器,由所述系统中的组件经由总线共享;
多个处理器,用于对共同任务进行共享处理,每个所述处理器包括从包含以下的组中所选择的至少一种通信机制:本地存储器、信号量机制、以及用于经由所述总线访问所述系统存储器的虚拟存储器机制;以及
驱动器,被耦合到所述多个处理器中的每一个,用于向每个所述处理器并发地发出相同的命令缓冲器以便完成所述共同任务,其中,所述共同任务的完成包括至少一个同步点,所述命令缓冲器包括用于在所述同步点处协调数据传送的至少一种同步机制,所述至少一个机制从包含以下的组中选出:所述信号量机制、所述虚拟存储器机制、以及经由所述系统总线访问所述系统存储器。
依照本发明的第二方面,一种系统,包括:
至少一个驱动器,可配置为构建与执行处理任务相关的一组命令和数据;以及
多个处理器,被耦合来接收该组命令和数据,并且可配置为共享所述处理任务,其中,所述多个处理器还可配置为,使用根据该组命令和数据而确定的通信机制来彼此通信,以便使所述处理任务同步。
依照本发明的第三方面,一种视频处理设备,被配置为:
接收一组共用的命令,该组共用命令可以被所述设备和其它视频处理器并发地进行解释;并且
解释在该组共用命令中的同步命令,以便访问在所述设备之外存储的信息,其中,所述信息与将要由所述设备所采取的动作相关,所述动作用于使所述设备和其它视频处理器对该组命令的并发执行进行同步,其中,所述同步命令包括信号量命令和存储器访问命令。
依照本发明的第四方面,提供了一种视频处理卡,包括:
被配置为构建用于处理视频数据的一组命令的电路,包括在同步点插入用于使执行该组命令的多个处理器同步的同步命令;以及
被配置为接收该共用组并且解释在该组共用命令中的同步命令以便访问在所述卡之外存储的信息的电路,其中,所述信息与将要由所述电路所采取的动作相关,所述动作用于使所述电路及在所述卡之外的其它电路对该组命令的并发执行进行同步,其中,所述同步命令包括信号量命令和存储器访问命令。
依照本发明的第五方面,一种多处理器方法,包括:
多个处理器中的每一个接收与任务相关的一组命令;并且
所述多个处理器共享对所述任务的执行,并且所述共享包括按照要求进行动作同步,以便在没有错误的情况下执行所述任务,其中,同步包括按照该组命令的指示,经由信号量机制来进行处理器间通信。
依照本发明的第六方面,一种视频处理方法,包括:
接收包括命令、数据的一组命令,其中,所述命令至少包括同步命令;并且
响应于对所述至少一个同步命令的解释来改变正常的命令执行流,其中,所述至少一个同步命令包括被解释来导致读取信号量寄存器的信号量命令以及被解释来导致读取存储单元的存储器命令。
可以使用被存储在计算机可读介质上的计算机软件来有益地执行本发明的方法。
通过参考来加以结合
这里通过在相同程度上进行参考来结合在此说明书中所提及的所有公布和专利申请,就好像每个相应公布或专利申请被专门地且分别地表明为通过参考进行结合。
附图说明
图1是依照一个实施例的视频处理系统的框图;
图2是依照一个实施例的视频处理系统的更详细的框图;
图3是依照一个实施例的包括帧同步的多VPU系统的元件的框图;
图4是依照一个实施例的包括基于寄存器的帧同步的多VPU系统的元件的框图;
图5是依照一个实施例的包括基于存储器的帧同步的多VPU系统的元件的框图;
图6是依照一个实施例的视频处理系统的各个组件的框图;
图7是视频处理系统的更详细的框图,所述视频处理系统是与依照一个实施例的图6的视频处理系统类似的配置;
图8是依照一个实施例的单卡视频处理系统的示意图;
图9是依照一个实施例的单卡视频处理系统的示意图;
图10是依照一个实施例的双卡视频处理系统的示意图;
图11是依照一个实施例的双卡视频处理系统的示意图;
图12是依照一个实施例的连结模块(interlink module,IM)的框图;
图13是用于图示依照一个实施例的各个负载平衡模式的示意图;
图14是依照一个实施例的连结模块(IM)的路径控制逻辑的框图;
图15是依照一个保护装置(dongle)实施例的I2C路径的框图;
图16是依照一个实施例的连结模块(IM)的I2C路径的框图;以及
图17是在依照一个实施例的VPU卡上的I2C路径的框图。
具体实施方式
这里描述了一种用于视频处理的改进的系统和方法。实施例包括具有至少一个图形处理单元(GPU)或视频处理单元(VPU)的一种视频处理系统。如这里所用,GPU和VPU是可交换的术语。在各个实施例中,在并行的VPU之间共享渲染任务,以便以最小的成本增加来提供改进的性能和能力。系统中的各个VPU协作生成将要显示的帧。在各个实施例中,组合或合并或合成由系统中的不同VPU所输出的数据,以便生成将要显示的帧。在各个实施例中,由系统中不同的VPU所处理的帧数据被同步,以便即使在这样系统中也能确保准确的操作:在该系统中包括多个VPU,这些VPU并未共享VPU卡并且并未受益于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发出的命令用于处理将要显示的同一帧。VPUA 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 A208和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 ExpressTM,Base Specification,修订版1.1,2005年3月28日;
PCI ExpressTM,Card Electromechanical Specification,修订版1.1,2005年3月28日;
PCI ExpressTM,Base Specification,修订版1.a,2003年4月15日;和
PCI ExpressTM,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之间可以有直接的专用通信机制。
VPUA 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均与其进行通信的独立组件。一个这种实施例包括“保护装置”中的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的许多配置。例如,如下所述的图6-11只图示了一些实施例。
图3是一个双VPU卡实施例的框图,示出了VPU A 310和VPUB 310的各个组件。VPUA 308和VPU B 310中的每个依照例如在图6和7中所示出的类似配置处于不同的VPU卡(未示出)上。VPU A308和VPU B 310中的每一个可以访问系统存储器或共享存储器305。VPU A 308和VPU B 310中的每一个接收命令缓冲器372,命令缓冲器372包括与渲染同一帧相关联的命令。可以要求多个命令缓冲器来向显示器渲染一个完整的帧。命令包括例如渲染命令、用于改变状态的命令和用于加载像素的命令。在帧缓冲器末尾处的最终命令是显示指令。
VPU A 308和VPU B 310均包括各自的命令处理器(commandprocessors,CP),CP A和CP B。CP A和CP B均可以访问如同所示的各自CP寄存器。VPU A 308和VPU B 310均包括各自的寄存器机A和B,用于控制对各个寄存器的访问。CP寄存器和与IDCT信号量(semaphore)机或寄存器机相关联的任何寄存器典型情况下在物理上位于特定VPU的本地存储器(未示出)中。VPU A 308和VPU B310均包括各自的IDCT信号量机A和B,用于控制对IDCT信号量的使用。IDCT是传统上用于在一个VPU上对两条处理流水线进行视频3D同步的信号量。VPU A 308和VPU B 310还均包括各自的视频处理流水线A和B。CP A和CP B均与系统存储器305通信。
在某种情况下,要求一种机制来使VPU A和VPU B同步。在各个实施例中,包括了各种机制,来确保VPU之一(A或B)在经过VPU输入命令缓冲器372中的特定执行点之前进行等待或停滞。只要另一个VPU到达了在命令缓冲器372中的同一执行点,则等待/停滞情况就被所述另一VPU复位。这种同步在此被称作为帧同步。使用帧同步的多种设备环境之一是VPU到VPU的数据传送。在这里所描述的实施例中,当从一个VPU向另一个VPU传送诸如纹理、渲染目标和顶点缓冲器之类的数据时,使接收VPU与正发送数据的VPU同步。这确保了接收VPU不会试图使用仍然正由发送VPU进行发送的数据。接收VPU在同步之前使用这种数据可能会导致不正确的操作和错误。
使用帧同步的另一种设备环境是交换锁定(Swap Lock)。当使用在VPU卡之外的设备来合成由每个VPU所渲染的最终帧时,应当在非常接近的时间内将显示缓冲器交换命令发送到两个VPU上的显示控制器。
使用帧同步的另一种设备环境是给共享存储器305的渲染。当渲染目标存在于共享存储器中且两个VPU对该渲染目标的不同部分进行写入时,应当在该渲染目标能够用作要被读取的纹理时刻的命令执行点之前,对这两个VPU进行同步。
在各个实施例中,存在两种从根本上不同的方式来实现在VPU之间的帧同步。一种是基于VPU寄存器的信号量方式,另一种是基于存储器的信号量方式。在基于VPU寄存器的信号量方式中,使用VPU B命令处理单元(CP)来使在VPU B自己的多个内部寄存器之一上的执行情况停滞。VPU A可以写入访问这些寄存器,以便它可以释放VPU B以使其继续执行。注意,在此帧同步的讨论中,VPUA或VPU B是任意使用的,并且在该例子中可以互换角色。在各个实施例中,存在用来实现基于寄存器的信号量机制的两种机制。它们是IDCT信号量机制和CP等待信号量机制。
IDCT信号量由IDCT_RB_SEMAPHORE寄存器来控制。当IDCT_RB_SEMAPHORE.IDCT_SEMAPHORE==0时,CP等待WAIT_UNTIL.WAIT_IDCT_SEMAPHORE。可以通过向IDCT_RB_SEMAPHORE.INC_IDCT_SEMAPHORE写入1来使信号量增加,并且这导致等待结束。
表1示出了依照IDCT信号量帧同步方法的一个实施例,用于两个VPU的典型同步序列。
表1
PM4流 | |
主 | 从 |
WAIT_UNTIL.WAIT_IDCT_SEMAPHORE | 写入到主(IDCT_RB_SEMAPHORE.INC_IDCT_SEMAPHORE) |
IDCT_RB_SEMAPHORE.IDCT_SEMAPHORE | WAIT_UNTIL.WAIT_IDCT_SEMAPHORE |
写入到从(IDCT_RB_SEMAPHORE.INC_DCT_SEMAPHORE) | IDCT_RB_SEMAPHORE.IDCT_SEMAPHORE |
为了能够通过存储器映射输入/输出(MMIO)来控制IDCT信号量,IDCT_CSQ_CONTROL.CSQ_MODE字段首先被设置为1。通过被称为“BLT”的对等数据传送来使用MMIO。
在各个实施例中,IDCT信号量由视频/多媒体驱动器以及驱动器306来使用。为了使用此信号量来用于多VPU操作,实施例包括用于在驱动器之间共享此资源的机制。在不同的实施例中,视频/多媒体驱动器可以在不访问IDCT信号量的情况下起作用,但是它们在该情况下可能运行地更为缓慢。为了缓和任何潜在的性能恶化,在一个实施例中,视频/多媒体驱动器检查当3D驱动器处于多VPU模式中时所设置的共享全局标记,并且限制此信号量的使用。帧同步操作依赖于被设置为1的IDCT_CSQ_CONTROL.CSQ_MODE比特。如果视频/多媒体驱动器由于任何原因而要求该比特为0,则所述比特应当再次被设置为1以用于多VPU操作。
使用IDCT方式的同步方法包括:使用多VPU PM4播放器播放器架构、以及使用到MMIO寄存器空间中的卡到卡数据传送的信号量更新。
如上所述,另一种基于寄存器的信号量是CP等待信号量机制。
表2示出了依照一个实施例的用于CP等待信号量帧同步方法的分组概要。
表2
分组名称 | IT_OPCODE | 描述 |
WAIT_SEMAPHORE | Ox22 | 在CP微引擎中等待信号量变为零 |
依照CP等待信号量,VPU在继续处理后续的命令流之前等待信号量变为零。在一个实施例中,VPU本地存储器中存在四个微代码单元留出来用作信号量。在其它实施例中,被留出用作为信号量的位置可以更多或更少。
CP的微代码读取所指定的微代码本地存储器地址。如果内容为零,则微代码继续至命令流中的下一分组。如果所述内容是非零的,则微代码进行循环并且重新读取该特定本地存储器地址,直到它为零为止。
选择性地,可以提供信号量复位值。如果提供了该值,则该值被写入到由所指定微代码本地存储器地址所引用的信号量存储器。这可以用来在下次出现具有所指定信号量偏移的WAIT_SEMAPHORE时使CP自动地暂停。
当前正执行的应用程序可以在任何时间把非零值写入到信号量存储单元。所述应用程序能够写入非零值,以使得CP微引擎在命令流中的下一个WAIT_SEMAPHORE分组处暂停。其影响在于,使在与VPU相关联的间接和环形缓冲器中所排队的所有VPU渲染暂停。然后所述应用程序可以把零写入到信号量,以便允许微引擎继续。所述应用程序可以如下所示,通过对两个寄存器的直接I/O寄存器写入来写入信号量存储器:
1.把信号量偏移(0xFC,0xFD,0xFE,或0xFF)写入到CP_ME_RAM_ADDR寄存器。
2.把信号量值(零或非零的)写入到CP_ME_RAM_DATAL寄存器。
在表3中示出了依照一个实施例的CP等待信号量分组的格式。
表3
序号 | 字段名称 | 描述 |
1 | [HEADER] | 分组的首部字段 |
2 | 信号量偏移 | 这是在等待循环中所想要测试的信号量。其可以是0xFC,0xFD,0xFE,0xFF中的任何一个。 |
3 | 信号量复位 | 可选的。一旦等待循环已经满足(即,一旦信号量为零),则此值如果存在的话,就被写入到信号量偏移。 |
在多VPU帧同步功能的情况下,由另一个VPU来执行对信号量的写入,例如通过这里所描述的VPU到VPU的数据传送机制来执行。
现在将描述基于存储器的信号量方式。虽然基于寄存器的信号量对于各个实施例来说是适用的且有效的,然而对于一些实施例来说基于存储器的方式可以提供附加的灵活性。例如,基于存储器的方式不要求一个VPU具有写入另个一VPU的寄存器的能力。另外,可以用于帧同步目的的存储单元的数目不太可能经常性地变得不够。相比之下,可以用于这些目的的VPU寄存器的数目是有限的。因为所有VPU可以始终对系统存储器进行读取和写入,所以基于存储器的机制可以在无限种类的多VPU配置中用于同步。这里所描述的实施例允许实现多个基于存储器的信号量。假定所要求的存储器只是两个DWORD,则存储器映射机制可用的信号量数目实际上是不受限制的。
表4图示了WAIT_MEM信号量。
表4
分组名称 | IT_OPCODE | 描述 |
WAIT_MEM | 0x2E | 在CP微引擎中等待可由VPU访问的存储器信号量变为零 |
依照WAIT_MEM信号量机制,VPU读取存储器中可由VPU访问的存储器信号量。VPU在继续处理后续命令流之前,等待所述可由VPU访问的信号量变为零。所述信号量可以存在于任何可由VPU访问的存储器(本地或非本地)中。信号量的基地址被对准到DWORD边界。存储器中的信号量由两个DWORD组成。
此分组不能增加、减少或改变存储器信号量的内容。
存储器信号量由两个DWORD组成:实际信号量和具有固定值2的附加DWORD。该附加DWORD保证命令处理器微引擎可以适当地循环以便根据需要重复地测试信号量值。所述信号量被如下组织:
信号量值 |
固定值2 |
在一个实施例中,该分组使用间接缓冲器#2(IB2)来读取存储器信号量。因此,该分组无法从IB2发起。
微代码读取在所指定设备地址中的值。如果所述内容为零,则微代码继续至命令流中的下一个分组。如果所述内容是非零的,则微代码进行循环,重新读取设备地址直到所读取的值为零为止。
如果存储器中序号3(SEM_LEN)和在信号量值之后DWORD都不等于2,则CP微引擎可能变得混乱并且最终使硬件中止。
在VPU上执行的驱动器/应用程序可以在任何时间把非零值写入到信号量存储器。所述应用程序能够写入非零值以使得CP微引擎在命令流中的下一个WAIT_MEM分组处暂停。其影响在于,使在间接和环形缓冲器中所排队的所有VPU渲染暂停。然后所述应用程序可以把零写入到信号量,以便允许微引擎继续进行。在表5中示出了依照一个实施例的WAIT_MEM信号量分组的格式。
表5
序号 | 字段名称 | 描述 |
1 | [HEADER] | 分组的字段首部 |
2 | SEM_ADDR[31:2] | 存储器信号量设备地址(所对准的DWORD)。此值被写入到CP_IB2_BASE以便读取所述信号量 |
3 | SEM_LEN | 存储器信号量长度此值必须为2此值被写入到CP_IB2_BUFSIZ以便第一时间读取信号量 |
图4是示出依照一个实施例用于帧同步的基于寄存器的信号量机制的图。VPU A 408和VPU B 410处于多VPU系统中。VPU A 408可以访问寄存器420 A,所述寄存器420 A是可用于存储各类数据的存储单元。VPU B 408可以访问寄存器420 B,所述寄存器420 B是可用于存储各类数据的存储单元。VPU A 408还可以访问VPU B寄存器420 B。VPU B 410还可以访问VPU A寄存器420 A。
所示出的命令缓冲器472包括将要由VPU A 408和VPU B 410执行的各种命令。从命令缓冲器472的顶部读取,存在四个渲染命令,然后是“VPUA释放VPU B信号量”命令。如从VPUA408到命令缓冲器472的箭头451 A以及从所述命令缓冲器472到VPU B寄存器420 B的虚线箭头451 B所示,此命令的效果在于,把值写入到VPU B寄存器420 B以便释放VPU B。
命令缓冲器472中的下一命令是VPU A等待信号量命令。如线路453 A所示,此命令的效果在于,把一个或多个值写入到VPU A 408寄存器420A。如前所述,该值防止VPUA继续执行。
命令缓冲器472中的下一命令是VPU B等待信号量命令。如线路453 B所示,此命令的效果在于,把一个或多个值写入到VPU B 410寄存器420 B。如前所述,该值防止VPU B继续执行。
命令缓冲器472中的下一命令是VPU B释放VPUA信号量命令。如从VPU B到命令缓冲器472的箭头452 B以及到寄存器420 A的虚线箭头452 A所示,其效果在于,把一个或多个值写入到寄存器420 A来释放VPU A以使其继续执行,如前所述。命令缓冲器中的下一线路声明“MVPU(多VPU)同步(sync)点”随着缓冲器中在该点处的命令出现。MVPU同步点包括要求在此所述的系统中的VPU之间进行帧同步的任何设备环境。渲染命令在同步点之后继续进行。
图5是示出依照一个实施例的用于帧同步的基于存储器的信号量机制的图。VPU A 508和VPU B 510处于多VPU系统中。VPU A 508可以访问VPU A存储器560 A。VPU B 510可以访问VPU B存储器560 B。VPU A 508还可以访问VPU B存储器560 B。VPU B 510还可以访问VPUA存储器560 A。存储器560在物理上可以位于任何地方。例如,存储器560 A和560 B可以处于可经由PCIE总线访问的系统存储器中的不同区域。作为替代,存储器560 A和560 B可以位于一个或多个VPU的本地存储器中。还可以跨过一个以上物理位置来分布存储器560。
所示出的命令缓冲器572包括将要由VPU A 508和VPU B 510执行的各种命令。从命令缓冲器572的顶部读取,存在四个渲染命令,然后是“VPU A释放VPU B信号量”命令。如从VPU A 508到命令缓冲器572的箭头551 A以及从所述命令缓冲器572到VPU B存储器560 B的虚线箭头551 B所示,此命令效果在于,把值写入到VPUB存储器560 B以便释放VPU B。
命令缓冲器572中的下一命令是VPU A存储器信号量命令。如线路553 A所示,此命令效果在于,当VPUA 508读取存储器560 A中的单元时,使VPU A 508的执行停滞。
命令缓冲器572中的下一命令是VPU B存储器信号量命令。如线路553 B所示,此命令效果在于,当VPU B 510读取存储器560 B中的单元时,使VPU B 510的执行停滞。
命令缓冲器572中的下一命令是VPU B释放VPU A信号量命令。如从VPU B 510到命令缓冲器572的箭头552 B以及到存储器560 A的虚线箭头552 A所示,其效果在于,把一个或多个值写入到存储器560 A来释放VPUA以使其继续执行,如前所述。命令缓冲器中的下一线路声明“MVPU(多VPU)同步点”随着在缓冲器中的该点处的命令出现。MVPU同步点包括要求在此所述的系统中的VPU之间的帧同步的任何设备环境。渲染命令在同步点之后继续进行。
图6是依照一个实施例的系统600的各个组件的框图。系统600包括主VPU卡652和从VPU卡654。主VPU卡652包括主VPU 608,并且从VPU卡654包括从VPU B 610。在一个实施例中,VPU 608和610均经由PICE总线634来通信。在一个实施例中,PCIE总线634是被划分成两个X8 PCIE总线635的X16总线。VPU A 608和B610中的每个都被连接到总线635。在一个实施例中,VPU A 608和VPU B 610只经由总线635通信。在一个候选实施例中,VPU A 608和VPU B 610部分经由总线635并且部分经由专用卡间连接637来通信。在其它实施例中,VPU A 608和VPU B 610专门地经由连接637来通信。
主VPU卡652包括IM 612。在其中VPU A 608和VPU B 610经由总线635通信的一个实施例中,每个VPU按照驱动器的指示来处理帧数据。作为图6中的一个例子,系统600在如下所述的“剪裁(scissoring)”负载平衡模式下执行视频处理。主VPU A 608产生输出606并且从VPU B 610产生输出611。输出606和611被输入到IM612以便合成,如下面进一步描述。在一个实施例中,从VPU B 610经由如同点划线路径663所示的总线635和634将其输出611传送到IM 612。在一个实施例中,从VPU B 610经由如同点划线路径661所示的专用卡间连接637将其输出611传送到IM 612。IM 612组合所述输出606和611以便生成用于显示的帧。此帧被IM 612经由连接器641输出到显示器630。
主VPU卡652包括连接器640和641。从VPU卡654包括连接器642和643。连接器640、641、642和643是本领域中公知的用于发送所需信号的连接器。例如,在一个实施例中连接器641是数字视频输入(digital video in,DVI)连接器。可以有多于或少于在图600中所示出的连接器数目。
在一个实施例中,这里所描述的各个配置可由用户配置,以便使用任意数目个可用的VPU进行视频处理。例如,系统600包括两个VPU,但是在穿越(pass-through)模式下,用户可以选择只使用一个VPU。在这种配置中,其中一个VPU可以是有效的,而另一个可能是无效的。在这种配置中,如这里所描述的任务共享或负载平衡可能是不可用的。然而,所启用的VPU可以执行常规的视频处理。从VPU卡B 654到显示器630的点划线路径665表示在穿越模式中可以单独使用从VPU B 610来用于视频处理。类似地,在穿越模式中可以单独使用主VPUA 608来用于视频处理。
图7是系统700的更详细的框图,所述系统700是与依照一个实施例的图6的系统类似的配置。所述系统700包括两个VPU卡,主VPU卡752和从VPU卡754。主VPU卡752包括主VPU A 708,并且从VPU卡754包括从VPU B 710。
主VPU卡752还包括接收器748和发送器750,其在一个实施例中用于接收和发送TDMS信号。在一个实施例中,双重连接器745是DMS连接器。主卡还包括用于向显示器输出数字视频信号的DVI连接器746,所述数字视频信号包括帧数据。主VPU卡752还包括视频数模转换器(DAC)。如同所示,连结模块(IM)712连接在VPU708和发送器以及接收器之间。VPU A 708包括集成的收发器(被标记为“集成”)和数字视频输出(DVO)连接器。
从VPU卡754包括两个DVI连接器747和748。从VPU B 710包括DVO连接器和集成的收发器。作为经由PCIE总线(未示出)进行通信的候选实施例,主VPU卡752和从VPU卡754经由专用的卡间连接737来通信。
图8-9是系统配置的其他实施例的图。图8是依照一个实施例的单卡系统800的图。所述系统800包括“超级卡(supercard)”或“巨卡(monstercard)”856,其包括一个以上的VPU。在一个实施例中,超级卡856包括两个VPU,主VPU A 808和从VPU B 810。超级卡856还包括IM 812,IM 812包括用于组合或合成来自两个VPU的数据的合成器,如下面所进一步描述。在其它实施例中还可以用专用的卡上VPU间连接来用于VPU间通信(未示出)。在一个实施例中,主VPU A 808和从VPU B 810均被连接到X8 PCIE总线835,所述X8 PCIE总线835源自X16 PCIE总线834。
所述系统800包括这里所描述的多个VPU(还被称为多VPU)的功能中的全部功能。例如,主VPU A 808按照驱动器的指示来处理帧数据,并且向IM 812输出所处理的帧数据809。从VPU B 810按照驱动器的指示来处理帧数据,并且输出所处理的帧数据811,所述帧数据811被传送到IM 812以便组合或合成。如前面参考图600所述,所述传送经由PCIE总线834或经由专用的VPU间连接(未示出)来执行。无论哪种情况,都将所合成的帧从IM 812输出到显示器830。
在穿越模式中还可以禁止多VPU能力并且使用其中一个VPU来独自执行视频处理。这例如借助短划线路径865来示出,所述短划线路径865图示了被连接到显示器830以输出用于显示的帧数据的从VPU B 810。在穿越模式中主VPUA 808还可以通过在路径866上输出帧数据来单独工作。
图9是依照一个实施例的单卡系统900的图。所述系统900包括“超级卡”或“巨卡”958,其包括一个以上的VPU。在一个实施例中,超级卡958包括两个VPU,主VPU A 908和从VPU B 910。超级卡958还包括IM 912,IM 912包括用于组合或合成来自两个VPU的数据的合成器,如这里所描述。在其它实施例中,还可以用专用的卡上VPU间连接来用于VPU间通信(未示出)。在一个实施例中,主VPU A 908和从VPU B 910均经由卡上桥981连接到X16 PCIE总线934。
所述系统900包括这里所描述的多VPU功能中的全部功能。例如,主VPU A 908按照驱动器的指示来处理帧数据,并且向IM 912输出所处理的帧数据909。从VPU B 910按照驱动器的指示来处理帧数据,并且输出所处理的帧数据911,所述帧数据911被传送到IM 912以进行组合或合成。如前面参考图600所述,所述传送经由PCIE总线934或经由专用的VPU间连接(未示出)来执行。无论哪种情况,都将所合成的帧从IM 912输出到显示器(未示出)。
在穿越模式中,还可以禁止多VPU能力并且使用其中一个VPU来独自执行视频处理。这例如借助短划线路径965来示出,所述短划路径965图示了被连接到输出端以便传送将要显示的帧的从VPU B910。在穿越模式中,主VPU A 908还可以通过在路径966上输出帧数据来单独工作。
图10是依照一个实施例的双卡系统1000的图。所述系统1000包括两个对等的VPU卡1060和1062。VPU卡1060包括VPU A 1008,并且VPU卡1062包括VPU 1010。在一个实施例中,VPU A 1008和VPU 1010是完全相同的。在其它实施例中,VPU A 1008和VPU B1010不是完全相同的。VPU A 1008和VPU 1010均被连接到从X16PCIE总线1034划分出来的X8 PCIE总线1035。VPU A 1008和VPU1010还均被连接,以便经由卡连接器向连结模块(IM)1012输出数据。在一个实施例中,IM 1012是“保护装置”中的集成电路,所述“保护装置”可被容易地连接到VPU卡1060和VPU卡1062。在一个实施例中,IM 1012是一个专门设计成包括这里所描述的所有合成功能的集成电路。IM 1012合并或合成由VPU A 1008和VPU 1010所输出的帧数据并且向显示器1030输出可显示的合成帧。
图11是依照一个实施例的双卡系统1100的图。所述系统1100类似于系统1000,但是被配置为在旁路模式下操作。系统1100包括两个对等体VPU卡1160和1162。VPU卡1160包括VPU A 1108,并且VPU卡1162包括VPU B 1110。在一个实施例中,VPU A 1108和VPU 1110是完全相同的。在其它实施例中,VPU A 1108和VPU B1110不是完全相同的。VPU A 1108和VPU B 1110均被连接到从X16PCIE总线1134划分出来的X8 PCIE总线1135。VPUA 1108和VPU1110还均被经由卡连接器连接,以便向连结模块(IM)1112输出数据。在一个实施例中,IM 1112是“保护装置”中的集成电路,所述“保护装置”可被容易地连接到VPU卡1160和VPU卡1162。在一个实施例中,IM 1112是一个专门设计成包括这里所描述的所有合成功能的集成电路。IM 1112还可配置为在穿越模式下操作,在所述穿越模式下,一个VPU独自操作而其它VPU未被启用。在这种配置中,如这里所描述的合成可能是不可用的。然而,启用的VPU可以执行常规的视频处理。在图11中,VPU A 1108被启用并且VPU B 1110被禁止,但是在旁路模式中,任何一个VPU可以工作,以便向显示器1130输出。
例如在图6-11中,如这里所示的配置目的是作为可能实施例的非限制性例子。其它配置也在如权利要求所定义的本发明的范围之内。例如,其它实施例包括在计算设备上安装或并入的第一VPU,所述计算设备诸如个人计算机(PC)、笔记本计算机、个人数字助理(PDA)、TV、游戏控制台、手持式设备等。第一VPU可以是集成VPU(也称为集成图形处理器或IGP)或者为非集成VPU。第二VPU被安装或并入到坞站(docking station)或外部封装单元。第二VPU可以是集成VPU或非集成VPU。
在一个实施例中,坞站专用于支撑第二VPU。第二VPU和第一VPU如这里所描述的进行通信,以便如所描述地协作执行视频处理并且生成输出。然而在这种实施例中,第二VPU和第一VPU经由一根或多根电缆或者易于连接和分离的其它机制来进行通信。这种实施例对于使计算设备能够通过与另一VPU协作来显著地增强其能力来说是特别有用的,所述计算设备在物理上可能很小并且具有有限的视频处理能力。
本领域普通技术人员应当理解,其他候选实施例可以包括在单片(single die)上的多个VPU(例如,单片上的两个VPU),或者在单个硅芯片上有多个核心。
图12是依照一个实施例的连结模块(IM)1212的框图。所有渲染命令都由系统中的每个VPU取出。在依照这里所描述的任何一个多VPU配置中,在VPU执行了所取出的命令之后,IM 1212合并来自多个VPU的像素和控制线路的流并且输出单个数字视频输出(DVO)流。
IM 1212包括主输入端口,用于接收来自主VPU的DVO流。在诸如在图10和11中所示出的那些配置的“保护装置”配置中,主VPU输入可以来自TDMS接收器。作为替代,在例如图6和7中所示的多卡配置中,主VPU输入可以来自主VPU卡上的主VPU。同步寄存器1502接收来自主VPU的DVO数据。
IM 1212还包括从输入端口,用于接收来自从VPU的DVO流。在诸如在图13和14中所示出的那些配置的“保护装置”配置中,从VPU输入可以来自TDMS接收器。作为替代,在例如图8和9中所示的“超级”VPU卡配置中,从VPU输入可以来自“超级”VPU卡结构上的从VPU。IM 1212包括从端口上的FIFO 1204,以便帮助在主VPU和从VPU之间同步输入流。
来自主VPU和从VPU的输入数据被传送到扩展模式混合器1214以及多路复用器(MUX)1216。IM 1212可配置为在多个合成模式下操作,如这里所描述。当如下面所进一步描述,通过扩展模式混合器1214,或者通过只选择非黑色像素进行显示,来组合由两个VPU所处理的帧的一部分时,整个帧都准备好进行显示。
控制逻辑确定IM 1212在哪种合成模式下操作。根据所述合成模式,扩展模式混合器或MUX会输出最终数据。当使用MUX时,控制逻辑决定哪个像素(主或从)通过所述MUX,该控制逻辑包括黑色寄存器1206和MUX路径逻辑与黑色比较器1208。数据被输出到TDMS发送器1218或DAC 1220。
使用黑色寄存器来允许软件设置已经进行了伽马调节的最终黑色值。
在一个实施例中,在多个VPU以及IM 1212之间的组件间通信包括多种I2C总线和协议。
如表6所示,通过I2C寄存器比特1224和TMDS控制比特1222的组合,来设置包括多种合成模式在内的多种操作模式。
表6:操作模式和控制比特
类别 | ||||
主 | 子 | 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:Bit | AFR_MAN_ON*=0AFR_AUTO*=1 | xAFR_MAS状态改变控制下一个数据路径 |
3=0 | ||||
连结 | AFR_AUTO | INTERLINK_ENABLE=1CONTROL_BITS_2:Bit3=0 | AFR_MAN_ON*=0AFR_AUTO*=0 | |
连结 | BLACKING | INTERLINK_ENABLE=1CONTROL_BITS_2:Bit3=0 | AFR_MAN_ON*=1AFR_AUTO*=x | 使用黑色像素来确定数据路径 |
连结 | SuperAA | INTERLINK_ENABLE=xCONTROL_BITS_2:Bit3=1 | n/a | CONTROL_BITS_2:Bit 4-7决定扩展模式 |
依照一个实施例,存在经由IM 1212的两个独立的数据路径。来自各个VPU的两个输入像素流中任意一个,通过MUX 1216(在穿越模式或“标准”连结模式中)进行处理,或者在扩展模式中通过混合器1214进行处理。在一个实施例中,所述扩展模式包括超级抗锯齿模式或“SuperAA模式”,如在一并待决的美国专利申请序号尚未分配、题目为“Antialiasing System and Method”中所描述,在此通过全部引用加以结合以供参考。
在MUX 1216中,选择来自VPU A或VPU B中任意一个的仅一个像素通过,并且不涉及任何像素处理。在扩展模式混合器1214中,在逐个像素基础上进行处理。在SuperAA模式中,例如,对所述像素进行处理、平均在一起、并且再次进行处理。在一个实施例中,处理步骤包括使用一个或多个查找表来产生中间或最终结果。
由I2C寄存器比特和控制比特来确定在MUX 1216路径和混合器1214路径之间的选择。例如,如果出现以下条件则选择混合器1214路径:
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 12的多个合成模式之一,来合成每个VPU所输出的处理数据,所述模式这里也被称作为“连结模式”和“合成模式”。IM 1212支持用于在许多VPU之间进行负载平衡的许多方法,包括超贴面(super-tiling)、剪裁(scissoring)以及交替帧渲染(alternate frame rendering,“AFR”),所有这些方法都是“变黑(blacking)”的组件。下面将描述这些模式。图13是用于图示由所述系统执行的各个负载平衡模式的图。来自系统中各个VPU的帧数据依照一种负载平衡模式来处理并且在合成器114中合成(例如图1所示),如在此所述,以便产生可显示的帧。
对于超贴面来说,软件驱动器控制确定贴面大小并且在图像数据和黑色贴面之间交替,以便在主和从VPU之间完全绘制每个帧。IM1212遍历非黑色像素(图像数据),在主输入和从输入之间创建超贴面类型的划分。如果想要的话,可以针对每对主和从帧来动态地调节贴面大小。超贴面可以把显示屏划分为棋盘图案,其中每个方块/贴面例如为32x32个像素。在多VPU系统的第一VPU上渲染图像贴面,而在第二VPU上渲染黑色贴面。超贴面为在渲染帧中的像素处理提供了细粒的负载分享、相对于其它负载平衡方法的更为均匀的像素负载分布、以及不太复杂的驱动实现方式。
剪裁把显示屏划分为两个部分,并且此划分可以是水平或垂直的。虽然当考虑软件实现和数据传输的灵活性时,水平划分可能更方便,然而垂直划分可以提供更好的负载平衡。在多个VPU的设备环境中,剪裁在利用3D渲染使数据传输并行化方面提供了优化机会。剪裁还支持从VPU(用于执行大部分数据转送)比主VPU进行更少量的工作的方法,由此使在主和从VPU之间的动态负载平衡方案便于进行。
剪裁包括垂直划分屏幕变黑控制和水平划分屏幕变黑控制。在垂直划分屏幕变黑控制的情况下,驱动器确定由主和从VPU分别输出帧的哪一端,从而使得在两个VPU之间完全绘制每个帧。每个VPU所不处理的帧部分被驱动器清除为黑色。然后IM 1212按照主和从VPU之间的垂直划分连结两个帧。所述划分不必是对屏幕的均匀划分(例如,每个VPU渲染50%),其可以针对每对主从帧来动态地调整。
在水平划分屏幕变黑控制的情况下,软件驱动器确定主和从VPU分别输出帧的上或下部分中的哪一个部分。然后驱动器进行清除以便把没有保持有效帧缓冲器数据的部分变为黑色,并且IM 1212按照对输入的水平划分,对所述输入进行混合。所述划分不必是对屏幕的均匀划分(例如,每个VPU渲染50%),其可以针对每对主从帧来动态地调整。
交替帧渲染(“AFR”)在帧级别上执行负载平衡。这里所提及的“帧”包括在发出显示缓冲器交换/翻转命令之前由应用程序所发出的渲染命令的序列。AFR通常根据IM 1212的交替输入,来把每个新的帧传送到输出端。一个VPU渲染偶数帧,而另一个VPU渲染奇数帧,但是实施例不受此限制。AFR允许对于整个3D流水线进行性能扩展,并且对于许多情况而言避免了渲染到纹理(render-to texture)的卡到卡(card-to-card)的数据传送。
一个实施例的IM 1212可以在人工控制、具有自动VSync切换的人工控制或变黑控制之下执行AFR。当使用人工控制时,驱动器为在下一个VSync之后的帧手动选择IM 1212的输入。采用使用具有VSync切换的人工控制的AFR,并且在下一垂直消隐(verticalblank)之后,IM 1212将耦合到主VPU的输入端选择为输出源,然后在每个VSync时自动地在主和从VPU之间进行切换。使用变黑控制,驱动器交替从主和从VPU发送完全绘制的帧和被清除为黑色的帧;结果,IM 1212在主和从帧之间切换。
其它合成策略是可用的并且不受IM 1212的限制。例如,扩展连结模式也是可用的,其超出了手动AFR和变黑模式的负载分享使用。这些模式虽然不是用于通过在多个VPU之间共享处理来净化速度增益的标准连结,但是通过把功能从VPU卸载到IM 1212上,提高了系统的质量和/或速度。作为扩展状态的一个例子,一个实施例的IM1212支持除了手动AFR和变黑模式之外的先前所提及的“SuperAA”模式。
再次参照图12,IM 1212支持多种输入模式以及单或双重链路TMDS宽度,这取决于输入连通性。IM 1212还包括计数器,用于监视在两个输入端的HSyncs和VSyncs之间的相位差。计数器可以包括像素/帧计数器,用于帮助匹配在这两个输入流上的时钟。
参照表7,在一个实施例中,IM 1212具有三个计数器1210。每个计数器都使主像素时钟递增,并且使用其中一个VSyncs来进行锁存和清除。
如果发生对I2C计数器的读取,则拖延对该寄存器的更新,直到在所述读取完成之后。如果发生对寄存器的写入,则延迟所述读取,直到所述写入完成为止。读取延迟只有几个IM内部时钟,因此对软件来说是透明的。
表7: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 1212。在这里被称作为“保护装置”的一种配置中,IM 1212接收两个独立的TMDS输出,其每一个均来自两个独立的VPU,并且IM 1212通过两个TMDS接收器把它们传递到所述保护装置上。然后独立的接收器把两个DVO流直接输出到保护装置的IM 1212中。IM 1212把两个所接收的输入混合到单个输出流中。然后来自IM 1212的输出DVO信号被馈送到TMDS发送器或经由DAC进行馈送,TMDS发送器和DAC都是通过在保护装置上的标准DVI-I连接器来驱动的。
在这里被称为“卡上”配置的另一配置中,IM 1212直接从存在于与IM 1212相同的卡上的两个VPU接收两个DVO信号流。与保护装置配置相对比,该卡上配置在VPU和IM 1212之间并不使用TMDS发送器或接收器。IM 1212把两个接收的输入混合到单个输出流中。然后来自IM 1212的输出DVO信号被馈送到TMDS发送器或经由DAC馈送,TMDS发送器和DAC例如都通过标准的DVI-I连接器来驱动。
在IM 1212输入端上接收的输入流这里可以被称作“主输入”和“从输入”,并且是分别从主和从VPU接收的。主和从VPU可以在两个独立的卡上或在单个“超级”卡上。任何一个VPU可以都可以作为主或从VPU。
主VPU被用作主时钟,并且将从时钟同步(“synced”)到该主时钟。除正常的卡初始化过程之外,不调节或调谐主时钟。从VPU被调节为略在主VPU之前运行,以便实行同步和FIFO等待时间。从VPU使用较大的FIFO,以便补偿在两个VPU的像素时钟速率之间的偏差,而主VPU路径只使用浅的FIFO,以便把主输入时钟域同步到内部DVO时钟域。在主和从VPU之间的流控制包括:两个VPU的初始同步,然后是对从VPU进行调节以便与主VPU相匹配。流控制包括:响应于IM 1212内的计数器,经由IM 1212或驱动器动作所产生的像素拖延信号进行的时钟调节。
如上所述的IM 1212支持多种操作模式,包括穿越模式和各个连结模式,如表1中所图示。如这里所描述,通过I2C寄存器比特和TMDS控制比特的组合来设置这些操作模式。
穿越模式是直接把IM 1212的输入传递到输出(监视器)的模式。借助初始切换I2C时钟,来在上电时选择所使用的输入端口。可以通过把ENABLE_INTERLINK寄存器从“1”切换回到“0”然后切换期望端口的I2C时钟,来再次改变路径。
连结模式包括多种模式,在这些模式中,IM 1212依照各种组合把从主和从VPU接收的输入耦合到输出。实施例的双重VPU连结模式包括但不局限于双重AFR连结模式(Dual AFR Interlink Mode)和双重变黑连结模式(Dual Blacking Interlink Mode)。
双重VPU连结模式是通过手动AFR控制或通过变黑模式来使用两个VPU的模式。在这些模式中,在操作期间对两个IM 1212端口连续地进行输出。
双重AFR连结模式包括在两个输入端口之间交替IM 1212输出源的模式。一旦根据VSync而开始,它可以由IM 1212驱动器手动进行,或者自动地进行。双重AFR连结模式的控制包括使用以下比特/状态:AFR_MAN_ON*=低;AFR_AUTO*=高或低;AFR_MAS(用于控制此时哪个卡正在输出,或者用于设置要自动切换的第一个卡)。
图14示出了IM的路径控制逻辑。oClk是输出像素时钟。oClk是直接根据来自从端口的sClk,在从通路(passthru)中产生的。在连结或主穿越模式中,oClk是根据来自主端口的、具有相同计时的mClk直接产生的。oClk:mDE简单地是被同步到oClk时域中的主端口的mDE信号。
双重变黑连结模式包括多种模式,在这些模式中,两个VPU并行进行输出,并且IM 1212通过为任何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*被置为无效为止。
I2C寄存器反映在结果动作发生之后的结果。其并不直接反映所时钟计时的比特。
在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 1212中的数据和控制路径,双重VPU连结模式在路由模式中工作,所述路由模式包括穿越、双重/单个输入、AFR手动连结和双重输入变黑连结。这些路由模式描述了来自两个接收器的哪些数据和控制线路经由发送器或DAC发送到IM 1212之外。表8示出了在一个实施例中,按照IM 1212的路由选择模式的数据、控制和时钟路由。
所述时钟是像素时钟,内部控制线是在TMDS发送器和接收器(和IM 1212)之间连接的线路,并且外部控制线路是不由诸如I2C和热插拔之类的TMDS电路处理的线路。从像素拖延信号在IM 1212和从DVI VSync引脚之间直接游走。
表8
路由模式 | 时钟 | 内部控制 | 旁路控制 | 数据 | 注释 |
穿越 | 主或从 | 主或从 | 主或从 | 主或从 | 通过第一I2C时钟切换来设置 |
AFR手动 | 主或从 | 主或从 | 主或从 | 主或从 | 由AFR MAN控制比特来设置 |
变黑 | 主 | 主 | 主 | 主或从 | 根据黑色像素来连结数据 |
当在单个VPU模式中使用IM 1212时,并且在驱动器为双重VPU模式设置了IM 1212和VPU之前,出现穿越。在加电时,IM 1212默认MUX把所有数据和控制线路直接从主VPU传递到所述IM 1212的输出端。一旦IM 1212发现一个输入TMDS I2C时钟发生切换,它就把MUX设置为把该特定通道传递到输出端。这包括时钟和所有控制信号,而不管它是来自主还是从VPU。这就允许IM 1212在BIOS上电操作期间,甚至在驱动器知道存在IM 1212之前,就把系统的默认视频卡直接连接到监视器。
在双重VPU连结模式中,一旦加载了驱动器,则所述驱动器可以检测IM 1212是否存在以及存在到IM 1212的一个连接还是两个连接。通过经由每个VPU的端口读取IM 1212的I2C ID寄存器,来进行该检测。驱动器可以按照在每个端口上所读取的IM 1212 ID寄存器的第0个比特的值,来确定哪个所发现的连接是主连接,以及哪个所发现的连接是从连接。
如果只发现一个连接,则IM 1212留在穿越模式中。如果发现两个到IM 1212的连接,则驱动器接管屏幕控制,设置IM 1212的MUX以便从主端口输出,并且将连接到主端口的VPU作为主VPU。从此端口来驱动时钟,直到掉电或者到IM 1212的输入连接之一被断开。
一个实施例的MUX是通过包括穿越初始状态、AFR人工控制和变黑控制的机制来设置的。通过TMDS CNTR比特来设置这些模式以及用于每个模式的特定控制,并且IM 1212在下一垂直消隐期间作出响应。根据I2C控制比特设置,在下一个HSync或下一个VSync时,主/从切换(AFR_MAS)可以锁存/出现。
除了使用TDMS控制寄存器之外,驱动器还使用I2C控制寄存器来控制并监视IM的功能。
I2C寄存器用于进行控制和监视,控制和监视不需要在每帧都进行或更快的进行不必发生什么。寄存器可以对于IM的主和从端口而言都可用。
对于更为动态的控制来说,I2C控制寄存器用于设置不同的多VPU模式,并且用于手动地切换IM数据路径。
在视频处理系统的一个实施例中,使用集成电路间(Inter-Intergrated Circuit,I2C)总线来实现用于IM的集成电路间通信。I2C是典型情况下用于连接集成电路(IC)的总线。I2C是多主总线,这意味着可以把多个IC连接到同一总线,并且每一个IC通过发起数据传送来作为主装置。
图15是用于保护装置1570上的IM 1512的实施例的图,其示出了各个I2C路径。保护装置1570接收来自主VPU A和从VPU B的数据。在一个实施例中,主VPU A和从VPU B存在于一个或多个VPU卡上。在一个实施例中,对于IM 1512来说存在三个独立的I2C总线。存在来自两个输入端口中的每一个的I2C总线,所述输入端口是主输入端口和从输入端口。第三I2C总线从IM 1512去往发送器,以及任何已连接的输出设备,诸如面板和/或阴极射线管(CRT)。
两个输入I2C总线都经由DVI主和从输入端口馈送到保护装置1870中,并且在两个独立通道上直接馈送到IM 1812中。
图1 6是依照一个实施例的IM 1612内的I2C路径的图。IM 1612包括主标识(ID)I2C寄存器和从ID I2C寄存器。IM 1612还包括SDC切换传感器、MUX及其它I2C寄存器。
VPU A或VPU B中的任何一个可以通过各自的输入端口来直接访问ID寄存器,而不考虑I2C总线所有权。
IM 1612具有一组寄存器,该组寄存器可以在特定的I2C设备地址上由I2C访问。所有其它地址通过IM 1612而传送到I2C输出端口上。
主ID寄存器和从寄存器均具有同一内部地址,但是只可从它们各自的I2C总线(从或主)来访问。
除了IM_xxx_ID寄存器(偏移0)和I2C_Reset寄存器之外,使用一种先出现先服务(first com,first serve)的仲裁机制,按照I2C的逐个周期的基础,来对I2C总线进行仲裁。
对于多字节寄存器的读取周期来说,保持所有权直到读取最后的字节为止。软件驱动器确保依照从底到顶的顺序来完全读取所有字节。如果依照从底到顶顺序没有完全读取所有字节,则所述总线可以会保持锁定并且工作情况可以变为是未定义的。
对于通过IM 1612传递到外部设备的访问来说,IM 1612不理解页面寻址或者任何周期,所述周期要求与先前访问中的任何动作的相关性(延续一个以上I2C停止比特的周期)。因此,增加寄存器的比特(CONTROL_BITS_2:比特0:I2C_CLOCK)。如果需要多I2C访问,则软件会设置此寄存器比特。当此寄存器比特被设置时,总线被专门地给予该端口,直到所述比特被复原为止,此时恢复自动仲裁。在两个端口试图设置此比特的情况下,则标准的仲裁方法确定哪个端口获得访问,并且发送否定应答(negative acknowledgement,NACK)信号以便让该请求者知道没有成功。
在I2C总线由于一些意外原因而被锁定的情况下使用特殊的I2C_Reset寄存器。对此寄存器的任何读取,不管I2C总线的所有权如何,都会始终强迫I2C状态机复位并释放I2C总线所有权,将其恢复到自动仲裁。
对于其它I2C寄存器来说,按照先出现先服务方式来动态地仲裁I2C总线所有权。用于首先利用时钟和起始比特来访问其它寄存器的输入端口,在当前I2C周期的持续时间内获得所有权(即,直到下一停止比特为止)。对于IM 1612上的多字节读取寄存器(计数器)来说,从所读取的第一个字节开始维持所述所有权,直到已经读取了寄存器的最后字节为止。
如果在总线已经被许可给另一输入端口之后开始I2C访问,则响应于该访问尝试而发送否定应答(NACK)信号。待读取的数据未被定义,并且写入被丢弃。
IM 1612支持对访问离开IM 1612的单个非页面类型的I2C访问。为了允许在多个相关类型的I2C周期期间锁定I2C总线,如果输入端口把I2C_LOCK比特(I2C_CONTROL_2:比特0)设置为1,则把I2C总线保持到该端口的所有权中直到同一端口把同一比特设置回0。此寄存器遵循相同的先出现先服务的仲裁协议。
如果从任何一个端口读取I2C_RESET寄存器(不要求仲裁或所有权),则I2C状态机被复位并且任何I2C所有权被清除。
图17是依照一个实施例,用于主VPU A和IM 1712处于同一VPU卡1752上的配置的I2C总线路径的图。VPU卡1752例如可以是图8的系统的一部分。VPU卡1752包括主VPU 1708、IM 1712、DVI发送器和可选的DVI发送器。存在三个I2C总线(主、从和连结),如所示的进入和离开IM 1712。在一个实施例中,连结I2C总线是主I2C总线或从I2C总线的继续,这取决于哪个总线被首先被访问。
所有IM 1712 I2C寄存器都可以用于从或主I2C端口。如果I2C总线目前由其它路径使用,则使用标准的NACK进行响应。IM 1712设备ID是一个例外,其能够同时由任何一个端口来访问。
为了选择性地验证I2C周期是否已经成功地完成,所有写入寄存器都必须可被写回的。由于IM 1712上的I2C寄存器没有超时,所以这与在各种常规视频卡上所使用的现有I2C访问方法相匹配。不是必须要进行读回来验证写入。
每当IM 1712 I2C得到停止比特时,IM 1712 I2C复位其状态机(未示出)。依照已知的I2C协议,在每个I2C周期的开始和结束时发生。
CONTROL_ONESHOTS寄存器(未示出)具有与其它读取/写入寄存器不同的行为。一旦被写入,IM 1712就把其结果锁存到内部控制比特。在CONTROL_ONESHOTS寄存器本身在下次读取此寄存器时被清除(允许对所述写入进行确认)。
一旦IM 1712完成了所请求功能并且CONTROL_ONESHOTS寄存器的相应比特被清除,则CONTROL_ONESHOTS比特的内部拷贝被IM 1712自动清除。IM 1712不会重新锁存内部版本直到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自动清除。
例如在诸如图10和11中的保护装置配置中,通过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 (21)
1.一种系统,包括:
系统存储器,由所述系统中的组件经由总线共享;
多个处理器,用于对共同任务进行共享处理,每个所述处理器包括从包含以下各项的组中所选择的至少一种通信机制:本地存储器、信号量机制、以及用于经由所述总线访问所述系统存储器的虚拟存储器机制;以及
驱动器,被耦合到所述多个处理器中的每一个,用于向每个所述处理器并发地发出相同的命令缓冲器以便完成所述共同任务,其中,所述共同任务的完成包括至少一个同步点,所述命令缓冲器包括用于在所述同步点处协调数据传送的至少一种同步机制,所述至少一种机制从包含以下各项的组中选出:所述信号量机制、所述虚拟存储器机制、以及经由所述系统总线访问所述系统存储器。
2.一种系统,包括:
至少一个驱动器,可配置为构建与执行处理任务相关的一组命令和数据;以及
多个处理器,被耦合来接收该组命令和数据,并且可配置为共享所述处理任务,其中,所述多个处理器还可配置为,使用根据该组命令和数据而确定的通信机制来彼此通信,以便使所述处理任务同步。
3.如权利要求2所述的系统,其中,所述多个处理器每一个都包括:
至少一个存储设备,可由所述多个处理器经由所述通信机制进行访问;
至少一个寄存器,可由所述多个处理器经由所述通信机制进行访问;以及
通信单元,包括信号量机,所述信号量机可配置为便于实现所述通信机制。
4.如权利要求3所述的系统,其中,该组命令和数据包括:
至少一个信号量命令,用于使所述多个处理器中的至少一个读取在该处理器的至少一个存储设备中和/或者在该处理器的至少一个寄存器中的一等待信号量;以及
至少一个信号量命令,用于使所述多个处理器中的至少一个把信号量写入到另一处理器的至少一个存储设备和/或者至少一个寄存器中,以便释放一等待信号量。
5.如权利要求2到4中任何一项所述的系统,其中:
所述多个处理器包括视频处理单元(VPU);并且
所述共享处理任务包括渲染视频帧。
6.如权利要求5所述的系统,其中,所述共享处理任务包括至少一个同步点,所述同步点包括:
VPU到VPU的数据传送;
交换锁定事件;以及
将所述视频帧渲染到共享存储器。
7.一种视频处理设备,被配置为:
接收一组共用的命令,该组共用命令可以被所述设备和其它视频处理器并发地进行解释;并且
解释在该组共用命令中的同步命令,以便访问在所述设备之外存储的信息,其中,所述信息与将要由所述设备采取的动作相关,所述动作用于使所述设备和其它视频处理器对该组命令的并发执行进行同步,其中,所述同步命令包括信号量命令和存储器访问命令。
8.一种视频处理卡,包括:
被配置为构建用于处理视频数据的一组命令的电路,包括在同步点处插入用于使执行该组命令的多个处理器同步的同步命令;以及
被配置为接收该共用组并且解释在该组共用命令中的同步命令以便访问在所述卡之外存储的信息的电路,其中,所述信息与将要由所述电路采取的动作相关,所述动作用于使所述电路及在所述卡之外的其它电路对该组命令的并发执行进行同步,其中,所述同步命令包括信号量命令和存储器访问命令。
9.一种多处理器方法,包括:
多个处理器中的每一个接收与任务相关的一组命令;并且
所述多个处理器共享对所述任务的执行,并且所述共享包括按照要求进行动作同步,以便在没有错误的情况下执行所述任务,其中,同步包括按照该组命令的指示,经由信号量机制来进行处理器间通信。
10.如权利要求9所述的方法,还包括:驱动器构建该组命令,包括插入信号量命令和同步点。
11.如权利要求10所述的方法,其中,所述任务包括渲染视频帧,并且所述同步点包括在该组命令中发生同步的点,所述同步点包括:
VPU到VPU的数据传送;
交换锁定事件;以及
将所述视频帧渲染到共享存储器。
12.如权利要求9到11中任何一项所述的方法,其中,所述多个处理器包括视频处理单元(VPU),并且其中,同步还包括:第一VPU和第二VPU访问彼此的寄存器和/或本地存储器以便同步所述任务的执行。
13.如权利要求12所述的方法,其中,对于所述任务的执行进行同步的步骤包括:所述第一VPU停滞其自己的执行,包括依照在该组命令中的命令来读取其自己的寄存器和/或本地存储器中的寄存器信号量。
14.如权利要求13所述的方法,其中,同步还包括:所述第二VPU依照在该组命令中的命令把寄存器信号量写入到所述第一VPU的寄存器和/或本地存储器,以便把所述第一VPU从停滞中释放。
15.如权利要求9到14中任何一项所述的方法,其中,同步包括:经由共享存储器信号量机制来在所述多个处理器之间进行通信。
16.一种其上存储有指令的计算机可读介质,所述指令当在系统中执行时,使所述系统执行依照权利要求9到15中任何一项所述的多处理方法。
17.一种其上存储有指令的计算机,所述指令当在视频处理驱动器中执行时,使所述驱动器执行一种多处理方法,所述方法包括:
并发地为多个处理器中的每一个创建共用命令缓冲器,以便完成共同的视频处理任务,其中,所述多个处理器经由系统总线耦合;并且
使所述共用命令缓冲器可用于所述多个处理器中的每一个,其中,所述共同任务的完成包括至少一个同步点,所述命令缓冲器包括用于在所述同步点处协调数据传送的至少一种同步机制,所述至少一种机制从包含以下各项的组中选出:信号量机制、虚拟存储器机制、以及经由系统总线来访问系统存储器。
18.如权利要求17所述的介质,其中,创建所述共用命令缓冲器的步骤包括:在同步点插入信号量命令。
19.一种视频处理方法,包括:
接收包括命令、数据的一组命令,其中,所述命令至少包括同步命令;并且
响应于对所述至少一个同步命令的解释来改变正常的命令执行流,其中,所述至少一个同步命令包括被解释来导致读取信号量寄存器的信号量命令以及被解释来导致读取存储单元的存储器命令。
20.一种其上存储有指令的计算机可读介质,所述指令当被处理时适合于产生能够执行一种方法的电路,所述方法包括:
构建用于处理视频数据的一组命令,所述构建包括:在同步点处插入用于使执行该组命令的多个处理器同步的同步命令;
接收该组命令,并且
执行该组命令中的指定部分,所述执行包括解释在同步点处的同步命令,其中,所述同步命令包括被解释来导致读取信号量寄存器的信号量命令以及被解释来导致读取存储单元的存储器命令,并且其中,所述同步命令便于实现在所述多个处理器之间的处理器间通信。
21.一种借助如权利要求9到15或19中任何一项所述的方法而产生的数字图像。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/140,114 US20060271717A1 (en) | 2005-05-27 | 2005-05-27 | Frame synchronization in multiple video processing unit (VPU) systems |
US11/140,114 | 2005-05-27 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101198988A true CN101198988A (zh) | 2008-06-11 |
Family
ID=37075081
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006800175207A Pending CN101198988A (zh) | 2005-05-27 | 2006-05-26 | 在多个视频处理单元(vpu)的系统中的帧同步 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20060271717A1 (zh) |
EP (2) | EP1883904B1 (zh) |
CN (1) | CN101198988A (zh) |
WO (1) | WO2006129194A2 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103299347A (zh) * | 2011-12-31 | 2013-09-11 | 华为技术有限公司 | 基于云应用的在线渲染方法和离线渲染方法及相关装置 |
CN105103139A (zh) * | 2013-04-11 | 2015-11-25 | 高通股份有限公司 | 用于改善跨越相干总线的信号量管理序列的性能的方法和设备 |
CN105934744A (zh) * | 2013-12-06 | 2016-09-07 | 并发投资有限责任公司 | 用于在硬件中跨多个处理单元/处理器划分并同步处理任务的系统和方法 |
CN108133453A (zh) * | 2017-12-13 | 2018-06-08 | 北京奇虎科技有限公司 | 一种基于OpenGL的图像处理器及其功能扩展方法 |
CN111787185A (zh) * | 2020-08-04 | 2020-10-16 | 成都云图睿视科技有限公司 | 一种vpu平台下的多路摄像头数据实时处理的方法 |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8054314B2 (en) * | 2005-05-27 | 2011-11-08 | Ati Technologies, Inc. | Applying non-homogeneous properties to multiple video processing units (VPUs) |
US7629978B1 (en) * | 2005-10-31 | 2009-12-08 | Nvidia Corporation | Multichip rendering with state control |
JP4327173B2 (ja) * | 2006-04-19 | 2009-09-09 | 株式会社ソニー・コンピュータエンタテインメント | グラフィックスプロセッサ、描画処理装置および描画制御方法 |
TWI376605B (en) * | 2006-09-04 | 2012-11-11 | Novatek Microelectronics Corp | Method and apparatus for enhancing data rate of advanced micro-controller bus architecture |
GB0715000D0 (en) * | 2007-07-31 | 2007-09-12 | Symbian Software Ltd | Command synchronisation |
US20090138647A1 (en) * | 2007-11-26 | 2009-05-28 | Hagita Yasuharu | Bus switch, electronic equipment, and data transfer method |
US9542192B1 (en) * | 2008-08-15 | 2017-01-10 | Nvidia Corporation | Tokenized streams for concurrent execution between asymmetric multiprocessors |
US8356200B2 (en) * | 2008-09-26 | 2013-01-15 | Apple Inc. | Negotiation between multiple processing units for switch mitigation |
US9307267B2 (en) * | 2008-12-11 | 2016-04-05 | Nvidia Corporation | Techniques for scalable dynamic data encoding and decoding |
TWI534753B (zh) * | 2009-01-07 | 2016-05-21 | 創新科技有限公司 | 用於分段處理輸入資料之資料處理裝置、使用該裝置之系統及用於資料傳輸之方法 |
US8675002B1 (en) * | 2010-06-09 | 2014-03-18 | Ati Technologies, Ulc | Efficient approach for a unified command buffer |
US20120001925A1 (en) | 2010-06-30 | 2012-01-05 | Ati Technologies, Ulc | Dynamic Feedback Load Balancing |
TW201344452A (zh) * | 2012-04-20 | 2013-11-01 | Beyond Innovation Tech Co Ltd | 內部整合電路介面的資料傳輸裝置及方法 |
US8930584B2 (en) * | 2012-08-09 | 2015-01-06 | Oracle International Corporation | System and method for providing a linearizable request manager |
CN102905054B (zh) * | 2012-10-23 | 2017-11-21 | 上海佰贝科技发展有限公司 | 一种基于图像多维特征值比对的视频同步方法 |
US9064437B2 (en) * | 2012-12-07 | 2015-06-23 | Intel Corporation | Memory based semaphores |
CN103077139B (zh) * | 2013-02-01 | 2016-05-11 | 威盛电子股份有限公司 | 使用内部集成电路总线的集成电路及其控制方法 |
US9088305B2 (en) | 2013-07-08 | 2015-07-21 | Blackberry Limited | Docking station connectivity monitor/controller |
US8868808B1 (en) * | 2014-03-26 | 2014-10-21 | Cae Inc. | Configurable simulator with a plurality of configurable modular cards |
US10902545B2 (en) * | 2014-08-19 | 2021-01-26 | Apple Inc. | GPU task scheduling |
CN104331297A (zh) * | 2014-11-28 | 2015-02-04 | 广东威创视讯科技股份有限公司 | 一种渲染引擎的绘制方法及装置 |
US11055806B2 (en) * | 2015-02-27 | 2021-07-06 | Advanced Micro Devices, Inc. | Method and apparatus for directing application requests for rendering |
US10593299B2 (en) * | 2016-05-27 | 2020-03-17 | Picturall Oy | Computer-implemented method for reducing video latency of a computer video processing system and computer program product thereto |
Family Cites Families (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA1309198C (en) * | 1987-12-10 | 1992-10-20 | Carlo J. Evangelisti | Parallel rendering of smoothly shaded color triangles with anti-aliased edges for a three dimensional color display |
US5428754A (en) * | 1988-03-23 | 1995-06-27 | 3Dlabs Ltd | Computer system with clock shared between processors executing separate instruction streams |
US5459835A (en) * | 1990-06-26 | 1995-10-17 | 3D Labs Ltd. | Graphics rendering systems |
EP0541534A1 (en) * | 1990-08-03 | 1993-05-19 | Du Pont Pixel Systems Limited | Data-array processing systems |
US5434970A (en) * | 1991-02-14 | 1995-07-18 | Cray Research, Inc. | System for distributed multiprocessor communication |
US5361370A (en) * | 1991-10-24 | 1994-11-01 | Intel Corporation | Single-instruction multiple-data processor having dual-ported local memory architecture for simultaneous data transmission on local memory ports and global port |
US6359624B1 (en) * | 1996-02-02 | 2002-03-19 | Kabushiki Kaisha Toshiba | Apparatus having graphic processor for high speed performance |
US6278645B1 (en) * | 1997-04-11 | 2001-08-21 | 3Dlabs Inc., Ltd. | High speed video frame buffer |
US6377266B1 (en) * | 1997-11-26 | 2002-04-23 | 3Dlabs Inc., Ltd. | Bit BLT with multiple graphics processors |
US6476816B1 (en) * | 1998-07-17 | 2002-11-05 | 3Dlabs Inc. Ltd. | Multi-processor graphics accelerator |
WO2000004494A1 (en) * | 1998-07-17 | 2000-01-27 | Intergraph Corporation | Graphics processing system with multiple strip breakers |
US6243107B1 (en) * | 1998-08-10 | 2001-06-05 | 3D Labs Inc., Ltd. | Optimization of a graphics processor system when rendering images |
US6191800B1 (en) * | 1998-08-11 | 2001-02-20 | International Business Machines Corporation | Dynamic balancing of graphics workloads using a tiling strategy |
US6677952B1 (en) * | 1999-06-09 | 2004-01-13 | 3Dlabs Inc., Ltd. | Texture download DMA controller synching multiple independently-running rasterizers |
US6720975B1 (en) * | 2001-10-17 | 2004-04-13 | Nvidia Corporation | Super-sampling and multi-sampling system and method for antialiasing |
US6816952B1 (en) * | 2002-05-31 | 2004-11-09 | Unisys Corporation | Lock management system and method for use in a data processing system |
US6885376B2 (en) * | 2002-12-30 | 2005-04-26 | Silicon Graphics, Inc. | System, method, and computer program product for near-real time load balancing across multiple rendering pipelines |
US7120816B2 (en) * | 2003-04-17 | 2006-10-10 | Nvidia Corporation | Method for testing synchronization and connection status of a graphics processing unit module |
US7119808B2 (en) * | 2003-07-15 | 2006-10-10 | Alienware Labs Corp. | Multiple parallel processor computer graphics system |
US7015915B1 (en) * | 2003-08-12 | 2006-03-21 | Nvidia Corporation | Programming multiple chips from a command buffer |
US7525547B1 (en) * | 2003-08-12 | 2009-04-28 | Nvidia Corporation | Programming multiple chips from a command buffer to process multiple images |
US6956579B1 (en) * | 2003-08-18 | 2005-10-18 | Nvidia Corporation | Private addressing in a multi-processor graphics processing system |
US7075541B2 (en) * | 2003-08-18 | 2006-07-11 | Nvidia Corporation | Adaptive load balancing in a multi-processor graphics processing system |
US7545380B1 (en) * | 2004-12-16 | 2009-06-09 | Nvidia Corporation | Sequencing of displayed images for alternate frame rendering in a multi-processor graphics system |
JP2006185348A (ja) * | 2004-12-28 | 2006-07-13 | Fujitsu Ltd | マルチプロセッサシステム及びロックフラグ操作方法 |
US20060238964A1 (en) * | 2005-04-25 | 2006-10-26 | Cho-Hsine Liao | Display apparatus for a multi-display card and displaying method of the same |
-
2005
- 2005-05-27 US US11/140,114 patent/US20060271717A1/en not_active Abandoned
-
2006
- 2006-05-26 WO PCT/IB2006/001702 patent/WO2006129194A2/en not_active Application Discontinuation
- 2006-05-26 EP EP06779753.0A patent/EP1883904B1/en active Active
- 2006-05-26 EP EP10075697A patent/EP2280379A3/en not_active Withdrawn
- 2006-05-26 CN CNA2006800175207A patent/CN101198988A/zh active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103299347A (zh) * | 2011-12-31 | 2013-09-11 | 华为技术有限公司 | 基于云应用的在线渲染方法和离线渲染方法及相关装置 |
CN105103139A (zh) * | 2013-04-11 | 2015-11-25 | 高通股份有限公司 | 用于改善跨越相干总线的信号量管理序列的性能的方法和设备 |
CN105103139B (zh) * | 2013-04-11 | 2018-04-20 | 高通股份有限公司 | 用于改善跨越相干总线的信号量管理序列的性能的方法和设备 |
CN105934744A (zh) * | 2013-12-06 | 2016-09-07 | 并发投资有限责任公司 | 用于在硬件中跨多个处理单元/处理器划分并同步处理任务的系统和方法 |
CN105934744B (zh) * | 2013-12-06 | 2019-05-17 | 并发投资有限责任公司 | 用于在硬件中跨多个处理单元/处理器划分并同步处理任务的系统和方法 |
CN108133453A (zh) * | 2017-12-13 | 2018-06-08 | 北京奇虎科技有限公司 | 一种基于OpenGL的图像处理器及其功能扩展方法 |
CN111787185A (zh) * | 2020-08-04 | 2020-10-16 | 成都云图睿视科技有限公司 | 一种vpu平台下的多路摄像头数据实时处理的方法 |
CN111787185B (zh) * | 2020-08-04 | 2023-09-05 | 成都云图睿视科技有限公司 | 一种vpu平台下的多路摄像头数据实时处理的方法 |
Also Published As
Publication number | Publication date |
---|---|
EP2280379A3 (en) | 2011-03-16 |
EP2280379A2 (en) | 2011-02-02 |
WO2006129194A3 (en) | 2007-02-22 |
WO2006129194A2 (en) | 2006-12-07 |
US20060271717A1 (en) | 2006-11-30 |
EP1883904B1 (en) | 2013-09-04 |
EP1883904A2 (en) | 2008-02-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101218562B (zh) | 一种多处理器方法和装置 | |
CN101198988A (zh) | 在多个视频处理单元(vpu)的系统中的帧同步 | |
US7663635B2 (en) | Multiple video processor unit (VPU) memory mapping | |
US8654133B2 (en) | Dynamic load balancing in multiple video processing unit (VPU) systems | |
US8781260B2 (en) | Compositing in multiple video processing unit (VPU) systems | |
CN101198982B (zh) | 抗锯齿系统及方法 | |
US8854380B2 (en) | System and method for rendering and displaying high-resolution images | |
US7817155B2 (en) | Master/slave graphics adapter arrangement | |
CN102981892A (zh) | 用于不同种类处理单元的集中式设备虚拟化层 | |
KR100501052B1 (ko) | 메모리 제어기 허브 | |
US20060267988A1 (en) | Synchronizing multiple cards in multiple video processing unit (VPU) systems | |
CN104871246A (zh) | 用于执行基于图形处理单元的存储器传送操作的多模式存储器存取技术 | |
CN103870674A (zh) | 在台式计算机上实现远程游戏服务器 | |
WO2023016553A1 (zh) | 多个屏幕的显示方法及装置、计算机可读存储介质、终端 | |
JP5697763B2 (ja) | 画像並進のためのエッジのアルファ値でのレイヤ混合 | |
CN113012636A (zh) | 一种时序控制器及显示设备 | |
Jang et al. | Design of a DMA controller for augmented reality in embedded system | |
US9390042B2 (en) | System and method for sending arbitrary packet types across a data connector | |
US20220179784A1 (en) | Techniques for supporting large frame buffer apertures with better system compatibility |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20080611 |