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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мотивация на этот вопрос

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

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

В памяти WB очистка movntiхранилищ с помощью lock xor byte [esp], 0несколько быстрее, чем очистка clflushopt. Но @Eldan не сообщает об улучшении скорости памяти VGA после программирования MTRR, чтобы сделать его WC. (И та же скорость, что и для оригинального хранилища, что указывает на то, что по умолчанию VGA- кадровый буфер был UC. Некоторые старые BIOS имели возможность сделать VGA-память WC , которую они назвали USWC = Uncached Speculartive Write Combining.)

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

Резюме

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

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

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

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

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

Если нет, можем ли мы приблизить хранилище WC + clflush к кадровому буферу, используя movnti + что-то в пространстве пользователя в памяти WB?

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

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

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

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

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

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

Я нашел патент Phoenix BIOS US20120159520 от 2011 года, эмулирующий устаревшее видео с использованием uefi.

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

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

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

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

.. исключение поддержки HW для текстового режима кажется чем-то, что продавцы могли бы хотеть сделать

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

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

Контроллер памяти в ЦПУ будет либо перенаправлять доступ к кадровому буферу VGA на встроенный графический контроллер, порту PCI Express, подключенному непосредственно к ЦП, либо интерфейсу DMI, соединяющему ЦП с PCH. Хотя возможна маршрутизация отдельных кадров кадрового буфера VGA, это, по-видимому, предназначено только для поддержки отдельного устройства MDA (монохромный дисплейный адаптер). Встроенный графический контроллер недостаточно хорошо документирован, поэтому возможно, что он может быть настроен для генерации 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 прибудет на следующей или последующей инструкции.)