GEMINIGHT 警告:您的浏览器不支持JavaScript将无法正常浏览!
Warning: Your browser does not support JavaScript!
注册(Register) | 登录(Login)
看随机帖

主站(Home) »  论坛(Forum)  » 程序编写(Program)
GEMINIGHT

自称:发贴器2号
等级:发贴器
帖子数:4906
积分:9179
阅读权限:99
Direct3D 10系统 1樓
Tags: Direct3D

Tags引力关联贴

作者:David Blythe
翻译:clayman
Blog:http://blog.csdn.net/soilwork
clayman_joe@yahoo.com.cn
译注:这篇文章是MS在SIGGraph 2006上发表的论文,点击这里下载原文

\N


摘要

\N

本文描述了第四代PC平台上图形图像单元(GPU)的系统构架。与上一代图形管道相比,新的管道有了重大改变,引入了一个新的可编程阶段(stage)用于生产额外的图元,并把图元流保存到内存中;扩展了所有可编程阶段的功能,涉及到顶点、图片内存资源,以及新的储存格式。此外,我们还描述了API、运行时以及实现新管道的着色语言的结构性改变。解决当前系统中的缺陷,是我们设计的基本思想。文章不但描述了重要设计抉择背后的原理,同时也描述了那些最终被否决的方案。

\N

1.前言

\N

过去10年,OpenGL和Direct3D所依赖的渲染管道构架已经取得了重大发展。最近5年中,随着从固定管道到可编程管道的过渡,发生了许多戏剧性的变化。虽然变化的进程很快,但每一步都反映出了设计者在通用性、性能以及成本上所做出的妥协。
我们一直在努力了解以及构建一个系统,来解决许多程序中对图形加速器的需求(呈现图形、CAD、多媒体处理,等等)。但是,我们更想把注意力集中在交互式娱乐应用中。这些程序需要管理数十亿字节的艺术品,包括几何体、纹理、动画数据以及着色程序,占用大量系统资源(CPU、内存、带宽),以可交互的速率渲染丰富的、充满细节的图片。在处理海量数据的同时,保证渲染的灵活性,是对设计者的重大挑战之一。在系统设计的方方面面,都可以反映出我们对这个问题的解决方案。
与上个版本的Direct3D一样,Direct3D 10同样是在应用程序开发者、硬件设计师以及API/运行时构架师三方的合作下设计的。在三年多的设计过程中,合作者之间详细的交流是无价的,让我们更深入了软硬件部署的代价,以及在大量不同硬件进行权衡。在开发Direct3D 10的过程中,调查显示应用程序开发者通常受以下限制的困扰,以及用来缓解这些问题的策略:
1. 状态(state)改变的代价过高。 改变任何类型的状态(顶点格式、纹理、shader、shader参数、混合模式,等等)都会付出很大代价。优化方法通常是通过查询对象状态来排序,减少API状态改变次数;减少外观的改变;或者使用基于shader的技术,使用shader来决定状态。对于后者,例子之一就是把多张纹理打包为一张纹理地图(texture map)(也称为纹理地图集),通过纹理坐标变换,来索引相应的子纹理。
2. 硬件加速器性能变化太多。 应用程序不得不编写一系列分支语句,以保证在不同硬件上都能正常运行。这些问题会影响到程序的特性设置,资源管理,算法精度,以及储存格式。
3. CPU和GPU之间频繁的同步。传统的图形管道允许有限制的重新使用管道当前产生的数据,作为下一个处理步骤的输入数据。Render-to-texture就是这种机制的最好例子之一,所渲染的图片接下来能被当作纹理使用,最小化CPU的干涉。但是,产生新顶点数据,或者创建立方贴图就需要CPU与GPU进行更多的协调和通信,降低了效率。
4. 指令以及数据类型的限制。通常都以精度和所支持的流程控制指令来衡量vertex shader,同样的方法也用来衡量pixel shader,但是,无论是pixel还是vertex shader都不支持整数指令。此外,出于对pixel shader精确性的要求,还指定了浮点算法。应用程序要么不使用这些额外的功能,要么模仿他们的使用。基于表格功能的计算就是例子之一。
5. 资源限制。 纹理读取的次数、纹理范围、程序指令,等等,都受到限制。应用程序不得不压缩算法,或者把它们分为多个shader pass。因此,还出现了对自动划分shader程序的研究。

\N

2.背景

\N

我们的系统建立于PC,工作站以及游戏机平台上的应用程序可编程渲染管道。当前的图形管道分为两个编程阶段,一个用于处理顶点数据(vertex shader),一个用来处理像素或片断(fragment or pixel shader)。在Lindholm2001里描述了设计早期vertex shader的思想和折中。除了细小的差别以外,pixel shader也是按这样的轨迹来设计的。可以把顶点以及像素着色器的发展分为4代(包括Direct3D 10),如表一所示:

通过挖掘顶点和像素片断之间的独立性,硬件管道实现了很高的处理吞吐量。大多数顶点和像素着色器都是以并行的状态来处理相互独立的顶点和像素片断。典型的硬件实现中pixel shader的数量要比vertex shader多很多,反映出典型的渲染过程中,像素处理的工作量要比顶点多很多。与vertex shader相比,这种特性将影响pixel shader的性能,因为pixel shader被过多的复制了。
可编程管道直接使用了较低的抽象层,比如OpenGL或Direct3D。这些抽象层隐藏了不同硬件管道实现之间的差别,提供了一个方便的接口。对特定的平台来说,比如游戏机,它的硬件管道与PC平台相比是不同的,底层细节也是由这些抽象层来暴露。
我们把这些抽象层称为运行时(runtime),并且通过它所提供的API对他进行控制。运行时为设备提供了独立的资源管理(分配内存,控制生存期,初始化,虚拟技术,等等),所有纹理贴图,顶点缓冲,状态改变以及和硬件加速器的通信都通过特定设备的驱动程序来完成。对可变成管道来说,运行时还加入了对照色程序的抽象和管理任务。
由于早期可编程处理器对指令储存空间的限制,为了在有限资源内,最大化对硬件的控制,不得不使用类似于汇编的语言来编写照色程序。但是,随着硬件功能的增加,需要一种高级的编程抽象来提高程序员的生产力。一种与C类似,并且添加了对潜在渲染管道进行定制的编程语言满足了这种需求。此外,还发展出了一些其他的语言,利用浮点处理器和GPU内存带宽来完成渲染以外的一些计算,但是,我们不打算在这篇文章里对这些应用进行讨论。
虽然新的编程语言有必要与CPU编程语言(特别是C)类似,但我们还是进行了一些重要的修饰。举例来说,硬件结构和编译模型更像是一台虚拟机,汇编着色语言扮演了独立于硬件的中间语言(IL),而不是特定的机器语言。在离线环境下,Microsoft HLSL之类的高级语言被编译为IL,在程序运行时,通过驱动程序内建的翻译器,实时转换为目标硬件的指令。需要注意的是,OpenGL shading language使用了一种不同的方法来完成运行时的编译过程。
另一个重要的区别是,着色程序并不是孤立的程序,通过一个运行在CPU上的程序来协调渲染管道,它们通常是共同(in concert)执行的。 此外CPU程序还以纹理或填充寄存器常量的方式,为着色程序提供参数。
虽然本文没有具体描述特定硬件新图形管道的构架,但图形管道的设计很大程度上都是根据硬件实用性以及多硬件并行处理来设计的。此外,当前硬件实现的结构体系也将延续或者影响我们的设计。

\N

3.图形管道
Direct3D保留了通用硬件加速器的3D管道结构。我们添加了两个新的阶段,并对其他的阶段进行了简化或者进一步归纳(generalized)。基本的图形管道如图1所示。为了保证文章的连续性,我们将讨论图形管道的每一个阶段,而不是只讨论新增的两个阶段。为了和以前的术语一致,使用了通用的术语,比如 顶点(vertex),纹理(texture)以及像素(pixel),但需要注意,这些术语只表示普通用法中的某些特定含义。
Input Assembler(IA)从附加到顶点缓冲上的8个输入流中接收1D的顶点数据,并且把数据项转换为规范的格式(比如,float32)。可以为每个流指定独立的顶点结构,每种结构最多包含16个域(也称为元素,element)。每种元素可以由1到4个基本数据项组成(比如,float32s)。通过读取当前的有效流来装配(assembled)顶点。一般来说,将会连续的从顶点缓冲中读取顶点数据,但是,如果指定了索引缓冲,那么每个流将使用共享的索引来计算每个顶点缓冲中顶点数据的偏移值。指定索引可以带来额外的性能优化,顶点处理器将根据索引值计算结果,通过用索引值作索引的结果缓存,可以避免使用相同索引重新计结果(译注:这里的结果因该是指顶点数据序列)。
此外,IA还提供了一种机制,允许IA高效的复制对象n次。这种机制是实现instancing的解决方案,把包含k个顶点的数据块(block)复制n次。同时,将使用当前的实体(instance),图元(primitive),以及顶点id对图元数据进行“标记(tagged)”,在可编程阶段,可以访问这些id,以便计算变换,材质等参数。
Vertex Shader(VS) 通常用来把顶点从模型空间变换到裁剪空间。VS读取一个顶点,输出一个顶点。VS与其它可编程阶段一样,有一些共同的特性,包括支持扩展的浮点、整数、控制类型,可以访问128块内存缓冲(纹理)以及16个参数(常量)冲。我们会在第四节详细讨论这些通用核心(common core)。
Geometry Shader(GS) 把同一图元的所有顶点作为输入,产生新的顶点或者图元。输入和输出图元的类型不一定要匹配,但对着色程序程序来说是固定的。以发射额外图元对象的方式,GS程序可以增加输入图元的数量,每一次调用(per-invocation)最多产生1024个32-bit的顶点数据。三角形和线段被输出为连续的顶点带。在一次调用中,GS程序可以输出1个以上的图形带,或者删除输入的图元,不进行任何输出。GS程序同样可以在不产生新几何体的情况下,把额外的属性附加到图元上,比如为每个图元计算额外的属性。由于可以访问当前图元的所有顶点,因此,计算三角形平面方程(triangle’s plane equation)之类的几何属性将会容易。
除了输入图元之外,还可以处理三角形和线段的邻接顶点。每个三角形包含三个顶点,以及三个邻接顶点,而每条线段则包含2个顶点以及2个邻接顶点。对于三角形和线段来说,邻接顶点将作为顶点缓冲格式的一部份,当指定(渲染)了带邻接的图元拓扑之后,IA会对提取邻接顶点。

Stream Output(SO)将把GS输出的顶点信息复制为4个连续的输出缓冲子集。理想情况下,SO的输出能力(不带索引)应该和IA(8 streams * 16 elements)的输入能力相匹配,但硬件代价是不合理的。SO只能输出一个1~16元素的流,或者4个单一元素的流。此外, IA可以读取8或者16bit的数据类型,并把他们转换为float32,而SO只能写入原始的32-bit的数据类型。但是,数据类型转换和打包可以在GS程序中轻易实现,减少了固定功能的支持。
Set-up and Rasterization Stage(RS) 是一个功能固定的阶段,用来处理剪切(clipping),剔除(culling),透视划分,观察点变化,图元设置,裁剪(scissoring),深度偏移,以及片断(fragment)生成。现代GPU设计总是包含某种形势的早期深度处理(z-cull,hierarchical-z)。我们将明确讨论这种优化,因为对应用程序开发者来说,它变的不太透明了。RS的输入是单一图元的顶点以及属性,输出一系列像素片断。
Pixel shader程序指定了通过顶点属性插值产生片断属性的方式(no interpolation, non-perspective-corrected interpolation, or perspective-corrected interpolation)。现代GPU通常支持多采样抗锯齿。当一个片断不包含像素的中心时,需要很小心的指定属性赋值行为,因为中心点的值有可能超出范围。通过片断边界,可以使用赋值限定器(质心centroid)来指定所需的值。
Pixel Shader(PS)读取单一像素片断的属性,输出包含1~8个属性(颜色)以及任意深度值的单一片断。每个属性值(元素)要么被分别写入单独的颜色缓冲中(称为渲染目标),要么完全丢弃(不输出片断)。一般情况下,深度和stencil值来自于RS。PS可以可以替些深度值,但无法改变stencil值。无论是丢弃像素还是重写深度值,都有可能影响RS中的深度处理优化(depth-processing optimizations),因为这样做会改变片断的可见性。
Output Merger(OM)接收来自于PS的片断,执行普通的 stencil和深度测试操作,以及渲染目标混合。OM为一个统一的depth / stencil缓冲以及8个其他的渲染目标(属性缓冲)指定了约束点(bind point)。Pixel shader必须分别为每个渲染目标输出单独的值(不支持多点传送)。此外,所有的渲染目标都共享一种混合功能,但是,可以对每个渲染目标独立的激活或者屏蔽混合。

发表于:2006-7-3 06:57(约17年前)  访问量:876
pinkgun

自称:逆转,然后再见
注册于:2006年6月29日
等级:论坛元老
帖子数:3187
积分:14828
阅读权限:60
2樓

Direct3D 10是配合 Windows Vista 的吧?
SIGNATURE
发表于:2006-7-3 20:37(约17年前)
Jeminai

自称:雙子騎士
注册于:2005年5月26日
等级:站长
帖子数:6414
积分:41794
阅读权限:200
3樓
用什么系统我还不太清楚、、、
SIGNATURE
我的Blog网址:blog.geminight.com
发表于:2006-7-5 07:23(约17年前)
Jeminai

自称:雙子騎士
注册于:2005年5月26日
等级:站长
帖子数:6414
积分:41794
阅读权限:200
Direct3D 10系统(二) 4樓

\N

作者:David Blythe
翻译:clayman
Blog:http://blog.csdn.net/soilwork
clayman_joe@yahoo.com.cn

\N


3.1 内存结构以及数据流

\N

现代GPU很大程度上都在处理持续性(retained)的数据结构,包括顶点和索引缓冲,纹理贴图,渲染目标,以及depth/stencil缓冲。GPU通常把这些数据储存在直接连接到它自身的高性能内存系统中。数据结构的类型包括1D到3D的图片、 2D的立方贴图(所有贴图都可以选择是否包含mipmap层次),以及1D同族(homogenous)或不同族(heterogeneous)的索引以及顶点缓冲。为了提高效率,Direct3D 10对这些数据结构进行了统一,统称为资源。性能在两个方面得到了提升:首先,在一个单独的渲染pass中,可以增加处理数据的范围;第二,增加了易用性,可以在第一个pass中产生资源数据,然后在接下来的渲染pass中使用这些数据。
单pass渲染效率的提高得益于几个方面。首先是数组化资源(arrayed resources)。纹理以及渲染目标将被创建为一个同类型资源的线形数组(最多包含512个元素),并且作为纹理或者渲染目标,约束到图形管道上。用于处理纹理的着色指令将包含由着色器计算(shader-computed)的数组索引。这减轻了应用程序开发者把多张图片打包为一张纹理,以及控制纹理坐标选取子纹理的工作量。但是,纹理数组队对打(解)包尺寸不一致的的图片不一定有用,应为数组中的元素都应该具有相同尺寸。
当把一个渲染目标的数组约束到OM时,将为GS中的每个图元计算目标数组索引。这允许GS把图元分类(或者复制)到不同的数组元素中。使用一个pass,把环境渲染到包含6个2D渲染目标的立方贴图就是例子之一。当处理环境中的几何体时,由GS决定把图元渲染到立方贴图的哪个面,并且为每个面输出(issue)一次图元。需要注意,GS的渲染目标数据选择机制与PS的多渲染目标输出是独立的。
为了激活render-to-cube-map以及简化数组的使用,我们为资源引入了view的概念(resource are extended with the notion of a view),要么选择资源中的一个子集(e.g 选取数组中的一个元素),要么把额外的类型数据绑定到部分类型化(partially-typed)的资源上。对后一种情况来说Direct3D 10允许创建不受特定元素类型约束的资源(e.g float16,snorm 16,etc)。这在一定程度上允许了储存类型的“转换”,数据类型可以改变,但数据类型的大小不能变(e.g 不能把两个float16当作一个float32 来对待)。不能直接把资源约束到管道上;而需要通过view来绑定。同一资源的两个不同view可以同死约束到管道上。
在接下来的pass中使用渲染好的立方贴图是multipass渲染或重复渲染的一个例子,它们都是由Direct3D 10更加灵活的资源模型来实现。另外一个类似的有用特性就是render-to-vertex-buffer。实现方法之一就是把顶点缓冲作为渲染目标(使用一个view)连接到管道上,使用着色器中的一个阶段来计算新顶点数据,并且把它当作颜色熟悉数据传递到余下的管道,输入渲染目标。这种方法的复杂性在于:数据尺寸以及顶点元素类型一致性(4 x float32)的限制, 相对简单操作却需要使用管道的多个阶段(e.g VS and PS),以及如何把1D顶点数据映射为2D渲染目标的问题。Driect3D 10应用程序使用view来选择顶点缓冲中邻近的子区域,并把它作为宽度为n,高度为1的2D渲染目标,子区域的最大宽度为8K个元素。
流输出的特性提供了交替(alternative)处理连续1D输出的能力。流输出的特性之一就是支持丰富的输出格式,举个例子来说,可以输出相当于每个顶点16 x 4x float32个元素的数据,也意味着更大的缓冲(128MB vs. 128KB)。流输出不支持随机访问(分散scatter)输出流中的数据,相反渲染目标的方法却可以,通过绘制点和使用VS修改渲染目标点坐标的方法来控制寻址。出于这些原因,两种方法都是很有用的。
为了支持重复计算,根据资源将会连接到图形管道的哪一个约束点(bind points),我们放宽了资源系统规定参数(constraints)的范围(i.e IA buffer, VS/GS/PS texture, SO buffer,以及OM render targets),并把view作为适配器(e.g 渲染到一个单独的mipmap层次,或者3D纹理中的2D片)。然而,这些适配器并不是完全通用的:2D资源不能当作1D资源来处理,由单一元素组成的同族资源不能转变为非同族的资源,比如多元素顶点缓冲。这些限制主要是为了防止对整个资源结构的多重定义(reinterpretation),以便硬件实现优化储存层次。同样,同一资源不能同时作为输入和输出数据的限制仍然存在。

\N

3.2 储存格式
虽然在着色器上操作的都是32-bit的数据(浮点或者整数),但是我们提供了丰富的数据储存类型来减少内存占用以及带宽。如果数据类型不是8-bit的整数倍,那么将被和其他类型的数据打包到一起,组成8-bit的整数倍数据。几乎可以使用所有格式来处理顶点缓冲,纹理,流输出(使用手动转换和打包),以及渲染目标。下表列举了这些数据类型。

Unorm,snorm,以及float16(half)是已经被广泛使用的格式。虽然float16对高动态范围(hight-dynamic range)图片的应用很有吸引力,但他需要消耗过多的储存空间,以及内存带宽。Direct3D 10提供了两种可选的32-bit打包方式:两个float11(R,G)和一个float10(B)的组合,以及一种共享指数?(shared-exponent)的格式—R、G、B每个元素9-bit,指数5-bit。这些类型被限制为正数,可以提供与float16一样地动态范围(10个数量级 order of magnitude)。对于低精度的情况来说,11-11-10的格式是渲染HDR颜色数据的目标(destination)格式,而共享指数的格式则被限制为用来进行纹理操作的源格式。共享指数的格式使用了一种比较复杂的编码方式来避免人工效果(artifacts),因此被限定为只读的。
除了这些简单的压缩格式之外,Direct3D 10还增加了一种4x4 texel block compression (S3TC) 格式。这种格式一到四元素的版本,分别可以提供8:1,6:1,以及4:1的压缩率。包含三到四个颜色元素的格式适合于低动态范围(low-dynamic-range)颜色,而二个元素的格式则适合于切线空间的法线图数据。

\N

3.3设计考虑
另外还有几个构架设计决定也是值得讨论的。
与前一代的技术相比,Direct3D 10要求所有特性都必须由硬件来实现。但其中有两个例外的地方:代价昂贵的32-bit浮点纹理过滤,以及包含多采用(multisampler)抗锯齿的渲染纹理格式。这增加了实现提供者的负担,但也反映出应用程序开发者更注重性能,而不是如何解决特性难题。强调硬件对重要格式的支持,增加了他们支持各种不同应用程序的可能性。
从管道与核心API中移除了所有可以通过可编程体系实现的传统固定管道功能。包括顶点变换,光照,点精灵,雾,以及alpha混合。虽然使用软件可以轻易模拟固定功能的特性,但我们相信为了减少复杂性,应该通过其他的库来实现这些功能,而不是核心API。
尽管我们对管道进行了比较大的改动,但固定管道中一些重要的部分仍然存在。在早期的考虑中,我们曾希望把IA也作为完全可编程的部分,允许实现复杂的索引风格或者顶点布局(layouts),但最终我们认为这些额外的复杂性不一定是有用的。相反,VS的内存读取功能允许在VS中实现复杂的索引方案(indexing schemes);事实上,可以只计算顶点的id,而不从IA中读取任何数据。不管怎样,出于性能的考虑,我们仍然保留了一个强大的IA,它在管道中的位置和功能可以为硬件在管理与顶点相关的内存通信时提供便利。
对于GS来说,涉及到许多复杂的设计问题。其中,比较重要的管道性能权衡之一,就是在保持顺序操作的情况下实现并行。GS保留了输入数据的顺序,因此,多个并行执行的GS单元不能发射出超出顺序(out of order)的图元。这需要对并行的实现做一些变化:缓冲他们的输出,按照输入顺序依次处理整个缓冲。高效的缓存管理,可以根据输出数据的上限,以及GS程序的能力,来指定一个较小的(译注:缓冲)界限(bound)。1024个32-bit值的最大限度(ceiling)是硬件代价和有效放大率(amplification)的折衷,比如,挤出(extruding)三角形的边。毫无疑问,使用GS来进行更大的尺度缩放——比如镶嵌(tessellation)——是很有诱惑力的,但是,我们预料这将会导致性能的迅速降低。
在应用中,GS包含了和RS同样多的功能。虽然我们希望GS执行族划分(homogeneous devide),观察变换,等等。但在这些操作之前进行剪切是不切实际的,因此,在剪切时,GS-RS进行了划分。GS执行一些剪切设置,e.g 计算顶点到模型剪切平面(model clip-plane)的距离,之后,连同顶点在裁剪空间的坐标,一起传递给RS。由于没有精确定义过固定功能的RS顶点处理精度和准度设置,因此对GS来说,虽然误差不大,但无法精确模拟变换,来产生图片空间(image-space)的坐标。这限制了GS的通用性,无法实现一些基于图元的图片空间坐标的算法。
最后,固定功能对OM的限制也是经常讨论到的。OM单元是唯一的同时支持内存读写(read-modify-write)的阶段,这也是可编程单元经常需要使用的特性之一。有人曾提出把OM的功能合并到PS中。但是,管理复杂管道要承担的风险,以及最大化内存系统的效率的需求,都没有理由证明这种合并是有必要的。由于PS的计算都是在像素片断上执行,而混合(blend)操作是基于采样来计算,因此,多采样(multisampling)进一步复杂化了结构。促使PS依据采样粒度来执行,对性能有重要意义。此外,使用提前的depth和stencil遮挡优化,也能极大的提高性能。

SIGNATURE
我的Blog网址:blog.geminight.com
发表于:2006-7-7 05:46(约17年前)

标题(Title):
关键字标签(Tags):
路人:回贴可以不必登录