游戏开发论坛

 找回密码
 立即注册
搜索
查看: 4444|回复: 5

先睹为快——下一代DirectX(上)

[复制链接]

6

主题

390

帖子

400

积分

中级会员

Rank: 3Rank: 3

积分
400
发表于 2004-4-3 08:52:00 | 显示全部楼层 |阅读模式
按:很多术语没有翻,不习惯的朋友请见谅。原文出处:http://www.beyond3d.com/articles/directxnext/

介绍
因为下一个版本的DirectX并不会挨到Longhorn(译者注:MS下一代操作系统的开发代号)的发布,Microsoft DirectX小组在Microsoft Meltdown和一些其他的开发者大会上,用幻灯片预先向开发者们介绍了下一代DirectX(DirectX Next)及其新特性。最近该幻灯演示在MSDN上对公众开放。这篇文章的目的就是提供关于下一代DirectX中新特性的,更全面更详细的评论,并顺水推舟探究一把下一代DirectX可能会提供怎样的能力。

DirectX的前7个版本,满足了针对特殊的图形特性中,最具革命性的性能提升。如environment mapping和bump mapping。而DirectX 8一反潮流,推出了不少新的、用于通用目的的系统。最受瞩目的当属programmable pipeline了,它使得vertex shading和pixel shading不再只是简单的由一些参数做调整,或由开启/关闭一些特效来完成。在DirectX 8中,你能得到一组输入数字和输出数字,并且你可以利用他们为所欲为——只要在硬件资源允许的范围内。至少,对于vertex shading来说是如此。从另一方面来说,pixel shading却受到了不小的限制,并不如上面所说的那么programmable。你可以方便的在输入后(通过vertex shader outputs,pixel shader constants以及textures),完成其中的向量操作后输出到帧缓存(frame buffer),但你也仅仅只能这样了。DirectX 8.1提供了对这方面的一些增强,但是直到DirectX 9的诞生,才真正解决这些问题。

Unified Shader Model(统一着色模型,译者注:翻不好,把中文放在括号内吧)
DirectX 9推出了pixel shader和vertex shader的2.0/2.x/3.0编程模型。2.0是作为所有支持DirectX 9的图形芯片都要支持的最小标准出现的;2.x是为比那个最小标准能多做一些的高级处理芯片所设计的;而3.0则是为全新的一代产品(应该在2004年的某一时间内问世)所打造。Pixel Shader 2.0中的通用寄存器至少比DirectX 8中的通用寄存器多6倍,且拥有比之多2的级数倍(squared)的指令槽(instruction slots)数量。这使得pixel shader的功能几乎和DirectX 8中的vertex shader功能一样强大。同时,对于在vertex shader中使用texture lookup的需求越来越强烈,特别是当应用程序需要利用general-pupose displacement mapping时尤甚。因此,3.0版本的pixel/vertex shading model会拥有非常相似的能力,因为事实上在硬件层面这两个部分使用的元件已经出现了大量的冗余(becoming largely redundant)。顺理成章,所有4.0 的shader models将会在语法和功能上完全相似,允许硬件将不同的硬件元件组合在一个pool中。这样做还能带来一种好处:若某一种shading的性能有所加强,则同时两种shading的性能都会得到增强。

能统一shader model非常了不起——有好些情况下你需要在vertex层做pixel层的操作,或者在pixel层你需要做一些通常在vertex层做的事情。但关于指令数限制呢?还有资源限制?如果你能抛开恶心的硬件限制,随心所欲创建任意多的texture,并能写任意长度的shader,难道不是件很酷的事么?这听上去像是梦话,但是事实证明我们离这一步已经不太远了——这只关系到一件事,那就是图形处理器的显存系统……


虚拟显存
在多数主流显卡上的显存系统,通常是以一种“以处理器为中心”的方式设计的——它所能看到的是texture objects,vertices,triangles和shaders。如果你想随一张texture map渲染一个几何体,但这时这texture并不在显存里,那就需要在处理器进行渲染之前将texture及其mip-maps全调入显存。但这种方法存在一些问题。问题一,太浪费了——某一帧中你不可能需要整个texture object如mip-maps。事实上,mip-map层你最少需要的通常是最能吃你显存和总线带宽的家伙。当游戏的规模非常大且是露天环境,而大量的texture都在非常远的地方,只需要最低分辨率的mipmap时,这种情况尤为明显。这在我们只传输一张texture时不成问题,但若当我们经常访问AGP/系统内存时,问题就会恶化。现代显卡的带宽差不多已经是AGP总线的10倍左右,若用户的显存耗尽时,延迟的情形会非常明显——无论什么应用程序的帧频都会上窜下跳的。

一个解决方案是将所有的texturing工作都放到AGP显存(译者注:可能是系统内存,因与后文不符)里做。这肯定能解决刚才的不同步性能问题。但是问题是为渲染每一帧所需的所有东西都是通过同一个慢速总线所造成的。就是说这只是用一个使所有工作慢下来的方法解决了性能波动问题。所以肯定还有更好的解决方案。

当图形处理器长得越来越像他们的通用处理器同胞兄弟时,也许能从CPU如何管理内存中获得答案。而且事实上,通用处理器也遇到了相似的问题:所有的程序不可能都放在CPU缓存中,而从系统内存中执行程序又太慢。解决方案就是抛开物理内存的限制,转而使用虚拟内存。有了虚拟内存,程序员就不必担心缓存/系统内存究竟有多少,他们就可以使用虚拟内存地址管理内存。虚拟内存分成小的“页”(通常大小在4KB左右)。由具体实现来决定,计算机如何管理每个页并确保页在需要时读入缓存。

当这个用法扩展到图形处理器时,虚拟显存将很好的处理性能波动问题,因为所有textures,shaders以及其他东西都分成了小块在总线上无缝地传输。例如一块4KB的page file,相当于一个32×32×32bit的texture,当一块新的texture出现在视野中时,你应该不会在总线上一遍又一遍的传输该texture,因为它已经相当大了。但相对于性能影响,它又显得非常小。

整数指令集
无需考虑指令数限制的确是编程上的一大改进,但对于让图形处理器更为通用的目标来说,尚有许多地方有待改进。其中比较重要的一方面是整数处理的改进。现在,几乎所有在shader中完成的工作都是浮点数(除static branching之外)。浮点数在多数图形处理中表现的很好,但当你开始处理dynamic branching或者需要进行一种非插值的显存查询时(如索引一块vertex buffer),问题就出现了。

在现在的图形处理器中,你所能做的唯一一种内存寻址就是texture lookup,它使用浮点值。如果地址并不是texel对齐的,则要么取最近的texel(当执行point sampling时),要么取多个texels做插值。对于texture来说这很好,但对于通用内存性质来说,这绝对不够。因为连续的内存块根本和其他的内存块没有关系(因此,在其中取插值是毫无意义的)。幸运的是,Microsoft为了解决这类问题,在4.0 shader model中包含了一整套整数指令集。

无限资源
虚拟显存在资源问题上也有几点帮助。第一,AGP/系统内存较之从前,成为更可行的存储空间,这是由带宽和内存的合理利用所带来的。第二,既然虚拟内存由一个逻辑地址空间表示,那么图形处理器的用户也可以请求任意多的显存——只要虚拟地址空间允许。这由具体实现来决定如何映射虚拟内存到用户计算机上的物理限制。消耗超大空间内存的应用程序可能不会有最优的帧频,但至少他们可以运行起来了。虚拟地址空间也不必很小——3Dlabs的Wildcat VP使用虚拟显存并有16GB的虚拟地址空间。很显然,当你吃掉16GB显存的时候,资源不再成为一个限制了。

当虚拟显存应用在shader上时,情况开始变得有趣了。其中一个问题是,当在旧的内存系统中使用无限制的shader时,内存系统不会将shader看成是指令集,而将他作为一块抽象数据,可能放得进指令槽,也可能放不进。一旦shader被调入,shader会在每一个处理得vertex/pixel上执行一遍直到shader被调出。照这样下去,解决这个问题要么无休止地增加图形处理器上的指令槽,或者利用某种multi-passing技术将shader分割成可管理的小块。对于一个图形处理器来说,能放的进多少指令槽一定有限,所以第一个方法不可取。第二个办法可行,但这就变成虚拟显存系统要做的事情了。

更好的解决方案是自己提供虚拟显存。不像以前把shader当作内存中的唯一实体,而把它们当作任何可以分割成页的东西。假设图形处理器拥有足够的指令槽用以执行一页大小的shader指令,你可以将shader当作一系列的页来执行——调入shader页1,执行shader,然后暂停执行直到下一个页调入,恢复执行,并循环往复直到整个程序执行完毕。指令槽就变成了L1指令缓存,而所有的事务就可以像在通用处理器上处理一样。

虚拟显存让下一代DirectX可以号称“无限资源”,因为现在对于shader没有任何长度限制,对于texture也没有任何大小限制——只要在图形处理器的虚拟地址空间内能容纳所有数据。然而资源,实际上还是存在限制。对于shader,当一个shader大到不能放进图形处理器的L1缓存中时,性能上就会出现一个显著的落差,因为现在需要处理很多页的换进换出,并且在这之间进行等待,更糟糕的是这些全都跟每个象素的shading有关。同样的,当texture开始要分派到系统内存中,或者更糟——硬盘中时,也将出现性能的大幅下降。Microsoft提供了2个新的性能值(caps values)用以指示资源限制——一个指示理论上最大的容量,超过这个容量程序将无法正常工作;另一个指示实际应用中考虑的最大容量,超过这个容量将对实时操作产生影响(定义为640×480下10fps)。

69

主题

335

帖子

343

积分

中级会员

Rank: 3Rank: 3

积分
343
QQ
发表于 2004-4-3 09:58:00 | 显示全部楼层

Re:先睹为快——下一代DirectX(上)

翻译的好难看懂!(我太菜了)就知道了个“虚拟显存”,不过现在的directx9如果显存不够的话,不是就保存到内存了,不知道这个虚拟显存的好处在哪里?

不大明白。。。

18

主题

631

帖子

660

积分

高级会员

Rank: 4

积分
660
发表于 2004-4-3 11:30:00 | 显示全部楼层

Re:先睹为快——下一代DirectX(上)

总之就是对硬件的需求越来越高,能使用的功能越来越多。

5

主题

255

帖子

255

积分

中级会员

Rank: 3Rank: 3

积分
255
发表于 2004-4-3 13:10:00 | 显示全部楼层

Re:先睹为快——下一代DirectX(上)

真的吗?

6

主题

390

帖子

400

积分

中级会员

Rank: 3Rank: 3

积分
400
 楼主| 发表于 2004-4-3 16:40:00 | 显示全部楼层

Re:先睹为快——下一代DirectX(上)

对于虚拟显存,我的理解是:现在可能看不出太多优势,毕竟一旦超出了显存限制就会有显著的性能下降——这对一个实时系统来说是不可接受的(使用虚拟内存后,效率有其不可预知性);但MS可能是在为未来做准备,当计算机模型发展到一定程度,总线速度不成问题时,可能虚拟显存的优势就体现出来了。

翻译是很烂,抛砖引玉,最好还是看原文。大家有什么意见或者发现什么错误请联系我。多谢

1

主题

5

帖子

5

积分

新手上路

Rank: 1

积分
5
发表于 2004-4-8 12:52:00 | 显示全部楼层

Re:先睹为快——下一代DirectX(上)

[em18]
虚存的意义其实是这样的:
所谓的现有的agp调用系统内存的方式是在显存不够的时候把数据存储与系统内存,当要在一段时间内反复使用这些数据的时候,就需要不断地经过agp总线来读取数据,而agp总线地吞吐量是相当有限的。反复如此将大大降低性能。
而虚存的调用方式虽然同样是在显存不够的时候把数据存储与系统内存,但读取的时候就大不一样,)虚存调用方式会在读到不在显存中的数据时把系统内存中的数据调入显存,并在显存满的时候通过一定的算法淘汰一定量的旧的(或长时间不使用的)数据到系统内存,换句话说就是可以动态的保证最近的和最常被使用的数据保留与显存中,使得调用这些数据时可以获得最快的响应,这样就不会出现一段时间反复调用同一数据的时候有太大的性能损失了。而现在的agp内存存放数据是固定的。。。。。。(其缺点不用我再解释了吧
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2025-5-16 16:19

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表