博客园_KlayGE游戏引擎

KlayGE C++代码风格指南英文版

2012-05-02T04:52:00Z

转载请注明出处为KlayGE游戏引擎，本文的永久链接为http://www.klayge.org/?p=1941

参考了google的C++风格指南之后，我也照着写出了一份KlayGE C++代码风格指南。主要方针和google的类似，但有几处理念上的区别：

允许使用异常，但仅仅用来抛出错误
在必要的时候允许小心地使用RTTI
const在所修饰类型的右边
可以任意使用boost的库
优先使用stream，而不是printf

有兴趣的朋友可以参考一下。目前只有英文版，中文版正在翻译中，近期将会问世。

本文链接

Normal2Height工具已经完成

2012-05-01T08:20:00Z

转载请注明出处为KlayGE游戏引擎，本文的永久链接为http://www.klayge.org/?p=1930

多年前就想为KlayGE做个Normal2Height的工具，一直没时间，现在终于抽空把它完成了。

缘由

Normal map的来源有多种。游戏开发中常规的做法是根据高模和低模的位置对应关系生成height map，然后用height map生成normal map。这种情况下不必担心是否能得到高精度的height map。但很多低端的做法是让美术直接画normal map，根本没有高模。随着游戏渲染水平的提高，normal mapping（NM）这种1970年代的技术已经不能满足需要了，越来越多的游戏开始过渡到更精确的parallax mapping（PM）、parallax occlusion mapping（POM）甚至displacement mapping（DM）。他们除了normal map，还需要有height map才能工作。所以如果normal map是手绘而成，就会因为缺乏height map而无法升级。如果能反过来，从normal map生成height map，就能在一定程度上解决这个问题。

比较一下normal mapping和parallax occlusion mapping，就可以明显地看出来在视差、遮挡效果和真实感上，POM远胜于NM。

使用Normal mapping渲染

使用Parallax occlusion mapping渲染

算法

我实现的算法是基于NVIDIA在SIGGRAPH 2011上提到的Generating Displacement from Normal Map for use in 3D Games。我就不详细讨论了，有兴趣的朋友可以看原始pdf。这里指讨论一下基本的想法。

从height map计算normal map靠的是差分，所以直觉上从normal map计算height map就需要积分。但因为normal map保存的时候经过量化，误差比较大，造成不同的积分路径无法收敛到同一个值。

所以NV的方法是，先根据normal map计算depth difference map（DDM）。然后对DDM上的每个pixel，根据极坐标从小到大的顺序累计几圈，得到最终的height。

就是这样简单的累积算法，就能得到不错的效果。对于这样的normal map：

可以恢复出height map：

虽然比原始的高精度height map模糊，但在用于POM和DM的时候在视觉上看不出区别。

总结

在有了Normal2Height这样的工具之后，老土的normal mapping都可以顺利地进化到更精致的渲染效果。同时，对原有美术流水线的影响几乎为0。

理论上，还可以尝试通过求解Poisson Equation来得到精度更高的height。

本文链接

FFT镜头效果的新进展

2012-05-01T08:19:00Z

转载请注明出处为KlayGE游戏引擎，本文的永久链接为http://www.klayge.org/?p=1920

FFT镜头效果已经完成，并集成入KlayGE开发版中，命名为FFTLensEffectPostProcess。除此之外，还写了一个命令行工具，用于产生镜头效果的纹理。虽然FFT的方法能在一个pass内产生各种复杂的镜头效果，但目前性能低于默认的多重gaussian blur。其中最主要的开销来自于FFT本身，下面就着重就讨论一下GPU FFT的进展和未来。

前不久我在用Pixel Shader实现FFT的时候，提到了用Compute Shader来实现FFT效率可以更高。之前Ocean的例子里就有用于实现波浪模拟的CS4 FFT（从NV的例子改进而成），它的输入和输出是1D Buffer的形式。为了更通用，在进入KlayGE核心的时候改成了2D Texture的形式。可惜的是，CS4不能写入纹理，就需要增加一个把Buffer转成纹理的PS。CS5的实现基本类似于CS4，但改为直接读写纹理。现在CS4和CS5的FFT都已经实现完毕，终于可以比较一下性能。

算法的差异

由于输出的限制，pixel shader的FFT只能实现最简单的radix-2算法，每次输入2个复数、生成2个复数。而compute shader支持任意写入，所以可以实现更复杂的radix-4、radix-8甚至multi-radix。在这里我实现的是radix-8，每次处理 8个复数。所以512×512只需要6个pass，比PS的18个pass少得多。

另一个区别在于，因为CS4的限制，CS4 FFT的数据都以float2的Buffer来保存（实部和虚部），只有3通道，每个pixel的RGB是排列成R0/R1/R2…Rn G0/G1/G2…Gn B0/B1/B2…Bn的形式。而在PS和CS5的实现中，仍然保留R0G0B0A0/R1G1B1A1/R2G2B2A2…RnGnBnAn的排列，并且是4通道的。所以单从计算来说，CS4少一个通道，标量的计算量和带宽耗用量都会小于PS和CS5。

性能比较

这里的输入是512×512，分别在高端、中端、低端显卡上同时比较了正向FFT和逆向IFFT。

	NV GTX580 FFT/IFFT (ms)	AMD HD6670 FFT/IFFT (ms)	NV 9800GT FFT/IFFT (ms)	NV NVS4200M FFT/IFFT (ms)
PS	2.12/2.28	7.09/7.22	7.99/8.16	33.30/33.30
CS4	0.70/0.70	2.44/2.47	3.33/3.45	10.36/9.80
CS5	0.76/0.76	2.40/2.39	不支持	8.86/8.81

从结果可以看出，CS4的实现能比PS快2倍左右，一方面来自于radix-8带来的计算量减小，另一个方面来自于pass数减少。有趣的是，除了高端的GTX580，其他卡上CS5都比CS4略快。在NV的卡上，以64-bit为单位的IO效率高于其他格式，这一点也给CS4带来了一定的优势。

反过来，这个结果也说明了CS5还有优化的空间。CS5多做了1/3的计算，IO效率也不不是最高的，却能于CS4相似甚至更快。

未来

这个版本里的FFT镜头效果暂时告一段落，除了继续优化之外，以后还有很多算法级别的改进值得尝试。

数据格式

现在所有的中间格式都是ABGR32F。如果用ABGR16F的话，在暗处将会出现一些artifact。如果这样的artifact在可以接受的范围内，或者用其他补偿方法来改进16F的精度，速度就能大大提高。输入和输出格式则不受限制。输入格式可以用ABGR16F、或者更少的 B10G11R11F，输出格式可以用ABGR16F。

纯实数FFT

因为输入数据是张只有实数部分的图像，对纯实数做FFT的结果是头尾对称的，可以利用这一点做算法上的改进。FFTW里面，这个变换称为r2c。对 n长度的输入它只需要输出n/2+1个复数，而不用n个，IO和计算量都可以减小。另一个尝试的方向是DCT。作为FFT的特例，经过特殊寻址安排的 DCT也符合卷积定理。所以用输入输出都是纯实数的DCT也能减少IO。

sFFT

今年一月，MIT的一个团队提出了Spare Fast Fourier Transform（sFFT）的算法。在输入信号稀疏的情况下，sFFT能比传统FFT快之百倍。由于用于镜头效果的输入仅仅是亮度大于某个阈值的pixel，稀疏程度非常高，所以也可能可以利用sFFT来进行加速。

本文链接

Forward框架的逆袭：解析Forward+渲染

2012-04-22T06:58:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/04/21/forward%e6%a1%86%e6%9e%b6%e7%9a%84%e9%80%86%e8%a2%ad%ef%bc%9a%e8%a7%a3%e6%9e%90forward%e6%b8%b2%e6%9f%93/

AMD在7900系列显卡发布的时候同时推出了Leo demo，并说明它不是用近年流行的Deferred框架渲染完成，而是用到了一种叫Forward+的框架。这个框架不需要Deferred的大带宽要求，却仍能实时渲染上千光源。EG2012上有篇新paper叫做Forward+: Bringing Deferred Lighting to the Next Level，讲述的就是这个方法。但目前作者还没有放出该论文的全文，这里我只能通过只言片语和AMD的文档来解析这个神奇的Forward+。

Tiled-based Deferred Shading

在进入正题之前，我们先回顾一下Intel在SIGGRAPH Courses 2010里提到的Tiled-based Deferred Shading。它的算法框架是：

生成G-Buffer，这一步和传统deferred shading一样。
把G-Buffer划分成许多16×16的tile，每个tile根据depth得到bounding box。
对于每个tile，把它的bounding box和light求交，得到对这个tile有贡献的light序列。
对于G-Buffer的每个pixel，用它所在tile的light序列累加计算shading。

在原先的deferred框架下，每个light需要画一个light volume，以决定它会影响到哪些pixel（也就是light culling）。而用tiled based的方法，只需要一个pass就可以对所有的光源进行求交。如果用了AMD在Mecha demo中用到的OIT方法，还可以做一个per-tile linked list，直接把light序列存在链表里。

Forward+ Rendering

有了Tiled-based Deferred Shading的基础，理解Forward+就变得简单多了。Forward+ Rendering和Tiled-based Deferred Shading的关系就好比原先的Forward Shading和Deferred Shading，所以我们可以照猫画虎一次：

Z-prepass，很多forward shading都会用这个作为优化，而在forward+中，这个变成了必然步骤。
把Z-Buffer划分成许多16×16的tile，每个tile根据depth得到bounding box。
对于每个tile，把它的bounding box和light求交，得到对这个tile有贡献的light序列。
对于每个物体，在PS中用该pixel所在tile的light序列累加计算shading。

从这里可以看出，前两步与Tiled-based deferred shading大同小异，但只需要Z-Buffer，而不需要很消耗带宽的G-Buffer（G-Buffer最小也要32bit color + 32bit depth）。第三步是完全一样的。第四部由于用了forward，可以有forward的各种好处：

复杂材质
支持硬件AA（虽然我一直认为硬件AA多算了很多东西，是一种巨大的浪费）
带宽利用率高
支持透明物体

由于light已经在步骤3中cache了，所以也可以不像传统的forward那样，把材质和光源搅在一起。加上shader中动态分支的能力，不难实现类似deferred那样的巨量光源支持。由于带宽省了很多，Forward+的速度能比Deferred快。在原paper里的性能比较足以说明这个问题。

另一个有趣的地方是透明物体的渲染。虽然我在KlayGE中用Deep G-Buffer的方法解决了纯Deferred下透明物体的渲染。正如很多读者指出的，这么做所带来的带宽翻倍在很大程度上拖慢了整个系统。在Forward+中，第一步生成Z-prepass的时候，可以采用双Z- Buffer的办法，一个放不透明物体的Z，另一个放透明物体的Z。在第二步计算tile bounding box的时候，不管透不透明都放在一起计算一个总的bounding box。后面步骤不变，就能原生支持透明物体。

由于有了Z-Buffer，其他原先对Deferred有利的效果，比如GI、SSR，都可以直接应用。SSAO、SSVO之类的方法，如果需要考虑pixel normal，就需要适当的修改才能应用上。

在AMD的demo中，步骤2和3是用compute shader实现的。而在Tiled-based Forward Rendering这篇blog中，他完全用PS实现了per-tile linked list，但仍然需要D3D11的UAV特性。所以Forward+还没法再D3D11之前的硬件上实现。

总结

所谓三十年河东三十年河西，作为Forward框架的新发展，Forward+给我们提供了一个新思路。这样的竞争性发展总比所有资源都投到一方、忽视另一方要好。

从贡献程度来看，最有突破性的其实不是Forward部分，其实是Tiled-based。Forward+只能算作Tiled-based Deferred Shading的“Forward化”。顺便说一下，很多移动平台的GPU在硬件上支持Tiled-based Rendering（TBR），也是利用它来最大化计算相关性和带宽利用率。不支持TBR的Tegra就吃亏许多了。

本文链接

基于Pixel Shader的FFT已经完成

2012-04-22T06:57:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/04/12/%e5%9f%ba%e4%ba%8epixel-shader%e7%9a%84fft%e5%b7%b2%e7%bb%8f%e5%ae%8c%e6%88%90/

上周末把GPU Gems 2里的GPU FFT在KlayGE里实现了一下，经过优化和调整，昨晚已经进入KlayGE的开发版本中。完整的FFT Lens Effects也会很快集成进去。

这里用到的是那篇文章中提到的方法1，因为经过测试，方法2在现代GPU上速度不如方法1。我做的改进是把原来的3张查找表合并成1张，并都用 16F而不是32F的格式保存输入输出数据。在GTX580上，512×512的数据量，PS版本的FFT花费0.94ms左右，能达到CPU FFTW的75倍速度。但即便如此，对于lens effect那样的应用来说还是有点慢。所以接下去考虑用Compute Shader来实现FFT，pass数会减少到1/3。PS每次处理2个数，512×512需要log(512) + log(512) = 18个pass；CS每次可以处理8个数，所以只要6个pass。在Ocean的例子里有个CS4的FFT，需要多两个texture和buffer互转的pass。CS5的FFT将会更干净，效率更高。

本文链接

NV GTX680对GTX580：另一个视角

2012-04-22T06:56:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/03/31/nv-gtx680%e5%af%b9gtx580%ef%bc%9a%e5%8f%a6%e4%b8%80%e4%b8%aa%e8%a7%86%e8%a7%92/

2年前，D3D11显卡刚出来没多久的时候，我曾经做过一个《NV GTX480对ATI HD5870：另一个视角》，用DX SDK的D3D11例子来对当时巅峰的显卡进行各个单项的性能评测。时过境迁，现在NV GTX680已经上市，硬指标对比如下表所示。

	GTX 680	GTX 580
制程（nm）	28	40
晶体管数量（Million）	3540	3000
Die大小（mm^2）	294	520
显存（MB）	2048	1536
SM数量	8	16
核心配比	1536:128:32	512:64:48
核心频率（MHz）	1006-1058	772
shader频率（MHz）	N/A	1544
显存频率（MHz）	6008	4008
像素填充率（GP/s）	32.2	37.06
纹理填充率（GT/s）	128.8	49.41
显存带宽（GB/s）	192	192.4
总线宽度（bit）	256	384
API	D3D11.1 OpenGL 4.2 OpenCL 1.2	D3D11.1 OpenGL 4.2 OpenCL 1.1
Gflop/s	3090.4	1581.1
TDP（watts）	195	244
Gflop/s-watt	15.85	6.48

从指标上可以看出，GTX680的 SP数量急剧提高（512->1536），但SM数量见到原来的一半（16->8），所以每个SM内的SP个数从32猛增到192。这对scheduler是极大的考验。

由于配置上的较大不同，性能能有多高看理论值不行，还是得实际跑程序才能知道。这次的评测仍然分三轮进行，分别评测传统图形流水线，DirectCompute和Tessellation的性能。测试的机器仍是两年前的Dell T5400 Workstation（Xeon E5440 4-core，4GB内存），依次装上GTX580和GTX680。两块显卡都是Zotac的公版。操作系统是Win7 64bit，使用传统界面以消除Areo界面的PS开销。显卡驱动分别是Forceware 295.73和Forceware 301.10。DX SDK的版本是June 2010。

第一轮传统图形流水线

第一论测试的是两块显卡在游戏常见的场景中的图形性能表现，选用的sample是Cascaded shadow depth map，contact hardening shadows， variance shadows 11和Dynamic shadow linkage 11。测试结果如下：

	GTX 680	GTX 580
CascadedShadowDepthMap	332.04	337.63
Contact Hardening Shadows	1225.67	851.30
VarianceShadows11	305.40	309.83
DynamicShaderLinkage11	2716.49	2620.81

很失望吧，除了Contact hardening shadows，GTX 680并没有比GTX 580提高多少，甚至还有所下降。但领先的那个例子恰恰是计算量和带宽要求最大的。

第二轮 DirectCompute

盛传GTX 680的GPGPU能力不如从前，第二轮就来测试DirectCompute这个GPGPU能力。

	GTX 680	GTX 580
NBodyGravityCS11	675.10	374.28
AdaptiveTessellationCS40	1031.88	938.46
HDRToneMappingCS11	3308.63	2815.89

GTX 680在三个例子中都得到了领先的地位，最明显的是NBodyGravityCS11，达到了1.8x的提升。我认为和这个例子的计算量大、但分支较少有关。一个SM包含那么多的SP，对于分支diverse的代价是很大的。

第三轮 Tessellation

Tessellation一直是NV的强项，这次GTX 680的tessellator再次有了提升。

	GTX 680	GTX 580
DetailTessellation11	1077.48	983.20
PN-Triangles	2481.89	2376.34
SimpleBezier11	4373.63	3884.52
SubD11	923.32	578.62

也达到了全部领先的程度。最复杂的SubD11提升1.6x。

以上三个测试可以看到，GTX 680并没有传说中的GTX 580×3的性能，至少，在DX SDK sample的分辨率和复杂程度下没达到。但是可以看到的一个趋势是，对计算量和带宽要求越大的例子，GTX 680的提升就越大，所以其实在大部分时候它的能力是没有完全发挥出来的。分支的程度也比较影响GTX 680，所以应该在shader/kernel级别明智使用分支。另一个重要的事情在于驱动，对比2年前的测试，虽然GTX 580比GTX 480只是多了32个SP，但由于驱动的改进，性能却有非常明显的提升，部分例子甚至达到了3倍。目前GTX 680的驱动刚处于非常初级的状态，相信过一段时间成熟了才会达到GTX 680的最佳状态。

额外测试

在测完DX SDK的例子之后，我与顺便测试了KlayGE的例子。这里选了两个比较有代表性的例子，分别是Deferred和Forward流水线。分辨率是1280×800，高于DX SDK sample的800×600。

	GTX 680	GTX 580
Deferred rendering	150.55	139.84
Shadow cubemap	267.38/330.78	259.08/239.07

Deferred rendering的例子情况类似于前面的评测。比较有趣的是Shadow cubemap的例子。和《不争气的geometry shader》一样，这里分别测试了6 pass cubemap和1 pass cubemap。斜杠之前的FPS是6 pass的。在以前的显卡上，不管是NV还是AMD，通过geometry shader完成render to cubemap都比6 pass还慢。但在GTX 680上，GS终于翻身了，彻底打败6 pass的做法。从这个角度也可以看出GTX 680的硬件性能提升。

总的来说，GTX 680并没有官方宣传的“恐怖”性能。但凭借工艺的进步，在那个Die大小的情况下能达到这样的速度是很不容易的。期待下半年的旗舰GK110。

本文链接

FFT镜头效果解析

2012-03-23T10:28:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/03/22/fft%e9%95%9c%e5%a4%b4%e6%95%88%e6%9e%9c%e8%a7%a3%e6%9e%90/

3DMark11的whitepaper里突出了用FFT实现镜头效果的方法。这里指的镜头效果包括bloom和泛光等，一般在HDR的tone mapping之前做。

传统镜头效果

Bloom是最常见的效果。一般就用一个gaussian blur完成。但那样的结果缺乏层次感，只是亮的一片。在Halo等游戏中，用了较为复杂的bloom方式。它先把HDR image做多次downsample，在每一次上都分别作gaussian blur，然后再以一定的权重混合起来，得到富有层次的bloom。

Bungie的Bloom方法，来自Lighting and Material of HALO 3

对于bloom本身这样已经基本可以了，但如果要增加更多镜头眩光的效果，比如DX SDK里HDRLighting的Star Effect，就得再增加更多的pass。而且如果blur的kernel很大的话，速度也会有严重下降。比如在不少游戏里也开始使用类似Star Trek 11里面的横向镜头眩光，几乎需要一个全屏大小的kernel，对于实时应用来说是伤不起的。（J.J. Abrams在不少片子里都用了这种横向的lens flare）

FFT方法

其实所有这些镜头效果都是blur，也就是用一个kernel去卷积每一个像素。数学上有个卷积定理：

即

其中表示卷积，表示傅里叶变换，表示傅里叶逆变换。也就是说，函数卷积的傅里叶变换是函数傅里叶变换的乘积。所以，所与那些镜头效果需要的卷积都可以在FFT之后的频域上用一次乘法完成。不管你要多少层bloom、多少个star、多大的kernel，全都在1 pass内解决。

整个算法的框架非常简单：

对输入图像做FFT
把FFT过的kernel图像和1的结果做逐像素复数乘法
逆FFT

这就完成了所有的镜头效果。举个实际例子：

输入图像（来自前不久刚完成的Scene Player）

在FFT之前需要downsample到512×512大小，并且只保留亮的部分（bright pass）：

FFT的结果，分别是实数部分和虚数部分：

kernel图像，在Paint.net里面随便画的

kernel也做FFT之后，把两者进行复数相乘，

其中re和im分别表示实部和虚部。

逆FFT的结果

叠加回原图

唯一剩下的问题就是如何得到kernel的图像。目前我想到的方法是提供一个交互工具，由美术手工绘制，旁边显示最终结果。可以预定义一些pattern，在工具中迭加使用。

未来

FFT镜头效果的算法已经探索完成。目前的实验里，FFT调用的是FFTW库，下一步将会在GPU上实现FFT（有PS的版本和CS的版本），这样就能把整条流水线在GPU上，替换掉现在HDR post process里的bloom部分。

FFT还可以用于其它跟卷积有关的操作中，以后我会探索用FFT完成DoF、Bokeh、Motion blur、SSAO等常用的效果。Again，仍是在一个pass内完成。

本文链接

Scene Player初始版本完成

2012-03-23T10:27:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/03/21/scene-player%e5%88%9d%e5%a7%8b%e7%89%88%e6%9c%ac%e5%ae%8c%e6%88%90/

这几天KlayGE更新变少，主要是在做ScenePlayer。正如其名，Scene Player的作用是把场景描述文件的内容“播放”出来。目前场景描述文件是手工写的，以后会用Scene Editor来生成。

ScenePlayer初始版本在原有Deferred Rendering的框架上加入了脚本驱动的系统，可以完全通过Python脚本来控制灯、摄像机、物体的运动。也顺便加入了projective texture的支持。现在已经有多个例子可以通过场景描述文件在ScenePlayer中执行了。

本文链接

kfx格式的复活

2012-02-20T03:44:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/02/20/kfx%e6%a0%bc%e5%bc%8f%e7%9a%84%e5%a4%8d%e6%b4%bb/

老用户一定记得，在KlayGE 3.9之前，用来表示effect的.fxml都需要通过一个python写成的编译器进行离线编译，生成.kfx格式才能给runtime使用。在 3.9里引入了rapidxml，可以直接在runtime读取xml文件，流程变短，开发效率提高了。但随着这两年shader越写越复杂，编译 shader所花的时间越来越多，在载入的时候每次都编译shader，一来浪费时间，二来浪费计算。

KlayGE的模型格式.meshml也有过这样的问题，后来通过一个JIT在载入的时候动态把xml的.meshml编译成二进制的.model_bin，之后的载入速度就极大提高了。既不需要离线编译，也不用担心读取效率。因此，引入一个effect JIT也成了理所当然的事情。所以，事隔多年后，kfx格式原地满血复活。

原先的kfx目标是把effect的东西保存成二进制，以便runtime读取；现在的目标是减少时间和计算的浪费。因此，虽然扩展名仍是kfx，要装的东西仍是二进制的effect，但文件格式和能力并没有也不需要和以前的兼容了。新的格式不光有原先的二进制effect部分，更是可以在同一个文件中保存不同API编译后的shader。目前支持的有HLSL bytecode、GLSL、ESSL。不同的渲染插件可以选择自己能处理的格式读取。将来还将支持更多的二进制格式，尤其是OpenGL ES上的，以应对孱弱的OpenGL ES GLSL编译器。

顺便说说4.0上的.fxml_bin格式。因为Android上没有Cg，所以当时应急引入了.fxml_bin，把在PC上JIT好的ESSL 存在里面。这样Android上只要直接读取ESSL就可以了，不涉及Cg。但因为只是个应急方案，并没有仔细设计，每个fxml_bin只能保存一个 shader。以至于一个fxml可能编译生成许许多多不同的fxml_bin存在目录下。现在终于可以都删掉了。

现在比较一下用了新kfx后的载入速度吧。就选用Deferred Rendering这个shader最多最复杂的例子。

	使用kfx之前（秒）	使用kfx之后（秒）	加速（秒）
D3D11	4.8	2.6	2.2
OpenGL	6.0	2.6	3.4
OpenGL ES	28.2	25.3	2.9

D3D11插件省去了组装HLSL、编译HLSL的时间，大约2.2秒。OpenGL的shader需要经历Cg->传统GLSL-> 现代GLSL的流程，用了kfx之后这些都省掉，所以省下了最多的时间。OpenGL ES和OpenGL流程一样，但ESSL较简单，所以加速没那么明显。需要注意的是OpenGL ES还需要的25秒基本上花在载入纹理上了。因为OpenGL ES模拟器不支持DXT5、SRGB等，需要在载入的时候动态转换成ABGR8，相当慢。以后可能会发展出一个Platform compiler，针对不同平台把资源离线编译出最适合的格式，从根本上解决这个问题。

本文链接

OpenGL驱动的陷阱：ATI篇，再续

2012-02-13T07:04:00Z

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2012/02/13/opengl%e9%a9%b1%e5%8a%a8%e7%9a%84%e9%99%b7%e9%98%b1%ef%bc%9aati%e7%af%87%ef%bc%8c%e5%86%8d%e7%bb%ad/

AMD的OpenGL驱动问题很多，是个众所周知的事情。以前我也写过《OpenGL驱动的陷阱：ATI篇》和《OpenGL驱动的陷阱：ATI篇，后续》来阐述这个问题，当时最新的驱动是Catalyst 10.10。过了一年多的时间，AMD的驱动和KlayGE的代码都有了不少变化，情况又如何呢？

失败的例子

在去年的驱动上，发现的问题主要有三个（ticket #58）：

Deferred Rendering和Global Illumination中，GI的效果只在第一帧出现。没找到原因。
Detailed Surface和JudaTex Viewer中，纹理显示混乱。没找到原因。
GPU Particle System和Particle editor中，粒子没有显示出来。GS编译失败。

更新到Catalyst 12.1后（也可能在11.12或者11.11就更新了，我没测试），问题1直接得到解决，问题3的GS也能编译成功，但仍没有粒子显示，并且在 validate shader的时候打印GS输出的component过多。于是我把GL_GEOMETRY_VERTICES_OUT_EXT强制设置成32后问题解决。由于GLSL里面不能像HLSL，用[maxvertexcount(4)]这样的方式在shader里指定最大顶点输出个数，必须通过调用 glProgramParameteriEXT(glsl_program, GL_GEOMETRY_VERTICES_OUT_EXT, n)来设定。把n定在32，而不是1024这样的大数字之后GLSL program的link和validate都能顺利通过。当然，这个问题的最终解决方案还是应该在未来的HLSL bytecode to GLSL编译器里完成。

对于问题2，我曾经花了很多时间都没找出原因。后来偶然发现AMD的驱动上返回的PS最大纹理单元只有16（虽然它的硬件至少支持32），而 Juda Texture用到了17个纹理单元。所以一改成根据最大纹理单元数自动调整Juda Texture的shader，这个问题就迎刃而解了。

失败的函数

这几个函数是在原先的测试中发现过陷阱，这次再重新测试。

glBlitFramebufferEXT

问题依旧。

glClearBuffer*

已经正常了！

glBeginConditionalRender

本以为所有的例子终于再次都能跑的时候，Deferred Rendering和Post Processing又挂了，都是渲染几帧之后就驱动失去响应，自动重启GPU的大毛病。和前文提到的症状类似，于是轻车熟路地把OGLConditionalRender::BeginConditionalRender和 EndConditionalRender注掉，问题解决。所以还是AMD驱动的那个老毛病，glBeginConditionalRender和 glEndConditionalRender必须配对调用，否则一定会失去响应。在去年的驱动上，这会直接死机，必须强制关机才行。现在好多了，只要等几秒钟，让驱动重启即可。

glCopyImageSubDataNV

这是个新问题。在Catalyst 12.1上，增加了GL_NV_copy_image这个扩展的支持（是的，NV的扩展，也许没多久就会改成EXT甚至ARB）。但测试发现其结果和用glBlitFramebufferEXT一样，显示混乱。

本文链接