多线程,多显示场景图形设计:一种新的过程模型

多线程,多显示场景图形设计:一种新的过程模型

作者:Don Burns,2001
译者:王锐,2008

新的设想


场景图形的主要目的是改善场景优化,渲染状态排序和各种其它操作的性能,降低图形渲染引擎的负荷,并实现复杂场景的“实时”渲染。实时渲染的目标是以足够高的帧速(符合人眼的交互要求)渲染场景。飞行模拟程序通过窗口输出(out-the-window)的图像生成频率要求为60Hz或者更高,这样显示的内容才不会发生异常。而30Hz,20Hz或者15Hz的频率则是“可交互”的,即,视口可以交由用户进行操控,并在合适的时间响应用户的输入。基于这些目标,我们需要参照帧速60Hz的仿真要求实现我们的设计。我们假定帧速率恒定,且图形子系统针对垂直消隐时间(vertical blanking time,即电子枪扫描完一帧之后返回原点的时间)与渲染交换缓冲区(rendering buffer swap)执行同步的能力恒定。此外,我们还假定多显示的系统已经实现了同步锁相(genlock),至少实现了帧锁相(frame lock,借助硬件使每个显示屏上的帧实现同步),这样就可以实现垂直回描边界(vertical retrace boundary,即电子枪扫描完一帧之后返回的边界)在所有图形子系统上的同步。

多任务,多显示,单系统绘图的传统方法


使用场景图形实现实时渲染的“传统”方法是实现多个阶段,即:APP(用户阶段),CULL(拣选阶段),DRAW(绘制阶段)。APP阶段用于更新所有的动态用户数据,包括相机的位置,以及运动对象的位置和属性变化。CULL必须跟随在APP之后,这一阶段中,首先参照视口锥截体(viewing frustum)中的可见对象,其次参照用于渲染性能的渲染状态,对场景进行排序。CULL阶段更新摄像机位置的依赖数据,并为其后的DRAW阶段构建一个“显示列表”(display list)。DRAW阶段仅仅是遍历整个显示列表,并执行OpenGL的各种调用,将数据传递给图形子系统进行处理。

在一个具备多个图形子系统的系统中,有必要为每个图形子系统设置CULL和DRAW 阶段,因为在假定各个视口锥截体均不同的前提下,只有CULL阶段能够为每个子系统构建唯一的“显示列表”。而APP阶段则不必设置多个,因为每个视口均会共享同一个APP阶段更新的动态数据。

鉴于此,一个具备多图形子系统的系统,要实现多任务的机制,则需要定义过程如下:一个单处理器的系统需要顺序地执行各个阶段(例如,APP,CULL_0,DRAW_0,CULL_1,DRAW_1,CULL_2,DRAW_2),而一帧的时间也就相当于这些阶段耗费的总时间。因此,我们需要实现的任务主要有两个:(1)唯一的APP任务,(2)每个图形子系统各自的CULL/DRAW任务。


在多处理器系统中,如果处理器树木足够多的话,那么每一个任务都可以在某一个处理器上并行地执行。此外,CULL/DRAW任务也可以分离为两个任务并行地运行。

并行多处理器环境的模型实现主要有两个目标。(1)分离并行化(Task Division Parallelization):将一个大型的任务分解成多个可以并行运行的小型任务,以削减运行时间;(2)集成并行化(Task Aggregation Parallelization):将一个任务N次倍乘后,并行地运行它的每个实例,而不增加运行时间。将CULL/DRAW阶段从APP阶段分离出来,然后将CULL和DRAW分离成独立并行的任务,这是一个“分离并行化”的例子。将多个CULL/DRAW组合的任务添加给各个图形子系统,这是一个“集成并行化”的例子。

并行地运行各个阶段可能会带来一些问题。首先,各个阶段必须顺序地处理数据。换句话说,APP阶段完成对数据的处理之后,CULL阶段才可以开始使用这些数据。同样,DRAW阶段也不可以在CULL完成数据生成之前使用这些数据。不过,APP阶段不需要等待CULL和DRAW阶段的工作完成,就可以开始下一帧的数据处理工作,因此,系统管线流程的设计如下图所示:

此外,各个阶段之间共享的数据也需要进行保护和缓存。由之前的阶段写入的数据,不可以被同时发生的其它并行阶段读取。这样场景图形软件就需要引入复杂的数据管理功能。

以上所述是SGI Iris Performer在九十年代提出的一种框架结构。在当时它是合适的,但是现在已经有些过时。


实时且具备窗口输出(out-the-window)的飞行模拟系统需要60Hz的帧速率,也就是说,每个阶段只有16.667毫秒的时间来完成其任务。1990年,SGI开始开发实时图形系统,它所使用的处理器速度是现在处理器的1/60。由于图形系统与图形处理器的能力成比例相关,APP和CULL阶段所需的时间负荷并不是相同的。上图所示的系统设计中,APP和CULL阶段被假定可能占用整整一帧的时间进行处理。


后来,系统频宽的增长降低了基于本地的图形分配的消耗,而DRAW阶段需要分离成两个独立的执行线程:一个在主机上运行,另一个在图形子系统上运行。这一改变将在后面的部分详述。


最后一个需要提及的话题是等待时间(latency,即获得系统任何形式响应所需的最小时间)。飞行模拟系统可以允许有大约三帧的视觉反应延迟时间。这一时间延迟是符合真实人体行为研究的结果的,因此我们不得不参照上述过程模型的要求进行折衷的设计。

新的实现方案


在目前的硬件条件(以60Hz为帧速率标准)下运行的大多数应用程序,其CULL预阶段(即APP阶段)和CULL阶段的处理时间分别限制在少于1毫秒和少于3-5毫秒的范围内。这样的话,各个阶段要各自占用完整的一帧,或者占用一个完整的CPU时间,恐怕是浪费且不切实的。下面的图表反映了这一事实。


有一种提议是,交由CULL预阶段和CULL阶段来执行复杂的任务,以增加了它们的运行时间。但是,大多数执行复杂操作的应用程序任务,其更好的实现方案是与帧的实现部分同步运行。


首先我们考虑单处理器,单图形子系统的系统模型。当CULL预阶段和CULL阶段的计算需求降低时,各阶段的运行相位可以如图进行设计:

 

这一方案的好的方面是,所有的三个阶段可以在一帧执行,响应时间也只有一帧。不利的方面是,DRAW阶段分配的时间较以前大大减少,其启动时间也在一帧的中部位置。使用场景图形的另一个益处是,CULL阶段可以去除不可见的场景,以降低主机图形子系统的带宽压力,同时它还负责按照状态变化值对所有对象进行排序,以优化图形流水线的性能。


由于系统带宽和图形性能的不断提高,那些运行在老式硬件平台下的应用程序,其需求可能较以前有所降低。分配给渲染的时间也许是充足的。这样的话,场景图形系统也就不必再考虑数据保护和管理上的特殊需要了。


现在我们考虑多图形子系统,多处理器的系统模型。为了使用多处理器系统的优势,我们需要设置一个主线程,用于运行CULL预阶段的任务,并为每个图形子系统设置CULL/DRAW线程。为此,我们要针对数据管理考虑以下两个方面:
(1)CULL预阶段的公共数据写入。
(2)CULL阶段生成的内部数据,分别复制到各个CULL/DRAW阶段中。
然后,我们才可以安全地执行各个阶段,如下图所示:

我们已经解决了集成并行化所存在的问题,但是还没有解决DRAW阶段少于一帧时间的问题。我们必须将CULL和DRAW阶段分割成不同的处理线程来实现这一目标。因此我们需要考虑如何保护和缓存数据,这些数据由CULL阶段生成,由DRAW阶段处理。下面的部分将讨论这一主题,其阶段图如下所示。

对于硬件厂商来说,上图所示的情景一定是十分诱人的,因为它使用了7个CPU来控制3个图形子系统。而且还有一种说法是,如果保留CPU 0来执行操作系统任务,从CPU 1开始执行仿真任务,那么我们还需要第八个CPU。但是,对于工程人员来说,上图中存在了太多的空闲空间。同时,我们还增加了每一帧的响应时间。不过这还是好过旧式模型的三帧的响应时间。


主机绘制 vs. 图形子系统绘制


到这里为止,我们一直都把DRAW作为一个独立的阶段,或者一个独立的线程(进程)进行介绍。在旧式的系统上,由于绘制(DRAW)过程受到主机向图形子系统传输的带宽和图形处理速度的影响,这一工作模型应当说是合理的。但是如今,我们需要认识到,当DRAW阶段运行于主机的某个专有CPU上时,它同时与图形子系统上的另一个并行处理器产生交互。OpenGL程序所做的仅仅是封装了OpenGL协议(以数据和信息流的方式),并传递给图形子系统,后者处理数据和信息流的内容并执行实际的矩阵变换,并实现结果的渲染。主机的绘制(DRAW)过程略微提前于图形子系统的绘制过程开始,并略微提前(有时可能会大幅提前)结束处理。通过使用基于主机的计时工具来进行图形基准测试,即可获得这一结论。


下图所示为主机DRAW(也称作分派)阶段和图形子系统DRAW阶段的实时运作流程

 

从上图可以看出,一帧时间内,主机DRAW(分派)过程在帧的边界开始。而主机DRAW分派OpenGL调用和图形子系统开始处理这些调用之间的时间区域,被称作分派时间(Dispatch latency)。黄色的条带表示图形子系统完成数据流的读入和处理,完成矩阵变换,渲染,并执行渲染缓存的交换所需的时间。由于交换缓存在下一次垂直回描(vertical retrace)消隐之前不会开始,因此图形子系统在这段时间里处于空闲。


注意,由于DRAW分派过程在图形子系统的处理完成之前已经结束。为了实现应用程序与图形子系统的同步,大多数主流的图形软件都会选择在下一帧之前等待一个指示“交换缓存已经执行”的信号。这可以说是一个优化主机运行时间的机会。


综上,再考虑到主机和图形系统的并行特性,我们可以设想如下图所示的过程模型。

在这个模型中,我们根据图形子系统垂直回描信号的精确时间,规划主机上的帧调度工作。不过,我们可以控制时间产生轻微的摆动,这样就可能在垂直回描之前,在主机上开始 新的一帧。当垂直回描信号产生,同时图形子系统的处理重置之时,我们在主机上完成CULL预阶段,CULL阶段,并向下传递由主机DRAW过程生成的OpenGL协议。这一工作的起始时间与图形子系统的帧边界尽量贴近。注意,CULL和DRAW(分派)位于同一线程中,执行串行处理。其结果是,原本用于等待垂直回描信号而浪费的主机时间,现在得到了有效的节约。


这一模型意味着场景图形的内存管理计算强度得到了改善,同时给图形系统的DRAW阶段提供了最大的渲染时间。此外,响应时间也降低到少于两帧。


-----------------------------------------------------------------------------------------------------------

开放场景图形多处理器模型的设计


开放场景图形多处理器(Open Scene Graph Multi Processor)模型的设计如图所示。

 

图中所示的矩形块表示的是一种抽象的概念,它不是与硬件紧密结合的,也无法直接加以实现。模型的实现方法将在本文中陆续给出。红色的字体表示模型配置文档和实现时所用到的专有名词。线和箭头表示数据在系统中的流向,最终完成在显示器上的渲染。


主线程(Main Thread)


主线程是运行CULL预阶段的进程或线程。其内容包括了用于运行此线程的CPU。我们假设主线程在它被触发的主机上开始运行。我们使用配置管理器来启动并初始化上图的每一项内容,而主线程则运行在配置管理器所运行的主机上。


拣选/绘制线程


拣选(CULL)/绘制(DRAW)可以作为一个线程来执行,也可以像之前章节所述的那样,运行于不同的线程上。它可以指定两个参数:一个是系统运行的主机名称,另一个是在该主机上负责调度线程的CPU序号。如果CPU的数目为复数(不大于2),那么我们假设拣选/绘制线程可以作为不同的线程来运行。


渲染表面


渲染表面描述了最终渲染结果显示的屏幕空间。其中定义了
·主机(Host):执行显示的系统所在的主机名称;
·显示设备(Display):即图形子系统,此处假设在XWindow系统下使用显示设备;
·屏幕(Screen):此处假设在XWindow系统下使用屏幕;
·窗口(Window):此处假设在XWindow系统下使用窗口;
·视口(Viewport):视口指的是窗口内的一个矩形区域,用于安置渲染的最终结果。
以上所述在配置文档中均为实际的实现细节。


配置


上面所述的内容可以按照三个独立的环境进行配置。
(1)单系统映像(Single System Image)
如果主机域名始终保持不变,那么我们的系统将在同一个主机上进行初始化。然后我们就可以根据CPU域的定义来设置线程的参数。
(2)图像集群(Graphics Cluster)
如果CULL/DRAW阶段所在的主机域与CULL预阶段所在的主机域不同,那么在CULL/DRAW的主机上需要启动一个CULL预阶段的代理器,它用于执行CULL预阶段(另一台主机上)生成的动态数据集的同步。如果数据同步没有完成,那么这个代理器会阻塞CULL阶段的运行。
(3)WireGL设置
渲染表面包括一个“主机”域。它可以用于实现WireGL(一种集群渲染系统)的执行,以处理主机DRAW阶段传递的OpenGL协议。这种配置调度的方便之处在于,它允许上述配置之间互相“混合搭配”(mix-and-match)。例如,某个应用程序可以在三个本地图形子系统上运行其窗口输出的渲染,同时为仿真工作站(Instructor Operator Station)提供多集群的显示,并在WireGL集群系统上实现各个显示结果的最终合成。


多处理器(MP)模型


前面的章节叙述了两种类型的MP模型,用于实现多任务,多显示的开放场景图形系统 的实现。其不同点可以归结为CULL/DRAW作为一个线程还是分开处理的问题。如果考虑到同一主机上,存在移相的帧的调度,那么把CULL/DRAW分别进行处理可能就是不妥的。此外,忽略其带来的优越性的话,上述实现方法所引入的内存管理问题也可能导致性能降低。


不过,我们仍然会在这里依次讨论这两种模型。


MP模型A - 数据流


如前面的章节所述,这里我们假设一个单一的,基于主机的APP/CULL/DRAW流水线,注意这里可能存在多个CULL/DRAW过程。

这个模型中假设有一个基于主机的可微调的帧调度机制,一个单一的线程来执行CULL/DRAW。时间线A,B,C表示下一幅图中数据流的活动时间。

如前文所述,CULL预阶段负责更新场景图形中的动态数据。这些动态数据包括摄像机位置,场景中的移动物体位置,时间戳,帧数,消耗时间,以及其它一些数据管理的参量。我们假设这些数据已经被正确分配,且都是应用程序可以访问的公共量。当CULL预阶段结束时,它向CULL阶段发送一个信号,使其进入运行状态。CULL负责读取更新的动态数据,并生成内部的数据(应用程序无法访问它们),供DRAW阶段使用。这些数据是串行进行处理的。DRAW阶段将遍历这些内部数据并传递相应的OpenGL调用。


这个模型较为简练,它只需要简单地实现主机上帧发生相移(phase shifted)时调度的实时性即可。OpenSceneGraph本身已经包括了多显示系统中,对多重渲染上下文(rendering context)的支持。


当CULL/DRAW作为一个线程运行时,不需要做特殊的更改。


MP模型B - 数据流


下面我们讨论CULL/DRAW分别在不同线程上运行的情况。注意,下图中并没有包括图形子系统的DRAW部分。此模型假设不存在相移,且主机已经处理了与图形子系统的同步问题。

此模型的数据流程如下图所示。

上图与单线程CULL/DRAW过程图的区别在于,从CULL传递到DRAW的内部数据需要经过双缓存的过程。CULL生成的数据将被写入“缓存0”,此时DRAW从“缓存1”读取数据。到达CULL和DRAW线程的同步点时,执行两个缓存的交换。


这种方法需要编写内部数据的双重缓存,以及CULL和DRAW线程的同步位置实现代码。


总结


OpenSceneGraph的设计用于实现多任务,多处理器和多显示的功能。它的实现方法是先进的,并且充分利用了现有硬件环境的优势。开放场景图形(Open Scene Graph)已经在SGI的MPK上测试成功,执行结果令人满意。开放场景图形的开发者迫切希望实现一个跨 平台的,灵活、透明地执行于图形集群(graphics cluster)上的解决方案。在了解了目前的困难之后,相信一款多显示,多处理器的实时开放场景图形系统将会在不久之后诞生。
---------------------------------------------------------------------------------------------------------------------
原文参见:http://andesengineering.com/OSG_ProducerArticles/OSGMP/index.html

posted on 2009-03-05 22:51 zmj 阅读(1197) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理