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

Question

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

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

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

Является ли предложенный в статье метод даже действительным и может ли он использоваться для поддержки приложений, использующих glReadPixels?

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

Answer 1

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

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