В отличие от систем с архитектурой x86, использование UEFI (Unified Extensible Firmware Interface) на ARM-платформах не стало топом в IT-новостях. Из этого не следует, что расширяемый интерфейс фирменного программного обеспечения – идея только для рынка персональных компьютеров. Спецификация UEFI декларирует универсальные подходы для инициализации любого аппаратного обеспечения и его взаимодействия с операционной системой.
В силу того, что спецификация UEFI поддерживает все распространенные архитектуры вычислительных систем, хотелось бы сравнить их аппаратную производительность с «чистого листа», т.е. до запуска драйверной поддержки. Особенно интересно посмотреть на работу графики на конкурирующих процессорных платформах. Так ли она хороша, как об это говорят ее производители? Образцов для сравнения сколько угодно – NVidia, например, выпускает Tegra для работы с ARM, и GeForce для персональных систем.
Чтобы ответить на поставленный вопрос мы решили свою утилиту UEFImark, измеряющую скорость записи в видеопамять и выводящую информацию о графических возможностях системы поставить на рельсы EFI Byte Code.
Как известно, EFI Byte Code (EBC) – довольно изящный метод разработки кроссплатформенного программного обеспечения в рамках спецификации UEFI. Его идея очевидна и не нова – программа, написанная в системе команд модной ныне регистровой виртуальной машины, может быть выполнена на любой аппаратной платформе, снабженной программой-интерпретатором команд.
Работа с графикой
Для визуализации графической информации в среде UEFI, а также как объект для бенчмарок, применяется GOP (Graphics Output Protocol). В рамках данного UEFI-протокола, используется функция BLT (Block Transfer). Эта функция выполняет построение на экране прямоугольного объекта, получая от вызывающей процедуры в качестве входных параметров его координаты, размеры и содержимое.
В отличие от UEFImark x64 Edition, приложение UEFImark EBC Edition не использует прямое обращение к видео памяти, так как в системах с архитектурами, отличными от PC, такой метод визуализации может не поддерживаться. Для декларирования такой ситуации предусмотрен специальный атрибут BltOnly. Точнее, прямое обращение к видео памяти планируется использовать, но только тогда, когда детектирована x86-совместимая платформа и видео память доступна в адресном пространстве.
Бенчмарки
Обратимся к последней строке экрана системной информации – GOP.BLT, FPS. Она содержит два параметра:
- Параметр Fill – результат измерения производительности процедуры GOP.BLT.Fill, выполняющей построение монотонного прямоугольника на экране, путем заполнения заданных участков видео памяти заданной константой.
- Параметр Copy – результат измерения производительности процедуры GOP.BLT.Copy, выполняющей построение на экране прямоугольника, пиксельное содержимое которого предоставляется данной процедуре в буфере, находящемся в оперативной памяти. Содержимое данного буфера копируется в заданные участки видео памяти.
Результат запуска утилиты UEFImark, EBC Edition, на платформе ASUS T100T, снабженной 32-битным вариантом UEFI firmware, работающей под управлением 64-битного процессора Intel Atom Z3740
В данных тестах, размер прямоугольника задан равным размеру экрана. Для измерения времени используется таймер, реализованный в рамках CPU Architectural Protocol (CAP), метод доступа к которому не зависит от аппаратных особенностей платформы. Объем видео памяти, используемой для представления экрана, зависит от горизонтального и вертикального разрешения, а также количества бит на пиксель. Соответственно, чем больше разрешение и количество бит на пиксель, тем больший объем требуется обработать. Поэтому, количество кадров в секунду или FPS (frames per second) будет различным для различных видео режимов. При сравнении производительности двух систем для них требуется использовать одинаковые видео режимы.
Кадры или мегабайты в секунду
Почему в бенчмарках EBC-версии мы перешли от измерения скорости записи в видео память в мегабайтах в секунду, к измерению интегральной производительности видео подсистемы в кадрах в секунду или FPS?
Точное измерение пропускной способности шин возможно только для нативного кода, непосредственно выполняющего запись в видео память, так как между моментами чтения начального и конечного состояний таймера должны быть расположены только те операции, время выполнения которых требуется измерить. При использовании технологий GOP.BLT и UEFI API это условие невыполнимо, так как вызываемая API-процедура выполняет не только собственно пересылку блока, но и ряд вспомогательных операций. Основные из них — подготовка параметров для пересылки блока, передача управления на подпрограмму, сохранение параметров, восстановление параметров, возврат из подпрограммы и т. д. Поэтому для этих методов графической визуализации используется интегральный параметр FPS.
Особенности отладки
Готовящаяся к выходу версия 0.13 поддерживает выдачу 8-битных отладочных кодов в 8-битный порт с адресом 80h. При отладке используется устройство IC80v5.0 производства IC Book Labs. В целях обеспечения работоспособности программы на платформах с архитектурами, отличными от x86, выдача кодов в порт 80h выполняется только в случае успешного детектирования платформы x86 в сочетании с firmware IA32 EFI или x64 UEFI. В целях обеспечения работоспособности в эмулируемой среде, выдача кодов в порт 80h выполняется только в случае, если программа работает в режиме супервизора, а именно текущий уровень привилегий (CPL), определяемый битами [1,0] регистра сегмента кода (CS), равен нулю, что означает отсутствие эмулятора или отсутствие режима перехвата обращений к портам ввода-вывода. Практика показала, что вывод в порт 80h может вызвать аварийное завершение эмулятора.
Резюме
Поддержка EBC реализована сегодня в рамках UEFI firmware следующих четырех типов платформ: IA32, x64, IPF (Itanium Processor Family) и ARM, поэтому, наша программа-максимум такова: функциональность информационной утилиты UEFImark v0.96, реализованной сегодня исключительно для среды x64 UEFI, обеспечить в единой утилите UEFImark EBC Edition для платформ четырех типов, перечисленных выше.
Автор: icbook
