Невозможно понять логику синхронизации BufferQueue, которая помогает для асинхронного отображения

Question

Я читаю архитектуру Android от this.

С первой попытки я не мог понять все, кроме кусочков здесь и там.

Что я понимаю?

1)

Там что-то называется "Sync Framework. - OK

2)

Эта синхронизация структура может быть использована между процессами и между пространством пользователя и пространством ядра. - OK

3)

Используется для механизма асинхронной. - ОК.

4)

Предполагая, что нет синхронизации рамок.

void display_buffer(struct dma_buf *buf); 

Существует система отображения, который отображает данный буфер.

while (1) { 
    -> Fill the buffer(buf) 
    -> call display_buffer(buf); -> Displays into the screen. 
    } 

Там может быть задержка потому, что синхронное.

5)

Предположим, что мы имеем синхронизации поддержку платформы. Это что-то вроде: я дам систему отображения буфера и начало работы, вам нужно отобразить буфер, когда вы получите сигнал о начале. В то же время, когда вы закончите, вам нужно завести меня в заблуждение. которые предоставила мне система отображения. [я понял не полностью, но я чувствую, что это помогает для асинхронной модели], так что я могу заполнить буфер во время рендеринга системы.

struct sync_fence* display_buffer(struct dma_buf *buf, 
    struct sync_fence *fence); 

Серый Площадь: Но все же, я не мог в состоянии написать псевдокод для того, как может display_buffer на асинхронном режиме можно использовать?

Чтение абзаца с официальной ссылки android.

Последние Android-устройства поддерживают «синхронизацию», что позволяет системе выполнять некоторые полезные функции в сочетании с аппаратными компонентами, которые могут манипулировать графическими данными асинхронно. Например, производитель может представить серию OpenGL ES команды рисования, а затем завершать выходной буфер до завершения рендеринга. Буфер сопровождается заграждением, который сигнализирует, когда содержимое будет готово. Второй забор сопровождает буфер, когда он возвращается в свободный список, так что потребитель может освободить буфер, пока содержимое все еще используется. Этот подход улучшает латентность и пропускную способность, когда буферы перемещаются по системе. «

ВОПРОС:

Я смущен, особенно с этим утверждением

.» Второй забор сопровождает буфер, когда он возвращается в свободный список, так что потребитель может освободите буфер, пока содержимое все еще используется. Такой подход улучшает задержку и пропускную способность, как буферы перемещаться по системе «.

Второй забор на том же самом буфере ?. или другой буфер, как я ?. см есть два буфера очереди один заполняется список и другой один пустой список.

Answer 1

Если вы хотите углубиться в синхронизации рамки, вы также должны прочитать this document и особенно раздел «явная синхронизация» this document.

Ваше описание близко, но не совсем верно. Каждый буфер имеет «заборный» забор и «выпускной» ограждение. «Захватный» забор указывает, когда производитель, такой как OpenGL ES, закончил рендеринг. Он не сообщает потребителю (HardwareComposer, который подает отображение), что нуждается в, чтобы отобразить буфер, а скорее, что теперь разрешено, чтобы отобразить буфер, потому что рендеринг завершен. «Заблокировка» сигнализируется HWC, когда буфер больше не обращается к аппаратным средствам отображения, что означает, что потребителю снова разрешено писать на него.

Снижение латентности является результатом не связывания состояния буфера с его состоянием в очереди. BufferQueue может считать вас заполненными данными до завершения рендеринга и может иметь вас в «свободном» списке до того, как будет отображаться экран, показывающий буфер. Это позволяет механизмам очереди IPC выполнять свою задачу без блокировки на графическом процессоре или дисплее.

Как только сигнализация сигнализируется, она никогда не перестает сигнализировать, поэтому вы не можете использовать один забор для нескольких событий. Вот почему вам нужны два разных забора, поскольку «данные готовы» и «данные больше не нужны».

FWIW, название «BufferQueue» немного вводит в заблуждение. Заполненные буферы находятся в очереди, пустые буферы находятся в пуле. (В пуле есть политика FIFO, поэтому это по существу очередь, но это не гарантируется.)