0

我有一个使用大量片段着色器的应用程序。着色器都在应用程序启动时编译（在后台队列中）。我最近在 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 个 vec4 的统一数组，以及三个纹理。如果我删除任何纹理或减小数组的大小，它会毫无问题地链接。

4

1 回答 1

2

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

  • 如果在 iPhone 5s 上运行时使用 OpenGL ES 3.0，则可以利用统一缓冲区对象 (UBO)，它允许比统一数组更大的存储空间。另请注意，即使您在支持 ES3 的设备上运行时并没有真正利用 ES3 功能，使用 ES3 上下文也会给您带来更大的限制（MAX_TEXTURE_IMAGE_UNITS等）。

  • 大容量数据的另一个好地方是纹理。您在该着色器中使用了三个纹理单元，因此您有足够的空间添加第四个，它可以保存一个 32x32 图像，其数据与您的统一数组相同，并且可能会更快地进行采样。（一般建议是注意此处的相关纹理提取，但在 A7 上没有任何惩罚，因此您可以在特定于新 GPU 的代码中执行此操作。）

于 2013-10-17T22:53:25.917 回答