Одним из важнейших нововведений спецификации 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-приложения: отсутствие унификации оборудования потребует от разработчика написания драйверов для всех моделей графических процессоров.
Автор: icbook
