O SO / shell do Windows 98 usa a CPU para gravar no buffer de tela / tela?

Quero dizer, ele usa a CPU para acessar o MMIO para colocar pixels na tela sem ter outro hardware (por exemplo, GPU, etc.) após isso.

Quando o Windows 98 é inicializado, ele carrega uma imagem por qualquer programa iniciado (Winload.exe?), Decodifica a imagem e grava no dispositivo MMIO na tela. Uma GPU não é necessária para isso, mas o Windows 98 possui drivers de dispositivo para GPUs. Eu assumo que funciona assim:

GANHE PROGRAMA DE CARGA -> DECODIFICAÇÃO DE IMAGEM -> EXIBIDOR DE CHAMADA -> ESCREVA PIXELS.

Aqui estão as duas perguntas:

1. Quando o Windows 98 é inicializado e mostra a imagem principal da tela inicial por padrão (ou qualquer imagem definida pelo usuário), a CPU a decodifica e grava diretamente em um middleware de software framebuffer / VGA / VESA (driver) para coloque os pixels na tela e evite usar a GPU se houver um driver de GPU carregado?

2.Se nenhum driver de GPU for detectado, o Windows 98 pode funcionar completamente bem (o próprio sistema operacional) sem nenhuma GPU e apenas fazer com que a CPU escreva no buffer de quadros (sem considerar coisas como OpenGL / DirectX / etc.)?

Em palavras mais simples, o Windows 98 opera 100% com a CPU e não precisa de GPU (exceto talvez por manipulação de gráficos de última geração OpenGL / DirectX / desenho acelerado por hardware / etc. Para jogos, decodificação de vídeo etc.)? Os jogos em 3D provavelmente usam gráficos rápidos da GPU, acelerando com o OpenGL / DirectX, por isso é improvável que a CPU faça qualquer coisa, exceto gravar na GPU para isso. Mas o shell / GUI e as funções básicas do sistema operacional parecem muito básicas e sem aceleração, e possivelmente são desenhadas apenas com a CPU usando algum tipo de monitor que desenha software de baixo nível para manipulação de pixels?

Observe que estou dizendo "GPU", mas podemos considerar que isso significa qualquer hardware que não seja a CPU que grava na tela. As CPUs podem gravar diretamente na tela sem nenhuma GPU, mas ir além disso requer MMIO, programação de baixo nível, especificações e engenharia eletrônica / de computadores.

Um pouco de história ajudará você a entender como as coisas funcionavam no mundo do Windows 9x.

Desde o Intel 80386, os processadores tiveram dois "modos" de operação: Modo Real e Modo Protegido. Quando você liga o computador pela primeira vez - mesmo um moderno equipamento para jogos Core i7 -, o processador inicia no Modo Real. O Modo Real não oferece proteção de memória, suporte a multitarefa, nem níveis de privilégios de código - nada. Qualquer programa tem acesso direto e irrestrito à memória. A comunicação com o hardware foi fornecida pelo BIOS através de chamadas de interrupção.

Uma interrupção faz exatamente o que o nome implica; para a CPU morta em suas trilhas. Os programas carregariam um bitmap de uma imagem no buffer de quadros. Ele colocaria um ponteiro para essa memória no byte baixo do registro da CPU do AX (conhecido como AL) e a instrução BIOS para exibi-lo no byte alto (AH). Ele chamaria a interrupção do BIOS 0x10h e o BIOS assumiria o controle. A CPU não está mais no controle do seu computador neste momento.

O BIOS então leria as instruções em AH e passaria o ponteiro em AL para o hardware de vídeo. A GPU copia o conteúdo do buffer de quadro para sua própria RAM e libera o controle de volta para o BIOS, que o devolve à CPU. A CPU está agora de volta ao banco do motorista.

É importante lembrar que todas as versões da família Windows 9x eram basicamente aplicativos DOS. Então, quando o Win98 recebeu sua tela inicial, a CPU ainda estava no Modo Real e ainda estava usando interrupções do BIOS para exibi-lo. A pequena animação bonitinha no fundo era apenas um truque de paleta de ciclismo. Não havia desenho acontecendo lá.

Agora, quando o Windows é carregado, uma de suas primeiras ordens de negócios era mudar a CPU para o modo Protegido de 32 bits. Isso basicamente expulsou o DOS da memória e disse ao BIOS o que ele poderia fazer consigo mesmo. A maioria das funções que seriam tratadas pelo BIOS agora são substituídas pelo Windows HAL e pelo Kernel. No mundo Windows, os aplicativos conversam com o hardware por meio de uma chamada de API, e essa chamada da API o executou no driver de vídeo, que era um componente necessário do sistema operacional.

Agora (finalmente), é aqui que entramos na sua pergunta. O Windows controlava o hardware de vídeo (como continua até hoje) através de um driver de vídeo. Se nenhum driver estivesse disponível, ele retornaria ao driver padrão do Windows, que usava o framebuffer para fazer seu desenho. A única diferença é que a CPU está sempre no controle via E / S mapeada na memória e o BIOS não está envolvido. Se um driver estivesse presente, ele ainda usaria o MMIO, mas para emitir comandos proprietários para a GPU, não quadros de bitmap. A GPU tem acesso direto à memória e pode operar em paralelo com a CPU, incluindo comunicação bidirecional através desses intervalos de E / S.

O Windows 98 tinha drivers para o hardware de vídeo de seu dia e poderia fornecer aceleração 2D e 3D completa, incluindo OpenGL e DirectX. Mas ele ainda precisa de um driver para comunicar essas coisas à GPU e não pode fazê-lo sem ela.

Os controles da janela de desenho (por exemplo, botões, barras de título etc.) foram feitos por meio da GDI (Windows Graphics Device Interface), que era a principal API do Windows usada para desenhar elementos da tela. Possui todos os tipos de funções, incluindo formas, canetas, cores de preenchimento e, sim, bitmaps também. O GDI traduziria essas instruções em código de driver. O driver (seja o driver da GPU ou o driver do framebuffer) ficou encarregado de obter essas instruções GDI na tela por qualquer meio que fosse programado para executar.

Isso é muito complicado de digerir e é apenas uma breve visão geral de como os dados entram e os pixels saem. Espero que ele responda algumas de suas perguntas.