Skip to content

Archive

Tag: GLSL
经过越来越多的测试,在Windows上DXBC2GLSL已经可以取代Cg成为主要的shader编译工具了。由于DXBC2GLSL需要用d3dcompiler把HLSL编译成DXBC,在非Windows上,原先就只能仍然使用Cg来做HLSL到GLSL的转换。 后Cg时代 且不说Cg那差的要死的GLSL支持度,不久前NVIDIA宣布停止Cg的开发和维护,继续用Cg肯定不是个办法。那么在非Windows上编译HLSL就有几个选择: 开发一个自己的跨平台HLSL编译器。 用wine的HLSL编译器。 用wine载入d3dcompiler。 UE4用了第一个选择,但它需要花费的时间精力实在太大了,对于KlayGE来说不合算。第二个选择按说是最佳方法。Wine致力于实现可以在Linux上执行Windows原生程序的抽象层,其中包含了d3dcompil ...
[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 ...
从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 ...
多年来,在论坛和各个网站上不断能看到拿OpenGL和D3D进行比较的帖子和文章。他们经常制造很多谜思,使得初学者和一些从业人员对OpenGL和D3D产生了各种各样的流言。 有人说,OpenGL直接调到驱动,性能高于D3D。 有人说,Shader都得写两套,很麻烦。 有人说,OpenGL和D3D在底层有很多区别,而且不可设置。 有人说,图形引擎如果要兼容两者,就只能取其功能的交集,最后还不如任何一种API。 真的么? 本文试图: 找出现代OpenGL和D3D的共通之处 归纳如何让API对上层代码尽量透明 本文不希望: 讲解函数间的对应关系 如何在OpenGL和D3D之间作选择 贬低一方,抬高另一方 下面先从几个比较基本的方面 ...
上一个帖子提到了在Catalyst 11.4上,KlayGE的OpenGL插件黑屏的情况,现已查明是因为AMD和NVIDIA的GLSL不兼容的原因。NV的驱动上fragment shader可以定义varying out vec4 v_gl_FragData[8]这样的输出数组,但AMD的驱动上不支持。所以我再次修改GLSL生成器,把数组拆成独立变量,解决了问题。但实际上AMD的GLSL预定义了out vec4 gl_FragData[],所以变成预定义可以,自定义不行的情况。估计得等以后他们自行解决吧,目前只能先绕开了。