Игры с UEFI

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.