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], eax
magasin 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 mov
magasins 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 10h
fonctions 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 10h
appels 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 movnti
et 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 movnti
magasins avec un lock xor byte [esp], 0
est 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
- Est-ce que certains / tous les vrais systèmes modernes déclenchent un SMI sur chaque magasin vers le framebuffer en mode texte?
- 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
perf
des compteurs de performance. - 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")
- 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.
perf
car Linux n'est pas encore démarré. L'évaluation de la latence SMI (System Management Interrupt) sur une machine Linux-CentOS / Intel contient quelques détails sur la façon de compter les SMI.
MSR_SMI_COUNT=0x34
sans avoir à programmer un compteur au préalable.