Использование кэшей текстур OpenGL ES вместо glReadPixels для получения данных текстуры

В iOS 5 были введены кэши текстур OpenGL ES, чтобы обеспечить прямой путь от видеоданных камеры к OpenGL без необходимости копирования буферов. Краткое введение в кэш текстур было представлено в сессии 414 — Достижения в OpenGL ES для iOS 5 от WWDC 2011.

Я нашел интересный article, которая в конце еще больше злоупотребляет этой концепцией и обходит вызов glReadPixels, просто блокируя текстуру, а затем напрямую обращаясь к буферу.

glReadPixels работает очень медленно из-за тайлового рендерера, который используется в iPad 2 (даже если вы используете только текстуры 1x1). Однако описанный метод работает быстрее, чем glReadPixels.

Действительно ли предложенный в статье метод вообще действителен и можно ли его использовать для повышения приложений, которые полагаются на glReadPixels?

Поскольку OpenGL обрабатывает графические данные параллельно с ЦП, как вызов CVPixelBufferLockBaseAddress должен знать, когда рендеринг завершен, не обращаясь к OpenGL?


ios core-video opengl-es-2.0 glreadpixels
person Etan    schedule 13.02.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Я описываю способ сделать это в этом ответе, основанном на вашей статье, указанной выше, и образце Apple ChromaKey с WWDC 2011. Учитывая, что Apple использовала это в одном из своих образцов, и что я не слышал ничего против этого от их инженеров OpenGL ES, я считаю, что это правильное использование кэшей текстур. Он работает на всех устройствах, совместимых с iOS 5.x, которые я пробовал, и точно так же работает в iOS 5.0 и 5.1. Это намного, намного быстрее, чем glReadPixels().

Что касается того, когда блокировать базовый адрес пиксельного буфера, вы должны иметь возможность использовать glFlush() или подобное для блокировки до тех пор, пока все данные не будут отображены в вашей текстуре FBO. Кажется, это работает для кодирования фильма 30 FPS 1080p, которое я сделал из FBO с текстурной поддержкой.

person Brad Larson    schedule 20.03.2012