Поддерживает ли современное видеооборудование P C текстовый режим VGA в HW или B IOS эмулирует его (в режиме управления системой)?

Question

Что действительно происходит на современном оборудовании P C, загруженном в 16-битном устаревшем режиме MBR * IOS, когда вы сохраняете байт, такой как '1' (0x31), в VGA текст (режим 03) кадровый буфер по физическому линейному адресу B8000? Как медленно работает mov [es:di], eax магазин с MTRR для этого региона, установленным в U C? ( Экспериментальное тестирование на одном ноутбуке Kaby Lake iGPU показывает, что clflushopt в W C был примерно такой же скорости, как U C для VGA-памяти. Но без clflushopt mov сохраняет в W C память никогда не покидает ЦП и не обновляет экран вообще, работает супер быстро.)

Если это не SMI для каждого магазина, есть ли способ приблизить эту стоимость куска памяти WB в пространстве пользователя для экспериментов с производительностью без фактической перезагрузки в реальном режиме? (например, использование страницы BSS в качестве притворного кадрового буфера, который фактически нигде не отображается).

Соответствующий глиф шрифта появляется на экране в следующей ссылке sh, но аппаратное сканирование действительно читает этот ASCII char из VRAM (или DRAM для iGPU) и сопоставление с глифами растровых шрифтов на лету? Или существует какой-то программный перехват в каждом магазине или один раз для каждого vblank, поэтому реальное оборудование должно обрабатывать только растровый буфер кадров?

---

Legacy B IOS загрузка , хорошо известная для использования System Management Режим (SMM) для эмуляции USB kbd / mouse как устройства PS / 2. Мне интересно, если он также используется для кадрового буфера текстового режима VGA. Я предполагаю, что - это , используемый для портов ввода / вывода VGA для установки режима, но вполне вероятно, что аппаратный текстовый фрейм-буфер может поддерживаться. Тем не менее, большинство компьютеров проводят все свое время в графическом режиме, поэтому отказ от поддержки HW в текстовом режиме кажется чем-то, что производители могут захотеть сделать. (OTOH этот блог говорит о том, что VGA-контроллер homebrew verilog может реализовывать текстовый режим довольно просто.)

Мне особенно интересны системы, использующие iGPU в Intel Skylake, но будет заинтересован в более ранних / более поздних версиях iGPU от Intel и AMD, а также новых или старых дискретных графических процессорах.

(включая поставщиков, отличных от AMD и NVidia; есть некоторые материнские платы Skylake с разъемами PCI, а не P * 1129) *Ie. Если современные драйверы микропрограммного обеспечения GPU действительно эмулируют текстовый режим, то, вероятно, есть некоторые старые видеокарты PCI с аппаратным текстовым режимом VGA. И, возможно, такая карта может сделать магазины просто транзакцией PCI вместо SMI.)

Мой собственный рабочий стол - i7-6700k в игровом моторе Asus Z170 Pro Gaming, никаких дополнительных карт - только iGPU с монитором 1920x1200 на выходе DVI-D. Я не знаю деталей системы Kaby Lake i5-7300HQ, на которой тестирует Элдан, только модель процессора.

---

Я нашел Phoenix B IOS патент US20120159520 от 2011 года , Эмуляция устаревшего видео с использованием uefi . Вместо того, чтобы требовать от поставщиков видеооборудования предоставления драйверов UEFI и для собственных 16-разрядных драйверов реального режима, они предлагают драйвер VGA реального режима (функции int 10h и т. Д.), Который вызывает поставщика. поставляемый видеодрайвер UEFI через перехватчики SMM.

Аннотация
[...] Опциональный ПЗУ для видеосигнала generi c уведомляет об общем видеодрайвере c для SMM запрос на видеоуслуги. Такое уведомление может быть выполнено с использованием программного прерывания управления системой (SMI). После уведомления драйвер SMM generic c уведомляет сторонний видеодрайвер UEFI о запросе видеоуслуг. Сторонний видеодрайвер предоставляет запрошенные видеоуслуги операционной системе. Таким образом, сторонний графический драйвер UEFI может поддерживать самые разные операционные системы, даже те, которые изначально не поддерживают протоколы отображения UEFI.

Большая часть описания посвящена обработке вызовов int 10h и тому подобное, которое, очевидно, уже перехватывает IVT, поэтому может легко запускать пользовательский код, который специально запускает SMI. Соответствующая часть - это то, что они описывают для прямых хранилищ в кадровом буфере текстового режима, который должен работать даже для кода, который не вызывает программных или аппаратных прерываний. (Кроме HW, запускающего SMI в таких хранилищах, который, по их словам, они могут использовать, если это поддерживается.)

Поддержка текстового буфера

[0066] В некоторых вариантах осуществления , приложения могут напрямую манипулировать текстовым буфером VGA . В таком варианте осуществления универсальный драйвер 130 c видео SMM поддерживает это одним из двух способов, в зависимости от того, обеспечивает ли аппаратное обеспечение перехват SMI при доступе на чтение / запись в область памяти 740 КБ-768 КБ ( где расположены текстовые буферы).

[0067] Когда доступна перехват SMI, аппаратное обеспечение генерирует SMI при каждом доступе для чтения или записи. Используя адрес прерывания ловушки SMI, можно рассчитать точный текстовый столбец и строку и получить доступ к соответствующей строке и столбцу на виртуальном текстовом экране.

Альтернативно, для этой области включена нормальная память и, используя periodi c SMI, generic c video Драйвер 130 SMM сканирует изменения в эмулированном аппаратном текстовом буфере и обновляет соответствующий виртуальный текстовый экран, поддерживаемый видеодрайвером. В обоих случаях, когда обнаруживается изменение, символ перерисовывается на виртуальном текстовом экране.

Это всего лишь один патент производителя B IOS, и он не говорит нам, каким образом большинство оборудования на самом деле работает, или если другие поставщики делают разные вещи. По сути, это подтверждает, что существует некоторое оборудование, которое может захватывать магазины в этом диапазоне. (Если только это не гипотетическая возможность, которую они решили охватить в своем патенте.)

Для варианта использования, который я имею в виду, захват только с экрана refre sh будет значительно быстрее, чем захват в каждом магазине поэтому мне любопытно, какое аппаратное обеспечение / прошивка работает каким образом.

---

Мотивация для этого вопроса

Оптимизация возрастающего десятичного счетчика ASCII в видеопамяти RAM на 7-м поколении Intel Core - многократное сохранение новых цифр для счетчика текста ASCII в одних и тех же нескольких байтах видеопамяти.

Я тестировал версию кода в 32-битном пользовательском пространстве под Linux в WB-памяти, надеясь приблизить ситуацию с movnti и различными способами заставить ЦП синхронизировать c свой буфер W C с видеопамятью после каждого хранилища (или, возможно, иногда с помощью прерывания по таймеру). Но это нереально c, если ситуация с загрузчиком реального режима не просто сохраняет в DRAM, но вместо этого запускает SMI.

В памяти WB очистка movnti хранилищ с lock xor byte [esp], 0 несколько быстрее, чем промывка с clflushopt. Но @Eldan не сообщает об улучшении скорости памяти VGA после программирования MTRR, чтобы сделать его W C. (И та же скорость, что и для оригинального хранилища, что означает, что по умолчанию VGA кадровый буфер был U C. Некоторые старые BIOS имели возможность сделать VGA память W C, которую они называли USW C = спекулятивное объединение без кэширования.)

Это не является реальной проблемой, поэтому я не ищу реальные обходные пути ; хотя было бы интересно узнать, может ли ручное сохранение пиксельных байтов в графическом режиме VGA намного быстрее.

---

Сводка

1. Любые / все реальные современные системы вызывают SMI в каждом хранилище для кадрового буфера текстового режима?
2. Если нет, можем ли мы приблизить W C store + clflu sh к кадровому буферу, используя movnti + что-то в пользовательском пространстве в памяти WB ? Таким образом, мы можем легко профилировать с помощью perf для счетчиков производительности.
3. Если разные BIOS и / или аппаратные средства используют разные стратегии, каковы эти стратегии? (Я не хочу подробностей, просто высокий уровень, такой как «SMI каждые vblank для синхронизации c кадрового буфера VGA с фактическим аппаратным кадровым буфером»)
4. Будет ли видеокарта P CIe или PCI с аппаратным текстовым режимом VGA работать быстрее, чем на самом деле встроенные графические процессоры? Я предполагаю, что фактическая транзакция записи P CIe будет медленнее, чем ожидание, когда магазин нажмет DRAM, но запись P CIe будет дешевле, чем SMI в каждом магазине. Было бы интересно сравнение приблизительного значения / порядка величин.

Все эти вопросы тесно связаны между собой, но я могу разделить их, если совпадений не так много, как я ожидал.

Answer 1

Какие-либо / все настоящие современные системы запускают SMI в каждом магазине в кадровый буфер текстового режима?

Для видеокарт я очень сильно сомневаюсь. Производители видеокарт используют логи c «get pixel data from char + attribute», встроенную в аппаратное обеспечение с 1980-х годов (она предшествует VGA и не сильно изменившуюся со времен CGA), и просто вставляют эти логики c в каждый новый проектировать, не особенно заботясь об этом.

Для вещей, которые вообще не являются видеокартами (например, инструменты удаленного управления системой с использованием локальной сети), я не знаю, но подозреваю, что нет (часто они используют специальный ЦП управления, а не основной процессор / с, чтобы он работал, даже если компьютер выключен).

Если нет, можем ли мы приблизить W C store + clflu sh к кадровому буферу, используя movnti + что-то в пользовательском пространстве в памяти WB?

Если вы не в пользовательском пространстве, вы можете изменить MTTR (на всех процессорах - MTRR должны совпадать, и в них включена специальная последовательность) сделать область оперативной памяти «некэшированной»; или использовать PAT в таблицах страниц (намного проще, чем возиться с MTRR, особенно если вы все равно используете пейджинг, но немного другое поведение из-за необходимости согласованности кэша). Если вы находитесь в пользовательском пространстве, вам придется полагаться на то, что предоставляет ОС / ядро, и (в зависимости от того, какая это ОС) ОС / ядро ​​может вообще не предоставлять никакого способа сделать это.

Однако; даже если вы найдете способ сделать (область) ОЗУ некэшированной, она все равно будет не очень похожа, потому что вы будете писать напрямую на что-то, подключенное к контроллеру памяти, встроенному в ЦП (этот ЦП может записывать в очень быстро вместо того, чтобы говорить с чем-то на другом конце канала PCI (это будет иметь большую задержку и меньшую пропускную способность со стороны ЦП). Даже для встроенного видео (где в конечном итоге это те же микросхемы ОЗУ) запись в VRAM go по совершенно иному пути (при условии перераспределения / GART / пейджинга в видеокарте, осуществляемого VGA-регистром «режима записи»), зависит от VGA-регистров битовой / плоской маски и т. д. c).

Будет ли видеокарта P CIe или PCI с аппаратным текстовым режимом VGA быстрее, чем любые встроенные графические процессоры?

Для записи с CPU в VRAM; обычно интегрированное видео значительно быстрее, чем дискретные карты (по крайней мере, для простых операций записи из ЦП в буферы линейных кадров, где не используется ни одна из VGA «logi c»).

Для чрезвычайно приблизительных приблизительных оценок; Я ожидаю, что одна запись в ОЗУ будет составлять около 150 циклов, а одна запись в PCI будет близка к 1000 циклам. Для SMI я бы ожидал несколько сотен циклов задержки до того, как SMI прибудет в CPU, затем стоимость конвейера CPU flu sh, затем около 500 циклов для сохранения состояния CPU (и того же состояния загрузки на обратном пути); тогда код прошивки должен будет найти причину SMI (еще несколько сотен циклов?), прежде чем он узнает, что это была запись в VRAM, а не что-то еще; тогда ему нужно будет проверить сохраненное состояние процессора и найти и декодировать инструкцию, которая произвела запись (потому что он не может знать, какие данные записывались, если это была запись в байтах / словах / словах и т. д. c) принимая во внимание предыдущее состояние ЦП (в каком режиме был ЦП, размер кода и т. д. c) и отслеживая, как эмуляция инструкции влияет на будущее состояние ЦП (улучшение RIP и т. д. c) - не забывайте, что они Я буду эмулировать каждую инструкцию, которая может вызвать запись, включая такие вещи, как XADD, et c). Затем необходимо проанализировать состояние (эмулируемых) регистров VGA (режим записи, маска записи, разрешение плоскости, все, что контролирует, какой банк 64 КБ отображается в прежней области, высоту шрифта и т. Д.). В принципе; для эмуляции SMI буфера фрейма записи в текстовый режим; Я ожидал бы, что пройдет несколько десятков тысяч циклов, прежде чем код прошивки упустит из виду незначительную, но важную деталь, скрытую среди огромного количества сложности, заставляя его делать неправильные вещи и быть ненормально сломанным.

Другие заметки

Я нашел патент Phoenix B IOS US20120159520 от 2011 г. «Эмуляция устаревшего видео с использованием uefi».

Я сомневаюсь, что это когда-либо было реализовано, потому что я сомневаюсь, что оно когда-нибудь сможет работать. Есть слишком много (общих и неясных) вещей, которые вы можете сделать с устаревшими интерфейсами (например, обнаружение вертикального refre sh, настройка нестандартных режимов видео, таких как «mode X», скрипка с «start start» для реализации плавной прокрутки и / или перелистывание страниц, используйте «CRT C info» в VBE для изменения таймингов видео и т. д. c), которые не поддерживаются UEFI и не могут быть выполнены через. сторонний видеодрайвер для UEFI.

Вместо этого производители видеокарт не удосужились предоставить драйверы UEFI в течение примерно 10 лет, а прошивка UEFI использовала устаревший интерфейс для эмуляции служб UEFI (часто нарушая безопасную загрузку, пока они работали в Это); пока почти все не было UEFI в любом случае.

Я предполагаю, что (SMM) используется для портов ввода / вывода VGA для установки режима.

Я предполагаю, что нет. Единственное, что смутно связано с видео, для которого я подозреваю, что SMM может использоваться, - это управление яркостью подсветки экрана в ноутбуках (особенно для старых ноутбуков, и особенно для «событий открытия / закрытия крышки») во время ранней загрузки (до ОС).

.. отказ от поддержки HW в текстовом режиме кажется чем-то, что поставщики могут захотеть сделать

Я все еще верю, что (в конечном итоге, после уже слишком длительная фаза перехода «гибридный BIOS + UEFI») удаление более чем 30-летнего накопленного устаревшего беспорядка (A20, VGA, PS / 2, PIT, PI C, ...) из аппаратного обеспечения является одной из основных причин, по которой производители оборудования (Intel) настаивают на принятии UEFI.

Answer 2

При просмотре различных современных таблиц Intel CPU и Platform Controller Hub (PCH) не представляется необходимым внедрить необходимое оборудование. Кажется, что нет никакого способа генерировать SMI (прерывание управления системой) в ответ на обращения к процессору кадрового буфера VGA (физические адреса 0xA0000 - 0xBFFFF).

Контроллер памяти в ЦП будет либо маршрутизировать доступ к кадровому буферу VGA к встроенному графическому контроллеру, порту PCI Express, подключенному непосредственно к ЦП, или интерфейсу DMI, соединяющему ЦП с PCH. Хотя возможна маршрутизация отдельных кадров кадрового буфера VGA, это, по-видимому, предназначено только для поддержки отдельного устройства MDA (Mono chrome Display Adapter). Встроенный графический контроллер недостаточно хорошо документирован, поэтому возможно, что он может быть настроен для генерации SMI при доступе к буферу кадров VGA, но это кажется маловероятным. В любом случае, это не будет работать с дискретной графикой.

Intel PCH также, похоже, не поддерживает генерацию SMI в ответ на доступ к буферу кадров VGA. Это было бы самым естественным местом для этого, поскольку у него уже есть поддержка генерации SMI в ответ на доступы ввода / вывода к контроллеру клавиатуры, контроллеру IDE и другим устаревшим устройствам. Возможно, есть какая-то недокументированная функция, которая делает это, но она не включена в списки возможных источников SMI, приведенные в таблицах PCH.

Теоретически, для производителей материнских плат было бы возможно подключить поддельное устройство VGA к PCH через порт PCI Express и затем генерируйте SMI, используя вывод PCH GPIO. Однако я не уверен, что это сработает на практике. К тому времени, когда ЦП получает SMI, он мог перейти к выполнению других инструкций, и было бы невозможно проверить состояние ЦП во время доступа к буферу кадров.

(Подобная проблема произошла с Эмуляция SoundBlaster 16. в SoundBlaster Live. Он будет генерировать PCI SERR # при доступе к устаревшим портам SoundBlaster, что приведет к генерации NMI на процессоре. К сожалению, эмуляция будет нарушена на многих материнских платах Pentium 4, потому что NMI появится на следующей или последующая инструкция.)