引擎设计跟踪(九.14.2d) [翻译] shader的跨平台方案之2014

Origin: http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in-2014/

简译 translation:

作者在2012年写过一篇shader跨平台的文章, 开始提到了并有链接.

1.手写或者宏替换

使用宏定义将 HLSL & GLSL 的不同之处封装, 并让每个开发人员了解他们的不同之处. 例子: Valve的Source 2引擎

优点: 简单,容易实现
缺点: 每个开发者都必须熟悉使用宏定义库, 还有其他语法上的不同.

2.设计自己的Shader Langugage, 并转换为HLSL/GLSL后端代码

或者使用可视化shader编辑器来动态生成HLSL/GLSL.

3.将HLSL的byte code翻译成GLSL

优点: byte code翻译比HLSL翻译更简单. 而且M$的D3DCompile做了很好的优化, 这样从优化后的byte code, 可以直接转为足够优化的GLSL.

缺点:HLSL的封闭式工具链, 只能在windows上跑. HLSL的编译器做的优化可能太过, 有些优化对于现代显卡没有意义.

对应的工具:

  • James Jones的HLSLCrossCompiler, 支持DX10/11 byte code到多种GLSL的转换, 目前处于活跃开发状态.
  • Ryan Gordon的MojoShader, 支持DX9, SM1.1 - SM3.0
  • Valve的TOGL, 仍然是DX9, 而且部分支持. (只部分支持SM3.0)
  • (译者附: KlayGE 好像也有DX的byte code 到GLSL的翻译器)

4.在源代码级别将HLSL翻译为GLSL, 或者GLSL到HLSL

  • hlsl2glslfork - by Unity: DX9的HLSL转换到GLSL 1.xx 和GLSL ES(支持ES3). Unity的产品和其他地方有用到, 确实可用, 不过原代码不怎么好, 而且不支持DX10/11.
  • ANGLE - by Google: OpenGL ES 2.0 (还有3.0?) 转换到DX9/10的HLSL. 这套GLES的模拟器基于D3D, 正好也有shader交叉编译器.
  • OpenGL Reference Compiler -  by Khronos: 本身只是一个GLSL校验器和解析器, 但是可以用来生成HLSL.
  • HLSL Cross Compiler - by Epic UE4: 不开源.希望会开源吧. 可能是基于Mesa GLSL或者glsl optimizer.
  • hlslparser: 来源未知. DX9的HLSL转换到GLSL3.1
  • MojoShader - by Ryan Gordon:好像有DX9 HLSL的解析代码

原作者是hlsl2glslfork的owner, 使用的是hlsl2glslfork+glsloptimizer(感觉是Unity内部的?).他也曾想过UE4的方式, 用自己的解析器, 或者Mesa 的GLSL栈, 替换掉hlsl2glslfork, 因为Mesa的GLSL代码比hlsl2glslfork的好, 而且支持SM3.0以后的特性,但是他没有时间做.

总结:

作者认为, 目前看来, 最终需要使用两种shader了. 独立于硬件(可以在不同硬件上跑的shader)的方案不太可行. 比如nVidia的Cg, 现在基本停止开发了.(可能是因为Cg太早了, 如果换做现在或许会好点).

翻译DX9 HLSL的方式, 这个基本已经有了解决方案, 比如hlsl2glslfork, mojoshader, ANGLE. 但是目前缺乏DX10/DX11级别的翻译/转换工具, 只有byte code级别的.

(译者注: 记得在搜索的时候发现, 虽然Cg可以直接在A/N卡上跑, 但是Cg是N商的东西, 对A卡支持不好. 目前已经停止开发了, 现在nVidia搞的nvFX, 但是还没有去看是什么情况.

另: 一直以为Cg是个翻译器, 直接翻译成HLSL或者GLSL. 难道有自己的byte code而且可以直接装入显卡运行?)

时间: 2024-10-25 08:48:31

引擎设计跟踪(九.14.2d) [翻译] shader的跨平台方案之2014的相关文章

引擎设计跟踪(九.14.2d) 开发计划

以后的开发计划: 完善game runtime code, 跑简单的demo目前只有编辑器的运行流程, 没有游戏/demo流程, 图形的测试主要在编辑器上测试, 现在需要测试android系统的图形, 没有demo的话没办法测试.计划准备先在Windows下测试, 将Windows下的游戏流程跑起来, 然后加一个简单的demo, 之后就可以测试android的GLES3.0了. 完善android rendering IK动画 Mile Stone 3: scene effects 完善defe

引擎设计跟踪(九.14) 更新记录和骨骼动画导出

骨骼动画是去年打算写的部分, 但是中间因为工作太忙, 已经拖了一年了. 期间也加了其他东西, 比如对UI做了部分完善.UI对toolbar button添加了drop down 支持, 一种是dropdown menu, 一种是dropdown property sheet 实现这些控件不难, 但是要做抽象和复用, 接口设计稍微有点复杂. 现在可以把一个IConfig对象绑定到toolbar的button里了. 这样保存这些配置的时候,直接使用IConfig接口就可以了.贴一个编辑器的配置文件,

引擎设计跟踪(九.14.2a) 导出插件问题修复和 Tangent Space 裂缝修复

由于工作很忙, 近半年的业余时间没空搞了, 不过工作马上忙完了, 趁十一有时间修了一些小问题. 这次更新跟骨骼动画无关, 修复了一个之前的, 关于tangent space裂缝的问题: 引擎设计跟踪(九) 3DS MAX 导出插件 引擎设计跟踪(九.10) Max插件更新,地形问题备忘 这里说明一下修复方法, 并且做一个总结. 之前的做法都不算错, 但是不完善. 这里有缝, 主要是因为那个战争机器3的模型本身已经复制了顶点( 左半部分和右半部分是不同的mesh, 有重合的顶点), 接缝处的顶点虽

引擎设计跟踪(九.14.3.2) Deferred shading的后续实现和优化

最近完成了deferred shading和spot light的支持, 并作了一部分优化. 之前forward shading也只支持方向光, 现在也支持了点光源和探照光. 对于forward shading, 可以在渲染每个对象之前, 用对象的包围盒, 查询空间内的光源, 然后填入shader cosntant里. 因为空间一般是基于四叉树或者八叉树的划分, 所以查询不会慢.现在透明物体也能通过forward shading 正常光照了. Deferred shading optimizat

引擎设计跟踪(九.14.2 final) Inverse Kinematics: CCD 在Blade中的应用

因为工作忙, 好久没有记笔记了, 但是有时候发现还得翻以前的笔记去看, 所以还是尽量记下来备忘. 关于IK, 读了一些paper, 觉得之前翻译的那篇, welman的paper (http://graphics.ucsd.edu/courses/cse169_w04/welman.pdf  摘译:http://www.cnblogs.com/crazii/p/4662199.html) 非常有用, 入门必读. 入门了以后就可以结合工程来拓展了. 先贴一下CCD里面一个关节的分析: 当Pic的方

引擎设计跟踪(九.14.2f) 最近更新: OpenGL ES & tools

之前骨骼动画的IK暂时放一放, 最近在搞GLES的实现. 之前除了GLES没有实现, Android的代码移植已经完毕: [原]跨平台编程注意事项(三): window 到 android 的 移植 总的来说上次移植的改动不是很大, 主要是DLL与.so之间的调整和适配, 还有些C++标准相关的编译错误. 数据包的加载/初始化/配置文件和插件的加载测试可用了, 但GLES没有实现, 所以上次的移植只能在真机上空跑. 最近想在业余时间抽空把GLES的空白填上, 目前接口调整差不多了, GLES r

引擎设计跟踪(九.14.2b) 骨骼动画基本完成

首先贴一个介绍max的sdk和骨骼动画的文章, 虽然很早的文章, 但是很有用, 感谢前辈们的贡献: 3Ds MAX骨骼动画导出插件编写 1.Dual Quaternion 关于Dual Quaternion, 这里不做太详细的介绍了,贴出来几个链接吧: http://en.wikipedia.org/wiki/Dual_quaternion http://www.seas.upenn.edu/~ladislav/kavan08geometric/kavan08geometric.pdf http

引擎设计跟踪(九.14.2i) Android GLES 3.0 完善

最近把渲染设备对应的GLES的API填上了. 主要有IRenderDevice/IShader/ITexture/IGraphicsResourceManager/IIndexBuffer/IVertexBuffer.都是体力活, 根据文档(https://www.khronos.org/opengles/sdk/docs/man3/)填上对应的API就可了.遇到的问题纪录在下面: Stick to the standard C++standard并没有要求char必须是unsignedtype

引擎设计跟踪(九.14.2g) 将GNUMake集成到Visual Studio

最近在做纹理压缩工具, 以及数据包的生成. shader编译已经在vs工程里面了, 使用custom build tool, build命令是调用BladeShaderComplier, 并且每个文件对应一个输出, vs会自动检查工程里面文件的依赖, 这样很方便. 纹理压缩如果也要放在visual studio里面, 可以用build event或者custom build step来做, 但是build dependency很难处理, 比如每个原始贴图对应一张目标贴图, 如果像编译shader