我有一個項目,我需要更新紋理的多個區域,並將這些區域同步到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