OpenGL - KlayGE游戏引擎 Skip to content

Archive

Category: OpenGL
这几年Intel和AMD都推出了集成GPU的消费级CPU,并强调它们的内存是共享的架构,也就是UMA(Unified Memory Architeture)。最近AMD和NVIDIA的独立显卡也加入战团,开始逐步支持UMA。最新的D3D12直接内置了UMA的支持,开发者可以让自己的程序充分利用上UMA所带来的优势。那么UMA能带来什么好处?它的限制在哪里? 各种平台的状况 自从PC上第一块GPU,NVIDIA Geforce 256问世以来,GPU一直都是自带一块显存的。当年的AGP总线是非对称的设计,数据传到GPU要远快于从GPU读回。CPU和GPU的访存是完全分开的。后来的PCIE总线让两端传输的速度相等了,并提供了一些相互访问的能力。在驱动里,system memory的区域可以映射成可以被GPU访问的,反过来 ...
[zh]三年前,我就曾经计划过一个KlayGE的长期研发子项目,D3D11 HLSL字节码到GLSL的编译器。两年前,在d3d1x for linux代码的帮助下,基本的字节码解析和反汇编工具已经实现。如今,这个子项目被正式命名为DXBC2GLSL,在库和工具两个层面上提供HLSL字节码(DXBC)到GLSL的转换。2013年底,DXBC2GLSL支持VS和PS初始版本已经由团队新成员林胜华完成,并提交到开发版本中。GS的支持也已经在上个月加入。当前所有KlayGE中的shader已经全部通过测试。[/zh] [en]Three years ago, I've planned a long-term R&D sub-project of KlayGE, D3D11 HLSL bytecode to GLSL complier. Two years ago, derived from d3d1x for linux, a simple bytec ...
上一篇我们提到了SSSSS,作为本系列的最后一篇,本文将介绍KlayGE 4.4的OpenGL和OpenGLES插件的改进。 OpenGL 4.4 KlayGE在OpenGL方面一直是紧跟spec的步伐,这次也不例外。在八月份OpenGL 4.4发布的时候,glloader和KlayGE的OpenGL插件就很快加上了4.4的支持。并且这次把代码彻底过了一遍,很多原先通过扩展实现的功能,都尽量替换成用核心实现的,提高兼容性。 经过测试,OpenGL插件在NV和Intel的显卡上所有例子都能正常工作。 OpenGLES 3.0 虽然GLES3出了有一段时间了,但硬件支持度和开发环境都还没跟上,所以原先OpenGLES插件只支持2.0。这次尝试了PowerVR和Mali的OpenGLES 3模拟器,觉得还行,就加上了GLES3的支持。Adreno的模 ...
在一年一度的SIGGRAPH大会上,Khronos group按照惯例,发布了OpenGL 4.4。新的OpenGL 4.4标准包含了一些新功能,同时以核心和扩展的形式出现: ARB_buffer_storage ARB_clear_texture ARB_enhanced_layouts ARB_multi_bind ARB_query_buffer_object ARB_texture_mirror_clamp_to_edge ARB_texture_stencil8 ARB_vertex_type_10f_11f_11f_rev 另外,还有一些新扩展也宣布了: ARB_compute_variable_group_size ARB_indirect_parameters ARB_shader_draw_parameters ARB_shader_group_vote ARB_sparse_texture 为什么还是没有direct state access!为什么还是没有direct state access!为什么还是没有dire ...
前两年我曾经写过几篇关于AMD显卡上OpenGL驱动的陷阱,但原先我只在NV和AMD的卡上测试过KlayGE的例子,还从来没在Intel的集成显卡上测试过。前段时间曾经在Intel HD3000的笔记本上小测一下,结果惨不忍睹,所有的例子全部黑屏。最近在做KlayGE 4.3的最终测试和优化,就试图找一下失败的原因,以及修复的方法。这里把遇到的一些大坑总结一下,希望对遇到类似问题的朋友有所提示。 GLSL 所有例子都黑屏,最有可能的就是shader挂了。Debug下打开shader错误输出,果然,在NV和AMD驱动上都没事的GLSL遇到了编译失败。错误行是PS里的varying out vec4 v_gl_FragData。如果不用自定义的varying out,而用系统内建的gl_FragData就没事。所以判断应 ...
在SIGGRAPH 2012上,Khronos发布了OpenGL 4.3的spec,其中最主要的更新就是增加了compute shader!这里有spec的链接: OpenGL 4.3 Core Profile Specification (updated August 6, 2012) OpenGL Shading Language 4.30.6 Specification (updated August 3, 2012) 扩展的更新列表包括: GL_ARB_arrays_of_arrays:允许在GLSL中使用多维数组,比如float f[4][3]。 GL_ARB_ES3_compatibility:提供了EAC和ETC2纹理压缩格式。 GL_ARB_clear_buffer_object:用一个常量来清除buffer object。 GL_ARB_compute_shader:引入了一个新的shader stage,类似于D3D11的compute shader。 GL_ARB_copy_image:在纹理和渲染缓冲区之间 ...
在The Valve Linux Team的博客上看到他们把Left 4 Dead 2移植到Linux,并通过一定的优化,使得速度神奇般地超过了Windows OpenGL和Windows D3D(315 FPS vs 303.4 FPS vs 270.6 FPS)。原文在这里。他们还分析了Windows上OpenGL和D3D的性能差异,结论是在每个batch,OpenGL驱动都比D3D少了一个几毫秒开销。 不过这里比较的应该是D3D9,如果用D3D11的话情况可能会有所区别。毕竟,D3D11的调用开销远小于D3D9,API call的数量也少得多。
在越来越多的人讨论Cg存留问题的时候,Cg 3.1突然发布了。主要的改进有: Cg语言支持uniform buffer。 增加了OpenGL Unified Buffer Object(UBO)。 增加了翻译成OpenGL GLSL version 110和120的支持。 新的tessellation例子。 新的uniform buffer例子。 各个例子都加上了VC10的工程文件。 不知道NV怎么了,给出来的下载链接居然是错误的。正确的是http://http.developer.nvidia.com/Cg/cg_3_1_0010.html,有兴趣的朋友可以看看。
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就更新了,我没测试) ...
从KlayGE 4.0开始,不但有为了下一版本开发的短期任务,还有一些中长期研发的任务。其中之一就是HLSL bytecode to GLSL编译器。现在KlayGE里的shader主要由HLSL写成,通过#ifdef的土办法兼容Cg。对D3D11来说可以直接使用,但对于OpenGL和OpenGL ES 2就得大费周折了。那种情况下,shader需要经过Cg编译器编译成传统的GLSL,在经过我自己的token级别的编译器转换成现代的GLSL,然后才能使用。 为什么不直接用Cg?看看Cg runtime在ATI卡上的表现吧。 为什么不用传统的GLSL?NV的驱动有一套attribute和index之间的绑定规则,比如gl_Position一定是0,gl_Normal一定是6(或者某个数,但是个常量),而且无法通过API来获取预定义attribute的i ...