KlayGE游戏引擎

2011年，我曾经写过一篇《不争气的geometry shader》，里面比较了在当年的多个平台上跑多种 render to cubemap的方法。经过帧数的对比，得出的结论是geometry shader会造成严重性能问题，甚至还不如渲染6遍的结果。2012年，同样的测试在GTX 580和GTX 680上重新跑了一遍，发现GTX 680上geometry shader终于比渲染6遍更快。 到了2019年，情况又会有什么变化呢？我们再来跑一次。说是2019年，其实我的电脑是2015年配的，Intel i7-4790的CPU，NV GTX 960的GPU。系统是Win10 19H1。但因为GTX 960和D3D 11.4支持在GS之前的stage输出SV_RenderTargetArrayIndex，我们其实不需要GS也能render to cubemap或者render to texture array。所以我们需 ...

很多跨平台游戏引擎都有统一shader的需求。比如KlayGE从建立伊始，就强调一份代码跨多个平台，shader代码也不例外。如果需要对不同平台都分别写一遍shader，那样的工作量和可维护性都很糟糕。 既然有这样的需求，就必然会在技术上遇到一个问题，如何把一份代码编译成不同API上的shader。从目前的API上，我们至少需要应对HLSL/GLSL/ESSL，以后还有Vulkan加入战团。这里就打算探讨一下跨平台shader编译的情况，希望对大家有启发意义。 过去 刚有shader高级语言的时候，Cg是几乎唯一的shader语言。后来才在D3D9时代衍生出了HLSL，再往后有了GLSL和ESSL。所以自然而然一开始都会从Cg入手。在KlayGE发展的过程中，这还分为两个阶段。 运行中 ...

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

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

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

上周末实现了打算在KlayGE 4.0中使用的render to texture array功能。于是自然而然想到在ShadowCubeMap这个例子中使用，用来在1个pass内直接生成cubemap。结果，不比不知道，一比吓一跳。在不同GPU上FPS如下： NV 9800GT NV 480GTX AMD 5870 6 pass Cubemap 158.63 312.82 241.10 Dual Paraboloid 5.77 375.32 211.91 1 pass Cubemap 66.08 288.77 228.44 1 pass Cubemap with instance 105.37 281.34 224.10 1 pass Cubemap with instance GS NA 287.80 211.01 9800GT所在机器的CPU比后两套系统差得多，没法横向比较，只能纵向比较。后两套系统只有GPU不同，可以横向和纵向比较 ...

多年来，在论坛和各个网站上不断能看到拿OpenGL和D3D进行比较的帖子和文章。他们经常制造很多谜思，使得初学者和一些从业人员对OpenGL和D3D产生了各种各样的流言。 有人说，OpenGL直接调到驱动，性能高于D3D。 有人说，Shader都得写两套，很麻烦。 有人说，OpenGL和D3D在底层有很多区别，而且不可设置。 有人说，图形引擎如果要兼容两者，就只能取其功能的交集，最后还不如任何一种API。 真的么？ 本文试图： 找出现代OpenGL和D3D的共通之处 归纳如何让API对上层代码尽量透明 本文不希望： 讲解函数间的对应关系 如何在OpenGL和D3D之间作选择 贬低一方，抬高另一方 下面先从几个比较基本的方面 ...