Кроссплатформенная оценка графических возможностей в контексте UEFI

    В отличие от систем с архитектурой 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, выполняющей построение на экране прямоугольника, пиксельное содержимое которого предоставляется данной процедуре в буфере, находящемся в оперативной памяти. Содержимое данного буфера копируется в заданные участки видео памяти.

    image
    Результат запуска утилиты UEFImark, EBC Edition, на платформе ASUS T100T, снабженной 64-битным процессором Intel Atom Z3740, работающей под управлением 32-битного UEFI firmware

    В данных тестах, размер прямоугольника задан равным размеру экрана. Для измерения времени используется таймер, реализованный в рамках 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 для платформ четырех типов, перечисленных выше.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      +2
      То есть из всего многообразия характеристик видеоподсистемы вы тестируете только условную пропускную способность шины?
      Сомневаюсь что это превалирующая метрика, которая отражает производительность видео.
        +2
        Действительно, в рамках EFI Byte Code тестируется условная пропускная способность. В силу того, что мы не выполняем прямую запись в видео память (в отличие от предыдущей ветки утилиты UEFImark), а вызываем UEFI-функцию из «черного ящика» firmware. Каким образом реализуется эта технология априори неизвестно, хотя вариантов не много: либо процессорной записью в видеопамять или средствами графического акселератора.

        Судя по результатам бенчмарок – акселератор не используется. Для сравнения можно отметить, что в эмуляторе под Windows (EDKII) видеовывод на порядок быстрее и в метрике, и визуально. Скорее всего, эмулятор при обработке функции GOP.BLT использует акселерацию посредством Windows-драйверов.

        Мы не ставили задачу оценки производительности GPU. Для этого есть тесты запускаемые под Windows, использующие драйвера и аппаратную 2D/3D акселерацию. Под UEFI таких драйверов нет, а писать собственные для device-specific поддержки каждого GPU неперспективно.

        Мы ставили задачу оценить производительность именно под UEFI для оценки возможности создания графических приложений, работающих в данной среде без загрузки операционной системы, при использовании штатной для UEFI технологии вывода графики. Необходимо понимать, что производительность при выполнении операции GOP.BLT может не отражать производительности GPU и в частности 3D акселератора.
          0
          Ок, тогда цель понятна.
          Вы тестируете не GPU различных производителей, а соответствующею подсистему UEFI.
        0
        Это первые шаги на пути освоения кроссплатформенной графики, по мере развития набор тестов будет расширяться, хотя полноценное использование 3D под UEFI вряд ли возможно в ближайшее время. Тем не менее, работы в этом направлении уже давно ведутся:

          0
          Хостинг «Украина», похоже, не выдерживает хабр-эффекта.
          Вообще тема весьма интересная. Можете выложить .efi под x86_64 на файл-хостинг, очень хочется попробовать у себя?
          0
          Хотел задать вопрос может быть не совсем по теме, дело в том, что я с этим тоже столкнулся непосредственно.
          У вас на сайте я нашел такое утверджение: «работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol». В официальной спеке UEFI 2.5 я про это ничего не нашел. Описание в спеке выглядит так что SimpleTextOutput и GraphicsOutput независимые протоколы. Однако по факту имеем на некоторых машинах, что после GOP->SetMode() консоль действительно «портится». Вопрос в том, вы эту информацию где-то в официальных доках нашли, и если да, то где, либо это тоже эмпирически обнаружено?
            0
            Дайте-ка сообразить…
              0
              Поддержка Simple Text Output Protocol не гарантируется для каждого видеорежима, документальное подтверждение этого следует, например из наличия функции: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() которой на вход необходимо передать номер видеорежима, и она вернет статус, отражающий возможность вывода текста в данном режиме. Соответственно, если мы, пользуясь функциями протокола GOP (у которого номенклатура режимов более широкая) включим такой видеорежим, в котором не поддерживается Simple Text Output Protocol, то консоль действительно «испортится».

              Причина — в каждом видеорежиме своя организация видео памяти, количество байт на строку, базовый адрес буфера, размер фонта. Поэтому поддержку знакогенератора для всех возможных графических режимов разработчики Firmware посчитали излишней.
                0
                Хмм, дак у SimpleTextOutput и у GOP одни и те же режимы чтоли? Я так понял из документации, что у них независимые наборы режимов, у текста свои, у графики свои. Описание функции EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() из спеки 2.5:

                EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode()
                Summary
                Returns information for an available text mode that the output device(s) supports.

                Prototype
                typedef EFI_STATUS
                (EFIAPI *EFI_TEXT_QUERY_MODE) (
                IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This,
                IN UINTN ModeNumber,
                OUT UINTN *Columns,
                OUT UINTN *Rows
                );

                Parameters
                This — A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL instance. Type EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL is defined in the “Related Definitions” of Section 11.4.
                ModeNumber — The mode number to return information on.
                Columns, Rows — Returns the geometry of the text output device for the request ModeNumber.

                Description
                The QueryMode() function returns information for an available text mode that the output device(s) supports.
                It is required that all output devices support at least 80x25 text mode. This mode is defined to be
                mode 0. If the output devices support 80x50, that is defined to be mode 1. All other text dimensions
                supported by the device will follow as modes 2 and above. If an output device supports modes 2 and
                above, but does not support 80x50, then querying for mode 1 will return EFI_UNSUPPORTED.


                Как я понял из этого описания, данная функция на вход принимает номер текстового режима, и возвращает его геометрию в выходных параметрах, либо то, что режим невалидный (этот случай описан отдельно для режима 1). Я не нашел где было бы сказано, что номера режимов здесь такие же как и у GOP.

                Как можно было бы понять из документации что номенклатура текстовых и графических режимов пересекается? Куда посмотреть?

                Описано все так как будто текстовый и графический протоколы существуют абстрактно и независимо друг от друга. Или как все-таки следует понимать эту документацию?)
                  +1
                  Инициализация видео адаптера, выполненная функцией SetMode() графического протокола, не может не исказить настройки, выполненные одноименной функцией текстового протокола — видеоадаптер у них общий, несмотря на то, что это так хорошо скрыто за абстракциями.

                  Другое документальное подтверждение того, что вывод текста поддерживается не во всех режимах видео контроллера, это статус после выполнения функции OutputString() текстового протокола. Одна из возможных ошибок обозначена как EFI_UNSUPPORTED и в данном контексте описана так: «The output device mode is not curently in a defined text mode», что означает, что режим видео подсистемы не допускает текстовый вывод.

                  Допустим, что в нашей системе нумерация режимов у двух протоколов разная (Вы правы в том, что единая нумерация режимов не гарантируется документом, хотя и имеет место в ряде реализаций Firmware). Но раз предусмотрена указанная расшифровка кода ошибки, то по формальной логике, спецификация допускает, что можно ввести адаптер в такое состояние, в котором невозможен вывод текста, то есть «испортить консоль».

                  Именно это может произойти при использовании GOP->SetMode(), других вариантов просто нет, так как видов режимов только два: текст и графика.

                  По материалам нашего обсуждения выложена статья "Проблемы текстового режима UEFI".
                    0
                    О, спасибо за статью. Когда я гуглил проблему, ничего аналогичного найти не мог, теперь ситуация будет другой.

                    Судя по возможным ошибкам, спецификация действительно допускает такое состояние адаптера (а точнее сказать STO протокола), когда текстовый вывод недоступен.
                    У вас в статье написано что возможное решение (не гарантируемое) это позвать STO->Reset() после GOP->SetMode().
                    А если после вызова GOP->SetMode() позвать STO->SetMode(), разве это может как-то испортить режим GOP'а или просто текстовый режим не установится? Странно, почему в документации эти важные моменты явно никак не описаны.

                    Мне просто выводить текст поверх графики желательно, но не очень критично. Это используется для ошибочных логов, которые не только на экран попадают, но и в другие места. Реализовывать ради этого текстовый вывод средствами GOP, слишком развесисто. Проще в этих редких случаях без логов на экране обойтись. Главное просто не испортить графический режим Reset'ом или SetMode'ом)
                      0
                      Функции SetMode() обоих протоколов предписывают перевести видео адаптер в некоторое заданное состояние. Поскольку видео адаптер не является квантовым объектом, он не может одновременно находится в двух состояниях, предписываемых функциями SetMode() текстового и графического протокола, поэтому и возникает нарушение видеовывода, за исключением частных случаев, когда настройки двух целевых режимов совпадают.

                      Возможно и существуют реализации UEFI, в которых функция SetMode() текстового протокола не изменяет текущие настройки адаптера, а только настраивает процедуру текстового вывода на текущий видео режим. В таком случае работать будет без конфликтов. Но это гипотетический вариант. На практике, в связи с большим количеством различных реализаций UEFI, лучше не полагаться на возможность параллельной и бесконфликтной работы двух протоколов. После вызова GOP->SetMode мы в ответе за каждый пиксель.

                      Существует недокументированный, но довольно стабильный поведенческий паттерн в UEFI: если используется GOP и графика, но при этом видеорежим совпадает с дефолтным (GOP позволяет прочитать параметры текущего установленного режима), то вывод посредством текстового протокола работает.
                        0
                        логов, которые не только на экран попадают, но и в другие места

                        Интересно, выводом в диагностический порт пользуетесь или свойства платформы не позволяют это делать?
                          0
                          Да логи еще в ком порт сыпятся и на диск складываются )

              Only users with full accounts can post comments. Log in, please.