跨越OpenGL和D3D的鸿沟（一）：开篇

转载请注明出处为KlayGE游戏引擎，本文地址为http://www.klayge.org/2011/07/15/%e8%b7%a8%e8%b6%8aopengl%e5%92%8cd3d%e7%9a%84%e9%b8%bf%e6%b2%9f%ef%bc%88%e4%b8%80%ef%bc%89%ef%bc%9a%e5%bc%80%e7%af%87/

多年来，在论坛和各个网站上不断能看到拿OpenGL和D3D进行比较的帖子和文章。他们经常制造很多谜思，使得初学者和一些从业人员对OpenGL和D3D产生了各种各样的流言。

1. 有人说，OpenGL直接调到驱动，性能高于D3D。
2. 有人说，Shader都得写两套，很麻烦。
3. 有人说，OpenGL和D3D在底层有很多区别，而且不可设置。
4. 有人说，图形引擎如果要兼容两者，就只能取其功能的交集，最后还不如任何一种API。

真的么？

本文试图：

• 找出现代OpenGL和D3D的共通之处
• 归纳如何让API对上层代码尽量透明

本文不希望：

• 讲解函数间的对应关系
• 如何在OpenGL和D3D之间作选择
• 贬低一方，抬高另一方

下面先从几个比较基本的方面来探讨如何跨越两个API的鸿沟。

架构

OpenGL和D3D的架构基本上是这个样子的：

 

在架构上其实两者没有什么区别，只是D3D的runtime是在OS里，对于不同硬件来说都是一样的。而OpenGL的runtime直接是和驱动合为一体的。但这并不会造成性能有所差别，破解了流言1。

Shader

OpenGL 的原生shading language是GLSL，D3D的是HLSL。两者语法相似，但细节上天差地别。好在，NVIDIA的Cg在很大程度上类似于HLSL，而且可以编译 出GLSL来。所以，Cg编译器成了跨越这两种shader的桥梁。当然，要真正实用起来，还需要不少工作。比如Cg的Geometry Shader和HLSL 10+的有些许不同，需要通过#ifdef来分开。另外，Cg编译器生成的GLSL需要一些调整才能在ATI的驱动上工作，所以还需要多一次转换。好在这 些事情都可以通过程序自动完成，而且速度很快。具体可以参考KlayGE的OGLShaderObject::ConvertToGLSL。实际上，KlayGE的所有shader都只写了一份（语法用HLSL 11的），在不同API上可以自动编译成原生的shader使用（有OpenGL和OpenGL ES的编译器，曾经还有D3D9的）。这样就没有重写的繁琐，也没有增加runtime开销，破解了流言2。

当然，这里还有另一种更好的选择，把HLSL编译器生成的bytecode转换成GLSL。UE3等引擎用了MojoShader来完成这件事情。优点是不需要多次编译，缺点是不支持SM4+。

坐标系

初学者经常 说，OpenGL用右手坐标系，而D3D用左手；裁剪空间里OpenGL的z是[-1, 1]，而D3D是[0, 1]；不可调和。实际上，直接把左手的顶点和矩阵给OpenGL也是没有问题的。毕竟如果在VS里执行的都是mul(v, matrix)，得到的会是同样的结果。可能会造成麻烦的反而是viewport的z。假设一个经过clip之后的顶点坐标为(x, y, z, w)，那么在OpenGL上，该顶点经过viewport变换的z是(z/w + 1) / 2，而在D3D上则是z/w而已。这对于depth test不影响，但depth buffer里的值就不同了。所以需要对project matrix做一些调整，才能让他们写到depth buffer中的数值相同。具体来说，如果要让OpenGL流水线接受D3D的project matrix，就需要乘上

相当于把project space的顶点z都作了z = z * 2 – 1的操作，所以经过viewport变换就一致了。D3D到OpenGL的矩阵也可以依此类推。所以，在坐标系上，很容易就能使两者接受同样的输入，同时也没有增加runtime开销。

本篇讲的都是可以在不改变API的情况下，通过输入数据来消除OpenGL和D3D之区别。下一篇将讲解如何利用现代OpenGL提供的扩展和新功能，消除一些无法再上层解决的问题，继续破解各种流言。

KlayGE游戏引擎