HLSL:在编译时强制执行常量寄存器限制
在HLSL中,有没有办法限制编译器使用的常量寄存器的数量?
具体来说,如果我有类似的东西:
float4 foobar[300];
在 vs_2_0 顶点着色器中,编译器将愉快地生成具有超过 256 个常量寄存器的效果。但是 2.0 顶点着色器只能保证能够访问 256 个常量寄存器,因此当我尝试使用该效果时,它在运行时以一种模糊且依赖于 GPU 的方式失败。我宁愿它在编译时失败。
这个问题特别烦人,因为编译器本身在幕后分配常量寄存器,在我要求的寄存器之上。我必须检查装配体,看看是否超出了限制。
理想情况下,我想在 HLSL 中执行此操作(我正在使用 XNA 内容管道),但如果有一个可以传递给编译器的标志,那也会很有趣。
In HLSL, is there any way to limit the number of constant registers that the compiler uses?
Specifically, if I have something like:
float4 foobar[300];
In a vs_2_0 vertex shader, the compiler will merrily generate the effect with more than 256 constant registers. But a 2.0 vertex shader is only guaranteed to have access to 256 constant registers, so when I try to use the effect, it fails in an obscure and GPU-dependent way at runtime. I would much rather have it fail at compile time.
This problem is especially annoying as the compiler itself allocates constant registers behind the scenes, on top of the ones I am asking for. I have to check the assembly to see if I'm over the limit.
Ideally I'd like to do this in HLSL (I'm using the XNA content pipeline), but if there's a flag that can be passed to the compiler that would also be interesting.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
根据 Stringer Bell 对 Disassemble 方法的指出,我创建了一个小型的构建后实用程序来解析和检查效果。请注意,这不是很漂亮。它是为 XNA 3.1 设计的,需要来自 XNA WinForms 示例。在命令行上传递内容目录路径,不带尾部斜杠。
Based on Stringer Bell's pointing out of the Disassemble method, I have whipped up a small post-build utility to parse and check the effect. Be warned that this is not very pretty. It is designed for XNA 3.1 and requires the
ServiceContainer
andGraphicsDeviceService
classes from the XNA WinForms sample. Pass a content directory path on the command line with no trailing slash.