텍스쳐의 여러 영역을 업데이트하고 그 영역을 매 프레임마다 OpenGL로 동기화해야하는 프로젝트가 있습니다. iDevices 용 xcode5 프로젝트에서 OpenGL ES 2.0을 사용하고 있습니다.glTexSubImage2D iOS7에서 느림
이러한 텍스처 변경 사항을 동기화하려면 glTexSubImage2D를 사용합니다.이 함수는 바운드 텍스처의 작은 영역에 대해 프레임 당 수백 번 호출 할 수 있습니다. 이 기능은 ios6을 실행하는 iPhone4에서 테스트 할 때 필요한만큼 빠르게 작동합니다.
iOS7을 실행하는 iPad Mini Retina에서 테스트 할 때 상당히 느려집니다. stall은 glTexSubImage2D라는 3 개의 함수에서 mach_msg_trap에 나타납니다. agxuCreateRenderTarget (38.2 %)
불행하게도 CPU의 결합 된 86.1 %를 차지, 나는 (때문에 명성 포인트의 부족으로) 프로파일의 이미지를 게시 할 수 없습니다,하지만 세 가지 기능은 agxuBlitRender에서 호출 SubmitPackets (25.5 %) agxuReleaseAllRenderTargets (16.2 %)
나는 mach_msg_trap 그냥 스레드가 대기하는 동안 회전을 의미 고맙지 만 나는 프로파일에서 기다리고 있는지 확인할 수 없습니다.
나는 초기에 mip-map이나 ios7 force를 재 작성하고 있는지 궁금해했다. glip의 옵션에 따라 mipmap을 켜지는 않았지만 선택의 여지가 많지 않을 수도 있습니다 (모든 TextureMinFilters는 밉맵을 지향합니다. GL_NEAREST로 설정하더라도 GL_NEAREST_MIPMAP_NEAREST로 기본값이 될 수 있습니다). 그것은 GL_NEAREST를 무효로 간주한다). iPhone4 버전이 똑같은 코드를 사용한다는 사실은 두포에서 밉 매핑을 처리 할 때 결정적인 요인이 아닐 수도 있습니다.
프레임 당 한 번만 전체 텍스처를 복사하려고 시도했지만, OpenGL의 핵심 인 twiddle32x32_32가 프레임 당 CPU의 큰 부분을 차지할 때 텍스처 크기가 커질수록 상당히 느려집니다.
도움을 주신 모든 도움.
호기심 때문에 왜 프레임마다 여러 번 텍스처의 많은 부분을 업데이트해야합니까? 이 텍스처가 각 프레임을 재구성하려고 시도하고 있습니까? –
@BradLarson 많은 개체를 처리하기 위해 더 큰 블록으로 모으는 (또는 다시 분할하는) 입자 시스템이 있습니다.내가 물리적 속성을 수집 할 때, 네 개의 작은 큐브가 하나의 큰 큐브에 모이게되는 것과 같이 큰 그래픽 큐브를 수집해야합니다 (크고 큰 큐브와 함께). 그래서 더 작은 엔티티의 텍셀을 함께 움직여 더 큰 그룹의 텍셀로 단순화하고, 자외선을 조정해야합니다. 나는 그것이 텍스처 아트라스의 한 형태라고 생각하며 그것을하는 더 단순하고 (더 잘 이해되는) 방법이있을 것입니다. 비록 Mini Retina에서 iPhone4보다 더 빨리 작동한다면 :) – Drainboy