GPUImage가 runloop이있는 쓰레드 대신 세마포어와 처리 큐를 사용하는 이유는 무엇입니까?

Question

내가 아는 한 GPUImage는 DAG 탐색을 수행하고 프레임 버퍼 텍스처 캐시와 함께 단일 사용 리소스로 취급하면서 OpenGL 사용을 보호하기 위해 세마포어를 사용합니다.

여기에 세마포어를 사용해야하는 이유가 있습니까? 그들은 불필요하게 상황을 복잡하게하지 않습니까? 이들이 제공하는 이점과 runloop의 별도 스레드에서 실행하는 대신 각 필터 DAG에 별도의 스레드 구현을 사용하면 어떤 종류의 문제가 발생할 수 있습니다. 현재 GPUImage 아키텍처에 대한 결정을 알리는 특정 디자인 고려 사항이 있습니까?

Answer 1

OpenGL (ES) 컨텍스트로 작업 할 때 한 번에 둘 이상의 스레드에서 액세스하면 문제가 발생합니다. 주 스레드에서 모든 렌더링 및 상호 작용 코드를 간단히 수행 할 수는 있지만 UI가 방해가되어 UI 이벤트 (예 : 메뉴 풀다운) 중에 이미지 또는 비디오 처리가 중단됩니다. 백그라운드 스레드에서 OpenGL (ES) 렌더링을 수행하는데도 significant performance advantages이 있습니다.

따라서 백그라운드 스레드에서 OpenGL (ES) 렌더링을 수행하면서 동시에 액세스를 보호해야합니다. 수동으로 작성된 스레드와 잠금이이를 수행하는 한 방법이지만 잠금은 상당한 성능 오버 헤드를 가지며 수동으로 작성된 스레드를 적절하게 관리하면 많은 코드가 추가 될 수 있고 자원을 낭비 할 수 있습니다.

한 번에 한 번 씩 그랜드 센트럴 디스패치 대기열은 이와 같이 공유 리소스에 안전하고 잠금없는 액세스를 제공하는 비교적 쉽고 효율적인 방법입니다. 컨텍스트에서 OpenGL (ES) 렌더링을 수행하려는 모든 장소는 컨텍스트 직렬 디스패치 대기열에 발송되도록 블록으로 간단하게 포장합니다. 따라서 코드에서 이러한 액세스가 이루어지는 위치를 쉽게 알 수 있으며 수동 스레드, runloops 및 잠금을 유지 관리하는 성능 및 코드 오버 헤드를 방지 할 수 있습니다.

왜 내가 디스패치 세마포어를 my answer here에 사용하는지에 대해 논의하지만 이것은로드에 응답하여 수신 프레임을 선택적으로 삭제하는 방법입니다.

이와 같은 직렬 디스패치 대기열을 사용하면 주어진 시간에 대기열을 통과하는 단일 이미지 또는 비디오 프레임 만 갖고 싶습니다. 단일 GPU를 사용하면 한 번에 두 개 이상의 이미지를 렌더링 할 수 있습니다.

그러나 초당 30-60 프레임으로 처리 할 프레임을 제공하는 카메라가 있고 이러한 이미지를 처리하기 위해 처리 파이프 라인이 때때로 1/30 또는 1/60 초 이상 걸리는 경우, 당신은 결정을 내려야합니다. 들어오는 프레임을 드롭하거나 처리 대기열에 추가합니까? 후자의 경우 사용 가능한 처리 및 메모리 리소스가 모두 소진 될 때까지 대기열에 점점 더 많은 프레임을 계속 구축 할 것이며 처리 과정에서 더 큰 지연을 볼 수 있습니다.

디스패치 세마포어를 사용하면 직렬 디스패치 대기열에서 이미 처리중인 프레임이 있으면 즉시 프레임을 삭제하고 효율적이고 안전하게 수행 할 수 있습니다. 또한 몇 줄의 코드 만 추가합니다. 거의 모든 코드는 my answer here입니다 (스위프트 3에서는 더 짧고 읽기 쉽습니다).

내가 위에서 설명한 아키텍처는 철저히 프로파일 링되었으며, 이러한 요구 사항에 가장 적합한 솔루션이었습니다. 오래된 IOS 하드웨어에서 분자 모델을 60 FPS OpenGL ES로 렌더링하고, Mac에서 실시간 머신 비전 처리를하고, iOS에서 실시간 비디오 필터링을 제공하는 데 수년 동안 사용해 왔습니다. 다중 스레드 코드로 잘못 될 수있는 모든 것들을 감안할 때 매우 견고하고 유지 관리가 쉽다는 것이 입증되었습니다. GCD 대기열 및 세마포어의 오버 헤드는 비디오 렌더링의 성능 병목 현상에 가깝지 않습니다.