Que se passe- t-il vraiment sur le matériel PC moderne démarré en mode MBR BIOS hérité 16 bits lorsque vous stockez un octet tel que '1'(0x31) dans le tampon de trame du texte VGA (mode 03) à une adresse linéaire physique B8000? Quelle est la lenteur d'un mov [es:di], eaxmagasin avec le MTRR pour cette région défini sur UC? ( Les tests expérimentaux sur un ordinateur portable Kaby Lake iGPU indiquent que clflushopt sur WC était à peu près la même vitesse que UC pour la mémoire VGA. Mais sans clflushopt, les movmagasins dans la mémoire WC ne quittent jamais le CPU et ne mettent pas à jour l'écran du tout, fonctionnant très vite .)

S'il ne s'agit pas d'un SMI pour chaque magasin, existe-t-il un moyen d'estimer ce coût sur un morceau de mémoire WB dans l'espace utilisateur, pour des expériences de performances sans réellement redémarrer en mode réel? (par exemple, en utilisant une page BSS comme un tampon d'image qui ne s'affiche réellement nulle part).

Le glyphe de police correspondant apparaît à l'écran lors de la prochaine actualisation, mais le balayage matériel lit-il vraiment ce caractère ASCII de VRAM (ou DRAM pour un iGPU) et mappe-t-il à la volée des glyphes de police bitmap? Ou y a-t-il une interception logicielle sur chaque magasin ou une fois par vblank, de sorte que le véritable matériel ne doit gérer qu'un framebuffer bitmap?

Le démarrage du BIOS hérité est bien connu pour utiliser le mode de gestion du système (SMM) pour émuler la souris / kbd USB en tant que périphériques PS / 2. Je me demande s'il est également utilisé pour le tampon de cadre en mode texte VGA. Je suppose qu'il est utilisé pour les ports d'E / S VGA pour le réglage du mode, mais il est plausible qu'un tampon de cadre de texte puisse être pris en charge par le matériel. Cependant, la plupart des ordinateurs passent tout leur temps en mode graphique, donc laisser de côté le support matériel pour le mode texte semble être quelque chose que les vendeurs pourraient vouloir faire. (OTOH ce blog suggère qu'un contrôleur VGA homebrew verilog peut implémenter le mode texte assez simplement.)

Je suis spécifiquement intéressé par les systèmes utilisant l'iGPU dans Intel Skylake, mais je serais intéressé par les iGPU précédents / ultérieurs d'Intel et d'AMD, et les nouveaux ou anciens GPU discrets.

(Y compris les fournisseurs autres que AMD et NVidia; il existe des cartes mères Skylake avec des emplacements PCI, pas PCIe. Si les pilotes de micrologiciel GPU modernes émulent le mode texte, il y a probablement de vieilles cartes vidéo PCI avec le mode texte VGA matériel. Et peut-être une telle carte pourrait faire des magasins simplement une transaction PCI au lieu d'un SMI.)

Mon propre bureau est un i7-6700k dans un mobo Asus Z170 Pro Gaming, pas de cartes d'extension juste iGPU avec un moniteur 1920x1200 sur la sortie DVI-D. Je ne connais pas les détails du système Kaby Lake i5-7300HQ sur lequel @Eldan teste, uniquement le modèle de CPU.

J'ai trouvé le brevet US20120159520 de Phoenix BIOS de 2011 , émulant la vidéo héritée en utilisant uefi . Au lieu d'exiger des fournisseurs de matériel vidéo pour fournir à la fois UEFI et pilotes natifs option ROM en mode réel 16 bits, ils proposent un véritable mode pilote VGA ( int 10hfonctions et ainsi de suite) qui appelle un pilote vidéo UEFI fournisseur fourni par des crochets SMM.

Résumé
[...] L'option vidéo générique ROM notifie un pilote SMM vidéo générique de la demande de services vidéo. Une telle notification peut être effectuée à l'aide d'une interruption de gestion du système logiciel (SMI). Lors de la notification, le pilote vidéo SMM générique informe un pilote vidéo UEFI tiers de la demande de services vidéo. Le pilote vidéo tiers fournit les services vidéo demandés au système d'exploitation. De cette façon, un pilote graphique UEFI tiers peut prendre en charge une grande variété de systèmes d'exploitation, même ceux qui ne prennent pas en charge nativement les protocoles d'affichage UEFI.

Une grande partie de la description couvre la gestion des int 10happels et des trucs comme celui qui, de toute évidence, piège déjà à travers l'IVT, peut donc facilement exécuter du code personnalisé qui déclenche un SMI exprès. La partie pertinente est ce qu'ils décrivent pour les magasins directs dans le tampon de trame en mode texte qui doivent fonctionner même pour le code qui ne déclenche aucune interruption logicielle ou matérielle. (Autre que HW déclenchant SMI sur ces magasins, qu'ils disent pouvoir utiliser s'ils sont pris en charge.)

Prise en charge du tampon de texte

Dans certains modes de réalisation, les applications peuvent manipuler directement le tampon de texte du VGA . Dans un tel mode de réalisation, le pilote vidéo SMM générique 130 prend en charge cela de deux manières, selon que le matériel fournit ou non une interruption SMI lors de l'accès en lecture / écriture à la région de mémoire de 740 Ko à 768 Ko (où se trouvent les tampons de texte).

Lorsque le piégeage SMI est disponible, le matériel génère un SMI à chaque accès en lecture ou en écriture. En utilisant l'adresse d'interruption de l'interruption SMI, la colonne et la ligne de texte exactes peuvent être calculées et la ligne et la colonne correspondantes dans l'écran de texte virtuel accessibles.

Alternativement, la mémoire normale est activée pour cette région et, à l'aide d'un SMI périodique, le pilote SMM vidéo générique 130 recherche les changements dans le tampon de texte matériel émulé et met à jour l'écran de texte virtuel correspondant maintenu par le pilote vidéo. Dans les deux cas, lorsqu'un changement est détecté, le caractère est redessiné sur l'écran de texte virtuel.

Ce n'est qu'un brevet de fournisseur de BIOS et ne nous dit pas de quelle manière la plupart du matériel fonctionne réellement, ni si d'autres fournisseurs font des choses différentes. Il ne confirme essentiellement que certains matériel existe qui peut piéger sur les magasins dans cette gamme, cependant. (Sauf si c'est juste une possibilité hypothétique qu'ils ont décidé de couvrir dans leur brevet.)

Pour le cas d'utilisation que j'ai en tête, le piégeage uniquement à l'actualisation de l'écran serait beaucoup plus rapide que le piégeage sur chaque magasin, donc je suis curieux de savoir quel matériel / microprogramme fonctionne dans quel sens.

Motivation pour cette question

Optimisation d'un compteur décimal ASCII incrémentiel dans la RAM vidéo sur Intel Core de 7e génération - stockage répétitif de nouveaux chiffres pour un compteur de texte ASCII dans les mêmes octets de RAM vidéo.

J'ai testé une version du code dans un espace utilisateur 32 bits sous Linux, sur la mémoire WB, dans l'espoir d'approximer la situation avec movntiet différentes façons de faire en sorte que le CPU synchronise son tampon WC avec la RAM vidéo après chaque magasin (ou peut-être occasionnellement dans une interruption de la minuterie). Mais ce n'est pas réaliste si la situation du chargeur de démarrage en mode réel ne se limite pas au stockage sur DRAM, mais déclenche plutôt un SMI.

Sur la mémoire WB, le rinçage des movntimagasins avec un lock xor byte [esp], 0est un peu plus rapide que le rinçage avec clflushopt. Mais @Eldan ne signale aucune amélioration de la vitesse pour ceux sur la mémoire VGA après avoir programmé un MTRR pour le rendre WC. (Et la même vitesse que pour les magasins normaux d'origine, indiquant que par défaut le framebuffer VGA était UC. Certains BIOS plus anciens avaient une option pour créer de la mémoire VGA WC , qu'ils appelaient USWC = Combinaison d'écriture spéculative non mise en cache.)

Ce n'est pas un problème du monde réel, donc je ne recherche pas de solutions de contournement réelles ; bien qu'il serait intéressant de savoir si le stockage manuel d'octets de pixels dans un mode graphique VGA pourrait être beaucoup plus rapide.

Sommaire

1. Est-ce que certains / tous les vrais systèmes modernes déclenchent un SMI sur chaque magasin vers le framebuffer en mode texte?
2. Si non, pouvons-nous rapprocher un magasin WC + clflush du framebuffer, en utilisant un movnti + quelque chose dans l'espace utilisateur sur la mémoire WB? Nous pouvons donc facilement profiler avec perfdes compteurs de performance.
3. Si différents BIOS et / ou matériels utilisent des stratégies différentes, quelles sont ces stratégies? (Je ne veux pas de détails, juste un niveau élevé comme "SMI chaque vblank pour synchroniser le framebuffer VGA avec le framebuffer matériel")
4. Une carte vidéo PCIe ou PCI avec un mode texte VGA matériel serait-elle plus rapide que les GPU intégrés? Je suppose qu'une transaction d'écriture PCIe réelle serait plus lente que d'attendre qu'un magasin atteigne la DRAM, mais qu'une écriture PCIe serait moins chère qu'une SMI sur chaque magasin. Une comparaison approximative / ordre de grandeur serait intéressante.

Ces questions sont toutes étroitement liées, mais je peux diviser cela s'il n'y a pas autant de chevauchements que je m'y attendais.

Est-ce que certains / tous les vrais systèmes modernes déclenchent un SMI sur chaque magasin vers le framebuffer en mode texte?

Pour les cartes vidéo, j'en doute fort. Les fabricants de cartes vidéo ont intégré la logique «obtenir les données en pixels à partir de char + attribut» dans le matériel depuis les années 1980 (elle est antérieure à VGA et n'a pas beaucoup changé depuis CGA), et il suffit de copier-coller cette logique dans chaque nouvelle conception sans s'en soucier .

Pour les choses qui ne sont pas du tout des cartes vidéo (par exemple, des outils de gestion de système à distance utilisant un réseau local), je ne sais pas, mais je ne pense pas (souvent, ils utilisent un processeur de gestion spécial plutôt que le ou les CPU principaux pour que cela fonctionne même si l'ordinateur est éteindre").

Si non, pouvons-nous rapprocher un magasin WC + clflush du framebuffer, en utilisant un movnti + quelque chose dans l'espace utilisateur sur la mémoire WB?

Si vous n'êtes pas dans l'espace utilisateur, vous pouvez modifier les MTTR (sur tous les CPU - les MTRR doivent correspondre et il y a une séquence spéciale impliquée) pour rendre une zone de RAM "non mise en cache"; ou utilisez PAT dans les tables de pages (beaucoup plus facile que de jouer avec les MTRR, surtout si vous utilisez la pagination de toute façon, mais un comportement légèrement différent en raison du besoin de cohérence du cache). Si vous êtes dans l'espace utilisateur, vous devrez vous fier à tout ce que le système d'exploitation / noyau fournit et (selon le système d'exploitation qu'il est), le système d'exploitation / noyau peut ne fournir aucun moyen de le faire.

Toutefois; même si vous trouvez un moyen de rendre (une zone de) RAM non mise en cache, elle ne sera toujours pas très similaire, car vous écrirez directement sur quelque chose attaché à un contrôleur de mémoire intégré au CPU (ce CPU peut écrire extrêmement rapidement ) au lieu de parler à quelque chose à l'autre extrémité d'une liaison PCI (qui aura une latence plus élevée et une bande passante plus faible du côté du processeur). Même pour la vidéo intégrée (où il s'agit techniquement des mêmes puces RAM à la fin), les écritures sur la VRAM passent par un chemin très différent (sous réserve de remappage / GART / pagination dans la carte vidéo, effectué par un registre VGA en "mode d'écriture", effectué par registres VGA masque bit / plan, etc.).

Une carte vidéo PCIe ou PCI avec un mode texte VGA matériel serait-elle plus rapide que les GPU intégrés?

Pour les écritures du CPU vers la VRAM; la vidéo généralement intégrée est nettement plus rapide que les cartes discrètes (au moins pour les écritures en clair du CPU vers les tampons de trames linéaires où aucune des "logiques d'écriture" du VGA n'est impliquée).

Pour des estimations approximatives extrêmement approximatives; Je m'attendrais à ce qu'une seule écriture sur la RAM soit d'environ 150 cycles et une seule écriture sur le PCI à près de 1000 cycles. Pour SMI, je m'attendrais à quelques centaines de cycles de latence avant que SMI n'arrive au processeur, puis au coût de vidage du pipeline du processeur, puis à environ 500 cycles pour enregistrer l'état du processeur (et le même état de chargement sur le chemin de retour); alors le code du firmware devrait trouver la cause du SMI (encore quelques centaines de cycles?) avant de pouvoir savoir que c'était une écriture sur VRAM et pas autre chose; il devrait ensuite examiner l'état du processeur enregistré et trouver et décoder l'instruction qui a fait l'écriture (car il ne peut pas savoir quelles données étaient en cours d'écriture, s'il s'agissait d'une écriture octet / mot / dword, etc.) tout en prenant en compte tenir compte de l'état précédent du processeur (dans quel mode le processeur était, la taille du code,XADD, etc). Ensuite, il devrait analyser l'état des registres VGA (émulés) (mode d'écriture, masque d'écriture, validation de plan, quels que soient les contrôles de la banque de 64 Ko mappée dans la zone héritée, la hauteur de police, ...). Fondamentalement; pour l'émulation SMI d'une mémoire tampon de trame en mode texte; Je m'attendrais à ce qu'il prenne des dizaines de milliers de cycles avant que le code du micrologiciel ne néglige un détail mineur mais important enfoui dans une énorme quantité de complexité, ce qui le fait faire la mauvaise chose et être inutilisablement cassé.

Autres notes

J'ai trouvé le brevet US20120159520 de Phoenix BIOS de 2011, émulant la vidéo héritée en utilisant uefi.

Je doute que cela ait jamais été mis en œuvre, car je doute que cela puisse jamais fonctionner. Il y a beaucoup trop de choses (courantes et obscures) que vous pouvez faire avec les interfaces héritées (par exemple, détecter l'actualisation verticale, configurer des modes vidéo non standard comme "mode X", jouer avec "démarrage de l'affichage" pour implémenter un défilement fluide et / ou un retournement de page , utilisez "info CRTC" dans VBE pour modifier les synchronisations vidéo, etc.) qui n'est pas pris en charge par UEFI et ne peut pas être effectué via. un pilote vidéo tiers pour UEFI.

Au lieu de cela, les fabricants de cartes vidéo n'ont pas pris la peine de fournir des pilotes UEFI pendant environ 10 ans et le micrologiciel UEFI a utilisé l'interface héritée pour émuler les services UEFI (interrompant souvent le démarrage sécurisé pendant qu'ils y étaient); jusqu'à ce que presque tout était UEFI de toute façon.

Je suppose que (SMM) est utilisé pour les ports d'E / S VGA pour le réglage du mode.

Je suppose que non. La seule chose vaguement liée à la vidéo que je soupçonne que SMM peut être utilisée est de contrôler la luminosité du rétroéclairage de l'écran des ordinateurs portables (en particulier pour les ordinateurs portables plus anciens, et en particulier pour les "événements d'ouverture / fermeture du couvercle") pendant le démarrage précoce (avant le système d'exploitation) prend le relais).

.. laisser de côté le support matériel pour le mode texte semble être quelque chose que les vendeurs pourraient vouloir faire

Je crois toujours que la suppression (éventuelle, après la phase de transition "BIOS hybride + UEFI" déjà trop longue) de plus de 30 ans de désordre hérité accumulé (A20, VGA, PS / 2, PIT, PIC, ...) du matériel est l'une des principales raisons pour lesquelles les fabricants de matériel (Intel) poussent / ont poussé à l'adoption de l'UEFI.

En lisant diverses fiches techniques de CPU Intel et de Platform Controller Hub (PCH) modernes, il ne semble pas que le matériel nécessaire soit implémenté. Il ne semble pas y avoir de moyen de générer un SMI (System Management Interrupt) en réponse aux accès du processeur du tampon de trame VGA (adresses physiques 0xA0000 - 0xBFFFF).

Le contrôleur de mémoire du CPU achemine les accès au tampon de trame VGA vers le contrôleur graphique intégré, le port PCI Express connecté directement au CPU ou l'interface DMI connectant le CPU au PCH. Bien qu'il soit possible d'acheminer séparément les parties du tampon de trame VGA, cela semble uniquement destiné à prendre en charge un périphérique MDA (Monochrome Display Adapter) distinct. Le contrôleur graphique intégré n'est pas bien documenté, il est donc possible qu'il puisse être configuré pour générer un accès SMI sur le tampon de trame VGA, mais cela semble peu probable. Dans tous les cas, cela ne fonctionnerait pas avec des graphiques discrets.

Les PCH d'Intel ne semblent pas non plus avoir de support pour générer des SMI en réponse aux accès au tampon de trame VGA. Ce serait l'endroit le plus naturel pour lui, car il prend déjà en charge la génération de SMI en réponse aux accès d'E / S au contrôleur de clavier, au contrôleur IDE et à d'autres périphériques hérités. Il est possible qu'il existe une fonctionnalité non documentée qui le fasse, mais elle n'est pas incluse dans les listes de sources SMI possibles données dans les fiches techniques PCH.

Théoriquement, il serait possible pour un fabricant de cartes mères de connecter un faux périphérique VGA au PCH via un port PCI Express, puis de générer des SMI à l'aide d'une broche GPIO PCH. Cependant, je ne suis pas sûr que cela fonctionnera dans la pratique. Au moment où le CPU obtient le SMI, il aurait pu passer à l'exécution d'autres instructions et il ne serait pas possible d'examiner l'état du CPU au moment de l'accès au tampon de trame.

(Un problème similaire s'est produit avec l'émulation SoundBlaster 16 sur le SoundBlaster Live. Il générerait un PCI SERR # lors de l'accès aux ports SoundBlaster hérités, ce qui générerait une NMI sur le CPU. Malheureusement, l'émulation se briserait sur de nombreuses cartes mères Pentium 4 car le NMI arriverait sur l'instruction suivante ou suivante.)