Was passiert wirklich auf moderner PC-Hardware, die im 16-Bit-Legacy-BIOS-MBR-Modus gestartet wird, wenn Sie ein Byte wie '1'(0x31) im VGA-Text- Framebuffer (Modus 03) unter physischer linearer Adresse speichern B8000? Wie langsam ist ein mov [es:di], eaxGeschäft mit der MTRR für diese Region auf UC eingestellt? ( Experimentelle Tests auf einem Kaby Lake iGPU-Laptop haben ergeben , dass clflushopt auf WC ungefähr die gleiche Geschwindigkeit wie UC für VGA-Speicher hat. Ohne clflushopt verlassen movSpeicher im WC-Speicher jedoch niemals die CPU und aktualisieren den Bildschirm überhaupt nicht und laufen superschnell .)

Wenn es sich nicht um eine SMI für jedes Geschäft handelt, gibt es eine Möglichkeit, diese Kosten für einen Teil des WB-Speichers im Benutzerbereich für Leistungsexperimente ohne tatsächlichen Neustart im Real-Modus zu schätzen? (z. B. Verwenden einer BSS-Seite als vorgetäuschten Framebuffer, der eigentlich nirgendwo angezeigt wird).

Das entsprechende Schriftzeichen wird bei der nächsten Aktualisierung auf dem Bildschirm angezeigt. Liest das Hardware-Scan-Out das ASCII-Zeichen wirklich aus dem VRAM (oder DRAM für eine iGPU) und ordnet es im laufenden Betrieb Bitmap-Schriftzeichen zu? Oder gibt es in jedem Geschäft oder einmal pro vblank ein Software-Abfangen, sodass die echte Hardware nur einen Bitmap-Framebuffer verarbeiten muss?

Beim Booten von Legacy-BIOS wird bekanntermaßen der System Management Mode (SMM) verwendet , um USB kbd / mouse als PS / 2-Geräte zu emulieren. Ich frage mich, ob es auch für den Framebuffer im VGA-Textmodus verwendet wird. Ich nehme an, es ist für VGA I / O - Ports für die Modus-Einstellung verwendet , aber es ist plausibel , dass ein Text Framebuffer von der Hardware unterstützt werden könnte. Die meisten Computer verbringen ihre gesamte Zeit jedoch im Grafikmodus. Daher scheint es etwas zu sein, das Anbieter möglicherweise tun möchten, wenn sie die HW-Unterstützung für den Textmodus weglassen. (OTOH dieser Blog schlägt vor, dass ein Homebrew-Verilog-VGA-Controller den Textmodus ziemlich einfach implementieren kann.)

Ich interessiere mich speziell für Systeme, die die iGPU in Intel Skylake verwenden, würde mich aber für frühere / spätere iGPUs von Intel und AMD sowie für neue oder alte diskrete GPUs interessieren.

(Einschließlich anderer Anbieter als AMD und NVidia; es gibt einige Skylake-Motherboards mit PCI-Steckplätzen, nicht PCIe. Wenn moderne GPU-Firmware-Treiber den Textmodus emulieren, gibt es vermutlich einige alte PCI-Grafikkarten mit Hardware-VGA-Textmodus. Und möglicherweise eine solche Karte könnte dazu führen, dass Geschäfte nur eine PCI-Transaktion anstelle einer SMI sind.)

Mein eigener Desktop ist ein i7-6700k in einem Asus Z170 Pro Gaming-Mobo, keine Zusatzkarten, nur eine iGPU mit einem 1920x1200-Monitor am DVI-D-Ausgang. Ich kenne die Details des Kaby Lake i5-7300HQ-Systems nicht, auf dem @Eldan testet, nur das CPU-Modell.

Ich habe das Patent US20120159520 von Phoenix BIOS aus dem Jahr 2011 gefunden , das Legacy-Videos mit uefi emuliert . Anstatt von Videohardwareanbietern zu verlangen, dass sie sowohl UEFI- als auch native 16-Bit-Realmodus-Options-ROM-Treiber bereitstellen , schlagen sie einen Realmodus-VGA-Treiber ( int 10hFunktionen usw.) vor, der einen vom Hersteller bereitgestellten UEFI-Videotreiber über SMM-Hooks aufruft.

Zusammenfassung
[...] Das generische Videooptions-ROM benachrichtigt einen generischen Video-SMM-Treiber über die Anforderung von Videodiensten. Eine solche Benachrichtigung kann unter Verwendung eines Software System Management Interrupt (SMI) durchgeführt werden. Nach der Benachrichtigung benachrichtigt der generische Video-SMM-Treiber einen UEFI-Videotreiber eines Drittanbieters über die Anforderung von Videodiensten. Der Videotreiber eines Drittanbieters stellt die angeforderten Videodienste für das Betriebssystem bereit. Auf diese Weise unterstützt ein UEFI-Grafiktreiber eines Drittanbieters möglicherweise eine Vielzahl von Betriebssystemen, auch solche, die die UEFI-Anzeigeprotokolle nicht nativ unterstützen.

Ein Großteil der Beschreibung behandelt die Bearbeitung von int 10hAnrufen und ähnlichen Dingen, die offensichtlich bereits das IVT durchlaufen, und kann daher problemlos benutzerdefinierten Code ausführen, der absichtlich eine SMI auslöst. Der relevante Teil ist das, was sie für direkte Speicherungen im Framebuffer im Textmodus beschreiben, die auch für Code funktionieren müssen, der keine Software- oder Hardware-Interrupts auslöst. (Anders als HW, das SMI in solchen Geschäften auslöst, die sie verwenden können, wenn sie unterstützt werden.)

Unterstützung für Textpuffer

In bestimmten Ausführungsformen können Anwendungen den Textpuffer des VGA direkt manipulieren . In einer solchen Ausführungsform unterstützt der generische Video-SMM-Treiber 130 dies auf eine von zwei Arten, abhängig davon, ob die Hardware eine SMI-Überfüllung beim Lese- / Schreibzugriff auf den 740 KB-768 KB-Speicherbereich (wo sich die Textpuffer befinden) bereitstellt .

Wenn eine SMI-Überfüllung verfügbar ist, erzeugt die Hardware bei jedem Lese- oder Schreibzugriff eine SMI. Unter Verwendung der Trap-Adresse des SMI-Traps kann die genaue Textspalte und -zeile berechnet und auf die entsprechende Zeile und Spalte im virtuellen Textbildschirm zugegriffen werden.

Alternativ wird normaler Speicher für diesen Bereich aktiviert und unter Verwendung eines periodischen SMI sucht der generische Video-SMM-Treiber 130 nach Änderungen im emulierten Hardware-Textpuffer und aktualisiert den entsprechenden virtuellen Textbildschirm, der vom Videotreiber verwaltet wird. In beiden Fällen wird das Zeichen auf dem virtuellen Textbildschirm neu gezeichnet, wenn eine Änderung festgestellt wird.

Dies ist nur das Patent eines BIOS-Anbieters und sagt uns nicht, wie die meiste Hardware tatsächlich funktioniert oder ob andere Anbieter andere Dinge tun. Es ist im Wesentlichen bestätigen , dass einige Hardware vorhanden ist , wo Falle auf Geschäfte in diesem Bereich, though. (Es sei denn, dies ist nur eine hypothetische Möglichkeit, die sie in ihrem Patent behandelt haben.)

Für den Anwendungsfall, an den ich denke, wäre das Überfüllen nur bei der Bildschirmaktualisierung erheblich schneller als das Überfüllen in jedem Geschäft. Daher bin ich gespannt, welche Hardware / Firmware auf welche Weise funktioniert.

Motivation für diese Frage

Optimieren eines inkrementierenden ASCII-Dezimalzählers im Video-RAM des Intel Core der 7. Generation - wiederholtes Speichern neuer Ziffern für einen ASCII-Textzähler in denselben wenigen Bytes des Video-RAM.

Ich habe eine Version des Codes im 32-Bit-Benutzerbereich unter Linux im WB-Speicher getestet, in der Hoffnung, die Situation mit movntiund auf verschiedene Arten zu approximieren , damit die CPU ihren WC-Puffer nach jedem Speicher (oder vielleicht gelegentlich in) mit dem Video-RAM synchronisiert ein Timer-Interrupt). Dies ist jedoch nicht realistisch, wenn die Bootloader-Situation im Real-Modus nicht nur im DRAM gespeichert, sondern stattdessen eine SMI ausgelöst wird.

Im WB-Speicher ist das Löschen von movntiSpeichern mit a lock xor byte [esp], 0etwas schneller als das Löschen mit clflushopt. Aber @Eldan meldet keine Geschwindigkeitsverbesserung für diejenigen im VGA-Speicher, nachdem ein MTRR so programmiert wurde, dass es WC wird. (Und die gleiche Geschwindigkeit wie beim Original, bei dem normale Speicher ausgeführt werden, was darauf hinweist, dass der VGA-Framebuffer standardmäßig UC war. Einige ältere BIOS hatten die Option, VGA-Speicher-WC zu erstellen, das sie USWC = Uncached Speculative Write Combining nannten.)

Es ist kein reales Problem, daher suche ich nicht nach tatsächlichen Problemumgehungen . Es wäre jedoch interessant zu wissen, ob das manuelle Speichern von Pixelbytes in einem VGA-Grafikmodus viel schneller sein könnte.

Zusammenfassung

1. Lösen einige / alle echten modernen Systeme in jedem Geschäft eine SMI für den Framebuffer im Textmodus aus?
2. Wenn nein, können wir einen WC-Speicher + Clflush an den Framebuffer annähern, indem wir ein movnti + etwas im User-Space im WB-Speicher verwenden? So können wir uns leicht perffür Leistungsindikatoren profilieren .
3. Welche unterschiedlichen Strategien verwenden verschiedene BIOS und / oder Hardware? (Ich möchte keine Details, nur eine hohe Ebene wie "SMI jedes vblank, um den VGA-Framebuffer mit dem tatsächlichen Hardware-Framebuffer zu synchronisieren")
4. Wäre eine PCIe- oder PCI-Grafikkarte mit Hardware-VGA-Textmodus schneller als die integrierten GPUs? Ich vermute, dass eine tatsächliche PCIe-Schreibtransaktion langsamer ist als das Warten, bis ein Geschäft den DRAM erreicht, aber dass ein PCIe-Schreibvorgang in jedem Geschäft billiger ist als ein SMI. Ein Vergleich von Baseballstadion und Größenordnung wäre interessant.

Diese Fragen sind alle eng miteinander verbunden, aber ich kann sie aufteilen, wenn es nicht so viele Überschneidungen gibt, wie ich erwartet habe.

Lösen einige / alle echten modernen Systeme in jedem Geschäft eine SMI für den Framebuffer im Textmodus aus?

Bei Grafikkarten bezweifle ich das sehr. Bei Grafikkartenherstellern ist seit den 1980er Jahren die Logik "Pixeldaten von char + attribute abrufen" in die Hardware integriert (sie ist älter als VGA und hat sich seit CGA nicht wesentlich geändert). Sie können diese Logik einfach ausschneiden und in jedes neuere Design einfügen, ohne sich darum zu kümmern .

Für Dinge, die überhaupt keine Grafikkarten sind (z. B. Remote-Systemverwaltungstools, die LAN verwenden), weiß ich es nicht, aber ich vermute es nicht (oft verwenden sie eine spezielle Verwaltungs-CPU anstelle der Haupt-CPUs, damit es auch dann funktioniert, wenn der Computer es ist ausgeschaltet").

Wenn nein, können wir einen WC-Speicher + Clflush an den Framebuffer annähern, indem wir ein movnti + etwas im User-Space im WB-Speicher verwenden?

Wenn Sie sich nicht im Benutzerbereich befinden, können Sie MTTRs ändern (auf allen CPUs - MTRRs müssen übereinstimmen und es ist eine spezielle Sequenz erforderlich), um einen RAM-Bereich "nicht zwischengespeichert" zu machen. oder verwenden Sie PAT in den Seitentabellen (viel einfacher als das Durcheinander mit MTRRs, insbesondere wenn Sie ohnehin Paging verwenden, aber ein etwas anderes Verhalten, da immer noch Cache-Kohärenz erforderlich ist). Wenn Sie sich im Benutzerbereich befinden, müssen Sie sich auf das Betriebssystem / den Kernel verlassen, und (je nachdem, um welches Betriebssystem es sich handelt) bietet das Betriebssystem / der Kernel möglicherweise überhaupt keine Möglichkeit, dies zu tun.

Jedoch; Selbst wenn Sie einen Weg finden, (einen Bereich von) RAM zwischengespeichert zu machen, wird es nicht sehr ähnlich sein, da Sie direkt auf etwas schreiben, das an einen in die CPU eingebauten Speichercontroller angeschlossen ist (auf den die CPU extrem schnell schreiben kann) ) anstatt mit etwas am anderen Ende einer PCI-Verbindung zu sprechen (das hat eine höhere Latenz und eine geringere Bandbreite von der CPU-Seite). Selbst bei integriertem Video (bei dem es sich am Ende technisch um dieselben RAM-Chips handelt) gehen Schreibvorgänge in den VRAM einen ganz anderen Weg (vorbehaltlich Remapping / GART / Paging in der Grafikkarte, bewirkt durch ein VGA-Register im "Schreibmodus") Bit- / Ebenenmasken-VGA-Register usw.).

Wäre eine PCIe- oder PCI-Grafikkarte mit Hardware-VGA-Textmodus schneller als die integrierten GPUs?

Für Schreibvorgänge von der CPU in den VRAM; In der Regel ist integriertes Video erheblich schneller als diskrete Karten (zumindest für einfache Schreibvorgänge von der CPU in lineare Frame-Puffer, bei denen keine der "Schreiblogiken" des VGA beteiligt ist).

Für extrem grobe Schätzungen des Baseballstadions; Ich würde erwarten, dass ein einzelner Schreibvorgang in den RAM ungefähr 150 Zyklen und ein einzelner Schreibvorgang in die PCI ungefähr 1000 Zyklen beträgt. Für SMI würde ich einige hundert Latenzzyklen erwarten, bevor SMI bei der CPU ankommt, dann die Kosten für das Leeren der CPU-Pipeline, dann etwa 500 Zyklen, um den CPU-Status (und denselben Ladezustand auf dem Rückweg) zu speichern. dann müsste der Firmware-Code die Ursache des SMI finden (noch ein paar hundert Zyklen?), bevor er wissen könnte, dass es sich um ein Schreiben in den VRAM handelt und nicht um etwas anderes; Dann müsste es den gespeicherten CPU-Status untersuchen und die Anweisung finden und dekodieren, die den Schreibvorgang ausgeführt hat (da es nicht wissen kann, welche Daten geschrieben wurden, ob es sich um ein Byte- / Wort- / Dword-Schreiben usw. handelt) Konto vorherigen CPU-Status (in welchem ​​Modus sich die CPU befand, Codegröße,XADD, usw). Als nächstes müsste der Status von (emulierten) VGA-Registern analysiert werden (Schreibmodus, Schreibmaske, Ebenenfreigabe, unabhängig davon, welche 64-KiB-Bank dem Legacy-Bereich zugeordnet ist, Schriftgröße, ...). Grundsätzlich; zur SMI-Emulation eines Frame-Puffers im Schreibmodus; Ich würde erwarten, dass es Zehntausende von Zyklen dauert, bis der Code der Firmware ein kleines, aber wichtiges Detail übersieht, das in einer enormen Komplexität verborgen ist, was dazu führt, dass es das Falsche tut und ungewöhnlich kaputt geht.

Weitere Hinweise

Ich habe das Patent US20120159520 von Phoenix BIOS aus dem Jahr 2011 gefunden, das Legacy-Videos mit uefi emuliert.

Ich bezweifle, dass dies jemals umgesetzt wurde, weil ich bezweifle, dass es jemals funktionieren kann. Es gibt viel zu viele (häufige und undurchsichtige) Dinge, die Sie mit den älteren Schnittstellen tun können (z. B. vertikale Aktualisierung erkennen, nicht standardmäßige Videomodi wie "Modus X" einrichten, mit "Anzeigestart" herumspielen, um ein reibungsloses Scrollen und / oder Umblättern von Seiten zu implementieren Verwenden Sie "CRTC-Informationen" in VBE, um Video-Timings usw. zu ändern, die von UEFI nicht unterstützt werden und nicht über erfolgen können. ein Drittanbieter-Videotreiber für UEFI.

Stattdessen haben sich die Hersteller von Grafikkarten etwa 10 Jahre lang nicht die Mühe gemacht, UEFI-Treiber bereitzustellen, und die UEFI-Firmware verwendete die Legacy-Schnittstelle, um UEFI-Dienste zu emulieren (wobei häufig der sichere Start unterbrochen wurde, während sie gerade dabei waren). bis fast alles sowieso UEFI war.

Ich gehe davon aus, dass es (SMM) für VGA-E / A-Ports zur Moduseinstellung verwendet wird.

Ich nehme nicht an. Das einzige, was vage mit Videos zu tun hat, für das ich vermuten würde, dass SMM verwendet werden könnte, ist die Steuerung der Helligkeit der Hintergrundbeleuchtung des Bildschirms in Laptops (insbesondere bei älteren Laptops und insbesondere bei "Deckelöffnungs- / Schließereignissen") während des frühen Startvorgangs (vor dem Betriebssystem) übernimmt).

Das Auslassen der HW-Unterstützung für den Textmodus scheint etwas zu sein, das Anbieter möglicherweise tun möchten

Ich glaube immer noch, dass die (eventuelle, nach der bereits zu langen Übergangsphase "Hybrid BIOS + UEFI") mehr als 30 Jahre angesammelten Legacy-Chaos (A20, VGA, PS / 2, PIT, PIC, ...) von der Hardware entfernt wurden ist einer der Hauptgründe, warum Hardwarehersteller (Intel) auf die Einführung von UEFI drängen.

Beim Lesen verschiedener moderner Intel CPU- und Platform Controller Hub (PCH) -Datenblätter scheint es nicht so zu sein, dass die erforderliche Hardware implementiert ist. Es scheint keine Möglichkeit zu geben, ein SMI (System Management Interrupt) als Reaktion auf Prozessorzugriffe auf den VGA-Frame-Puffer (physikalische Adressen 0xA0000 - 0xBFFFF) zu generieren.

Der Speichercontroller in der CPU leitet entweder Zugriffe auf den VGA-Bildspeicher an den integrierten Grafikcontroller, den direkt an die CPU angeschlossenen PCI Express-Port oder die DMI-Schnittstelle weiter, die die CPU mit dem PCH verbindet. Während es möglich ist, Teile des VGA-Bildpuffers separat zu routen, scheint dies nur dazu gedacht zu sein, ein separates MDA-Gerät (Monochrome Display Adapter) zu unterstützen. Der integrierte Grafikcontroller ist nicht gut dokumentiert, sodass er möglicherweise so konfiguriert werden kann, dass bei VGA-Frame-Buffer-Zugriffen ein SMI generiert wird. Dies ist jedoch unwahrscheinlich. In jedem Fall würde es mit diskreten Grafiken nicht funktionieren.

Intel PCHs scheinen auch keine Unterstützung für die Generierung von SMIs als Reaktion auf VGA-Frame-Buffer-Zugriffe zu haben. Dies wäre der natürlichste Ort dafür, da es bereits Unterstützung für die Generierung von SMIs als Reaktion auf E / A-Zugriffe auf den Tastaturcontroller, den IDE-Controller und andere ältere Geräte bietet. Es ist möglich, dass es eine undokumentierte Funktion gibt, die dies tut, aber sie ist nicht in den Listen möglicher SMI-Quellen enthalten, die in den PCH-Datenblättern angegeben sind.

Theoretisch wäre es für einen Motherboard-Hersteller möglich, ein gefälschtes VGA-Gerät über einen PCI Express-Port mit dem PCH zu verbinden und dann SMIs mithilfe eines PCH-GPIO-Pins zu generieren. Ich bin mir jedoch nicht sicher, ob dies in der Praxis funktionieren wird. Zu dem Zeitpunkt, an dem die CPU die SMI erhält, könnte sie andere Anweisungen ausführen, und es wäre nicht möglich, den CPU-Status zum Zeitpunkt des Frame-Buffer-Zugriffs zu überprüfen.

(Ein ähnliches Problem trat bei der SoundBlaster 16-Emulation auf dem SoundBlaster Live auf. Beim Zugriff auf die älteren SoundBlaster-Ports wurde eine PCI-SERR-Nummer generiert, wodurch ein NMI auf der CPU generiert wurde. Leider wurde die Emulation auf vielen Pentium 4-Motherboards unterbrochen, da die NMI würde bei der nächsten oder nachfolgenden Anweisung eintreffen.)