Używanie buforowania tekstur OpenGL ES zamiast glReadPixels w celu uzyskania danych tekstury

Question

W iOS 5 zostały wprowadzone pamięci podręczne OpenGL ES Texture zapewniające bezpośrednią drogę od danych wideo kamery do OpenGL bez potrzeby kopiowania buforów. Wprowadzono krótkie wprowadzenie do pamięci podręcznych tekstury w session 414 - Advances in OpenGL ES for iOS 5 of WWDC 2011.

Znalazłem interesujący article, który w dalszym ciągu nadużywa tej koncepcji i omija połączenie z glReadPixels przez proste zablokowanie tekstury, a następnie bezpośredni dostęp do bufora.

glReadPixels jest bardzo wolny z powodu opartego na kaflu renderera, który jest używany w iPadzie 2 (nawet jeśli używasz tylko tekstur 1x1). Jednak opisana metoda wydaje się działać szybciej niż glReadPixels.

Czy proponowana metoda w artykule nawet ważne i może być stosowany w celu zwiększenia aplikacji, które opierają się na glReadPixels?

Ponieważ OpenGL przetwarza dane graficzne równolegle do procesora, jak powinno się znać wywołanie CVPixelBufferLockBaseAddress, gdy renderowanie odbywa się bez rozmowy z OpenGL?

Answer 1

Opiszę, jak to zrobić w this answer, na podstawie powyższego artykułu i próbki ChromaKey firmy Apple z WWDC 2011. Biorąc pod uwagę, że Apple użył tego w jednej z ich próbek, i że nie słyszałem nic przeciwnego temu ze swoich inżynierów OpenGL ES, uważam, że jest to prawidłowe wykorzystanie pamięci podręcznych tekstur. Działa na każdym urządzeniu zgodnym z IOS 5.x, które wypróbowałem i działa równie dobrze w iOS 5.0 i 5.1. Jest znacznie, znacznie szybszy niż glReadPixels().

Co do tego, kiedy zablokować bazowy adres bufora pikseli, powinieneś być w stanie użyć glFlush() lub podobnego do zablokowania, dopóki wszystkie dane nie zostaną wyrenderowane do twojej tekstury FBO. Wydaje się, że działa to w przypadku kodowania filmów o szybkości 30 klatek na sekundę w rozdzielczości 1080p, które wykonałem z zabezpieczonych teksturami reklamowymi.