Question

我有一个使用大量片段着色器的应用程序。着色器全部在应用程序启动时编译（在后台队列中）。我最近在iPhone 5S上测试了应用程序，一切正常，但着色器需要更长时间才能编译。在5，编译需要0.8秒。在5S上，需要10秒钟。有谁知道这里发生了什么？

在iPhone 5（运行iOS 7.0.2）上：

   2013-10-16 16:53:41.949 Socialcam[1096:1603] -[EffectCaptureController compileShaders]: start
   2013-10-16 16:53:42.753 Socialcam[1096:1603] -[EffectCaptureController compileShaders]: end

在iPhone 5S（运行iOS 7.0.2）上：

   2013-10-16 16:46:52.856 Socialcam[9757:1603] -[EffectCaptureController compileShaders]: start
   2013-10-16 16:47:03.303 Socialcam[9757:1603] -[EffectCaptureController compileShaders]: end

编辑更多信息

更深入地研究这个问题，看起来iPhone 5S无法处理与之前设备一样多的制服。这实际上不是编译问题。对于我的一个着色器，链接阶段会挂起10秒钟，然后失败。对于所有其他着色器，没有问题，编译和链接只需几毫秒。有问题的着色器使用768 vec4s的均匀阵列，以及三种纹理。如果我删除任何纹理，或减少数组的大小，它链接没有问题。

Answer 1

由于听起来像大制服是问题，这里有一些替代方案：

如果在iPhone 5s上运行时使用OpenGL ES 3.0，则可以利用统一缓冲区对象（UBO），它允许比统一阵列大得多的存储空间。另请注意，即使您在支持ES3的设备上运行时没有真正利用ES3功能，使用ES3上下文也会为您提供更大的限制（MAX_TEXTURE_IMAGE_UNITS等）。
批量数据的另一个好处是纹理。您在该着色器中使用了三个纹理单元，因此您有足够的空间来添加第四个，这可以容纳32x32图像，其数据与您的统一阵列相同，并且可能更快地采样。（一般的建议是在这里注意依赖的纹理提取，但是在A7上没有惩罚，所以你可以在特定于新GPU的代码中这样做。）

iPhone 5S上的OpenGL ES 2.0片段着色器编译速度很慢

1 个答案: