有没有办法使用汇编手动编码着色器而不是在iPhone上使用GLSL？

Question

我想使用手工编码的汇编语言顶点和片段着色器,以便使用OpenGL ES 2.0在iPhone上编写非常优化的着色器.

我google了一下,但我找不到一个例子,即使苹果sdk允许它.

Answer 1

在iPhone上,无法手动调整着色器.值得注意的是,特别是在iPhone上,没有优化可以让编译器无法做到.也就是说,GLSL编译器可能会击败或匹配您的手动调整组件.

然而,在PC上,我个人并不相信驱动程序知道循环着色器应该使用更少的寄存器和更多指令,以便通过更高的占用率实现更高的吞吐量.司机根本没有足够的背景来做出正确的选择.特定于数据的编译时优化就是这个问题的一个很好的例子.

作为实际查看了GLSL编译器的汇编输出并尝试使用编译器的寄存器分配策略的人,我可以告诉你,没有组装访问绝对会损害性能(在PC上,有一些来自NVidia和AMD的公开工具)允许你这样做).使用组件的权衡是每个着色器都需要针对每个支持的部件进行手动调整,以实现最大可能的性能.虽然这有点极端,但如果我想投入自己的时间来精细调整我的产品支持的每个视频卡的渲染后端,那么我应该能够这样做.一个更实际的例子是低端视频卡的手动调整,但让GLSL编译器在更高端的视频卡上做它的工作.

此外,离线编译器提供安全机制.今天许多视频游戏都依赖于驱动程序来模拟现代图形API中的许多功能.作为一个在PC上的游戏即服务领域工作的游戏开发人员,我可以告诉你,由于新发布的图形驱动程序中存在轻微的GLSL错误,因此在半夜接听电话非常令人沮丧.驱动程序错误严重影响整体玩家体验.大多数玩家只是认为你的游戏被打破了,结果你实际上可能会失去玩家(而且我们可能会失败).能够为每个支持的视频卡编译一次并在事后进行手动调整将是这方面的巨大胜利.它只是意味着驾驶员必须做更少的工作.代码是邪恶的,因此执行的代码越少越好=).

作为旁注,我使用'compile' - 'view assembly' - 'modify' - 'repeat'方法进行了以下演示:http://www.youtube.com/watch？v = km0DpZUgvbg.我可以100%肯定地告诉你,我可以用汇编语言进一步提高这种射线追踪器的性能,而AFAIK,它是已经发布的最快的体素射线追踪器(截至2012年3月的情况,但是可能不再是真的).不出所料,每次有新的驱动程序出现时,我都会看到这个演示的性能从125-130 fps下降到30 fps - 所有这些都是因为驱动程序不知道如何正确优化我的着色器.这意味着每次新驱动程序出现时我都必须重复我的优化过程,这导致我只是将项目暂停(确认!).即使我的体素光线跟踪器能够以高性能方式支持各种硬件,但驱动程序目前无法在完整产品中支持此技术.我只是没有把这项技术付诸实践的重要性,因为它需要驱动程序供应商知道他们需要优化我的着色器的方式.如果我们只是直接进行装配着色器访问,那么有多少其他技术是可能的？这意味着缺乏组装访问实际上是一个严重的成本.对于这个职位的其他人,我建议如下:尽可能使用NVidia的汇编语言,如果没有,则回退到GLSL.如果我们展示了装配优于GLSL的优势,那么希望我们能够获得所有供应商的一流装配支持=).如果我们只是直接进行装配着色器访问,那么有多少其他技术是可能的？这意味着缺乏组装访问实际上是一个严重的成本.对于这个职位的其他人,我建议如下:尽可能使用NVidia的汇编语言,如果没有,则回退到GLSL.如果我们展示了装配优于GLSL的优势,那么希望我们能够获得所有供应商的一流装配支持=).如果我们只是直接进行装配着色器访问,那么有多少其他技术是可能的？这意味着缺乏组装访问实际上是一个严重的成本.对于这个职位的其他人,我建议如下:尽可能使用NVidia的汇编语言,如果没有,则回退到GLSL.如果我们展示了装配优于GLSL的优势,那么希望我们能够获得所有供应商的一流装配支持=).

最后,不要选择另一位作者,但我想指出"Nicol Bolas"所提出的论点几乎完全是错误的(对不起Nicol,我没有反对你,但我想指出一些流行的论点,只是不要坚持道德测试).请注意,一个谬误的论点并不意味着一个特定的结论是不正确的 - 只是所提出的论点只是谬误.

"为什么？你不相信编译器能做到这一点吗？你真的认为你对GPU有足够的了解能够不断击败编译器吗？"

• 这不是一个论点.这只是一个很多人无法想到真正答案的问题.因此,他们得出结论,他们应该只信任编译器.这可以防止人们进一步调查信任编译器的后果,并阻止对实际利弊的逻辑讨论发生.此外,在你的第二个问题中使用"真实"一词意味着回答是的人必须被欺骗.这也暗示了你对自己的看法,尼科尔 - 它意味着你重视你的观点高于所有其他人,任何不认为你的人都必须对他们有所不妥(不是说他们错了,而是他们有他们出了什么问题 - 差别很大.也就是说,您可能需要花一些时间来思考您的思考过程,你的感受和情绪状态.采用这种方法会严重限制你的学习能力,因为你不会以足够严谨的方式挑战自己的想法.请停止使用此参数.这不健康或道德.

"最终,你只需要相信构建GPU的人所做的编译器.这些天没有其他人有问题."

• 我有一个问题.而且,即使没有人确实有问题,这仍然无关紧要.事实是,允许汇编着色器可能仍然有一些好处.也就是说,达成共识并不意味着正确.此外,这个论点特别不道德,因为有一个隐含的"这些天没有其他人有问题,所以如果你有问题,你的想法一定很奇怪或过时".人们有一种自然的愿望,并且使用这种论点是一种在这个问题上将人们分开并迫害那些不像你的人的方式.也就是说,这个论点因其含义而特别隐蔽.请不要使用这个论点.

尼科尔,你的两个谬论都暗示你是正确和正常的,任何不同意你的人都是错的,并且他们有些不对劲.这些是非常不健康的观点,你应该严格检查它们以适应自己的心理健康和事业.

供将来参考:http://en.wikipedia.org/wiki/List_of_fallacies#Formal_fallacies

谢谢!

Answer 2

我想使用手工编码的汇编语言顶点和片段着色器，以便使用 opengl es 2.0 在 iPhone 上编写非常优化的着色器。

为什么？您不相信编译器能够完成它的工作吗？您真的认为您对相关 GPU 有足够的了解，能够始终击败编译器吗？

无论如何，你不能。您也无法在桌面 OpenGL 中做到这一点。ARB 装配着色器并不比 GLSL 更接近硬件；它们都经过内部编译器的编译和优化。

最终，您只需要信任构建 GPU 的人制作的编译器即可。如今没有人对此有任何问题。