Unified Shader架构与HLSL10语言

　　DirectX API作为一个应用程序与GPU的中间件，与其他中间件技术一样其指令翻译是由CPU来完成，随着GPU处理能力的增长超过CPU以后，CPU就成为系统渲染能力的一个瓶颈所在。这个问题在DirectX 9时代的一些高端产品上表现的特别明显，如GeForce 7950GX2 Quad SLi系统，GeForce 7900GTX SLi系统，Radeon X1950XTX CrossFire等系统下CPU俨然是图形性能的最大瓶颈。在可预见的下一个5年中，GPU的图形渲染性能仍将呈突破性增长，这将使在目前已经捉襟见肘的CPU资源更紧缺。为了发挥GPU的强大渲染能力，Microsoft在DirectX 10中致力于把更多的处理放在GPU内部来解决，把CPU从DirectX API的指令翻译中解脱出来。

　　除了致力于把CPU从DirectX API的指令翻译中解脱出来外，DirectX 10还提供了软件开发者更为便利的开发界面，以及提高内部硬件资源的利用率。上面是一个DirectX 9下的一个应用实例。在没有使用Unified Shader Architecture的DirectX 9架构下Vertex Shader单元与Pixel Shader单元是分开的，因此在一些Object比较多的应用下Vertex Shader Unit会处以Full Load的状态，而在通常情况下Pixel Shader Units通常都会处于Full Load状态，而Vertex Shader则比较空闲。VS/PS架构下不仅出现资源利用率不均的问题，指令的调用、场景的切换还会产生巨量的overhead文件。DirectX 10通过引入虚拟机机制可以在Unified Shader Unit中实现Vertex or Pixel or Geometry Shader操作，因此不管在任何的渲染场景环境下，DirectX 10的Unified Shader Architecture都可以灵活的做出更好的Load Balanced，而通过彻底设计的DirectX 10指令也可以有效的降低overhead文件的产生。

　　被广泛应用的高级着色语言HLSL10

　　高级着色语言广泛，迅速的被人们所接受，无疑显示了这种语言的重要性。为了支持新管线的特性，我们对高级着色语言――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也是可以的。

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>