Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
То есть из всего многообразия характеристик видеоподсистемы вы тестируете только условную пропускную способность шины?
Сомневаюсь что это превалирующая метрика, которая отражает производительность видео.
Сомневаюсь что это превалирующая метрика, которая отражает производительность видео.
Действительно, в рамках 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 акселератора.
Судя по результатам бенчмарок – акселератор не используется. Для сравнения можно отметить, что в эмуляторе под Windows (EDKII) видеовывод на порядок быстрее и в метрике, и визуально. Скорее всего, эмулятор при обработке функции GOP.BLT использует акселерацию посредством Windows-драйверов.
Мы не ставили задачу оценки производительности GPU. Для этого есть тесты запускаемые под Windows, использующие драйвера и аппаратную 2D/3D акселерацию. Под UEFI таких драйверов нет, а писать собственные для device-specific поддержки каждого GPU неперспективно.
Мы ставили задачу оценить производительность именно под UEFI для оценки возможности создания графических приложений, работающих в данной среде без загрузки операционной системы, при использовании штатной для UEFI технологии вывода графики. Необходимо понимать, что производительность при выполнении операции GOP.BLT может не отражать производительности GPU и в частности 3D акселератора.
Это первые шаги на пути освоения кроссплатформенной графики, по мере развития набор тестов будет расширяться, хотя полноценное использование 3D под UEFI вряд ли возможно в ближайшее время. Тем не менее, работы в этом направлении уже давно ведутся:
Хостинг «Украина», похоже, не выдерживает хабр-эффекта.
Вообще тема весьма интересная. Можете выложить .efi под x86_64 на файл-хостинг, очень хочется попробовать у себя?
Вообще тема весьма интересная. Можете выложить .efi под x86_64 на файл-хостинг, очень хочется попробовать у себя?
Как только с хостингом наладится :)
Похоже, что проблемы уже позади. Скачать утилиту можно либо на стр. jelezo.com.ua/programmy/uefimark_ebc_edition.html либо по адресу: jelezo.com.ua/image/Files/UEFImark/EBC/v0.13/UEFImark-EBC-Edition.zip
Параметры файла конфигурации (UEFIMARK.CFG) будут подготовлены сегодня-завтра.
Параметры файла конфигурации (UEFIMARK.CFG) будут подготовлены сегодня-завтра.
Утилита и исходный код для x86_64: jelezo.com.ua/programmy/ishodnyj_kod/ishodnyj_kod_uefimark_v096.html
Хотел задать вопрос может быть не совсем по теме, дело в том, что я с этим тоже столкнулся непосредственно.
У вас на сайте я нашел такое утверджение: «работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol». В официальной спеке UEFI 2.5 я про это ничего не нашел. Описание в спеке выглядит так что SimpleTextOutput и GraphicsOutput независимые протоколы. Однако по факту имеем на некоторых машинах, что после GOP->SetMode() консоль действительно «портится». Вопрос в том, вы эту информацию где-то в официальных доках нашли, и если да, то где, либо это тоже эмпирически обнаружено?
У вас на сайте я нашел такое утверджение: «работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol». В официальной спеке UEFI 2.5 я про это ничего не нашел. Описание в спеке выглядит так что SimpleTextOutput и GraphicsOutput независимые протоколы. Однако по факту имеем на некоторых машинах, что после GOP->SetMode() консоль действительно «портится». Вопрос в том, вы эту информацию где-то в официальных доках нашли, и если да, то где, либо это тоже эмпирически обнаружено?
Дайте-ка сообразить…
Поддержка Simple Text Output Protocol не гарантируется для каждого видеорежима, документальное подтверждение этого следует, например из наличия функции: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() которой на вход необходимо передать номер видеорежима, и она вернет статус, отражающий возможность вывода текста в данном режиме. Соответственно, если мы, пользуясь функциями протокола GOP (у которого номенклатура режимов более широкая) включим такой видеорежим, в котором не поддерживается Simple Text Output Protocol, то консоль действительно «испортится».
Причина — в каждом видеорежиме своя организация видео памяти, количество байт на строку, базовый адрес буфера, размер фонта. Поэтому поддержку знакогенератора для всех возможных графических режимов разработчики Firmware посчитали излишней.
Причина — в каждом видеорежиме своя организация видео памяти, количество байт на строку, базовый адрес буфера, размер фонта. Поэтому поддержку знакогенератора для всех возможных графических режимов разработчики Firmware посчитали излишней.
Хмм, дак у SimpleTextOutput и у GOP одни и те же режимы чтоли? Я так понял из документации, что у них независимые наборы режимов, у текста свои, у графики свои. Описание функции EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() из спеки 2.5:
Как я понял из этого описания, данная функция на вход принимает номер текстового режима, и возвращает его геометрию в выходных параметрах, либо то, что режим невалидный (этот случай описан отдельно для режима 1). Я не нашел где было бы сказано, что номера режимов здесь такие же как и у GOP.
Как можно было бы понять из документации что номенклатура текстовых и графических режимов пересекается? Куда посмотреть?
Описано все так как будто текстовый и графический протоколы существуют абстрактно и независимо друг от друга. Или как все-таки следует понимать эту документацию?)
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.
Как можно было бы понять из документации что номенклатура текстовых и графических режимов пересекается? Куда посмотреть?
Описано все так как будто текстовый и графический протоколы существуют абстрактно и независимо друг от друга. Или как все-таки следует понимать эту документацию?)
Инициализация видео адаптера, выполненная функцией SetMode() графического протокола, не может не исказить настройки, выполненные одноименной функцией текстового протокола — видеоадаптер у них общий, несмотря на то, что это так хорошо скрыто за абстракциями.
Другое документальное подтверждение того, что вывод текста поддерживается не во всех режимах видео контроллера, это статус после выполнения функции OutputString() текстового протокола. Одна из возможных ошибок обозначена как EFI_UNSUPPORTED и в данном контексте описана так: «The output device mode is not curently in a defined text mode», что означает, что режим видео подсистемы не допускает текстовый вывод.
Допустим, что в нашей системе нумерация режимов у двух протоколов разная (Вы правы в том, что единая нумерация режимов не гарантируется документом, хотя и имеет место в ряде реализаций Firmware). Но раз предусмотрена указанная расшифровка кода ошибки, то по формальной логике, спецификация допускает, что можно ввести адаптер в такое состояние, в котором невозможен вывод текста, то есть «испортить консоль».
Именно это может произойти при использовании GOP->SetMode(), других вариантов просто нет, так как видов режимов только два: текст и графика.
По материалам нашего обсуждения выложена статья "Проблемы текстового режима UEFI".
Другое документальное подтверждение того, что вывод текста поддерживается не во всех режимах видео контроллера, это статус после выполнения функции OutputString() текстового протокола. Одна из возможных ошибок обозначена как EFI_UNSUPPORTED и в данном контексте описана так: «The output device mode is not curently in a defined text mode», что означает, что режим видео подсистемы не допускает текстовый вывод.
Допустим, что в нашей системе нумерация режимов у двух протоколов разная (Вы правы в том, что единая нумерация режимов не гарантируется документом, хотя и имеет место в ряде реализаций Firmware). Но раз предусмотрена указанная расшифровка кода ошибки, то по формальной логике, спецификация допускает, что можно ввести адаптер в такое состояние, в котором невозможен вывод текста, то есть «испортить консоль».
Именно это может произойти при использовании GOP->SetMode(), других вариантов просто нет, так как видов режимов только два: текст и графика.
По материалам нашего обсуждения выложена статья "Проблемы текстового режима UEFI".
О, спасибо за статью. Когда я гуглил проблему, ничего аналогичного найти не мог, теперь ситуация будет другой.
Судя по возможным ошибкам, спецификация действительно допускает такое состояние адаптера (а точнее сказать STO протокола), когда текстовый вывод недоступен.
У вас в статье написано что возможное решение (не гарантируемое) это позвать STO->Reset() после GOP->SetMode().
А если после вызова GOP->SetMode() позвать STO->SetMode(), разве это может как-то испортить режим GOP'а или просто текстовый режим не установится? Странно, почему в документации эти важные моменты явно никак не описаны.
Мне просто выводить текст поверх графики желательно, но не очень критично. Это используется для ошибочных логов, которые не только на экран попадают, но и в другие места. Реализовывать ради этого текстовый вывод средствами GOP, слишком развесисто. Проще в этих редких случаях без логов на экране обойтись. Главное просто не испортить графический режим Reset'ом или SetMode'ом)
Судя по возможным ошибкам, спецификация действительно допускает такое состояние адаптера (а точнее сказать STO протокола), когда текстовый вывод недоступен.
У вас в статье написано что возможное решение (не гарантируемое) это позвать STO->Reset() после GOP->SetMode().
А если после вызова GOP->SetMode() позвать STO->SetMode(), разве это может как-то испортить режим GOP'а или просто текстовый режим не установится? Странно, почему в документации эти важные моменты явно никак не описаны.
Мне просто выводить текст поверх графики желательно, но не очень критично. Это используется для ошибочных логов, которые не только на экран попадают, но и в другие места. Реализовывать ради этого текстовый вывод средствами GOP, слишком развесисто. Проще в этих редких случаях без логов на экране обойтись. Главное просто не испортить графический режим Reset'ом или SetMode'ом)
Функции SetMode() обоих протоколов предписывают перевести видео адаптер в некоторое заданное состояние. Поскольку видео адаптер не является квантовым объектом, он не может одновременно находится в двух состояниях, предписываемых функциями SetMode() текстового и графического протокола, поэтому и возникает нарушение видеовывода, за исключением частных случаев, когда настройки двух целевых режимов совпадают.
Возможно и существуют реализации UEFI, в которых функция SetMode() текстового протокола не изменяет текущие настройки адаптера, а только настраивает процедуру текстового вывода на текущий видео режим. В таком случае работать будет без конфликтов. Но это гипотетический вариант. На практике, в связи с большим количеством различных реализаций UEFI, лучше не полагаться на возможность параллельной и бесконфликтной работы двух протоколов. После вызова GOP->SetMode мы в ответе за каждый пиксель.
Существует недокументированный, но довольно стабильный поведенческий паттерн в UEFI: если используется GOP и графика, но при этом видеорежим совпадает с дефолтным (GOP позволяет прочитать параметры текущего установленного режима), то вывод посредством текстового протокола работает.
Возможно и существуют реализации UEFI, в которых функция SetMode() текстового протокола не изменяет текущие настройки адаптера, а только настраивает процедуру текстового вывода на текущий видео режим. В таком случае работать будет без конфликтов. Но это гипотетический вариант. На практике, в связи с большим количеством различных реализаций UEFI, лучше не полагаться на возможность параллельной и бесконфликтной работы двух протоколов. После вызова GOP->SetMode мы в ответе за каждый пиксель.
Существует недокументированный, но довольно стабильный поведенческий паттерн в UEFI: если используется GOP и графика, но при этом видеорежим совпадает с дефолтным (GOP позволяет прочитать параметры текущего установленного режима), то вывод посредством текстового протокола работает.
логов, которые не только на экран попадают, но и в другие места
Интересно, выводом в диагностический порт пользуетесь или свойства платформы не позволяют это делать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кроссплатформенная оценка графических возможностей в контексте UEFI