Cosa succede realmente sul moderno hardware PC avviato in modalità MBR BIOS legacy a 16 bit quando si memorizza un byte come '1'(0x31) nel framebuffer di testo VGA (modalità 03) all'indirizzo lineare fisico B8000? Quanto è lento un mov [es:di], eaxnegozio con l' MTRR per quella regione impostato su UC? ( Test sperimentali su un laptop iGPU di Kaby Lake indicano che clflushopt su WC aveva all'incirca la stessa velocità di UC per la memoria VGA. Ma senza clflushopt, gli archivi movnella memoria WC non lasciano mai la CPU e non aggiornano affatto lo schermo, funzionando in modo super veloce .)

Se non è una SMI per ogni negozio, c'è un modo per approssimare questo costo su un pezzo di memoria WB nello spazio utente, per esperimenti sulle prestazioni senza riavviare in modalità reale? (ad esempio utilizzando una pagina BSS come un framebuffer fasullo che in realtà non viene visualizzato da nessuna parte).

Il glifo del carattere corrispondente appare sullo schermo nel prossimo aggiornamento, ma la scansione dell'hardware sta davvero leggendo quel carattere ASCII da VRAM (o DRAM per un iGPU) e la mappatura al glifo dei caratteri bitmap al volo? O c'è qualche intercettazione software su ogni negozio o una volta per vblank, quindi l'hardware reale deve solo gestire un framebuffer bitmap?

È noto che l' avvio del BIOS legacy utilizza la modalità di gestione del sistema (SMM) per emulare USB kbd / mouse come dispositivi PS / 2. Mi chiedo se sia utilizzato anche per il framebuffer in modalità testo VGA. Suppongo che sia utilizzato per le porte I / O VGA per l'impostazione della modalità, ma è plausibile che un framebuffer di testo possa essere supportato dall'hardware. Tuttavia, la maggior parte dei computer trascorre tutto il loro tempo in modalità grafica, quindi tralasciando il supporto HW per la modalità testo sembra che qualcosa che i venditori potrebbero voler fare. (OTOH questo blog suggerisce che un controller VGA verilog homebrew può implementare la modalità testo in modo abbastanza semplice.)

Sono particolarmente interessato ai sistemi che utilizzano l'iGPU in Intel Skylake, ma sarei interessato alle iGPU precedenti / successive di Intel e AMD e alle GPU discrete nuove o vecchie.

(Compresi fornitori diversi da AMD e NVidia; ci sono alcune schede madri Skylake con slot PCI, non PCIe. Se i moderni driver del firmware GPU emulano la modalità testo, presumibilmente ci sono alcune vecchie schede video PCI con modalità testo VGA hardware. E forse una tale scheda potrebbe rendere i negozi solo una transazione PCI anziché una SMI.)

Il mio desktop è un i7-6700k in un mobo Asus Z170 Pro Gaming, nessuna scheda aggiuntiva solo iGPU con un monitor 1920x1200 sull'uscita DVI-D. Non conosco i dettagli del sistema Kaby Lake i5-7300HQ su cui sta testando @Eldan, solo il modello di CPU.

Ho trovato il brevetto US20120159520 del BIOS Phoenix del 2011 , Emulazione di video legacy usando uefi . Invece di richiedere i venditori di hardware video per la fornitura sia UEFI e 16 bit driver opzione-ROM nativi modalità reale, propongono un driver in modalità reale VGA ( int 10hfunzioni e così via) che chiama un driver video UEFI fornito dal produttore tramite ganci SMM.

Abstract
[...] La ROM di opzione video generica notifica a un driver SMM video generico la richiesta di servizi video. Tale notifica può essere eseguita utilizzando un interrupt di gestione del sistema software (SMI). Dopo la notifica, il driver SMM video generico notifica a un driver video UEFI di terze parti la richiesta di servizi video. Il driver video di terze parti fornisce i servizi video richiesti al sistema operativo. In questo modo, un driver grafico UEFI di terze parti può supportare un'ampia varietà di sistemi operativi, anche quelli che non supportano nativamente i protocolli di visualizzazione UEFI.

Gran parte della descrizione riguarda la gestione di int 10hchiamate e cose come quella che già ovviamente intrappolano attraverso l'IVT, quindi può facilmente eseguire codice personalizzato che attiva intenzionalmente una SMI. La parte rilevante è ciò che descrivono per i negozi diretti nel framebuffer in modalità testo che devono funzionare anche per il codice che non attiva interruzioni software o hardware. (A parte HW che attiva SMI in tali negozi, che dicono di poter usare se supportati.)

Supporto buffer di testo

[0066] In alcune forme di realizzazione, le applicazioni possono manipolare direttamente il buffer di testo del VGA . In una tale forma di realizzazione, il driver SMM video generico 130 lo supporta in due modi, a seconda che l'hardware fornisca il trapping SMI sull'accesso in lettura / scrittura alla regione di memoria 740 KB-768 KB (dove si trovano i buffer di testo).

[0067] Quando è disponibile il trapping SMI, l'hardware genera un SMI su ogni accesso in lettura o scrittura. Utilizzando l'indirizzo trap della trap SMI, è possibile calcolare la colonna e la riga di testo esatte e accedere alla riga e colonna corrispondente nella schermata di testo virtuale.

In alternativa, la memoria normale è abilitata per questa regione e, utilizzando una SMI periodica, il driver SMM video generico 130 cerca le modifiche nel buffer di testo hardware emulato e aggiorna la schermata di testo virtuale corrispondente gestita dal driver video. In entrambi i casi, quando viene rilevata una modifica, il personaggio viene ridisegnato nella schermata di testo virtuale.

Questo è solo un brevetto del fornitore del BIOS e non ci dice in che modo funziona la maggior parte dell'hardware o se altri fornitori fanno cose diverse. Esso essenzialmente conferma che alcuni hardware esistente che intrappolano lattina sui negozi in tale intervallo, però. (A meno che non sia solo un'ipotetica possibilità che abbiano deciso di coprire nel loro brevetto.)

Per il caso d'uso che ho in mente, il trapping solo sull'aggiornamento dello schermo sarebbe molto più veloce del trapping su ogni negozio, quindi sono curioso di sapere quale hardware / firmware funzioni in questo modo.

Motivazione per questa domanda

Ottimizzazione di un contatore decimale ASCII incrementale nella RAM video su Intel Core di settima generazione : memorizzazione ripetuta di nuove cifre per un contatore di testo ASCII negli stessi pochi byte di RAM video.

Ho testato una versione del codice nello spazio utente a 32 bit sotto Linux, su memoria WB, sperando di approssimare la situazione movntie diversi modi per far sì che la CPU sincronizzi il suo buffer WC con la RAM video dopo ogni negozio (o forse occasionalmente in un interruzione del timer). Ma questo non è realistico se la situazione del bootloader in modalità reale non è solo l'archiviazione su DRAM, ma invece il trigger di una SMI.

Sulla memoria WB, svuotare i movntinegozi con a lock xor byte [esp], 0è leggermente più veloce che svuotare clflushopt. Ma @Eldan non segnala alcun miglioramento della velocità per coloro che sono nella memoria VGA dopo aver programmato un MTRR per renderlo WC. (E la stessa velocità dell'originale facendo normali negozi, indicando che per impostazione predefinita il framebuffer VGA era UC. Alcuni BIOS più vecchi avevano un'opzione per creare WC di memoria VGA , che chiamavano USWC = Uncached Speculative Write Combining.)

Non è un problema del mondo reale, quindi non sto cercando soluzioni alternative reali ; anche se sarebbe interessante sapere se la memorizzazione manuale di pixel byte in una modalità grafica VGA potrebbe essere molto più veloce.

Sommario

1. Qualcuno / tutti i veri sistemi moderni attivano una SMI in ogni negozio al framebuffer in modalità testo?
2. Se no, possiamo approssimare un archivio WC + clflush al framebuffer, usando un movnti + qualcosa nello spazio utente sulla memoria del bilanciamento del bianco? Quindi possiamo facilmente creare profili perfper i contatori delle prestazioni.
3. Se BIOS e / o hardware diversi utilizzano strategie diverse, quali sono tali strategie? (Non voglio dettagli, solo un livello elevato come "SMI ogni vblank per sincronizzare il framebuffer VGA con l'effettivo framebuffer hardware")
4. Una scheda video PCIe o PCI con modalità testo VGA hardware sarebbe più veloce di qualsiasi altra GPU integrata effettivamente? Immagino che una vera transazione di scrittura PCIe sarebbe più lenta dell'attesa che un negozio colpisca la DRAM, ma che una scrittura PCIe sarebbe più economica di una SMI su ogni negozio. Un confronto ballpark / ordine di grandezza sarebbe interessante.

Queste domande sono tutte strettamente correlate, ma posso dividerlo se non ci sono così tante sovrapposizioni come mi aspetto.

Qualcuno / tutti i veri sistemi moderni attivano una SMI in ogni negozio al framebuffer in modalità testo?

Per le schede video, ne dubito moltissimo. I produttori di schede video hanno avuto la logica "ottieni dati pixel da char + attributo" integrata nell'hardware dagli anni '80 (precede VGA e non è cambiata molto da CGA), e ha semplicemente tagliato e incollato quella logica in ogni nuovo design senza preoccuparsene molto .

Per cose che non sono affatto schede video (ad es. Strumenti di gestione remota del sistema che utilizzano LAN) non lo so ma sospetto di no (spesso usano una CPU di gestione speciale anziché la CPU principale in modo che funzioni anche se il computer è spento").

Se no, possiamo approssimare un archivio WC + clflush al framebuffer, usando un movnti + qualcosa nello spazio utente sulla memoria del bilanciamento del bianco?

Se non sei nello spazio utente, puoi modificare gli MTTR (su tutte le CPU - gli MTRR devono corrispondere e c'è una sequenza speciale coinvolta) per rendere "non memorizzata" un'area di RAM; oppure usa PAT nelle tabelle delle pagine (molto più facile che scherzare con gli MTRR, specialmente se usi comunque il paging, ma un comportamento leggermente diverso a causa della necessità di coerenza della cache). Se ti trovi nello spazio utente, dovrai fare affidamento su tutto ciò che il sistema operativo / kernel fornisce e (a seconda del sistema operativo in cui si trova) il sistema operativo / kernel potrebbe non fornire alcun modo per farlo.

Però; anche se trovi un modo per sbloccare (un'area di) RAM, questa non sarà ancora molto simile, perché scriverai direttamente su qualcosa collegato a un controller di memoria integrato nella CPU (che la CPU può scrivere in modo estremamente rapido ) invece di parlare con qualcosa all'altra estremità di un collegamento PCI (che avrà una latenza più elevata e una larghezza di banda inferiore dal lato CPU). Anche per i video integrati (dove tecnicamente sono gli stessi chip RAM alla fine) le scritture su VRAM passano attraverso un percorso molto diverso (soggetto a rimappatura / GART / paging nella scheda video, effettuato da un registro VGA in "modalità di scrittura", effettuato da registri VGA maschera bit / piano, ecc.).

Una scheda video PCIe o PCI con modalità testo VGA hardware sarebbe più veloce di qualsiasi altra GPU integrata effettivamente?

Per le scritture dalla CPU alla VRAM; in genere il video integrato è significativamente più veloce delle schede discrete (almeno per le scritture semplici dalla CPU ai buffer di frame lineari in cui non è coinvolta nessuna "logica di scrittura" del VGA).

Per stime del ballpark estremamente approssimative; Mi aspetto che una singola scrittura su RAM sia di circa 150 cicli e una singola scrittura su PCI sia vicina a 1000 cicli. Per SMI mi aspetterei alcune centinaia di cicli di latenza prima che SMI arrivi alla CPU, quindi il costo del flush della pipeline della CPU, quindi circa 500 cicli per salvare lo stato della CPU (e lo stesso stato di caricamento sul percorso di ritorno); quindi il codice del firmware dovrebbe trovare la causa della SMI (altre poche centinaia di cicli?) prima che potesse sapere che era una scrittura su VRAM e non qualcos'altro; quindi dovrebbe esaminare lo stato della CPU salvato e trovare e decodificare le istruzioni che hanno fatto la scrittura (perché non può sapere quali dati sono stati scritti, se fosse un byte / parola / dword, ecc.) mentre prende account stato CPU precedente (in quale modalità si trovava la CPU, dimensione del codice,XADD, eccetera). Successivamente dovrebbe analizzare lo stato dei registri VGA (emulati) (modalità di scrittura, maschera di scrittura, abilitazione piano, qualunque controllo quale banco di 64 KiB è mappato nell'area legacy, altezza carattere, ...). Fondamentalmente; per l'emulazione SMI di un buffer di frame in modalità di scrittura; Mi aspetterei che impiegherebbe decine di migliaia di cicli prima che il codice del firmware trascuri un dettaglio minore ma importante seppellito in un'enorme quantità di complessità, facendogli fare la cosa sbagliata ed essere insolitamente rotto.

Altre note

Ho trovato il brevetto US20120159520 del BIOS Phoenix del 2011, Emulazione di video legacy usando uefi.

Dubito che questo sia mai stato implementato, perché dubito che possa mai funzionare. Ci sono troppe cose (comuni e oscure) che puoi fare con le interfacce legacy (ad esempio, rileva l'aggiornamento verticale, imposta modalità video non standard come "modalità X", giocherella con "display start" per implementare lo scorrimento regolare e / o il capovolgimento delle pagine , utilizzare "Informazioni CRTC" in VBE per modificare i tempi dei video, ecc.) che non è supportato da UEFI e non può essere eseguito tramite. un driver video di terze parti per UEFI.

Invece, i produttori di schede video non si sono preoccupati di fornire driver UEFI per circa 10 anni e il firmware UEFI ha utilizzato l'interfaccia legacy per emulare i servizi UEFI (spesso rompendo l'avvio sicuro mentre erano lì); fino a quando quasi tutto era UEFI comunque.

Presumo che (SMM) sia utilizzato per le porte I / O VGA per l'impostazione della modalità.

Suppongo di no. L'unica cosa vagamente correlata al video per il quale sospetto che SMM possa essere utilizzata è il controllo della luminosità della retroilluminazione dello schermo nei laptop (soprattutto per i laptop più vecchi, e in particolare per "eventi di apertura / chiusura del coperchio") durante l'avvio anticipato (prima del sistema operativo prende il sopravvento).

.. tralasciando il supporto HW per la modalità testo sembra qualcosa che i venditori potrebbero voler fare

Credo ancora che la (eventuale, dopo la troppo lunga fase di transizione "ibrida BIOS + UEFI") di oltre 30 anni di pasticcio accumulato legacy (A20, VGA, PS / 2, PIT, PIC, ...) dall'hardware è uno dei motivi principali per cui i produttori di hardware (Intel) stanno spingendo per l'adozione UEFI.

Leggendo i vari moderni fogli dati Intel CPU e Platform Controller Hub (PCH), non sembra che l'hardware necessario sia implementato. Non sembra esserci alcun modo per generare un SMI (System Management Interrupt) in risposta agli accessi del processore del frame buffer VGA (indirizzi fisici 0xA0000 - 0xBFFFF).

Il controller di memoria nella CPU indirizzerà gli accessi al buffer del frame VGA al controller grafico integrato, alla porta PCI Express collegata direttamente alla CPU o all'interfaccia DMI che collega la CPU al PCH. Sebbene sia possibile instradare separatamente il buffer del frame VGA separatamente, questo sembra solo per supportare un dispositivo MDA (Monochrome Display Adapter) separato. Il controller grafico integrato non è ben documentato, quindi è possibile che possa essere configurato per generare una SMI sugli accessi al frame buffer VGA, ma questo sembra improbabile. In ogni caso, non funzionerebbe con una grafica discreta.

Anche gli Intel PCH non sembrano avere alcun supporto per la generazione di SMI in risposta agli accessi al frame buffer VGA. Questo sarebbe il posto più naturale per esso, poiché ha già il supporto per la generazione di SMI in risposta agli accessi I / O al controller della tastiera, al controller IDE e ad altri dispositivi legacy. È possibile che ci sia qualche caratteristica non documentata che lo fa, ma non è incluso negli elenchi delle possibili fonti SMI fornite nei fogli dati PCH.

In teoria, sarebbe possibile per un produttore di schede madri collegare un dispositivo VGA falso al PCH attraverso una porta PCI Express e quindi generare SMI utilizzando un pin GPIO PCH. Tuttavia, non sono sicuro che funzionerà in pratica. Quando la CPU riceve l'SMI, potrebbe essere passata all'esecuzione di altre istruzioni e non sarebbe possibile esaminare lo stato della CPU al momento dell'accesso al frame buffer.

(Un problema simile si è verificato con l'emulazione SoundBlaster 16 su SoundBlaster Live. Genererebbe un PCI SERR # quando si accedeva alle porte SoundBlaster legacy, generando un NMI sulla CPU. Sfortunatamente l'emulazione si sarebbe interrotta su molte schede madri Pentium 4 perché L'NMI sarebbe arrivato all'istruzione successiva o successiva.)