Понимание необходимости сигналов Android VSYNC

Я пытаюсь лучше понять подсистему отображения Android, но один момент, который все еще сбивает меня с толку, — это то, как обрабатываются сигналы VSYNC и почему их так много.

Android разработан для использования VSYNC в своей основе, но он использует несколько сигналов VSYNC. Через https://source.android.com/devices/graphics/implement.html в разделе "VSYNC Смещение" представлена ​​блок-схема, на которой показаны три сигнала VSYNC: HW_VSYNC_0, VSYNC и SF-VSYNC. Я понимаю, что HW_VSYNC используется для обновления времени в DispSync, а VSYNC и SF-VSYNC используются приложениями и SurfaceFlinger, но зачем вообще нужны эти отдельные сигналы? Кроме того, как смещения влияют на эти сигналы? Есть ли где-нибудь временная диаграмма, которая лучше объясняет это?

Спасибо за любую помощь, которую вы можете предложить.


person Shookit    schedule 14.01.2015    source источник


Ответы (1)


Чтобы понять это, лучше всего начать с документа Графическая архитектура системного уровня, обращая особое внимание на Раздел Необходимость тройной буферизации и связанная с ним диаграмма (в идеале это должен быть анимированный GIF). Предложение, начинающееся со слов «Если приложение начинает рендеринг на полпути между сигналами VSYNC», говорит именно о DispSync. Надеюсь, после того, как вы это прочтете, раздел DispSync графического документа устройства станет более понятным.

На большинстве устройств смещения DispSync не настроены, поэтому на самом деле имеется только один сигнал VSYNC. В дальнейшем я предполагаю, что DispSync включен.

Аппаратное обеспечение обеспечивает только один сигнал VSYNC, соответствующий обновлению основного дисплея. Остальные генерируются программно с помощью кода SurfaceFlinger DispSync, срабатывая с фиксированным смещением от фактического VSYNC. Некоторое умное программное обеспечение используется для предотвращения смещения таймингов по фазе.

Сигналы используются для запуска композиции SurfaceFlinger и отрисовки приложения. Если вы будете следовать разделу в документе по архитектуре, вы увидите, что это устанавливает два кадра задержки между тем, когда приложение отображает свое содержимое, и тем, когда содержимое появляется на экране. Подумайте об этом так: при трех случаях VSYNC приложение отрисовывает в V0, система выполняет композицию в V1, а скомпонованный кадр отправляется на дисплей в V2.

Если вы пытаетесь отслеживать сенсорный ввод, возможно, перемещая карту под пальцем пользователя, любая задержка будет восприниматься пользователем как вялая реакция на касание. Цель состоит в том, чтобы свести к минимуму задержку для улучшения взаимодействия с пользователем. Предположим, мы немного задержали события, поэтому приложение отрисовывает в версии 0.5, мы компонуем в версии 1.2, а затем переключаемся на отображение в версии 2. Смещая активность приложения и SF, мы уменьшаем общую задержку с 2 кадров до 1,5, как показано ниже.

введите здесь описание изображения

Вот для чего нужен DispSync. На диаграмме обратной связи на странице, на которую вы ссылаетесь, HW_VSYNC_0 — это аппаратное обновление для физического дисплея, VSYNC вызывает визуализацию приложения, а SF_VSYNC заставляет SurfaceFlinger выполнять композицию. Ссылаться на них как «VSYNC» немного неправильно, но на ЖК-панели называть что-либо «VSYNC», вероятно, неправильно.

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

Изменить: вы можете увидеть, как настроены значения в файле Конфигурация платы Nexus 5. Обратите внимание на настройки для VSYNC_EVENT_PHASE_OFFSET_NS и SF_VSYNC_EVENT_PHASE_OFFSET_NS.

person fadden    schedule 14.01.2015
comment
fadden, еще раз спасибо за помощь. Всего два вопроса: 1) Имеет ли смысл эта временная диаграмма? Оригинал (2 кадра задержки): i.imgur.com/4E2cD9l.png DispSync: i.imgur.com/p7LdmXF.png 2) Можно ли рисовать и компоновать в одном кадре, если достаточно уменьшить смещения (риск сокращения времени рендеринга)? - person Shookit; 14.01.2015
comment
Схемы выглядят хорошо. Можно рисовать и компоновать за один интервал VSYNC (обычно 16,7 мс), но на практике трудно регулярно укладываться в эти сроки, поэтому попытки сделать это часто приводят к дерьмовым результатам. Обратите внимание, что композиция SurfaceFlinger выполняется очень быстро, если все помещается в оверлеи, но если она возвращается к композиции GLES, это займет больше времени, особенно если SF и приложение в конечном итоге конкурируют за ресурсы графического процессора. Наиболее точной визуализацией DispSync является вывод системной трассы с устройства, на котором она включена, например. Нексус 5. - person fadden; 14.01.2015
comment
Есть ли аппаратная причина, по которой плата не поддерживает DispSync? Или это просто дополнительные испытания, которые производитель должен провести для реализации? Я тестирую N4 и заметил, что ни один из флагов VSYNC_EVENT_PHASE_OFFSET_NS не определен для N4 (равно как и RUNNING_WITHOUT_SYNC_FRAMEWORK). В этом случае по умолчанию они равны 0, отключая DispSync? - person Shookit; 15.01.2015
comment
Мы надеялись, что OEM-производители смогут предоставлять сигналы VSYNC в противофазе, но это не сработало, поэтому вместо этого было использовано программное решение. Последний раз, когда я проверял, у очень немногих устройств была включена DispSync. RUNNING_WITHOUT_SYNC_FRAMEWORK является отдельным, но связанным - он относится к системе ограждений, описанной в разделе «Явная синхронизация» графического документа, связанного с вашим вопросом. Платы Nvidia tegra3 устанавливают это, например. android.googlesource.com/device/asus/grouper/ +/леденец-релиз/ . Они использовали старый неявный подход к синхронизации, хотя сейчас это может быть исправлено. - person fadden; 15.01.2015
comment
Понятно; Я очень ценю ваше время. Я организую все это в ваш ответ, когда у меня будет несколько запасных циклов. Одна быстрая проверка: если DispSync не используется, то HW_VSYNC_0 немедленно запускает VSYNC-app и VSYNC-sf, или они все еще запускаются программным таймером? Или что в конечном итоге вызывает срабатывание этих сигналов? - person Shookit; 15.01.2015
comment
Если DispSync не включен, аппаратная VSYNC запускает и SF, и приложение. Следует отметить, что не все приложения управляются VSYNC. Пользовательский интерфейс Framework запускается с помощью обратных вызовов Choreographer, поэтому анимация происходит в VSYNC, но многие приложения (особенно игры) просто передают кадры в SurfaceView так быстро, как только могут. Они по-прежнему ограничены VSYNC, потому что они будут блокироваться в ожидании опустошения BufferQueue, но они явно не спят на VSYNC. (Честно говоря, документ графической арки может быть в 10 раз больше и все равно не охватывать всех входов и выходов.) - person fadden; 15.01.2015