2016-09-21 126 views
0

我有一个比较复杂的着色器,我想编译它。 着色器有700行,编译成〜3000条指令。HLSL编译速度

编译时间与fxc(Windows 8 SDK)约90秒。 我有另一个类似大小的着色器,编译时间为20秒。

因此,这里是我的问题:

  • 可以加快从应用的角度(FXC或FXC替代的速度更快的版本)的编制?
  • 是否有可能加快从代码视点编译(是代码构造大大减慢编译 - 哪些,如何避免它们)?
  • 是否有可能加快编译fxc设置的观点(一些秘密选项 - 快速编译或其他)?

编辑:在MSDN论坛

并行线程:

https://social.msdn.microsoft.com/Forums/en-US/5e60c68e-8902-48d6-b497-e86ac4f2cfe7/hlsl-compilation-speed?forum=vclanguage

回答

0

为什么着色器编译时间的问题? Fxc是一个离线编译器,这意味着生成的字节码是独立于硬件的,可以与应用程序一起分发。

如果您希望在开发过程中缩短迭代时间,可以使用“/ Od”命令行选项禁用最优化。

+0

问题当然是发展。编译可以通过incredibuild相对快速完成,但有两个关键部分 - 链接和编译着色器。由于着色器是从共享的C++头文件中清除的,因此每次代码更新都会导致新的编译。这是令人讨厌的... – user4663214

1

没有“更快”的fxc或d3dcompile库。

你可以通过不同的东西来加快速度,关闭优化就是其中之一,因为驱动程序会优化从dxbc到最终的微码。

但是,最好的建议是实现着色器缓存,例如,如果您预处理并散列着色器文件并仅在实际上不同时触发编译,则会节省时间。

d3dcompile库是多线程安全的,并且您想要利用多核CPU。如果编译多个着色器,那么实现包含接口来缓存文件加载也是很有价值的。最后,当一切都失败时,你别无选择,只能进行实验,找到需要这么长时间的东西,并且做一些重写,有时候,对于罪魁祸首可能足以解决编译时间。

+0

'[fastopt]'在我的经验中比其他国旗更好地工作,以提高构建时间。 –