Co tak naprawdę dzieje się na nowoczesnym sprzęcie komputerowym uruchomionym w 16-bitowym starszym trybie BIOS MBR, gdy zapisujesz bajt taki jak '1'(0x31) w buforze ramki tekstu VGA (tryb 03) pod fizycznym adresem liniowym B8000? Jak wolno mov [es:di], eaxsklep z MTRR dla tego regionu jest ustawiony na UC? ( Testy eksperymentalne na jednym laptopie Kaby Lake iGPU wskazują, że clflushopt na WC miał mniej więcej taką samą prędkość jak UC dla pamięci VGA. Ale bez clflushopt, movprzechowywanie w pamięci WC nigdy nie opuszcza procesora i nie aktualizuje ekranu w ogóle, działa bardzo szybko .)

Jeśli nie jest to SMI dla każdego sklepu, czy jest jakiś sposób na przybliżenie tego kosztu w części pamięci WB w przestrzeni użytkownika, do eksperymentów wydajnościowych bez ponownego uruchamiania w trybie rzeczywistym? (np. użycie strony BSS jako udawanego bufora ramki, który tak naprawdę nigdzie się nie wyświetla).

Odpowiedni glif czcionki pojawia się na ekranie przy następnym odświeżeniu, ale czy sprzętowe skanowanie naprawdę czyta ten znak ASCII z VRAM (lub DRAM dla iGPU) i mapuje na glify czcionek bitmapowych w locie? Czy jest jakiś program przechwytujący oprogramowanie w każdym sklepie lub raz na vblank, więc prawdziwy sprzęt musi obsługiwać tylko bufor bitmapowy?

Starsze uruchamianie systemu BIOS jest dobrze znane z używania trybu zarządzania systemem (SMM) do emulacji USB kbd / myszy jako urządzeń PS / 2. Zastanawiam się, czy jest on również używany w buforze ramek w trybie tekstowym VGA. Zakładam, że jest używany do portów we / wy VGA do ustawiania trybu, ale prawdopodobne jest, że bufor ramek tekstowych mógłby być obsługiwany przez sprzęt. Jednak większość komputerów spędza cały czas w trybie graficznym, więc pominięcie obsługi HW dla trybu tekstowego wydaje się być czymś, co producenci mogą chcieć zrobić. (OTOH ten blog sugeruje, że kontroler VGA homebrew verilog może w prosty sposób zaimplementować tryb tekstowy.)

Szczególnie interesują mnie systemy wykorzystujące iGPU w Intel Skylake, ale interesują mnie wcześniejsze i późniejsze iGPU Intela i AMD oraz nowe lub stare dyskretne GPU.

(W tym dostawcy inni niż AMD i NVidia; istnieją płyty główne Skylake ze gniazdami PCI, a nie PCIe. Jeśli współczesne sterowniki oprogramowania układowego GPU emulują tryb tekstowy, prawdopodobnie istnieją pewne stare karty graficzne PCI ze sprzętowym trybem tekstowym VGA. A może taka karta może sprawić, że sklepy będą tylko transakcją PCI zamiast SMI.)

Mój własny pulpit to i7-6700k w Asus Z170 Pro Gaming mobo, bez dodatkowych kart, tylko iGPU z monitorem 1920x1200 na wyjściu DVI-D. Nie znam szczegółów systemu Kaby Lake i5-7300HQ @Eldan testuje, tylko model procesora.

Znalazłem patent Phoenix BIOS US20120159520 z 2011 r. , Emulowanie starszego wideo za pomocą interfejsu uefi . Zamiast wymagać od dostawców sprzętu wideo dostarczania zarówno opcji UEFI, jak i natywnych 16-bitowych sterowników opcji ROM w trybie rzeczywistym, proponują sterownik VGA w trybie rzeczywistym ( int 10hfunkcje itp.), Który wywołuje dostarczony przez dostawcę sterownik wideo UEFI za pośrednictwem haków SMM.

Streszczenie
[...] Ogólny ROM opcji wideo powiadamia ogólny sterownik SMM wideo o żądaniu usług wideo. Takie powiadomienie może być wykonane przy użyciu przerwania zarządzania systemem oprogramowania (SMI). Po powiadomieniu ogólny sterownik SMM wideo powiadamia sterownik wideo UEFI innej firmy o żądaniu usług wideo. Zewnętrzny sterownik wideo zapewnia żądane usługi wideo dla systemu operacyjnego. W ten sposób sterownik grafiki UEFI innej firmy może obsługiwać wiele różnych systemów operacyjnych, nawet tych, które nie obsługują natywnie protokołów wyświetlania UEFI.

Znaczna część opisu obejmuje obsługę int 10hwywołań i tego typu rzeczy, które już wyraźnie przechwytują IVT, dzięki czemu można łatwo uruchomić niestandardowy kod, który celowo uruchamia SMI. Istotną częścią jest to, co opisują dla bezpośrednich sklepów w buforze ramek w trybie tekstowym, które muszą działać nawet w przypadku kodu, który nie wyzwala żadnego przerwania programowego ani sprzętowego. (Inne niż HW wyzwalające SMI w takich sklepach, które, jak twierdzą, mogą używać, jeśli są obsługiwane).

Obsługa bufora tekstowego

[0066] W niektórych przykładach wykonania aplikacje mogą bezpośrednio manipulować buforem tekstowym VGA . W takim przykładzie wykonania ogólny sterownik SMM wideo 130 obsługuje to na jeden z dwóch sposobów, w zależności od tego, czy sprzęt zapewnia pułapkę SMI przy dostępie do odczytu / zapisu w obszarze pamięci 740 KB-768 KB (gdzie znajdują się bufory tekstowe).

[0067] Gdy pułapka SMI jest dostępna, sprzęt generuje SMI przy każdym dostępie do odczytu lub zapisu. Korzystając z adresu pułapki pułapki SMI, można obliczyć dokładną kolumnę i wiersz tekstowy oraz uzyskać dostęp do odpowiedniego wiersza i kolumny na wirtualnym ekranie tekstowym.

Alternatywnie, normalna pamięć jest włączona dla tego regionu i, używając okresowego SMI, ogólny sterownik SMM wideo 130 skanuje w poszukiwaniu zmian w emulowanym sprzętowym buforze tekstowym i aktualizuje odpowiedni wirtualny ekran tekstowy obsługiwany przez sterownik wideo. W obu przypadkach po wykryciu zmiany znak jest przerysowywany na wirtualnym ekranie tekstowym.

To tylko patent jednego producenta BIOS-u i nie mówi nam, w jaki sposób działa większość sprzętu, ani czy inni dostawcy robią różne rzeczy. Zasadniczo potwierdza to, że istnieje jakiś sprzęt, który może pułapki na sklepy w tym zakresie. (Chyba że jest to tylko hipotetyczna możliwość, którą postanowili objąć patentem).

Jeśli chodzi o przypadek użycia, który mam na myśli, przechwytywanie tylko podczas odświeżania ekranu byłoby znacznie szybsze niż wychwytywanie w każdym sklepie, więc jestem ciekawy, który sprzęt / oprogramowanie układowe działa w jaki sposób.

Motywacja do tego pytania

Optymalizacja inkrementującego licznika dziesiętnego ASCII w pamięci RAM wideo w Intel Core 7. generacji - wielokrotne zapisywanie nowych cyfr licznika tekstu ASCII w tych samych kilku bajtach pamięci RAM wideo.

Przetestowałem wersję kodu w 32-bitowej przestrzeni użytkownika pod Linuksem, w pamięci WB, mając nadzieję na przybliżenie sytuacji movntii różne sposoby zmuszenia procesora do synchronizacji bufora WC z RAM wideo po każdym sklepie (a może czasami w przerwanie timera). Nie jest to jednak realistyczne, jeśli sytuacja w trybie bootowania w trybie rzeczywistym nie polega tylko na przechowywaniu w pamięci DRAM, ale zamiast tego powoduje uruchomienie SMI.

W pamięci WB opróżnianie movntisklepów za pomocą a lock xor byte [esp], 0jest nieco szybsze niż opróżnianie za pomocą clflushopt. Ale @Eldan zgłasza brak poprawy prędkości dla osób korzystających z pamięci VGA po zaprogramowaniu MTRR w celu uzyskania WC. (I ta sama prędkość, co w przypadku oryginalnych sklepów normalnych, co wskazuje, że domyślnie buforem ramki VGA był UC. Niektóre starsze BIOS-y miały opcję utworzenia WC pamięci VGA , którą nazwali USWC = Uncached Speculative Write Combination.)

To nie jest problem w świecie rzeczywistym, więc nie szukam rzeczywistych obejść ; chociaż byłoby interesujące wiedzieć, czy ręczne przechowywanie bajtów pikseli w trybie graficznym VGA mogłoby być znacznie szybsze.

Podsumowanie

1. Czy jakieś / wszystkie naprawdę nowoczesne systemy wyzwalają SMI w każdym sklepie do bufora ramki tekstowej?
2. Jeśli nie, czy możemy zbliżyć sklep WC + kliknięcie bufora ramki za pomocą movnti + czegoś w przestrzeni użytkownika w pamięci WB? Możemy więc łatwo profilować perfza pomocą liczników wydajności.
3. Jeśli różne BIOS-y i / lub sprzęt używają różnych strategii, jakie są te strategie? (Nie chcę szczegółów, tylko wysoki poziom, taki jak: „SMI co vblank do synchronizacji bufora ramki VGA z rzeczywistym buforowaniem ramki sprzętowej”)
4. Czy karta graficzna PCIe lub PCI ze sprzętowym trybem tekstowym VGA byłaby szybsza niż cokolwiek, co faktycznie robią zintegrowane karty graficzne? Zgaduję, że faktyczna transakcja zapisu PCIe byłaby wolniejsza niż oczekiwanie na trafienie pamięci DRAM do sklepu, ale zapis PCIe byłby tańszy niż SMI w każdym sklepie. Interesujące byłoby porównanie ballpark / rzędu wielkości.

Wszystkie te pytania są ze sobą ściśle powiązane, ale mogę to rozdzielić, jeśli nie nakładam się tak bardzo, jak się spodziewam.

Czy jakieś / wszystkie naprawdę nowoczesne systemy wyzwalają SMI w każdym sklepie do bufora ramki tekstowej?

W przypadku kart graficznych bardzo w to wątpię. Producenci kart graficznych mają wbudowaną w sprzęt logikę „pobierz dane pikselowe z atrybutu char +” od lat 80. (poprzedza VGA i niewiele się zmieniło od CGA), i po prostu wytnij i wklej tę logikę do każdego nowszego projektu, nie przejmując się tym zbytnio .

W przypadku rzeczy, które w ogóle nie są kartami graficznymi (np. Narzędzia do zdalnego zarządzania systemem za pomocą sieci LAN), nie wiem, ale nie podejrzewam (często używają specjalnego procesora zarządzania zamiast głównych procesorów, aby działał, nawet jeśli komputer jest wyłączony").

Jeśli nie, czy możemy zbliżyć sklep WC + kliknięcie bufora ramki za pomocą movnti + czegoś w przestrzeni użytkownika w pamięci WB?

Jeśli nie jesteś w przestrzeni użytkownika, możesz zmienić MTTR (na wszystkich procesorach - MTRR muszą się zgadzać i wymagana jest specjalna sekwencja), aby obszar pamięci RAM był „niebuforowany”; lub użyj PAT w tabelach stron (o wiele łatwiejsze niż branie w MTRR, szczególnie jeśli i tak używasz stronicowania, ale nieco inne zachowanie z powodu wciąż potrzebnej spójności pamięci podręcznej). Jeśli jesteś w przestrzeni użytkownika, będziesz musiał polegać na tym, co zapewnia system operacyjny / jądro, i (w zależności od systemu operacyjnego) system operacyjny / jądro może w ogóle nie zapewnić takiego sposobu.

Jednak; nawet jeśli znajdziesz sposób na to, aby pamięć RAM (obszar) nie była buforowana, nadal nie będzie bardzo podobna, ponieważ będziesz pisać bezpośrednio do czegoś podłączonego do kontrolera pamięci wbudowanego w procesor (ten procesor może zapisywać bardzo szybko ) zamiast rozmawiać z czymś na drugim końcu łącza PCI (które będzie miało większe opóźnienia i mniejszą przepustowość ze strony procesora). Nawet w przypadku zintegrowanego wideo (gdzie technicznie to te same układy pamięci RAM na końcu) zapisuje do VRAM, przechodząc bardzo inną ścieżkę (z zastrzeżeniem zmiany mapowania / GART / stronicowania na karcie graficznej, realizowanej przez rejestr VGA w „trybie zapisu”, realizowany przez rejestry VGA maski bitowej / płaszczyzny itp.).

Czy karta graficzna PCIe lub PCI ze sprzętowym trybem tekstowym VGA byłaby szybsza niż cokolwiek, co faktycznie robią zintegrowane karty graficzne?

Do zapisu z CPU do VRAM; zazwyczaj zintegrowane wideo jest znacznie szybsze niż karty dyskretne (przynajmniej w przypadku zwykłego zapisu z procesora do buforów klatek liniowych, w których nie występuje żadna „logika zapisu” VGA).

Dla bardzo przybliżonych szacunków typu ballpark; Spodziewałbym się, że pojedynczy zapis do pamięci RAM wyniesie około 150 cykli, a pojedynczy zapis do PCI będzie prawie 1000 cykli. W przypadku SMI oczekiwałbym kilkuset cykli opóźnień, zanim SMI dotrze do procesora, następnie koszt opróżnienia potoku procesora, a następnie około 500 cykli, aby zapisać stan procesora (i ten sam stan ładowania na ścieżce powrotnej); wtedy kod oprogramowania układowego musiałby znaleźć przyczynę SMI (kolejne kilkaset cykli?), zanim dowie się, że to zapis do VRAM, a nie coś innego; wtedy musiałby zbadać zapisany stan procesora oraz znaleźć i zdekodować instrukcję, która dokonała zapisu (ponieważ nie może wiedzieć, jakie dane były zapisywane, jeśli był to zapis bajtowy / słowny / dwordowy itp.) podczas wzięcia pod uwagę konto poprzedni stan procesora (w jakim trybie był procesor, rozmiar kodu,XADDitp.). Następnie musiałby przeanalizować stan (emulowanych) rejestrów VGA (tryb zapisu, maska ​​zapisu, zezwolenie na płaszczyznę, cokolwiek kontroluje, który bank 64 KiB jest mapowany w starszym obszarze, wysokość czcionki, ...). Gruntownie; do emulacji SMI bufora ramki zapisu w trybie tekstowym; Spodziewałbym się, że zajmie to dziesiątki tysięcy cykli, zanim kod oprogramowania przeoczy niewielki, ale ważny szczegół ukryty w ogromnym stopniu złożoności, powodując, że robi coś złego i jest niepoprawnie uszkodzony.

Inne notatki

Znalazłem patent Phoenix BIOS US20120159520 z 2011 r., Emulowanie starszego wideo za pomocą interfejsu uefi.

Wątpię, czy kiedykolwiek to wdrożono, ponieważ wątpię, czy kiedykolwiek się uda. Jest o wiele za dużo (powszechnych i niejasnych) rzeczy, które można zrobić przy użyciu starszych interfejsów (np. Wykrywanie odświeżania w pionie, konfigurowanie niestandardowych trybów wideo, takich jak „tryb X”, skrzypce z „uruchamianiem ekranu” w celu wdrożenia płynnego przewijania i / lub przewracania strony , użyj „informacji CRTC” w VBE, aby zmienić czasy wideo itp.), które nie są obsługiwane przez UEFI i nie można tego zrobić za pośrednictwem. sterownik wideo innej firmy dla UEFI.

Zamiast tego producenci kart graficznych nie zadali sobie trudu dostarczenia sterowników UEFI przez około 10 lat, a oprogramowanie układowe UEFI korzystało ze starszego interfejsu do emulacji usług UEFI (często przerywając bezpieczny rozruch podczas ich działania); dopóki prawie wszystko nie było UEFI.

Zakładam, że (SMM) jest używany do portów VGA I / O do ustawiania trybu.

Zakładam, że nie. Jedyną rzeczą niejasno związaną z wideo, do której, jak podejrzewam, może być wykorzystywany SMM, jest kontrolowanie jasności podświetlenia ekranu w laptopach (szczególnie w przypadku starszych laptopów, a zwłaszcza „zdarzeń otwierania / zamykania pokrywy”) podczas wczesnego uruchamiania (przed systemem operacyjnym) przejmuje).

.. pominięcie obsługi HW dla trybu tekstowego wydaje się być czymś, co producenci mogą chcieć zrobić

Nadal uważam, że (ewentualne, po już zbyt długiej fazie przejściowej „hybrydowy BIOS + UEFI”) usunięcie ponad 30 lat nagromadzonego starszego bałaganu (A20, VGA, PS / 2, PIT, PIC, ...) ze sprzętu jest jednym z głównych powodów, dla których producenci sprzętu (Intel) naciskają na przyjęcie UEFI.

Czytając różne współczesne arkusze danych Intel CPU i Platform Controller Hub (PCH), nie wydaje się, aby niezbędny sprzęt został zaimplementowany. Wydaje się, że nie ma żadnego sposobu na wygenerowanie SMI (przerwanie zarządzania systemem) w odpowiedzi na dostęp procesora do bufora ramki VGA (adresy fizyczne 0xA0000 - 0xBFFFF).

Kontroler pamięci w CPU będzie albo kierował dostęp do bufora ramki VGA do zintegrowanego kontrolera grafiki, portu PCI Express podłączonego bezpośrednio do CPU, lub interfejsu DMI łączącego CPU z PCH. Chociaż możliwe jest oddzielne kierowanie części bufora ramki VGA, wydaje się, że służy ono jedynie do obsługi oddzielnego urządzenia MDA (Monochrome Display Adapter). Zintegrowany kontroler grafiki nie jest dobrze udokumentowany, więc możliwe jest, że można go skonfigurować do generowania SMI na dostępie do bufora ramki VGA, ale wydaje się to mało prawdopodobne. W każdym razie nie działałoby to z dyskretną grafiką.

Wydaje się również, że Intel PCH nie obsługuje generowania SMI w odpowiedzi na dostęp do bufora ramki VGA. Byłoby to najbardziej naturalne miejsce, ponieważ ma już obsługę generowania SMI w odpowiedzi na dostęp do I / O do kontrolera klawiatury, kontrolera IDE i innych starszych urządzeń. Możliwe, że jest taka nieudokumentowana funkcja, która to robi, ale nie znajduje się ona na listach możliwych źródeł SMI podanych w arkuszach danych PCH.

Teoretycznie producent płyty głównej mógłby podłączyć fałszywe urządzenie VGA do PCH przez port PCI Express, a następnie wygenerować SMI przy użyciu pinu PCH GPIO. Nie jestem jednak pewien, czy to zadziała w praktyce. Zanim procesor otrzyma SMI, mógł przejść do wykonywania innych instrukcji i nie byłoby możliwe sprawdzenie stanu procesora w czasie dostępu do bufora ramki.

(Podobny problem wystąpił w przypadku emulacji SoundBlaster 16. w SoundBlaster Live. Generowałby PCI SERR # po uzyskaniu dostępu do starszych portów SoundBlaster, co generowałoby NMI w procesorze. Niestety emulacja zerwałaby na wielu płytach głównych Pentium 4, ponieważ NMI przyjedzie na następną lub kolejną instrukcję).