2014-01-16 1 views
2

텍스쳐의 여러 영역을 업데이트하고 그 영역을 매 프레임마다 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의 큰 부분을 차지할 때 텍스처 크기가 커질수록 상당히 느려집니다.

도움을 주신 모든 도움.

+0

호기심 때문에 왜 프레임마다 여러 번 텍스처의 많은 부분을 업데이트해야합니까? 이 텍스처가 각 프레임을 재구성하려고 시도하고 있습니까? –

+0

@BradLarson 많은 개체를 처리하기 위해 더 큰 블록으로 모으는 (또는 다시 분할하는) 입자 시스템이 있습니다.내가 물리적 속성을 수집 할 때, 네 개의 작은 큐브가 하나의 큰 큐브에 모이게되는 것과 같이 큰 그래픽 큐브를 수집해야합니다 (크고 큰 큐브와 함께). 그래서 더 작은 엔티티의 텍셀을 함께 움직여 더 큰 그룹의 텍셀로 단순화하고, 자외선을 조정해야합니다. 나는 그것이 텍스처 아트라스의 한 형태라고 생각하며 그것을하는 더 단순하고 (더 잘 이해되는) 방법이있을 것입니다. 비록 Mini Retina에서 iPhone4보다 더 빨리 작동한다면 :) – Drainboy

답변

1

지연 렌더링 타일 기반 디자인 및 왜곡 때문에 PowerVR GPU를 사용하는 모든 장치에서 glTexSubImage2D()가 매우 느립니다. 저는 EGL 이미지 확장을 사용하여 텍스처에 대한 가상 포인터를 얻고 픽셀에 직접 액세스 할 수있는 Android에 익숙합니다. 이것은 일반적으로 4 배 빠릅니다. 그러나 iOS에서도 이와 유사한 기능을 사용할 수 있다고 읽었습니다. 예를 들어 :

Using OpenGL ES texture caches instead of glReadPixels to get texture data

+0

Thanks Clay. 그래픽 레이어에서 픽셀 데이터를 읽는 것이 아니라 쓰는 것이 좋습니다. – Drainboy

0

glTexSubImage2D()를 호출 "프레임 당 수백 번"정말 나쁜 것입니다. 물러서서 왜해야하는지 스스로 물어보십시오. GPU가이를 지원하도록 설계되지 않았기 때문에 모든 플랫폼에서 속도가 느려집니다.

런타임에 텍스처 업데이트가 필요한 것은 무엇입니까?

해야하는 경우, 하나의 옵션은 텍스처를 주 메모리에 보관하는 것입니다 (BGRA 또는 LUMINENCE 픽셀 배열로). 거기에서 업데이트를 수행하십시오. 그런 다음 한 번의 호출로 GPU에 업로드하십시오. CPU가 멈추는 것을 최소화하려면 프레임의 처음 또는 끝에 업로드해야합니다. (GPU가 현재 그 텍스처를 사용하고 있다면 CPU는 오랜 시간을 차단할 것입니다.)

+0

Sean, 내가하고있는 일이 비 전형적이며, 초기 프로토 타입, 덜 강력한 하드웨어에서 작동하지 않는다면 "좋은 시도, 다른 것을 해보겠습니다"라고 말했을 것입니다. iPhone4에서의 나의 필요와 새로운 하드웨어에 대한 요구가 완벽하게 신속하게 처리된다는 사실은 (동일한 코드와 내용으로) 내 문제입니다. iPad의 경우 지금은 gTexlSubImage2D (많은 CPU가 twiddle32x32_32로 손실 됨)로 한 번에 업로드 중이며, iPhone.com4를 각 텍스쳐 변경 (코드의 동일한 지점)에 대한 gTexlSubImage2D 호출로 업데이트하면서 이유를 알고 싶습니다 가능한 경우이를 피하는 것이 필요합니다. – Drainboy

+0

구체적으로, 최악의 경우에도 iPhone4에서 CPU의 1 % 미만을 차지합니다. iPad Mini Retina에서는 mach_msg_trap에 85 % 이상 앉아서 1-2fps로 실행합니다. 같은 상황에서 당신도 아마 그 이유를 알고 싶을 것입니다 :) – Drainboy

+0

@Drainboy - 사용중인 함수의 CPU 기반 프로파일 링이 iOS 장치에서 실제 성능을 매우 정확하게 표현할 수 있을지 확신하지 못합니다. PowerVR GPU의 지연 특성 때문입니다. 렌더링 성능에 대한 의미있는 데이터를 얻으려면 화면의 처음부터 프레젠테이션까지 전체 프레임 렌더링 시간을 거의보아야합니다. 그러나, 그 망막 iPad 미니에는 A7 칩이 있고 Xcode의 최신 버전에는 더 나은 프로파일 링 정보를 줄 수있는 새로운 쉐이더 프로파일 러가 있습니다. 여기서 시도해 볼 수도 있습니다. –

관련 문제