被广泛应用的高级着色语言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也是可以的。

　　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系统状态改变的代价进行了充分缩减，因此，重新配置整个管道也是很高效的。