Що насправді відбувається на сучасному комп'ютерному апаратному забезпеченні, завантаженому в 16-бітному застарілому режимі BIOS MBR, коли ви зберігаєте байт, такий як '1'(0x31) у кадрі буфера тексту VGA (режим 03) за фізичною лінійною адресою B8000? Наскільки повільним є mov [es:di], eaxмагазин з MTRR для цього регіону на рівні UC? ( Експериментальне тестування на одному ноутбуці iGPU Kaby Lake показало, що clflushopt на WC був приблизно такою ж швидкістю, як і UC для VGA-пам'яті. Але без clflushopt, movзапам'ятовується в пам'яті WC ніколи не залишає процесор і не оновлює екран взагалі, працює дуже швидко .)

Якщо це не SMI для кожного магазину, чи є який-небудь спосіб наблизити цю вартість на шматок пам'яті WB в користувальницькому просторі, для експериментів із ефективністю без фактичної перезавантаження в реальний режим? (наприклад, використовуючи сторінку BSS як фреймбуфер, який фактично ніде не відображається).

Відповідний гліф шрифту з’явиться на екрані під час наступного оновлення, але чи справді сканування апаратних засобів читає, що ASCII-символ із VRAM (або DRAM для iGPU) та відображає бітові карти шрифтів на лету? Або є перехоплення програмного забезпечення в кожному магазині або один раз на vblank, так що справжнє обладнання має працювати лише з растровим кадром?

Старий завантажувальний BIOS добре відомий для використання режиму управління системою (SMM) для емуляції USB kbd / миші як пристроїв PS / 2. Мені цікаво, чи він також використовується для текстового режиму VGA framebuffer. Я припускаю , що це буде використовуватися для портів виведення для режиму встановлення VGA I / , але це правдоподібно , що текст фреймбуфер може підтримуватися апаратно. Однак більшість комп’ютерів проводять весь свій час у графічному режимі, тому відмова від підтримки HW для текстового режиму, здається, щось, що можуть захотіти зробити виробники. (OTOH цей блог дозволяє припустити, що контролер VGA-контролера для домашніх програм може реалізувати текстовий режим досить просто.)

Мене спеціально цікавлять системи, які використовують 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-бітних реальних режимів драйверів ROM-драйверів, вони пропонують драйвер VGA у реальному режимі ( int 10hфункції тощо), який викликає постачальник відео-драйверів UEFI через гачки SMM.

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

Значна частина опису охоплює обробку int 10hдзвінків та подібні речі, які вже очевидно потрапляють через IVT, таким чином можна легко запустити спеціальний код, який спеціально запускає SMI. Відповідна частина - це те, що вони описують для прямого зберігання в текстовий режим фреймбуфера, який повинен працювати навіть для коду, який не викликає жодних перерв програмного чи апаратного забезпечення. (За винятком HW, що викликає SMI в таких магазинах, які, за їхніми словами, вони можуть використовувати, якщо підтримуються.)

Підтримка текстового буфера

[0066] У певних варіантах здійснення програми можуть безпосередньо маніпулювати текстовим буфером VGA . У такому варіанті здійснення загальний драйвер 130 SMM для відео підтримує це одним із двох способів, залежно від того, чи забезпечує апаратне забезпечення захоплення SMI на доступ для читання / запису для області пам'яті 740 KB-768 KB (де розташовані текстові буфери).

[0067] Коли доступний захоплення SMI, апаратне забезпечення генерує SMI на кожному доступі для читання або запису. Використовуючи адресу пастки SMI-пастки, може бути обчислений точний текстовий стовпець і рядок, а також відповідні рядки та стовпці на екрані віртуального тексту.

Крім того, для цього регіону включена нормальна пам'ять, і, використовуючи періодичний SMI, загальний драйвер SMM для відео 130 сканує зміни в емуляційному текстовому буфері апаратури та оновлює відповідний віртуальний текстовий екран, що підтримується драйвером відео. В обох випадках, коли виявлена ​​зміна, символ перемальовується на екрані віртуального тексту.

Це лише один патент постачальника BIOS і не говорить нам, яким способом працює більшість апаратних засобів, або якщо інші постачальники роблять різні речі. Це фактично підтверджує, що існує деяке обладнання, яке може захоплювати магазини в цьому асортименті. (Якщо тільки це не є гіпотетичною можливістю, яку вони вирішили охопити у своєму патенті.)

Що стосується конкретного випадку, я маю на увазі, захоплення лише на оновлення екрана було б набагато швидше, ніж лову на кожному магазині, тому мені цікаво, яке обладнання та прошивка працює в якому напрямку.

Мотивація до цього питання

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

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

На WB-пам’яті промивання movntiмагазинів із a lock xor byte [esp], 0дещо швидше, ніж промивання clflushopt. Але @Eldan не повідомляє про покращення швидкості для пам'яті VGA після програмування MTRR, щоб зробити її WC. (І така ж швидкість, як і для оригінальних магазинів, що вказує на те, що за замовчуванням VGA framebuffer був UC. Деякі старі BIOS мали можливість зробити WC-пам'ять VGA , яку вони назвали USWC = Uncached Specurative Write Combining.)

Це не реальна проблема, тому я не шукаю реальних обхідних ситуацій ; хоча було б цікаво знати, чи зберігати вручну піксельні байти у графічному режимі VGA може бути набагато швидше.

Підсумок

1. Чи спрацьовує будь-яка / всі реальні сучасні системи SMI в кожному магазині до текстового режиму фреймбуфера?
2. Якщо ні, то чи можемо ми наблизити WC-магазин + clflush до фреймбуфера, використовуючи movnti + щось у користувальному просторі на WB-пам’яті? Тому ми можемо легко профайлюватиperf показники ефективності.
3. Якщо різні BIOS та / або апаратні засоби використовують різні стратегії, що це за стратегії? (Я не хочу деталей, просто високий рівень на зразок "SMI кожен vblank для синхронізації VGA framebuffer з фактичним апаратним framebuffer")
4. Чи буде відеокарта PCIe або PCI з апаратним VGA текстовим модулем бути швидшою, ніж будь-які інтегровані GPU? Я здогадуюсь, що фактична транзакція запису PCIe була б повільнішою, ніж очікування, коли магазин потрапить на DRAM, але запис PCIe буде дешевшим, ніж SMI у кожному магазині. Цікавим було б порівняння бального парку / порядку масштабу.

Ці питання дуже пов'язані між собою, але я можу розділити це, якщо не буде стільки перекриттів, скільки я очікую.

Чи спрацьовує будь-яка / всі реальні сучасні системи SMI в кожному магазині до текстового режиму фреймбуфера?

Що стосується відеокарт, я дуже сумніваюся в цьому. Виробники відеокарт мали логіку "отримати піксельні дані з атрибуту char +", вбудовану в апаратну техніку з 1980-х (вона передувала VGA і не дуже змінилася після CGA), і просто вирізали та вставили цю логіку в кожен новий дизайн, не піклуючись про це. .

Для речей, які взагалі не є відеокартами (наприклад, засоби віддаленого управління системою, що використовують локальну мережу), я не знаю, але не підозрюю (часто вони використовують спеціальний процесор управління, а не основний процесор, щоб він працював, навіть якщо комп'ютер є вимкнений").

Якщо ні, то чи можемо ми наблизити WC-магазин + clflush до фреймбуфера, використовуючи movnti + щось у користувальному просторі на WB-пам’яті?

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

Однак; навіть якщо ви знайдете спосіб зробити (область) оперативної пам’яті збереженою, вона все одно не буде дуже схожою, тому що ви будете писати безпосередньо до чогось, приєднаного до контролера пам'яті, вбудованого в процесор (цей процесор може записувати надзвичайно швидко ) замість того, щоб говорити з чимось на іншому кінці посилання PCI (це матиме більшу затримку та меншу пропускну здатність з боку процесора). Навіть для інтегрованого відео (де зрештою це технічно ті ж мікросхеми оперативної пам’яті в кінцевому підсумку) записи до VRAM проходять зовсім інший шлях (за умови переупорядкування / GART / пейджингу у відеокарті, що здійснюється за допомогою реєстрації VGA у режимі запису, що здійснюється бітові / плоскі маски VGA-регістри тощо).

Чи буде відеокарта PCIe або PCI з апаратним VGA текстовим модулем бути швидшою, ніж будь-які інтегровані GPU?

Для запису з процесора в VRAM; типово інтегроване відео значно швидше, ніж дискретні карти (принаймні, для звичайного запису з процесора в лінійні буфери кадрів, де жодна з "логіки запису" VGA не бере участь).

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

Інші примітки

Я знайшов патент Phoenix BIOS US20120159520 від 2011 року, Емуляція застарілого відео за допомогою uefi.

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

Натомість виробники відеокарт близько 10 років не намагалися надавати драйвери UEFI, а прошивка UEFI використовувала застарілий інтерфейс для імітації послуг UEFI (часто порушуючи безпечне завантаження, поки вони були на ньому); поки майже все не було УЄФІ.

Я припускаю, що це (SMM) використовується для портів VGA введення / виводу для встановлення режиму.

Я припускаю, що ні. Єдине, що нечітко пов'язане з відео, для якого я б підозрював, що SMM може бути використаний, - це контроль яскравості підсвітки екрана на ноутбуках (особливо для старих ноутбуків, і особливо для "відкритих / закритих подій кришки") під час раннього завантаження (перед ОС бере на себе).

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

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

Читаючи різні таблиці даних CPU Intel та платформи контролерів (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, оскільки НМІ надходить на наступну або наступну інструкцію.)