Архитектура встроенного графического драйвера

Александр Семенов

Встроенный графический драйвер Intel (Intel Embedded Graphics Driver, IEGD) рассчитан на разработчиков встроенных платформ и служит альтернативой драйверам для настольных и мобильных систем. Он имеет наращиваемую архитектуру, которая позволяет интеграторам встроенных систем и OEM-производителям оборудования сократить время выпуска новой продукции за счет отказа от создания дорогостоящих опытных образцов и сокращения времени освоения продукции при разработке заказных платформ.

Наращиваемая архитектура драйвера IEGD должна отвечать самым разнообразным и часто меняющимся требованиям к системам при их покупке. В настоящее время драйвер IEGD поддерживает наборы микросхем Intel 815/815E, Intel 845GV, Intel 852GME и 855GME. Благодаря расширяемой структуре драйвер способен поддерживать и новые модели НМС корпорации Intel, которые разрабатываются для семейства Intel Embedded 915, а также для других встроенных наборов микросхем.

Драйвер IEGD совместим со многими ОС, включая Microsoft Windows NT/2000/XP, Windows CE.NET, а также Red Hat и SUSE Linux. Архитектура IEGD поддерживает и функции вывода на дисплей для микропрограмм, например, Intel Embedded Video BIOS (vBIOS).

Благодаря блочной архитектуре порта дисплея IEGD может настраиваться на различные видеоподсистемы. Интерфейс порта, применяемый в IEGD, поддерживает такие популярные форматы кодеров и передатчиков, как TMDS, LVDS и TVout. Предусмотрена поддержка сторонних разработчиков драйверов порта, что облегчает процессы разработки и распространения драйверов.

Требования рынка встроенных устройств

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

Для рынка встроенных устройств очень важен размер программного кода драйвера. Большое значение имеет и то, что этот сегмент рынка объединяет продукцию, работающую под управлением самых разных ОС, включая несколько поколений Microsoft Windows, различные версии Linux, специализированные ОС. Наращиваемая архитектура драйвера IEGD как раз и должна удовлетворять всем этим требованиям и дать возможность сократить производственный цикл выпуска продукции. Модульность архитектуры позволяет также снизить степень риска, который обычно связан с добавлением новых функций в существующий драйвер.

Расширяемость

В плане расширяемости основная задача – обеспечить совместимость драйвера с разными ОС. Для этого в архитектуре IEGD предусмотрен сегментированный программный стек, который позволяет создать многократно используемые уровни со стороны ОС и со стороны набора микросхем. Чтобы быстро добавлять новые возможности, предусмотрена функциональная абстракция аппаратного обеспечения и экспорт программных интерфейсов (API), основанных на функциях отображения, а не на микроархитектуре НМС. Такой подход отличается от традиционного, когда для каждой ОС разрабатывается "монолитный" драйвер. Несмотря на то, что сегментация требуется из-за фиксированных капитальных затрат на проектирование, поддержка разработчиков новых ОС, наборов микросхем и графических интерфейсов минимизирована.

Конфигурирование

Чтобы обеспечить поддержку различных конфигураций для интеграторов встроенных систем и изготовителей комплектного оборудования, в драйвере IEGD есть возможность настройки в процессе компиляции и во время выполнения. Там, где это возможно, используется механизм автоконфигурации. Но при инициализации системы необходимо взаимодействие между различными компонентами, не все из которых соответствуют принципам архитектуры IEGD. Например, системный BIOS обычно использует настройки платформы, которые могут конфликтовать с настройками драйвера по умолчанию. По этой причине предусмотрена возможность отключения автоконфигурации – системный интегратор берет управление настройкой системы на себя.

Поддержка наборов микросхем, выбор режима отображения, компоновка модулей (как дополнительная возможность) и управление режимом электропитания задаются во время компиляции. Обычно опции времени компиляции используются для того, чтобы собрать полнофункциональный драйвер для конкретной системы и сократить его размер. Например, требуется поддержка только НМС Intel 845 и двумерной графики. Кроме того, необходимо минимизировать объем кода для использования в системе Windows CE с ограниченной памятью. В таком случае с помощью опций времени компиляции можно исключить модуль трехмерной графики и прикомпоновать только модуль поддержки НМС Intel 845. За счет этого объем кода драйвера сократится примерно на 50%.

В процессе динамического конфигурирования подключаются сервисы ОС для инициализации драйвера и установки связей, необходимых для работы. Самый важный аспект конфигурирования драйвера – связь с видеоподсистемой. Чтобы обеспечить совместимость с широким диапазоном систем, отличающихся по функциям и стоимости, интеграторы обычно разрабатывают одну системную плату с поддержкой разных типов и конфигураций дисплеев. В качестве примера такого подхода можно назвать желание обеспечить поддержку дисплеев с расширенной системой идентификации EDID (Extended Display Identification Data) либо без нее, плоских панелей с разным разрешением, а также систем с одним или несколькими мониторами.

В случае мультимониторной системы данные, отображаемые на дополнительном дисплее, могут полностью повторять данные на основном, а могут отличаться от них (например, в кассовых терминалах). В последнем случае на дисплее кассира отображается подробная информация обо всех покупках, а на дисплее покупателя – только о последней отсканированной покупке. Часто на этот дисплей выводится также реклама или другая информация для покупателей. С каждым дисплеем может работать отдельная программа. Драйвер IEGD позволяет системным интеграторам создать платформу для разных моделей кассовых терминалов с разными требованиями к системе (рис. 1).

Рис. 1. Платформа для разных моделей терминалов.

Универсальная архитектура инициализации в драйвере IEGD позволяет динамически инициализировать ресурсы видеоподсистемы в зависимости от подключенных дисплеев и тех их возможностей, которые были определены драйвером. Кроме того, если системный BIOS поддерживает динамическое определение конфигурации, на этапе начальной загрузки эту возможность будет использовать видео-BIOS (vBIOS), а на этапе загрузки ОС – драйвер. Если к системе подключен дополнительный дисплей, то при следующей перезагрузке видеоподсистема будет автоматически сконфигурирована с учетом его режима и частоты.

Хотя механизм получения информации о конфигурации дисплея в ОС Windows и Linux различен, встроенный видео-BIOS и архитектура драйвера остаются одними и теми же, а следовательно, представляют собой многократно используемые компоненты.

Модели абстракции

Чтобы повысить степень многократного использования кода, увеличить переносимость функций и быстро обеспечить поддержку новых графических возможностей НМС Intel, в наращиваемой архитектуре драйвера IEGD выделяется несколько уровней абстракции (рис. 2).

Рис. 2. Уровни абстракции в архитектуре драйвера IEGD.

Уровень аппаратных абстракций (Hardware Abstraction Layer, HAL) – единственный
уровень, который содержит код на уровне обращения к регистрам.

Уровень абстракций ОС (OS Abstraction Layer, OAL) содержит макросы и
API, которые используются для доступа к сервисам, специфичным для разных ОС.

Уровень абстракций интерфейса (Interface Abstraction Layer, IAL) обеспечивает
взаимодействие между конкретным графическим интерфейсом (например, DirectX*)
и уровнем аппаратных абстракций.

Наконец, уровень абстракций ресурсов (Resource Abstraction Layer, RAL)
предоставляет компоненты многократного использования для доступа к ресурсам
уровня платформы.

Уровень аппаратных абстракций

Уровень аппаратных абстракций – это набор функциональных модулей, содержащих аппаратно-зависимый код, разработанный специально для поддержки функций, которые обеспечивает блок растровой графики в графических НМС Intel Graphics Memory Controller Hub (GMCH). Корпорация Intel разработала уже три поколения ядра растровой графики, используемого в GMCH. Хотя эти ядра различаются микроархитектурой, они поддерживают сходный базовый набор команд и интерфейс на уровне регистров. Поэтому в драйвере IEGD можно использовать единый уровень аппаратных абстракций. Различия в функционировании определяются в HAL с помощью функциональной декомпозиции и динамической установки указателей на функции при инициализации драйвера.

Функциональные модули HAL используют внутренние и внешние (экспортируемые) API. Модули, обеспечивающие доступ и управление микроархитектурой, имеют дело с внутренними интерфейсами. Пример такого внутреннего интерфейса – модуль Display Resource Manager, предоставляющий сервисы для модулей, которые имеют внешние API. Точно так же функциональные интерфейсы (например, модуль обработки двумерной графики) предоставляют программные интерфейсы модулям уровня IAL для копирования прямоугольных битовых областей.

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

Уровень абстракций ОС

Уровень OAL отличается самой высокой степенью многократного использования из всех блоков архитектуры IEGD. Это набор макросов и исходного кода общего пользования, который предоставляет доступ к общим сервисам конкретной ОС – распределению памяти, управлению связными списками, таймеру, обработке прерываний, вводу-выводу, а также к шине PCI.

Для каждой ОС требуется отдельная реализация уровня OAL. Модель графических драйверов Windows предусматривает два отдельных драйвера, использующих разные сервисы ОС. Для поддержки такой структуры используются две реализации OAL – одна для драйвера мини-порта, а другая для драйвера дисплея. В соответствии с опциями конфигурирования для каждого драйвера будет скомпилирована и собрана соответствующая реализация OAL.

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

Уровень абстракций интерфейса

Уровень IAL обеспечивает взаимодействие между конкретным графическим интерфейсом (например, DirectX) и расположенным ниже уровнем HAL, который управляет аппаратурой. Этот промежуточный уровень преобразует точки входа интерфейса и структуры данных в общие вызовы и структуры данных HAL. Такое физическое разделение существенно отличает архитектуру IEGD от традиционной "монолитной" структуры драйверов. Работа с аппаратурой полностью отделена от графического интерфейса. Это позволяет создать межплатформенный уровень HAL.

С точки зрения архитектуры уровень IAL независим от ОС. Например, графический интерфейс XFree86 взаимодействует с реализацией IAL, которая работает с большинством версий Linux и Windows.

Уровень абстракций ресурсов

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

Вместо заключения

Использование абстракций в архитектуре IEGD позволяет создать базу для работы расширяемого драйвера, который поддерживает множество ОС и реализаций систем растровой графики Intel. Наращиваемая архитектура обеспечивается благодаря разделению нижнего уровня – аппаратного обеспечения GMCH, графических API, сервисов ОС и ресурсов уровня платформы. Сегментация позволяет создать ядро кода с автоматическим распознаванием аппаратуры и настройкой, обеспечивает высокую степень многократного использования кода драйвера и микропрограммного кода. Многократное использование кода, в свою очередь, повышает надежность и качество программного продукта.

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