|
|
原文出处：http://www.beyond3d.com/articles/directxnext/index.php?p=4
通用I/O模型
Unified shading model会带来一系列有趣的结果，其中有一些无法很快能得知。其中最显著的莫过于在vertex shader中处理texturing。这对于通用目的尤其重要，但并不仅限与此。另外一个显著后果是，拥有可以在vertex shader中直接写vertex buffer的能力，允许为今后的passes缓存结果。这在使用high-order surface mapping和high-order displacement mapping时显得尤为重要。允许你执行一次tessellate、displace然后将结果存储在显存中的vertex buffer中，在以后所有的passes中只需执行一个简单的查找（lookup）就能达到利用先前结果的目的。
也许最显著的特征发生在，将虚拟显存的哲学和上面提到的两个特征组合在一起时。有了虚拟显存，从texture中读数据和写数据的过程变得与读内存或写内存非常相似。而因此，导致了下一代DirectX中的通用IO模型的诞生。你现在可以在显存中写入任何数据，然后在pipeline的任意stage中都可以读取，甚至在后一个pass中也行。这些数据可以不必是vertex，pixel，或者其他图形数据——你拥有了对当前索引和vertex buffer的访问能力，你就可以为轮廓边的检测生成连通性信息。事实上，你应该可以在GPU上完成的一个pass中，生成所有的shadow volumes，然后将结果存储在显存中，让以后的passes使用。但这还有个小问题：在几何缩放（tessellation）之外，当前的显卡不能直接创建三角形。
拓扑学处理器
实际上，当前的图形处理器可以在使用点线等primitives时，创建新三角形。多数主流图形处理器只能将三角形光栅化（rasterizing），意味着所有的点线要在某一时刻转换成三角形。而任一点或者线要由2个三角形表示，这就需要2到6倍的顶点数（vertices）（取决于你的索引方式），而这一步当然越晚做越好。这样做是有好处的，而且实际上，对于shadow volume的操作也遇到同样的问题。这就需要将pipeline中这个部分做为完全可编程的（programmable），且先前阻塞的场景可以不依赖于主处理器。Microsoft将它称为拓扑学处理器（Topology Processor），并允许shadow volume和fur fin extrusions得以完全在图形处理器上完成。其他如proper line mitering，point sprite expansion和single pass render-to-cube也同样可以在图形处理器上完成。
拓扑学处理器在逻辑上是和tessellation元件分开的。这完全可能，然而一个设计合理的programmable primitive processor应该对这两方面都能进行操作。
增强的Tessellator
高次表面（higher-order surfaces）由DirectX 8首先推出，而很多硬件支持该特性（nVidia以RT-Patches的形式，ATI以N-Patches的形式），但由于他们的功能限制以及过于晦涩难懂，所以一直没有什么人对它们感兴趣。因此，所有硬件厂商都放弃了对高次表面的支持。直到DirectX9的出现，带来了adaptive tessellation（自适应几何缩放）和displacement mapping（置换贴图）。高次表面现在使用起来依然让人痛苦不堪，而且功能很受限制；但displacement mapping很好的解决了它的问题，并且已有不少开发者开始关注它。但不幸的是，硬件厂商已经放弃了对高次表面的支持，所以对displacement mapping感兴趣的开发者也只能因缺乏硬件支持而被迫放弃它。公平的说，对displacement mapping的实现一开始有点偏重Matrox公司，所以毫不奇怪没有很多硬件厂商支持它（甚至连Matrox自己也放弃了对它的支持）。有了符合pixel/vertex shader 3.0的硬件，情况可能会有所改观，硬件厂商可能会重拾高次表明和displacement mapping的旧局。但这还有一个关于所有当前DirectX高次表面的公式限制问题（formulations limitations）。
如果所有硬件都能直接支持所有普通高次表面的公式，如Catmull-Rom，Bezier以及B-Splines（B样条），表面细分（subdivision surfaces），所有的圆锥公式（all the conics）和所有合理的公式，那将是非常酷的一件事。若所有这些都能被用于自适应几何缩放那就更好了。如果DirectX支持所有这些高次表面，那么离真正使用它们的日子就不远了——你可以从你喜欢的DCC应用程序（Digital Content Creation Application）中导入高次表面，而现有系统中所有的问题全部一扫而光。幸运的是这就是Microsoft将要对下一代DirectX所要做的。有了displacement mapping和新的拓扑学处理器，我们真没有理由不去使用这些新特性了！（当然还得硬件支持）
普通API的改进
不是所有的增强都是新特性方面的——毕竟原有的DirectX接口中还存在不少累赘，特别是处理状态改变（state changes）的。当前，如果你想渲染一幅场景，它会分解成一系列批处理的几何体，这些几何体拥有完全相同的textures，存储在vertex buffer的同一连续块中，使用完全相同的vertex shaders，使用相同的转换矩阵等等。一般来说，如果在几何体中的一块，只要有一点点的不同，它们就必须分开来渲染。问题来了：对于每个绘图调用来说，这样的开销过大了。因为绘图调用指令必须通过DirectX接口，通过显卡驱动，最终到达图形处理器。这些问题只能由操作系统提供的高效接口来解决，很显然，Microsoft计划在Longhorn中搞定这些问题。
还有一些减少开销的方法：通过允许网格（mesh）在图形处理器中实现具化（instancing）。网格的具化是一种过程：将一个网格创建它的多个实例，使用不同的转换，不同的textures，甚至不同的displacement maps。
实际上，有了通用IO模型，应该可以将所有可见的textures和转换矩阵放进一个数组中，可由shader访问，将所有共享一个shader的几何体当作一个大批处理，并让shader决定对哪个几何体集合使用哪个texture或者哪个转换矩阵。这种将所有状态管理移交给图形处理器的做法，将大大减少CPU在渲染时的工作负担。
在Pixel Shader中访问帧缓存
你常常会想在某个图像上做些计算，比如做数字分阶（digital grading），色彩矫正（color correction）或者tone mapping。然而在DirectX9中，你无法读取当前你正向帧缓存覆盖的象素值，因为在多数的立即模式渲染器中，无法确认该值是否已经被正常写入。但实际上，当你试图从待渲染的texture中读取数据时，多数图形处理器和驱动程序工作的很好。不过因为这是个未定义的行为（undefined behavior），它可能会在任何时候导致崩掉你的程序，所以开发者不会指望这样的功能。在下一代DirectX中，开发者们终于得到了他们多年来梦想得到的功能——在pixel shader中（可能吧）直接访问帧缓存（中的象素）。为什么我说可能？因为在下一代DirectX的显卡规范中，并未指明对立即模式的渲染器这不再是个问题，所以很显然，厂商们会要求把这样的特性从规范中去掉。估计多数情况下，该特性只能作为一个可选的特性，于是可怜的开发者只能走回老路去做了。
但如果强制要求，你就可以在pixel shader中做当前固定功能混合器（fixed function blenders）所能做的任何事了（如从帧缓存中存储的多个光源中，累计光照贡献度），而不用再起另一个渲染目标。事实上，一些硬件厂商可能会放弃固定功能混合器而选择将功能通过pixel shading模拟，就像ATI放弃了固定功能顶点处理（fixed function vertex processing）并用vertex shading完全模拟。这并不是说会在晶体管上有所增加来让处理进行的快一些。需要注意的是tile-based deferred renderers没有这些问题，所以你还是要观察硬件厂商对此的支持。
结论
实际上，下一代DirectX的很多大改进都很好的适合了tile-based deferred renderers。新型的内存管理模型，允许无限资源，允许无限的几何体，都一直是deferred rendering implementations所关注的方面。对于从pixel shader对当前帧缓存的访问，也能在tile-based deferred renderer上轻易实现，因为所有的数据都已经安放在tile buffer中。因此并不需要开销非常大的外部内存访问，或者代价高昂的管道和后端缓存flushes。前端对vertex/geometry shader所作的改变独立于tile-based deferred rendering法则，因此对于支持tile-based deferred renderers不成问题（因为用于即时模式的渲染器）。看看PowerVR是不是会利用这次机会搞出个具震撼力的下一代DirectX实现。
观察这些建议特性是如何开发出来的也非常有意思——这些特性并不明朗。例如，拓扑学处理器究竟会出现在pipeline中的哪一部分？而且关于新的tessellator单元是否是可编程的（programmable），或者高度可配置的（highly configurable），或者只是纯固定功能的（purely fixed function），都是未知数。
现在的API还是只是一个雏形，这里讨论的很多可能在一段时间内并不发布，可能会有大幅改动，或者根本不会出现，但肯定的是，在接下来的几年里，实时计算机图形的发展将会变得非常有趣。
特别感谢
（拷贝原文了）
A big “thank you” goes out to Dave Baumann, Conor Stokes and anyone else who provided input ? thanks, guys. ?
|
|
发表于 2004-4-3 16:37:00
