Direct3D 10系统（五） 全文完～～～

 Direct3D 10系统（五）

作者：David Blythe

本文版权归原作者所有，仅供个人学习使用，请勿转载，勿用于任何商业用途。

由于本人水平有限，难免出错，不清楚的地方请大家以原著为准。欢迎大家和我多多交流。

翻译：clayman

Blog：http://blog.youkuaiyun.com/soilwork

clayman_joe@yahoo.com.cn  

5.3 Resource Mapping and Access

         API 和管线设计比较复杂的问题之一，关系到如何在 CPU 和 GPU 之间共享资源。举个例子，无论 Direct3D 还是 OpenGL 都允许顶点缓冲映射到程序的地址空间中，而不管缓冲具体是分配在系统内存还是显存中。但是，分配的位置将会导致性能的巨大差异。现代图形加速器上，显存和加速器之间的带宽可能超过 50GB/s ，而 PCI-E 则只能为系统和 GPU 之间提供 2.8GB/s 的带宽。

         此外还有一些其它的问题。比如， CPU 对所访问的数据缓存与否，同样会带来很大的性能差异。同时，是否 write-combine ，也会造成同样的差异。另外，当 GPU 访问资源时，为了提高空间的一致性，资源加载的方法可能是 form row-order to another(e.g, Morton, boustrophedon, or pi orders), or tiled [Blinn 1990; Hakura and Gupta 1997; Igehy et al. 1999] 。我们认为这些方法本质上都是为了保证分割模式（ tiling pattern ）对应用程序透明，因此，当资源映射到 CPU 时，应该是以线形方式组织的。由于分割模式同时也依赖于访问模式， 2D 和 3D 纹理之间是有差异的，而且这种差异不仅仅是 CPU 和 GPU 之间的不同造成的。出于对性能的重要用影响，我们尝试暴露所有这些功能，但由于其本身的复杂性，却很难让应用程序真正获得性能上的提升。我使用了一个简单的模型，尽力提供了尽可能多的功能。

         我们对特定资源的写入者和读取者进行了分类， e.g ， GPU vs.CPU 以及 read vs. write 。如果最初只有一位客户访问资源，那么问题就变得简单了，因为可以采取对主要客户比较有利的方式，来分配资源。同样，如果可以预知资源将被用来读取或写入，也会有很大帮助。幸运的是，这样的描述完全可以覆盖大部分典型的应用范围。比如，渲染目标和纹理主要由 GPU 进行访问，并且分别被限制为写入目标和读取资源。另一方面，顶点缓冲的使用就比较复杂了。虽然静态的集合体主要由 GPU 来读取，但是动态的几何体则常常作为动画的一部分，先由 CPU 来生成，在由 GPU 进行处理。这些操作将导致频繁的 CPU 写入和 GPU 读取处理。

         Direct3D 10 根据使用类型，把资源分为 3 类： default, immutable, dynamic ，以及 staging 。 Default 对应比较简单的纹理，渲染目标，或者只由 GPU 访问的静态顶点缓冲。 Default 类型资源的初始化，通常需要复制另一资源的数据来进行。 Immutable 类型的资源不允许复制操作，但是在创建时，提供了另一种方法来进行初始化。 Default 和 immutable 类型的资源都不能映射到应用程序地址空间中，让 CPU 对它们进行访问。动态资源不但可以在管线中使用，也允许映射到 CPU ，进行只写的操作。适合于生成顶点数据，或者进行视频解码，等等。最后， staging 类型的资源只允许 CPU 对其进行访问，但是，可以对它的数据进行复制。 Staging 类型的资源对于初始化或者获取只有 GPU 能访问的资源时比较有用。

         为了检查资源可以绑到管线的哪个位置，将在创建资源时，对资源的布局（ placement ）和编码方式进行验证。这些分类包括：顶点缓冲，索引缓冲，常量缓冲， shader 资源（纹理），输出流缓冲，渲染目标，或者 depth/stencil 缓冲。这样的分类有两个目的：为驱动提供资源布局的信息，简化使用资源时的错误检查。

 

5.4 HLSL 10

         高级着色语言广泛，迅速的被人们所接受，无疑显示了这种语言的重要性。为了支持新管线的特性，我们对高级着色语言―― HLSL 也提出了一些新的目标。简单的说，我们希望应用程序开发者使用 HLSL 高效的开发程序，而不需要了解虚拟机的复杂细节，比如，寄存器名称或常量缓冲索引。我们把目标精炼为以下几个小点：

1．   应用程序不需要了解资源是如何配置和分配的。

2．   把 bind-by-position 作为主要的绑定机制，而不是现在的 bind-by-name 。

3．   程序员不再需要编写中间（汇编）语言代码

第一个目标主要用于解决下面这个问题：当前系统中，应用程序开发者需要学会控制常量储存空间中的参数布局。开发者需要对多个 shader 进行全局分配和布局（ global allocation and placement ），以便在多个 shader 之间共享某些变量。通过在每个管线阶段添加的多个常量缓冲，我们相信，编译器有足够的信息能自动对缓冲进行布局，当然，程序员还是要控制把参数分配到常量缓冲中的操作。我们对语言进行了扩展，允许把缓冲名作为参数的一部分，进行声明。

第二个目标则是设计思想的改变，主要与性能和未来的进一步发展有关系。 Bind-by-name 主要用于几个地方：对多个 shader 之间输入和输出数据进行匹配，让 vertex shader 的布局与 vertex shader 进行匹配，等等。虽然运行时可以让源数据和目标数据之间的名字匹配操作进行的比较高效，并且实现源—目标对缓存，但我们觉得这些只会带来不必要的复杂性，并且为运行时添加额外的负载。新系统中，将在多个方面发生变化。 Shader 的输出和输入将与 签名（ signature ） 相关，这和 C 总的函数原形有些类似。只有当前一阶段的输出和后一阶段的输入兼容时，管线才是有效的。兼容意味着输入和输出间 element-by-element 的对应。这里，我们允许下一阶段的管线，不使用上一阶段拖尾的（ trailing ）的输出数据。

Bind-by-postion 通用影响到 IA 和 SO 阶段的顶点缓冲绑定。但是，对这几个阶段，我们将创建独立的对象来封装（ encapsulate ）绑定，让代价较大的匹配操作只在创建时运行一次。

第三个目标是比较具有争议性的，它表示我们的实现 将不支持使用使用中间语言编写的 shader 作为输入 。我们认为着色程序的发展已经达到了一定复杂程度，因此，手写的 IL 很难比编译器产生的代码高效。此外，当我们改进优化技巧，联接，以及与驱动的交互时，无法保证对手写 IL 代码的支持和兼容。作为诊断技术，系统将支持编译器生成中间代码作为输出，但是，我们不允许应用程序开发者修改编译器的输出，并把它注入到运行时中。

         如何最优化编译器生成的代码性能，有很多问题。首先，是优化的范围，驱动可能允许把中间语言转换为特定机器语言时进行优化。随着 shader 复杂性的增加，确保开发者在优化之上，有充分的控制权，改变操作的执行顺序是相当重要的。特别是需要保证关键代码的恒定性（ invariance ），多 pass 算法应该能生成同样的中间值，以便把这些值复制到分散的 shader 中。我们考虑了几种在源码上指定中间值的方案，比如，要求以一种特定的方式来编译子程序，而不管这个子程序是否是内连的。但是，研究最终让我们选择了更加常见的方法：使用与 驱动编译器相关的，可选择的，定义良好的优化级别。

         请注意，我们首选的使用模型是在编写 shader 时，编译 HLSL 代码，在程序运行时通过驱动编译 IL 代码。这样的目的是希望减少程序运行时，编译 shader 所花费的时间。但是，在运行时再把 HLSL 编译为 IL 也是可以的。

 

5.5 HLSL-FX 10

         我们注意到，编程管道的成功，改变了人们的观点， shader 程序不但是引擎的一部分，同时，也是艺术家创作工具之一。为了适应这方面的应用， Effect （ FX ）系统对 HLSL 进行了扩展，允许使用它来初始化管线的固定功能部分。这和 CgFX 以及 Cg 所描述的方法很类似。虽然这些方法有共同的基础，但 HLSL-FX 是进行了革新的。我们的目标是， FX 首先需要满足实时运行的需求，其次，才是作为内容创建者的工具。基于一些历史原因，这两者在很多方面都是由差别的。创作工具常常通过牺牲性能来换取灵活性，而我们的运行时则把性能放在第一位。

         通过我们积累的经验和努力， FX 系统在易用性和性能方便都有了充分的提高。最终 FX ， HLSL ， API ，运行时，以及管线都紧密的结合到一起，作为互补的解决方案。我们同样对频繁的状态操作进行了改变，分离了名字查找以及匹配操作。

         再次来讨论处理状态改变的方式。构建应用程序的方法之一是渲染一系列几何体，每个几何体都有其各自的管线配置（一个 Effect ）。通过设置常量缓冲中的 shader 参数，纹理绑定，以及其他固定功能的状态，来传递参数给 Effect 。 为了最大化性能，应用程序应该使用一个 Effect 来绘制所有物体。这是场景管理系统中，传统的状态排序解决方案。但是，对一个 Effect 来说，可能有几个层次的参数，比如，当前时间和观察点是属于 per-frame 的状态；纹理或顶点数据则是角色的静态状态；位置和姿势则是对象的动态状态，等等。我们使用了一个单独的常量缓冲来储存 shader 每个层次的参数，当绘制物体时，将直接绑定保存静态参数的常量缓冲，保存动态参数的缓冲则要经过更新后再绑定。

         在实际应用中，应用程序并不能总是通过 Effect 来排序对象。通常还可能有其他的机制，控制着绘图，比如物体的远近程度，透明度，等等。我们已经把 Direct3D 10 系统状态改变的代价进行了充分缩减，因此，重新配置整个管道也是很高效的。

 

6 System Experience( 略 )

7 Future Work( 略 )

8 Conclusions( 略 )
～～～～～～～～～～～～～～～～～～～～～～～～全文完～～～～～～～～～～～～～～～～～～～～～

        呼呼，终于把主要部分都弄完了，希望理解错误的地方不是太多。后3个部分基本都是总结性的东西，就不再翻了。
       最近又比较茫然了，唉～～～。

       Work for money or work for what i like?