KlayGE游戏引擎

NVIDIA的Optimus技术可以在笔记本上兼顾耗电量和性能，并能做到自动无缝切换。但问题就在于，不想让它自动的时候，该怎么办？在ThinkPad T420s上，NV的独立显卡是NVS 4200M，feature level支持到D3D 11.0；Intel的集成显卡是HD 3000，feature level支持到D3D 10.1。（对feature level还不熟悉的朋友可以看这篇） 在BIOS中控制 支持Optimus的平台上，在BIOS中可以找到选项，可以选择使用NV、Intel或者自动切换。但这个是静态的，每次切换都得重启，肯定不是我们想要的。 在右键菜单中控制 在exe文件的图标上按右键，菜单里有一个“用图形处理器运行”的项，里面可以选择NV卡或者Intel卡。有趣的是，如果你在程序中枚举adapter，总会返回两块 ...

在OpenGL 4.3发布的同时，Khronos同时宣布了OpenGL ES 3.0。由于从OpenGL 3.3和4.2里吸取了大量内容，OpenGL ES 3.0给移动平台带来了许多原本只有桌面才有的功能。其中包括： 对渲染流水线的多项增强，用于加速高级视觉效果：遮挡查询、transform feedback、instanced rendering和支持4个或更多render target。 高质量的ETC2 / EAC纹理压缩成为标准，这样就不再需要给每个平台不同格式的纹理。 新版本的GLSL ES shading language，完整地支持整数和32位浮点操作。 极大地增强了纹理功能，包括保证支持浮点纹理、3D纹理、深度纹理、顶点纹理、NPOT纹理、R/RG纹理、固定纹理、2D纹理数组、通道交换、LOD和mip level钳制、无缝cube ma ...

在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的数量也少得多。

经过两天的努力，手写的ResizeTexture已经取代了D3DX11LoadTextureFromTexture和D3DX11FilterTexture，成功地去掉了所有D3DX的依赖（去掉的原因在此）。同样，原先glu里面我也只用到了gluScaleImage，现在也被替换了。 另一个改动是把D3DReflect的调用彻底挪到了shader JIT中。这样不但提高了载入速度，还去掉了运行期对D3DCompiler_xx.dll的依赖。 现在的KlayGE离Metro-ready越来越近。Windows的ARM版不能完全支持所有传统的Windows API，仍然需要对程序做一些改动才能支持。目前的障碍在于由于ARM没有注册表相关的函数，Python无法顺利地通过VC11编译成ARM版。影响了KlayGE核心的移植。不知道大家有没有什么办法对付这个问题。

自从DX9 SDK提供了D3DX的库之后，相信D3DX一度成了所有相关开发人员必不可少的库。但随着时间的发展，D3DX慢慢被拆散、重组，出现了XNAMath、DirectXTex、D3DCompile之类独立的组件，逐渐取代了D3DX的功能。 现在，DX SDK早已不再更新，被合并到了Windows SDK中。D3DX也彻底退休。虽然你仍可以通过使用DX SDK June 2010来支持D3DX，但Metro风格的新程序就没法那么做了。所以，从现在开始应该逐步减少对D3DX的依赖。 在KlayGE中，出于可移植的原因，从多年前就开始减少使用D3DX了。最先是用自己实现的模板数学库MathLib代替了D3DX Math，接着D3DXEffect这种重量型的框架也被自己实现的更高效的特效管理系统所取代。关于字体渲染，我就不 ...

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 ...

在越来越多的人讨论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 ...