Использует ли ОС / оболочка Windows 98 ЦП для записи в кадровый буфер / дисплей?

Question

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

Когда Windows 98 загружается, он загружает образ при запуске любой программы (Winload.exe?) и декодирует изображение и записывает на устройство MMIO на дисплей. Для этого не нужен графический процессор, но в Windows 98 есть драйверы устройств для графических процессоров. Я предполагаю, что это работает так:

ПРОГРАММА ЗАГРУЗКИ WIN -> ДЕКОДИРОВАНИЕ ИЗОБРАЖЕНИЯ -> ДРАЙВЕР ВЫЗОВА -> ЗАПИСЬ ПИКСЕЛЕЙ.

Вот два вопроса:

1.Когда Windows 98 загружается и показывает флагманское изображение с заставкой по умолчанию (или любое другое изображение, определенное пользователем), имеет ли ЦП его декодирование и запись непосредственно в промежуточное программное обеспечение (драйвер) кадрового буфера /VGA /VESA для установки пикселей на дисплее и избегать использования графического процессора, если драйвер графического процессора загружен?

2.Если драйвер графического процессора не обнаружен, может ли Windows 98 нормально работать (сама ОС) без какого-либо графического процессора и просто иметь возможность записи ЦП в буфер кадров (без учета таких вещей, как OpenGL/DirectX/ и т.д.)?

Проще говоря, Windows 98 работает на 100% с процессором и не нуждается в графическом процессоре (за исключением, может быть, OpenGL/DirectX для работы с высокопроизводительной графикой / аппаратного ускорения рисования / и т.д. Для игр, декодирования видео и т.д.)? В трехмерных играх, вероятно, используется быстрое ускорение графической карты с помощью OpenGL/DirectX, так что маловероятно, что центральный процессор будет делать что-либо кроме записи в графический процессор для этого. Но оболочка / графический интерфейс пользователя и основные функции ОС кажутся очень простыми и не имеют никакого ускорения, и, возможно, просто рисуются с одним только ЦП, используя какое-то отображение низкоуровневого программного обеспечения для манипулирования пикселями?

Обратите внимание, что я говорю "GPU", но мы можем считать, что это означает любое непроцессорное оборудование, которое записывает данные на дисплей. Процессоры могут записывать данные напрямую на дисплей без какого-либо графического процессора, но дальнейшее развитие требует MMIO, низкоуровневого программирования, спецификаций и электронного / компьютерного проектирования.

Answer 1

Немного истории поможет вам понять, как все работает в мире Windows 9x.

Начиная с Intel 80386, процессоры имели два "режима" работы: реальный режим и защищенный режим. При первом включении компьютера - даже современной игровой платформы Core i7 - процессор запускается в реальном режиме. Реальный режим не обеспечивает защиту памяти, не поддерживает многозадачность, нет уровней привилегий кода - ничего. Любая программа имеет прямой, неограниченный доступ к памяти. Связь с оборудованием обеспечивалась BIOS посредством вызовов прерывания.

Прерывание делает именно то, что подразумевает его имя; он останавливает процессор в мертвом состоянии. Программы будут загружать растровое изображение в буфер кадра. Затем он поместит указатель на эту память в младший байт регистра ЦП AX (известный как AL) и инструкцию BIOS для отображения ее в старшем байте (AH). Затем он вызывает прерывание BIOS 0x10h, и BIOS вступает во владение. На этом этапе процессор больше не контролирует ваш компьютер.

Затем BIOS считывает инструкцию в AH и передает указатель в AL на видеооборудование. Затем графический процессор скопирует содержимое кадрового буфера в свою собственную оперативную память и затем вернет управление обратно в BIOS, который затем вернет его в центральный процессор. Процессор теперь вернулся на место водителя.

Важно помнить, что все версии семейства Windows 9x были в основном приложениями DOS. Поэтому, когда Win98 показывали свой экран-заставку, процессор все еще находился в реальном режиме, и он все еще использовал прерывания BIOS для его отображения. Милая маленькая анимация внизу была просто палитрой трюков на велосипеде. Там не было никакого рисунка, происходящего там.

Теперь, когда Windows загружается, одним из первых ее заказов было переключение процессора в 32-битный защищенный режим. Это в основном выбило DOS из памяти и сказало BIOS, что он может делать с собой. Большинство функций, которые были бы обработаны BIOS, теперь заменены Windows HAL и Kernel. В мире Windows приложения взаимодействуют с оборудованием через вызов API, и этот вызов API запускает его через драйвер дисплея, который был обязательным компонентом операционной системы.

Теперь (наконец) вот где мы переходим к вашему вопросу. Затем Windows (как и по сей день) контролировала видеооборудование через драйвер дисплея. Если драйвер не был доступен, он по умолчанию вернулся к стандартному драйверу Windows, который использовал кадровый буфер для рисования. Единственное отличие состоит в том, что центральный процессор всегда контролируется с помощью ввода-вывода с отображением в памяти, а BIOS не задействован. Если бы драйвер присутствовал, он все равно использовал бы MMIO, но для того, чтобы выдавать собственные команды для GPU, а не для растровых кадров. Графический процессор имеет прямой доступ к памяти и может работать параллельно с центральным процессором, включая двустороннюю связь через эти диапазоны ввода / вывода.

Windows 98 действительно имела драйверы для видеооборудования своего времени и могла обеспечить полноценное ускорение 2D и 3D, включая OpenGL и DirectX. Но ему все еще нужен драйвер для передачи этих данных на графический процессор, и он не может без него.

Элементы управления окном рисования (т.е. кнопки, строки заголовка и т.д.) Выполнялись через интерфейс графического устройства Windows (GDI), который был основным API-интерфейсом Windows, используемым для рисования элементов экрана. Он имеет все виды функций, включая формы, ручки, цвета заливки и, конечно же, растровые изображения. GDI переведет эти инструкции в код драйвера. Драйвер (будь то драйвер графического процессора или драйвер кадрового буфера) отвечал за вывод этих инструкций GDI на экран с помощью любых средств, которые он запрограммировал.

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