Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Реализация аппаратного композитора HAL

Композиционные слои HAL Hardware Composer (HWC), полученные от SurfaceFlinger, уменьшают количество композиций OpenGL ES (GLES) и производительности графического процессора.

HWC абстрагирует объекты, такие как наложения и двухмерные блитеры, на составные поверхности и обменивается данными со специализированным оборудованием компоновки окон с составными окнами. Используйте HWC для компоновки окон вместо компоновки SurfaceFlinger с графическим процессором. Большинство графических процессоров не оптимизированы для компоновки, и когда графический процессор формирует слои из SurfaceFlinger, приложения не могут использовать графический процессор для собственного рендеринга.

Реализации HWC должны поддерживать:

  • Как минимум четыре наложения:
    • Статус бар
    • Системная панель
    • Приложение
    • Обои / фон
  • Слои, которые больше, чем дисплей (например, обои)
  • Одновременное предварительно умноженное альфа-смешение на пиксель и альфа-смешение на каждую плоскость
  • Аппаратный путь для защищенного воспроизведения видео
  • Порядок упаковки RGBA, YUV-форматы, свойства мозаики, изгиба и шага

Для реализации HWC:

  1. Внедрить нерабочий HWC и отправить всю композиционную работу в GLES.
  2. Реализуйте алгоритм для постепенного делегирования композиции в HWC. Например, делегируйте только первые три или четыре поверхности наложенному оборудованию HWC.
  3. Оптимизировать HWC. Это может включать в себя:
    • Выбор поверхностей, которые максимизируют нагрузку, снимаемую с графического процессора, и отправку их в HWC.
    • Обнаружение, обновляется ли экран. Если это не так, делегируйте состав GLES вместо HWC для экономии энергии. Когда экран снова обновится, продолжайте выгружать композицию в HWC.
    • Подготовка к распространенным случаям использования, таким как:
      • Главный экран, который включает в себя строку состояния, системную панель, окно приложения и живые обои
      • Полноэкранные игры в портретном и ландшафтном режиме
      • Полноэкранное видео с субтитрами и контролем воспроизведения
      • Защищенное воспроизведение видео
      • Многооконный разделенный экран

Примитивы HWC

HWC предоставляет два примитива, слои и дисплеи для представления работы над композицией и ее взаимодействия с оборудованием дисплея. HWC также обеспечивает контроль над VSYNC и обратный вызов для SurfaceFlinger, чтобы уведомить его, когда происходит событие VSYNC.

Интерфейс HIDL

Android 8.0 и выше использует HIDL- интерфейс, называемый Composer HAL, для связанного IPC между HWC и SurfaceFlinger. HAL Composer заменяет устаревший интерфейс hwcomposer2.h . Если поставщики предоставляют реализацию HWC Composer HAL, Composer HAL напрямую принимает вызовы HIDL от SurfaceFlinger. Если поставщики предоставляют устаревшую реализацию HWC, Composer HAL загружает указатели функций из hwcomposer2.h , перенаправляя вызовы HIDL в вызовы указателей функций.

HWC предоставляет функции для определения свойств данного дисплея; переключаться между различными конфигурациями дисплея (такими как разрешение 4k или 1080p) и цветовыми режимами (такими как собственный цвет или истинный sRGB); и для включения, выключения или перехода в режим пониженного энергопотребления, если это поддерживается.

Функциональные указатели

Если поставщики внедряют Composer HAL напрямую, SurfaceFlinger вызывает его функции через HIDL IPC. Например, чтобы создать слой, SurfaceFlinger вызывает createLayer() в HAL Composer.

Если поставщики реализуют интерфейс hwcomposer2.h , HAL Composer вызывает указатели на функции hwcomposer2.h . В hwcomposer2.h комментарии, функции интерфейса HWC называются по именам lowerCamelCase , которые не существуют в интерфейсе как именованных полей. Почти каждая функция загружается путем запроса указателя на функцию, используя функцию getFunction предоставленную hwc2_device_t . Например, функция createLayer является указателем функции типа HWC2_PFN_CREATE_LAYER , который возвращается, когда перечисляемое значение HWC2_FUNCTION_CREATE_LAYER передается в getFunction .

Подробную документацию по функциям Composer HAL и сквозным функциям HWC см. В разделе « composer . Подробную документацию по указателям на функции HWC смотрите в hwcomposer2.h .

Слой и отображение ручки

Слои и дисплеи управляются дескрипторами, сгенерированными HWC. Ручки непрозрачны для SurfaceFlinger.

Когда SurfaceFlinger создает новый слой, он вызывает createLayer , который возвращает тип Layer для прямых реализаций или hwc2_layer_t для hwc2_layer_t реализаций. Когда SurfaceFlinger изменяет свойство этого слоя, SurfaceFlinger передает значение hwc2_layer_t в соответствующую функцию модификации вместе с любой другой информацией, необходимой для выполнения модификации. Тип hwc2_layer_t достаточно велик, чтобы содержать указатель или индекс.

Физические дисплеи создаются путем горячего подключения. Когда физический дисплей подключен в горячем режиме, HWC создает дескриптор и передает его в SurfaceFlinger посредством обратного вызова горячего подключения. Виртуальные дисплеи создаются createVirtualDisplay() вызывающим createVirtualDisplay() для запроса дисплея. Если HWC поддерживает композицию виртуального дисплея, он возвращает дескриптор. Затем SurfaceFlinger делегирует композицию дисплеев в HWC. Если HWC не поддерживает композицию виртуального дисплея, SurfaceFlinger создает дескриптор и компонует дисплей.

Отображение композиционных операций

Раз в VSYNC SurfaceFlinger просыпается, если у него есть новый контент для компоновки. Это новое содержимое может быть новыми буферами изображения из приложений или изменением свойств одного или нескольких слоев. Когда SurfaceFlinger разбудит его:

  1. Обрабатывает транзакции, если они есть.
  2. Защелкивает новые графические буферы, если они есть.
  3. Выполняет новую композицию, если шаг 1 или 2 привел к изменению содержимого дисплея.

Для выполнения новой композиции SurfaceFlinger создает и уничтожает слои или изменяет состояния слоев, в зависимости от обстоятельств. Он также обновляет слои с их текущим содержимым, используя вызовы, такие как setLayerBuffer или setLayerColor . После того, как все слои обновлены, SurfaceFlinger вызывает validateDisplay , который сообщает HWC, чтобы проверить состояние слоев и определить, как будет продолжаться композиция. По умолчанию SurfaceFlinger пытается настроить каждый слой таким образом, чтобы этот слой был скомпонован с помощью HWC; хотя в некоторых случаях SurfaceFlinger создает слои через резервный графический процессор.

После вызова validateDisplay getChangedCompositionTypes вызывает getChangedCompositionTypes чтобы увидеть, хочет ли HWC изменить какой-либо из типов композиции слоя перед выполнением композиции. Чтобы принять изменения, acceptDisplayChanges вызывает acceptDisplayChanges .

Если какие-либо слои помечены для композиции SurfaceFlinger, SurfaceFlinger объединяет их в целевой буфер. Затем setClientTarget вызывает setClientTarget чтобы предоставить буфер для отображения, чтобы буфер мог отображаться на экране или дополнительно комбинироваться со слоями, которые не были отмечены для композиции SurfaceFlinger. Если слои не отмечены для композиции SurfaceFlinger, SurfaceFlinger обходит этап композиции.

Наконец, SurfaceFlinger вызывает presentDisplay чтобы сообщить HWC о завершении процесса компоновки и отображении окончательного результата.

Несколько дисплеев

Android 10 поддерживает несколько физических дисплеев. При разработке реализации HWC, предназначенной для использования на Android 7.0 и выше, в определении HWC есть некоторые ограничения:

  • Предполагается, что есть только один внутренний дисплей. Внутренний дисплей - это дисплей, о котором сообщает начальное горячее подключение во время загрузки. После горячего подключения внутреннего дисплея его нельзя отключить.
  • В дополнение к внутреннему дисплею, любое количество внешних дисплеев может быть подключено к сети во время нормальной работы устройства. Инфраструктура предполагает, что все «горячие» модули после первого внутреннего дисплея являются внешними дисплеями, поэтому, если будут добавлены еще какие-либо внутренние дисплеи, они будут неправильно отнесены к категории Display.TYPE_HDMI вместо Display.TYPE_BUILT_IN .

Хотя описанные выше операции SurfaceFlinger выполняются для каждого дисплея, они выполняются последовательно для всех активных дисплеев, даже если содержимое только одного дисплея обновляется.

Например, если внешний дисплей обновляется, последовательность выглядит следующим образом:

// In Android 9 and lower:

// Update state for internal display
// Update state for external display
validateDisplay(<internal display>)
validateDisplay(<external display>)
presentDisplay(<internal display>)
presentDisplay(<external display>)

// In Android 10 and higher:

// Update state for internal display
// Update state for external display
validateInternal(<internal display>)
presentInternal(<internal display>)
validateExternal(<external display>)
presentExternal(<external display>)

Композиция виртуального дисплея

Композиция виртуального дисплея аналогична композиции внешнего дисплея. Разница между композицией виртуального дисплея и композицией физического дисплея заключается в том, что виртуальные дисплеи отправляют вывод в буфер Gralloc, а не на экран. Hardware Composer (HWC) записывает выходные данные в буфер, обеспечивает ограничение завершения и отправляет буфер потребителю (например, видеокодеру, графическому процессору, процессору и т. Д.). Виртуальные дисплеи могут использовать 2D / блитер или оверлеи, если конвейер дисплея выполняет запись в память.

Режимы

Каждый кадр находится в одном из трех режимов после вызова SurfaceFlinger метода HWC validateDisplay() :

  • GLES - GPU объединяет все слои, записывая их непосредственно в выходной буфер. HWC не участвует в композиции.
  • СМЕШАННЫЙ - GPU объединяет некоторые слои в буфер кадров, а HWC объединяет кадровый буфер и остальные слои, записывая данные непосредственно в выходной буфер.
  • HWC - HWC объединяет все слои и записывает непосредственно в выходной буфер.

Выходной формат

Форматы вывода буфера виртуального дисплея зависят от их режима:

  • Режим GLES - Драйвер EGL устанавливает формат выходного буфера в dequeueBuffer() , обычно RGBA_8888 . Потребитель должен быть в состоянии принять формат вывода, установленный драйвером, иначе буфер не может быть прочитан.
  • Режимы MIXED и HWC - если потребителю необходим доступ к процессору, он устанавливает формат. В противном случае используется формат IMPLEMENTATION_DEFINED , и Gralloc устанавливает лучший формат на основе флагов использования. Например, Gralloc устанавливает формат YCbCr, если потребителем является видеокодер, а HWC может эффективно записывать формат.

Синхронизация заборов

Синхронизация (синхронизация) ограждения являются важнейшим аспектом графической системы Android. Заборы позволяют процессору работать независимо от параллельной работы графического процессора, блокируя только при наличии реальной зависимости.

Например, когда приложение отправляет буфер, который создается на графическом процессоре, оно также отправляет объект ограничения синхронизации. Этот забор сигнализирует, когда графический процессор завершил запись в буфер.

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

Для получения дополнительной информации о заборах синхронизации см. Интеграция Hardware Composer .