¿Qué sucede realmente en el hardware de PC moderno que se '1'inicia en el modo MBR heredado de 16 bits cuando almacena un byte como (0x31) en el framebuffer de texto VGA (modo 03) en una dirección lineal física B8000? ¿Qué tan lenta es una mov [es:di], eaxtienda con el MTRR para esa región establecida en UC? ( Las pruebas experimentales en una computadora portátil Kaby Lake iGPU indican que clflushopt en WC era aproximadamente la misma velocidad que UC para la memoria VGA. Pero sin clflushopt, las movtiendas en la memoria WC nunca abandonan la CPU y no actualizan la pantalla en absoluto, corriendo súper rápido .)

Si no es un SMI para cada tienda, ¿hay alguna forma de aproximar este costo en una porción de memoria WB en el espacio del usuario, para experimentos de rendimiento sin reiniciar en modo real? (por ejemplo, usando una página BSS como un framebuffer de simulación que en realidad no se muestra en ningún lado).

El glifo de fuente correspondiente aparece en la pantalla en la próxima actualización, pero ¿el escaneo de hardware realmente lee ese carácter ASCII de VRAM (o DRAM para una iGPU) y se asigna a los glifos de fuente de mapa de bits sobre la marcha? ¿O hay alguna intercepción de software en cada tienda o una vez por vblank para que el hardware real solo tenga que manejar un framebuffer de mapa de bits?

El arranque de BIOS heredado es bien conocido por usar el modo de administración del sistema (SMM) para emular el kbd / mouse USB como dispositivos PS / 2. Me pregunto si también se usa para el framebuffer de modo de texto VGA. Supongo que se usa para los puertos de E / S VGA para la configuración de modo, pero es posible que el hardware admita un buffer de cuadros de texto. Sin embargo, la mayoría de las computadoras pasan todo su tiempo en modo gráfico, por lo que dejar de lado el soporte HW para el modo de texto parece algo que los proveedores podrían querer hacer. (OTOH este blog sugiere que un controlador VGA verilog homebrew puede implementar el modo de texto de manera bastante simple).

Estoy específicamente interesado en los sistemas que usan iGPU en Intel Skylake, pero estaría interesado en iGPU anteriores / posteriores de Intel y AMD, y GPU discretas nuevas o antiguas.

(Incluidos los proveedores que no sean AMD y NVidia; hay algunas placas base Skylake con ranuras PCI, no PCIe. Si los controladores de firmware de GPU modernos emulan el modo de texto, presumiblemente hay algunas viejas tarjetas de video PCI con modo de texto VGA de hardware. Y tal vez una tarjeta de este tipo podría hacer que las tiendas sean solo una transacción PCI en lugar de una SMI).

Mi propio escritorio es un i7-6700k en un Asus Z170 Pro Gaming mobo, no hay tarjetas adicionales solo iGPU con un monitor de 1920x1200 en la salida DVI-D. No conozco los detalles del sistema Kaby Lake i5-7300HQ que @Eldan está probando, solo el modelo de CPU.

Encontré la patente US20120159520 de Phoenix BIOS de 2011 , emulando video heredado usando uefi . En lugar de exigir a los proveedores de hardware de video que suministren controladores ROM de opción de modo real de UEFI y de 16 bits en modo real, proponen un controlador VGA en modo real ( int 10hfunciones, etc.) que llama a un controlador de video UEFI suministrado por el proveedor a través de enlaces SMM.

Resumen
La ROM de opción de video genérico notifica a un controlador SMM de video genérico de la solicitud de servicios de video. Dicha notificación puede realizarse utilizando una interrupción de gestión del sistema de software (SMI). Tras la notificación, el controlador SMM de video genérico notifica a un controlador de video UEFI de terceros sobre la solicitud de servicios de video. El controlador de video de terceros proporciona los servicios de video solicitados al sistema operativo. De esta forma, un controlador de gráficos UEFI de un tercero puede admitir una amplia variedad de sistemas operativos, incluso aquellos que no admiten de forma nativa los protocolos de visualización UEFI.

Gran parte de la descripción cubre el manejo de int 10hllamadas y cosas por el estilo que obviamente atrapan a través de la IVT, por lo que pueden ejecutar fácilmente código personalizado que desencadena un SMI a propósito. La parte relevante es lo que describen para las tiendas directas en el framebuffer en modo de texto que deben funcionar incluso para el código que no desencadena ninguna interrupción de software o hardware. (Aparte de que HW desencadena SMI en tales tiendas, que dicen que pueden usar si son compatibles).

Soporte de buffer de texto

En ciertas realizaciones, las aplicaciones pueden manipular el búfer de texto del VGA directamente . En tal realización, el controlador de video SMM genérico 130 admite esto de una de dos maneras, dependiendo de si el hardware proporciona captura SMI en el acceso de lectura / escritura a la región de memoria de 740 KB-768 KB (donde se encuentran las memorias intermedias de texto).

[0067] Cuando la captura SMI está disponible, el hardware genera una SMI en cada acceso de lectura o escritura. Usando la dirección de la trampa SMI, se puede calcular la columna y fila de texto exacto y acceder a la fila y columna correspondientes en la pantalla de texto virtual.

Alternativamente, se habilita la memoria normal para esta región y, utilizando un SMI periódico, el controlador genérico de video SMM 130 busca cambios en el búfer de texto de hardware emulado y actualiza la pantalla de texto virtual correspondiente mantenida por el controlador de video. En ambos casos, cuando se detecta un cambio, el personaje se vuelve a dibujar en la pantalla de texto virtual.

Esta es solo la patente de un proveedor de BIOS, y no nos dice de qué manera funciona la mayoría del hardware, o si otros proveedores hacen cosas diferentes. Sin embargo, esencialmente confirma que existe algo de hardware que puede atrapar en tiendas en ese rango. (A menos que sea solo una posibilidad hipotética que decidieron cubrir en su patente).

Para el caso de uso que tengo en mente, atrapar solo en la actualización de la pantalla sería mucho más rápido que atrapar en todas las tiendas, así que tengo curiosidad por saber qué hardware / firmware funciona de esa manera.

Motivación para esta pregunta.

Optimización de un contador decimal ASCII incremental en RAM de video en Intel Core de séptima generación , almacenando repetidamente nuevos dígitos para un contador de texto ASCII en los mismos pocos bytes de RAM de video.

Probé una versión del código en el espacio de usuario de 32 bits en Linux, en la memoria WB, con la esperanza de aproximarme a la situación movntiy a las diferentes formas de hacer que la CPU sincronice su búfer WC con la RAM de video después de cada tienda (o quizás ocasionalmente en una interrupción del temporizador). Pero esto no es realista si la situación del cargador de arranque en modo real no solo se almacena en DRAM, sino que desencadena un SMI.

En la memoria WB, el vaciado de movntitiendas con a lock xor byte [esp], 0es algo más rápido que el vaciado con clflushopt. Pero @Eldan no informa ninguna mejora de velocidad para aquellos en la memoria VGA después de programar un MTRR para que sea WC. (Y la misma velocidad que para el original haciendo almacenamientos normales, lo que indica que, de manera predeterminada, el framebuffer VGA era UC. Algunos BIOS más antiguos tenían la opción de crear WC de memoria VGA , que llamaron USWC = Combinación de escritura especulativa no almacenada en caché).

No es un problema del mundo real, por lo que no estoy buscando soluciones reales ; aunque sería interesante saber si almacenar manualmente bytes de píxeles en un modo de gráficos VGA podría ser mucho más rápido.

Resumen

1. ¿Alguno / todos los sistemas modernos reales disparan un SMI en cada tienda al framebuffer en modo texto?
2. Si no, ¿podemos aproximar una tienda WC + clflush al framebuffer, usando un movnti + algo en el espacio del usuario en la memoria WB? Por lo tanto, podemos perfilar fácilmente perfpara contadores de rendimiento.
3. Si diferentes BIOS y / o hardware usan diferentes estrategias, ¿cuáles son esas estrategias? (No quiero detalles, solo un alto nivel como "SMI cada vblank para sincronizar el framebuffer VGA con el framebuffer de hardware real")
4. ¿Sería una tarjeta de video PCIe o PCI con modo de texto VGA de hardware más rápido que cualquier GPU integrada? Supongo que una transacción de escritura PCIe real sería más lenta que esperar que una tienda llegue a DRAM, pero que una escritura PCIe sería más barata que una SMI en cada tienda. Una comparación de estadio de béisbol / orden de magnitud sería interesante.

Todas estas preguntas están muy relacionadas, pero puedo dividir esto si no hay tanta superposición como esperaba.

¿Alguno / todos los sistemas modernos reales disparan un SMI en cada tienda al framebuffer en modo texto?

Para las tarjetas de video, lo dudo mucho. Los fabricantes de tarjetas de video han tenido la lógica "obtener datos de píxeles de char + atributo" integrada en el hardware desde la década de 1980 (es anterior a VGA y no ha cambiado mucho desde CGA), y simplemente cortan y pegan esa lógica en cada diseño más nuevo sin preocuparse mucho por ello .

Para cosas que no son tarjetas de video (por ejemplo, herramientas de administración de sistemas remotos que usan LAN) no lo sé pero sospecho que no (a menudo usan una CPU de administración especial en lugar de las CPU / s principales para que funcione incluso si la computadora está encendida) apagado").

Si no, ¿podemos aproximar una tienda WC + clflush al framebuffer, usando un movnti + algo en el espacio del usuario en la memoria WB?

Si no está en el espacio de usuario, puede cambiar los MTTR (en todas las CPU; los MTRR deben coincidir y hay una secuencia especial involucrada) para hacer que un área de RAM "no esté en caché"; o use PAT en las tablas de páginas (mucho más fácil que jugar con MTRRs, especialmente si está utilizando paginación de todos modos, pero un comportamiento ligeramente diferente debido a que todavía necesita coherencia de caché). Si está en el espacio de usuario, tendrá que depender de lo que proporcione el sistema operativo / núcleo, y (según el sistema operativo que sea) el sistema operativo / núcleo puede no proporcionar ninguna forma de hacerlo.

Sin embargo; incluso si encuentra una manera de hacer (un área de) RAM sin caché, todavía no será muy similar, porque escribirá directamente en algo conectado a un controlador de memoria incorporado en la CPU (esa CPU puede escribir extremadamente rápido ) en lugar de hablar con algo en el otro extremo de un enlace PCI (que tendrá una latencia más alta y un ancho de banda más bajo desde el lado de la CPU). Incluso para video integrado (donde técnicamente son los mismos chips de RAM al final) las escrituras en VRAM pasan por una ruta muy diferente (sujeto a reasignación / GART / paginación en la tarjeta de video, efectuada por un registro VGA de "modo de escritura", efectuado por bit / plano máscara VGA registros, etc.).

¿Sería una tarjeta de video PCIe o PCI con modo de texto VGA de hardware más rápido que cualquier GPU integrada?

Para escrituras de CPU a VRAM; Normalmente, el video integrado es significativamente más rápido que las tarjetas discretas (al menos para las escrituras simples desde la CPU a los buffers de cuadros lineales en los que no está involucrada ninguna de las "lógicas de escritura" del VGA).

Para estimaciones aproximadas extremadamente aproximadas; Esperaría que una sola escritura en RAM sea de alrededor de 150 ciclos y una sola escritura en PCI sea cercana a 1000 ciclos. Para SMI, esperaría unos cientos de ciclos de latencia antes de que SMI llegue a la CPU, luego el costo del lavado de la tubería de la CPU, y luego unos 500 ciclos para guardar el estado de la CPU (y el mismo estado de carga en la ruta de retorno); entonces el código del firmware tendría que encontrar la causa del SMI (¿otros cientos de ciclos?) antes de saber que era una escritura en VRAM y no otra cosa; entonces tendría que examinar el estado de la CPU guardada y encontrar y decodificar la instrucción que realizó la escritura (porque no puede saber qué datos se escribieron, si se trataba de una escritura de byte / word / dword, etc.) al tomar cuenta el estado anterior de la CPU (en qué modo estaba la CPU, el tamaño del código,XADD, etc.) A continuación, tendría que analizar el estado de los registros VGA (emulados) (modo de escritura, máscara de escritura, habilitación de plano, cualquier control que el banco de 64 KiB se asigne en el área heredada, la altura de la fuente, ...). Básicamente; para la emulación SMI de un búfer de trama en modo de escritura en texto; Esperaría que tomara decenas de miles de ciclos antes de que el código del firmware pase por alto un detalle menor pero importante enterrado entre una gran cantidad de complejidad, lo que hace que haga lo incorrecto y se rompa inusualmente.

Otras notas

Encontré la patente US20120159520 de Phoenix BIOS de 2011, emulando video heredado usando uefi.

Dudo que esto se haya implementado alguna vez, porque dudo que alguna vez pueda funcionar. Hay demasiadas cosas (comunes y oscuras) que puede hacer con las interfaces heredadas (p. Ej., Detección de actualización vertical, configuración de modos de video no estándar como "modo X", violín con "inicio de pantalla" para implementar desplazamiento suave y / o volteo de página , use "CRTC info" en VBE para modificar los tiempos de video, etc., que no sea compatible con UEFI y no se pueda hacer a través de. un controlador de video de terceros para UEFI.

En cambio, los fabricantes de tarjetas de video no se molestaron en proporcionar controladores UEFI durante aproximadamente 10 años y el firmware UEFI utilizó la interfaz heredada para emular los servicios UEFI (a menudo rompiendo el arranque seguro mientras estaban en él); hasta que casi todo era UEFI de todos modos.

Supongo que (SMM) se usa para puertos de E / S VGA para la configuración de modo.

Supongo que no. Lo único vagamente relacionado con el video que sospecho que se puede usar para SMM es controlar el brillo de la retroiluminación de la pantalla en las computadoras portátiles (especialmente para computadoras portátiles más antiguas, y especialmente para "eventos de apertura / cierre de la tapa") durante el inicio temprano (antes del sistema operativo se hace cargo).

.. dejar de lado el soporte HW para el modo de texto parece algo que los vendedores pueden querer hacer

Todavía creo que la eliminación (eventual, después de la fase de transición "BIOS híbrida + UEFI" ya demasiado larga) de más de 30 años de desorden heredado acumulado (A20, VGA, PS / 2, PIT, PIC, ...) del hardware Es una de las principales razones por las que los fabricantes de hardware (Intel) están / han estado presionando para la adopción de UEFI.

Al leer varias hojas de datos modernas de Intel CPU y Platform Controller Hub (PCH), no parece que se implemente el hardware necesario. No parece haber ninguna forma de generar un SMI (Interrupción de la gestión del sistema) en respuesta a los accesos del procesador del búfer de trama VGA (direcciones físicas 0xA0000 - 0xBFFFF).

El controlador de memoria en la CPU enrutará los accesos al búfer de trama VGA al controlador de gráficos integrado, el puerto PCI Express conectado directamente a la CPU o la interfaz DMI que conecta la CPU a la PCH. Si bien es posible enrutar partes del búfer de cuadro VGA por separado, esto solo parece ser compatible con un dispositivo MDA (Adaptador de pantalla monocromático) separado. El controlador de gráficos integrado no está bien documentado, por lo que es posible que se pueda configurar para generar un SMI en accesos de búfer de trama VGA, pero esto parece poco probable. En cualquier caso, no funcionaría con gráficos discretos.

Los PCH de Intel tampoco parecen tener ningún soporte para generar SMI en respuesta a los accesos al búfer de trama VGA. Este sería el lugar más natural para él, ya que ya tiene soporte para generar SMI en respuesta a los accesos de E / S al controlador de teclado, controlador IDE y otros dispositivos heredados. Es posible que haya alguna característica no documentada que haga esto, pero no está incluida en las listas de posibles fuentes SMI que figuran en las hojas de datos de PCH.

Teóricamente, sería posible que un fabricante de placas base conecte un dispositivo VGA falso a la PCH a través de un puerto PCI Express y luego genere SMI usando un pin PCH GPIO. Sin embargo, no estoy seguro de que esto funcione en la práctica. En el momento en que la CPU obtiene el SMI, podría haber pasado a ejecutar otras instrucciones y no sería posible examinar el estado de la CPU en el momento del acceso al búfer de trama.

(Un problema similar ocurrió con la emulación SoundBlaster 16 en SoundBlaster Live. Generaría un PCI SERR # cuando se accediera a los puertos de SoundBlaster heredados, lo que generaría un NMI en la CPU. Desafortunadamente, la emulación se rompería en muchas placas base Pentium 4 porque NMI llegaría en la instrucción siguiente o posterior).