O que realmente acontece no hardware moderno do PC inicializado no modo BIOS MBR herdado de 16 bits quando você armazena um byte como '1'
(0x31) no buffer de quadros de texto VGA (modo 03) no endereço linear físico B8000
? Quão lenta é uma mov [es:di], eax
loja com o MTRR para essa região definida como UC? ( Os testes experimentais em um laptop Kaby Lake iGPU indicam que o clflushopt no WC era aproximadamente a mesma velocidade que a UC para a memória VGA. Mas, sem o clflushopt, os mov
armazenamentos na memória do WC nunca saem da CPU e nem atualizam a tela, rodando super rápido .)
Se não for um SMI para todas as lojas, existe alguma maneira de aproximar esse custo em um pedaço de memória WB no espaço do usuário, para experiências de desempenho sem realmente reiniciar no modo real? (por exemplo, usando uma página BSS como um fingidor de moldura que na verdade não é exibido em lugar algum).
O glifo de fonte correspondente aparece na tela na próxima atualização, mas a digitalização de hardware está realmente lendo o caracter ASCII do VRAM (ou DRAM para um iGPU) e mapeando para os glifos de fonte de bitmap em tempo real? Ou existe alguma interceptação de software em cada loja ou uma vez por vblank, para que o hardware real precise lidar apenas com um buffer de quadro de bitmap?
Sabe-se que a inicialização do BIOS herdado usa o SMM (System Management Mode) para emular o kbd / mouse USB como um dispositivo PS / 2. Gostaria de saber se também é usado para o framebuffer de modo de texto VGA. Suponho que seja usado para portas de E / S VGA para configuração de modo, mas é plausível que um buffer de quadro de texto possa ser suportado por hardware. No entanto, a maioria dos computadores passa o tempo todo no modo gráfico, deixando de fora o suporte de HW para o modo de texto como algo que os fornecedores podem querer fazer. (OTOH neste blog sugere que um controlador VGA de homilrew verilog pode implementar o modo de texto de maneira bastante simples.)
Estou especificamente interessado em sistemas que usam o iGPU no Intel Skylake, mas estaria interessado em iGPUs anteriores / posteriores da Intel e AMD e em GPUs discretas novas ou antigas.
(Incluindo fornecedores que não são AMD e NVidia; existem algumas placas-mãe Skylake com slots PCI, e não PCIe. Se os drivers de firmware GPU modernos emulam o modo de texto, presumivelmente existem algumas placas de vídeo PCI antigas com o modo de texto VGA de hardware. E talvez essa placa poderia tornar as lojas apenas uma transação PCI em vez de uma SMI.)
Minha própria área de trabalho é um i7-6700k em um mobo Asus Z170 Pro Gaming, sem placas adicionais, apenas iGPU com um monitor 1920x1200 na saída DVI-D. Não conheço os detalhes do sistema Kaby Lake i5-7300HQ que o @Eldan está testando, apenas o modelo da CPU.
Encontrei a patente US20120159520 da Phoenix BIOS de 2011 ,
Emulando vídeo legado usando uefi . Em vez de exigir que os fornecedores de hardware de vídeo forneçam drivers UEFI e ROM nativos opcionais de modo real de 16 bits, propõem um driver VGA em modo real ( int 10h
funções e assim por diante) que chama um driver de vídeo UEFI fornecido pelo fornecedor por meio de ganchos SMM.
Resumo
A ROM da opção de vídeo genérico notifica um driver SMM de vídeo genérico da solicitação de serviços de vídeo. Essa notificação pode ser realizada usando uma interrupção de gerenciamento de sistema de software (SMI). Após a notificação, o driver SMM de vídeo genérico notifica um driver de vídeo UEFI de terceiros sobre a solicitação de serviços de vídeo. O driver de vídeo de terceiros fornece os serviços de vídeo solicitados ao sistema operacional. Dessa maneira, um driver gráfico UEFI de terceiros pode suportar uma ampla variedade de sistemas operacionais, mesmo aqueles que não oferecem suporte nativo aos protocolos de exibição UEFI.
Grande parte da descrição abrange o manuseio de int 10h
chamadas e coisas do tipo que obviamente já interceptam o IVT, portanto, podem executar facilmente códigos personalizados que acionam um SMI de propósito. A parte relevante é o que eles descrevem para armazenamentos diretos no buffer de quadros em modo de texto, que precisam funcionar mesmo para códigos que não acionam interrupções de software ou hardware. (Além de HW acionar o SMI nessas lojas, eles dizem que podem usar se houver suporte.)
Suporte de buffer de texto
[0066] Em certas modalidades, os aplicativos podem manipular diretamente o buffer de texto do VGA . Em tal modalidade, o driver SMM de vídeo genérico 130 suporta isso de duas maneiras, dependendo se o hardware fornece captura SMI no acesso de leitura / gravação à região de memória de 740 KB a 768 KB (onde os buffers de texto estão localizados).
[0067] Quando o trapping SMI está disponível, o hardware gera um SMI em cada acesso de leitura ou gravação. Usando o endereço de interceptação da interceptação SMI, a coluna e a linha exatas do texto podem ser calculadas e a linha e a coluna correspondentes na tela de texto virtual acessada.
Como alternativa, a memória normal é ativada para essa região e, usando um SMI periódico, o driver SMM de vídeo genérico 130 verifica alterações no buffer de texto de hardware emulado e atualiza a tela de texto virtual correspondente mantida pelo driver de vídeo. Nos dois casos, quando uma alteração é detectada, o caractere é redesenhado na tela de texto virtual.
Esta é apenas a patente de um fornecedor de BIOS e não nos diz de que maneira a maioria dos hardwares realmente funciona, ou se outros fornecedores fazem coisas diferentes. Essencialmente, confirma que existe algum hardware que pode prender nas lojas desse intervalo. (A menos que seja apenas uma possibilidade hipotética que eles decidiram cobrir em sua patente.)
Para o caso de uso que tenho em mente, capturar apenas a atualização na tela seria muito mais rápido que capturar em todas as lojas, por isso estou curioso para saber qual hardware / firmware funciona dessa maneira.
Motivação para esta pergunta
Otimizando um contador decimal ASCII incremental na RAM de vídeo no Intel Core de 7ª geração - armazenando repetidamente novos dígitos para um contador de texto ASCII nos mesmos poucos bytes de RAM de vídeo.
Testei uma versão do código no espaço do usuário de 32 bits no Linux, na memória WB, na esperança de aproximar a situação movnti
e diferentes maneiras de fazer com que a CPU sincronize seu buffer WC com a RAM de vídeo após cada armazenamento (ou talvez ocasionalmente em interrupção do temporizador). Mas isso não é realista se a situação do carregador de inicialização em modo real não estiver apenas armazenando na DRAM, mas ativando uma SMI.
Na memória WB, a descarga de movnti
lojas com a lock xor byte [esp], 0
é um pouco mais rápida do que a descarga de clflushopt
. Mas o @Eldan não relata melhora na velocidade para aqueles na memória VGA depois de programar um MTRR para torná-lo WC. (E a mesma velocidade do original que faz armazenamentos normais, indicando que, por padrão, o buffer de quadros VGA era UC. Alguns BIOS mais antigos tinham uma opção para tornar o WC da memória VGA , que eles chamavam de USWC = Uncached Speculative Write Combining.)
Não é um problema do mundo real, então não estou procurando soluções alternativas ; embora seja interessante saber se o armazenamento manual de bytes de pixel em um modo de gráficos VGA pode ser muito mais rápido.
Sumário
- Algum / todos os sistemas modernos reais acionam um SMI em todas as lojas no buffer de quadros em modo de texto?
- Se não, podemos aproximar uma loja de WC + descarga ao framebuffer, usando um movnti + algo no espaço do usuário na memória WB? Assim, podemos criar um perfil fácil
perf
para contadores de desempenho. - Se diferentes BIOS e / ou hardware usam estratégias diferentes, quais são essas estratégias? (Não quero detalhes, apenas um alto nível como "SMI every vblank para sincronizar o buffer de quadros VGA com o buffer de hardware real")
- Uma placa de vídeo PCIe ou PCI com modo de texto VGA de hardware seria mais rápida do que as GPUs integradas realmente fazem? Suponho que uma transação de gravação PCIe real seria mais lenta do que esperar uma loja atingir a DRAM, mas que uma gravação PCIe seria mais barata que uma SMI em todas as lojas. Uma comparação entre estimativa e ordem de magnitude seria interessante.
Todas essas questões são altamente relacionadas, mas posso dividir isso se não houver tanta sobreposição quanto espero.
perf
porque o Linux ainda não foi inicializado. A avaliação da latência SMI (System Management Interrupt) na máquina Linux-CentOS / Intel tem alguns detalhes sobre como contar SMIs.
MSR_SMI_COUNT=0x34
sem ter que programar um contador primeiro.