Одним из важнейших нововведений спецификации Unified Extensible Firmware Interface явилось появление и интеграция в firmware персональной платформы особой операционной среды UEFI Shell, позволяющей выполнять небольшие задачи или UEFI приложения без загрузки операционной системы. В этом контексте, в первую очередь речь идет о задачах, связанных с обслуживанием вычислительной системы: обновление firmware платформы и периферийных устройств, восстановление модулей операционной системы после различных сбоев, а также утилиты системной информации и диагностики. Упоминание об игровых приложениях, а тем более современных 3D играх в этом контексте прозвучит несколько парадоксально. И все же давайте попробуем ответить на вопрос: можно ли написать игру для выполнения в среде UEFI? Если можно, то как? Если нельзя, то почему?
На ранних этапах развития графических подсистем персональных платформ, во времена господства шины ISA, «рисование» объектов на экране осуществлялось программным путем. Принцип прост: видео память располагается в адресном пространстве центрального процессора, вывод графического объекта сводится к записи заданной информации по заданным адресам. Несколько упрощая, можно сказать, что координаты каждой отображаемой точки определяются адресом, по которому выполнена запись, а цвет – записанными данными. Достоинство такой модели — простота программной и аппаратной реализаций, недостаток — низкая производительность.
Как известно, современный видео адаптер, это «компьютер в компьютере». Графический процессор, входящий в его состав, способен выполнять собственный командный поток, взаимодействуя с оперативной памятью платформы в режиме bus-master, а также с локальной памятью видео адаптера. При этом основная задача центрального процессора сводится к подготовке в оперативной памяти блоков заданий для графического процессора.
В типовой современной персональной вычислительной системе, для шины, связывающей микросхему видео контроллера с видео памятью, характерны разрядности и тактовые частоты, существенно превышающие аналогичные параметры для шины оперативной памяти системной платы. И заметим, что в отличие от центрального процессора, графический процессор не использует транзитных звеньев (в виде шин AGP или PCI Express) при доступе к видео памяти. В результате, очевидное преимущество — высокая производительность. Но есть и недостатки. Об этом ниже.
Так уж исторически сложилось, что индустрия не выработала единой унифицированной программной модели для низкоуровневого доступа к регистрам видео акселератора. Унификация реализована исключительно на уровне программного интерфейса драйверов. Разработчику приложений, выполняемых в среде современных операционных систем, не требуется заботиться о низкоуровневом взаимодействии с регистрами видео контроллера потому, что его производитель предоставил драйвер, берущий эту задачу на себя. Проблема в том, что для среды UEFI такой инфраструктуры не предусмотрено.
Несомненно, такие факторы, как переход от 16-битного режима Real Mode к 64-битному Protected Mode, а также использование UEFI Driver Model вместо программных прерываний Legacy BIOS, закладывают фундамент для создания такой инфраструктуры. Но на сегодня фундамент есть, а инфраструктуры нет.
Ряд современных технологий позволили «вдохнуть вторую жизнь» в реализацию графики средствами центрального процессора. Речь в первую очередь об использовании 128 и 256-битных SSE инструкций, а также технологии Write Combining, позволяющей объединять результаты нескольких процессорных циклов записи в пакет размером до 4 килобайт для отправки по шине PCI Express. Иногда, такой подход позволяет получить приемлемый результат для 2D графики в рамках использования UEFI Graphics Output Protocol в сочетании с «дедовским» методом визуализации:
Рис 1. Снимок экрана, полученный из UEFI-среды в процессе запуска игры Tetris64
Но очевидно, что достичь функциональности и производительности, реализуемой средствами аппаратных графических процессоров, данный метод не позволит.
Приходится констатировать невозможность написания UEFI-приложения, реализующего 3D графику с кинематографическим качеством. Почему? Унифицированных протоколов и готовых драйверов, обеспечивающих поддержку 3D под UEFI, не существует. Также нереально решение этой задачи путем прямого обращения к аппаратным ресурсам видео акселератора из UEFI-приложения: отсутствие унификации оборудования потребует от разработчика написания драйверов для всех моделей графических процессоров.
Вспомнить все: программный вывод графики
На ранних этапах развития графических подсистем персональных платформ, во времена господства шины ISA, «рисование» объектов на экране осуществлялось программным путем. Принцип прост: видео память располагается в адресном пространстве центрального процессора, вывод графического объекта сводится к записи заданной информации по заданным адресам. Несколько упрощая, можно сказать, что координаты каждой отображаемой точки определяются адресом, по которому выполнена запись, а цвет – записанными данными. Достоинство такой модели — простота программной и аппаратной реализаций, недостаток — низкая производительность.
Компьютер в компьютере: аппаратный вывод графики
Как известно, современный видео адаптер, это «компьютер в компьютере». Графический процессор, входящий в его состав, способен выполнять собственный командный поток, взаимодействуя с оперативной памятью платформы в режиме bus-master, а также с локальной памятью видео адаптера. При этом основная задача центрального процессора сводится к подготовке в оперативной памяти блоков заданий для графического процессора.
В типовой современной персональной вычислительной системе, для шины, связывающей микросхему видео контроллера с видео памятью, характерны разрядности и тактовые частоты, существенно превышающие аналогичные параметры для шины оперативной памяти системной платы. И заметим, что в отличие от центрального процессора, графический процессор не использует транзитных звеньев (в виде шин AGP или PCI Express) при доступе к видео памяти. В результате, очевидное преимущество — высокая производительность. Но есть и недостатки. Об этом ниже.
Проблемы решенные и не решенные
Так уж исторически сложилось, что индустрия не выработала единой унифицированной программной модели для низкоуровневого доступа к регистрам видео акселератора. Унификация реализована исключительно на уровне программного интерфейса драйверов. Разработчику приложений, выполняемых в среде современных операционных систем, не требуется заботиться о низкоуровневом взаимодействии с регистрами видео контроллера потому, что его производитель предоставил драйвер, берущий эту задачу на себя. Проблема в том, что для среды UEFI такой инфраструктуры не предусмотрено.
Несомненно, такие факторы, как переход от 16-битного режима Real Mode к 64-битному Protected Mode, а также использование UEFI Driver Model вместо программных прерываний Legacy BIOS, закладывают фундамент для создания такой инфраструктуры. Но на сегодня фундамент есть, а инфраструктуры нет.
Компромиссы возможны
Ряд современных технологий позволили «вдохнуть вторую жизнь» в реализацию графики средствами центрального процессора. Речь в первую очередь об использовании 128 и 256-битных SSE инструкций, а также технологии Write Combining, позволяющей объединять результаты нескольких процессорных циклов записи в пакет размером до 4 килобайт для отправки по шине PCI Express. Иногда, такой подход позволяет получить приемлемый результат для 2D графики в рамках использования UEFI Graphics Output Protocol в сочетании с «дедовским» методом визуализации:
Рис 1. Снимок экрана, полученный из UEFI-среды в процессе запуска игры Tetris64
Но очевидно, что достичь функциональности и производительности, реализуемой средствами аппаратных графических процессоров, данный метод не позволит.
Резюме
Приходится констатировать невозможность написания UEFI-приложения, реализующего 3D графику с кинематографическим качеством. Почему? Унифицированных протоколов и готовых драйверов, обеспечивающих поддержку 3D под UEFI, не существует. Также нереально решение этой задачи путем прямого обращения к аппаратным ресурсам видео акселератора из UEFI-приложения: отсутствие унификации оборудования потребует от разработчика написания драйверов для всех моделей графических процессоров.