我要发帖 回复

正式会员

3

主题

26

积分

0

专家分

:

私信
发表时间 : 2009-6-16 08:42:58 | 浏览 : 3000    评论 : 5
对于3d 图形程序员,看到了这个标题,可能想到了硝烟弥漫的API大战… 首先声明,这篇文章并不参战,当然也不希望任何人利用本文的观点作为API战争的佐证,本文是要客观的阐述OpenGL 足以实现现代游戏的3d图形表现需要,而不是要贬低其它的API,比如Direct3D,当然本文的读者也不仅限于3d 图形程序员,也可以作为项目制作人选择什么API的一个参考。

如题所言,使用OpenGL制做3D游戏,当然,这不是说一定就直接使用OpenGL API来开发游戏;采用基于OpenGL的Graphics Engine来制作游戏,也包含在这个话题的范畴之内;可以理解为使用OpenGL API制作小型3d图形应用,或者采用基于OpenGL的Graphics Engine 来制作大型的图形应用;

下面就几个方面来说明选择OpenGL 的理由

1.跨平台

这个理由充足么?MS Windows 占据了多数PC用户,但是其它平台用户不应该忽视吧?如Linux,mac; 即便从商业角度来考虑,也不应该主动放弃阵地的。或者你会说,你的游戏只运行在MS Windows 平台,但是我要说,还是要用发展的眼光来看问题,现在的断言不一定永远都成立;举一个很现实的例子来说明这个问题,Windows 6(vista,2008,windows 7 )以后的版本都自己封杀了DX10,DX11,这意味着,DX10的游戏要想运行于WinXP,必须采用DX9 另实现,其实DX10,DX11 有很多的地方无法和DX9对应起来,这必然增大开发得复杂性和成本;然而如果采用OpenGL2.0 或者OpenGL 3.0都没有这个问题;它对任何平台都是一视同仁的,没有强行的拒绝任何系统,OpenGL拒绝的只是霸权主义,强jia(n)用户;这里可以看到,即便只做Windows 程序,DirectX都会难以跨自家的平台…

2.天生支持多核心

次时代游戏,一个非常热火的字眼,多线程渲染就是次时代的重要标志之一;OpenGL诞生伊始,就是针对高性能并行图形工作站而设计的,所以它天生支持多核心系统;而Direct3D 生来就是面向PC用户.根本就没有考虑多核心问题;这里说的多核心是CPU多核,而不是GPU多核;

OpenGL 采用TLS( Thread Local Storage,线程局部存储 )技术实现渲染线程的RenderContext,TLS,对于经常做多线程性能优化的程序员来说,应该非常的熟悉,它意味着互斥访问的零开销;它用的是独立的copy来实现共享资源的访问。

#define _declspec(thread) _THREAD_LOCAL_STORAGE
struct SRenderState
struct SRenderContext
{
SRenderState rs;// render state of this render context
}
struct SRenderTSD
{
SRenderContext* rc;//current render context of this thread
SRenderContext* rc_list;//all of render context of this thread
};

_THREAD_LOCAL_STORAGE SRenderTSD * _render_tsd;

从上面伪结构来看每个渲染线程可以有一个独立的_render_tsd 的copy,虽然你只定义了一个,但是每当有一个线程运行的时候,都有一份独立的copy;意味着每个线程的rc都是没有访问冲突的;既然rc没有访问冲突,那么每个rc的state_block也是独立的;
即便在多核心cpu上并发的执行set_state,也没有任何问题,因为set_state通过上面的_render_tsd来访问自己私有的state block;

假如一个并发的多线程如下所示:

Thread1 – RC1                Thread2 – RC2

//操作RC1                          //操作RC2
SetState()                          SetState()

//采用RC1.state绘制    //采用RC2.state绘制
DrawPrimitive()                DrawPrimitive()
…                    …

从上面看到,上面两个执行序列在多核心上任何时刻被打断都不会出现问题,因为它工作在各自独立的state block上。

另外不同线程的OpenGL渲染资源(纹理,显示列表,VB)是可以全局共享的,可以保证最大的利用率.

这里是否可以说明OpenGL 架构的天生优越性呢?Direct3D11以前的版本是都不行的;如果用Device来代表RenderContext,可以保证状态独立性,但无法实现资源共享;同一个device又只能使用一个state,面临着这样的尴尬境地:共享资源,就不能状态独立;状态独立,就不能共享资源;

到了Direct3D11 终于出现了RenderContext接口,才解决了这个问题。遗憾的是,在我写这篇文章之时,DirectX11 还没有正式发布,仅仅还是Preview 版本;在我设计的引擎中试图采用一些hack手段来改造Direct3D 9 来实现Render Context,后来也放弃了,因为DirectX11 已经意识到了这个问题,并且把它实现了,我没必要费这个力气了,用Direct3D11对应就好了。

3.天生支持多流

对于VertexStream,OpenGL是天生支持多流的;glVertexPointer,glNormalPointer,glTexcoordPointer…等等一系列API就是用来设置流的;Direct3D的FVF很令人讨厌;连MS自己都讨厌它,后来演变出了VertexDeclaration接口…那一堆罗里八索的declaration还是令我欲吐不已。

多流有什么好处?实时改写很高效。比如,修改Normal array,不必把Position,Texcoord,一起unmap…

当然对于只读的vertexbuffer,单流性能最好… 单流,就是跨距顶点格式,访问具有良好的局部性,所以提高了性能;不过,OpenGL 天生支持多流,并不是说它不支持单流,
用同样的api仍然很容易很简洁的实现跨距顶点格式。

4.多视图

多视图问题对于CAD开发者应该很感兴趣;我做过一些调研,大家使用OpenGL做多视图,通常使用这样的方案:在主线程创建所有视图的RenderContext,然后再渲染每个视图之前要执行MakeCurrentContext 操作;并且抱怨MakeCurrentContext 操作的开销很大。这里要说明的是,如果这样做,说明你真的还处在没有入门的阶段;使用OpenGL一定要有线程的概念:RenderContext是属于线程的;

让每个视图都有一个独立的线程,每个渲染线程都有独立的RenderContext,并且使用wglShareLists在不同线程间共享资源,也许你会觉得很麻烦,但是这的确是最佳的办法。

通常多视图都是子窗口,如果多个视图让子窗口在不同线程创建,会导致线程必须自己来处理消息队列,因为消息队列也是线程拥有的东西,并且还要调用AttachInput来给线程获得输入。

另一种思路是让渲染管线和视图相分离,就是采用离屏渲染的方法,让每个视图的渲染流程渲染到离屏的FBO中,在把FBO blit到视图窗口的显示区域。这样离屏渲染放在独立的线程中,而所有视图仍然在同一线程中,这样就解决了消息处理的麻烦问题,同时又实现了多线程并发渲染;

还有一个问题,如何把同时Present 所有的视图?熟悉Direct3D的程序员都知道使用SwapChain,但是OpenGL中的SwapBuffers,或者wglSwapBuffer仍然是一个和RC相关的API,就说此线程的SwapBuffer不能呈现彼线程的渲染视图,即便采用了ShareList来共享fbo也不成。它的实现就是不让你跨线程执行Swap。这也是ms实现的一个蹩脚之处。这个问题困扰了我许久。。。后来我意外之中发现了wglSwapMultipleBuffer 这个API,MS 对这个API的支持非常低调,只在wingdi.h中有寥寥数行声明而已,没有任何文档和注释。。。(真的很想骂ms…)


//wingdi.h
#if (WINVER >= 0x0500)
typedef struct _WGLSWAP
{
HDC hdc;
UINT uiFlags;
} WGLSWAP, *PWGLSWAP, FAR *LPWGLSWAP;

#define WGL_SWAPMULTIPLE_MAX 16
WINGDIAPI DWORD WINAPI wglSwapMultipleBuffers(UINT, CONST WGLSWAP *);
#endif // (WINVER >= 0x0500)

网上没有任何解释,不信你google一下这个api,寥寥无几。
我也只知道uiFlags设置非0表示可以翻转呈现,其他的细节只有ms自己知道了。而且只支持WINVER >= 0x0500的系统,就是说win2k/xp以下的系统不支持这个api,比如win95/98/nt

5.可编程管线

GPU编程今年来如火如荼,和多核环境一样,这也是3d图形编程的重大变化之一。Dx9时代的N6800芯片率先完整实现SHADER MODEL 3,标志着3d 图形编程进入次时代第一阶段。

OpenGL 2.0最初由3dlabs执掌帅印,GLSL1.0的推出,3dslabs功不可没,只是不知怎么就悄悄地被knronos给取代了。看起来knronos雷厉风行,但是雷声大雨点小。。。没有什么实质性的进展。

OpenGL 2.0 中的可编程管线支持Pixel shader,Vertex shader,Geometry Shader,相当于Shader Model 4.

如果从固定功能和可编程功能,以及框架结构对高性能渲染的支持程度来看,OpenGL 是远胜于Direct3D11 以前的任何版本;注意截至本文发布之时,Directx11还是未出生得胎儿,OpenGL 4.0似乎也在酝酿之中,但是看起来有点渺茫,这让我不得不怀疑khronos的实际执行能力了,但愿我怀疑错了。


6.扩展的问题

关于OpenGL 扩展,很多人的一致观点是OpenGL ARB 太官僚,效率太低,不过这的确是个事实。但也不得不承认,慎重的加入新的功能,才能保证质量。另一个观点是OpenGL扩展在不同显卡上支持得程度的不一样,比如 N 卡支持较好,A 卡支持不好。

这里首先要说,Direct3D 的功能也不是在任意显卡上都可以硬件实现,也是依赖硬件实际能力的。另外我个人只偏好 N 卡,A卡上OpenGL效果没怎么见过。但是我坚信一点,如果你只用 ARB 扩展,我相信是相同的。非 ARB 扩展本来就是有差异的。
如果说某一显卡对 ARB 扩展支持的不好,只能说明这款显卡是不合格的,而不能归罪于OpenGL。永远都要记住,OpenGL 只是一套规范而已,某某显卡不符合规范,这不能赖OpenGL吧?

另外,很多人只会用OpenGL 标准功能,而新版本OpenGL 的标准扩展却知之甚少。
而且他总把API版本和硬件OpenGL 版本相混淆,他总会说,MS的OpenGL 只支持1 .21,我如何使用OpenGL 2.0?这两个版本号根本就不是一类,没有可比性。

要使用OpenGL 新功能,推荐大家一定要多上 www.opengl.org这个站点
www.opengl.org/registry 下面的opengl specfiction pdf和那些 opengl extensions 都要看,ARB 开头的扩展是必须要掌握的;

和DirectX8,9,10一样,OpenGL 1.5,2.0,3.0所包含的不仅仅是API中看到的标准功能,也包括ARB标准扩展。

7.可用资源储备量
可用资源,一个是技术资料,包括文档,代码,商业库等等,这一点Direct3D很丰富,OpenGL也不差,大概大家都是轻信了OpenGL 胜过 Direct3D的谣言了,所以Direct3D的可用资源似乎积累的要多一点。
另一种可用资源就是3d用户。和上面的原因一样,很少有人深入的研究它们之间的细微差异,简单的听别人说Direct3D比OpenGL好,就认准了Direct3D了。让我想起了小马过河的故事。。。

最后我想说的是,无论用什么api,或者更退一步说,无论研究什么,自己都要深入的研究一下,才能做出准确的判断,才是对自己负责的一种态度。

最近VR访客

pillwkai26 评论于2009-6-16 12:26:51
有点意思,呵呵
tan_dunming 评论于2009-6-16 14:19:31
顶一下 呵呵
追求卓越
emhxj 评论于2009-6-16 15:50:21
有水平啊
k303281924 评论于2009-6-21 22:59:33
顶一下!!!!
stephencc 评论于2010-3-18 08:26:14
高手说出来的,顶

手机版|VR开发网 ( 津ICP备18009691号 ) 统计 网安备12019202000257

GMT+8, 2020-9-26 07:24 PM

返回顶部