我有一个项目,我需要更新纹理的多个区域,并将这些区域同步到openGL的每一帧。我正在使用openGL ES 2.0和iDevices的xcode5项目。glTexSubImage2D慢ios7
要同步那些纹理更改,我使用glTexSubImage2D,可能会为绑定纹理的小区域每帧几百次调用此函数。在运行ios6的iPhone4上进行测试时,此功能足以满足我的需求。
当我在运行ios7的iPad迷你视网膜上进行测试时,它显着停滞。 该档位显示在mach_msg_trap中,由glTexSubImage2D下调用的三个函数显示。
不幸的是我不能发布的配置文件的图像(由于缺乏信誉分),但三个功能从agxuBlitRender调用,占用了CPU的组合86.1%: agxuCreateRenderTarget(38.2%) SubmitPackets(25.5%) agxuReleaseAllRenderTargets(16.2%)
我很感激mach_msg_trap只是意味着线程在等待时正在旋转,但我无法从分析器中确定它正在等待什么。
我最初想知道它是重建mip-maps还是其他一些ios7强制的过程。我没有打开mipmap,虽然根据gl.h中的选项,我可能没有太多选择(即使将它设置为GL_NEAREST,所有TextureMinFilters都是以mipmap为导向的,但可能会默认为GL_NEAREST_MIPMAP_NEAREST if它认为GL_NEAREST无效)。 iPhone4版本使用完全相同的代码的事实可能不是决定性的因素,如果它涉及底层的mipmapping。
虽然我试过每帧只复制一次整个纹理,但当纹理尺寸较大时,如果函数twiddle32x32_32深入到openGL的核心,则每帧会消耗大部分CPU,这会变得明显慢一些。
任何帮助感激地收到。
出于好奇,为什么你需要更新纹理的许多单独的区域,每帧多次?这是你试图重建每一帧的纹理图集? –
@BradLarson我有一个粒子系统,其中许多对象被聚集成更大的块(或再次分割)进行处理。当我收集他们的物理特性时,我还需要收集它们的图形,比如四个小立方体被聚集成一个更大的立方体(等等,立方体越大越大)。所以我需要让小实体的纹理元素一起移动,以便简化为更大的纹理元组,从而随时调整UV。我想这是一种纹理图集,可能会有更简单(更好理解)的方法。如果Mini Retina的工作速度比iPhone4更快:) – Drainboy