Fiziksel doğrusal adresteki VGA metin (mod 03) çerçeve arabelleğine (0x31) gibi bir bayt depoladığınızda 16 bit eski BIOS MBR modunda önyüklenen modern PC donanımında gerçekten ne olur ? Bu bölge için MTRR olan bir mağaza UC'ye ne kadar yavaş ayarlanmış? ( Deneysel bir Kaby Gölü iGPU dizüstü test WC o clflushopt VGA bellek için UC kabaca aynı hızda olduğunu gösteriyor. Ama clflushopt olmadan, WC belleğine kaydeder süper hızlı koşma, CPU asla terk ve hiç ekranı güncelleme yok .)'1'B8000mov [es:di], eaxmov

Her mağaza için bir SMI değilse, gerçek modda yeniden başlatılmadan performans deneyleri için, kullanıcı alanındaki WB bellek yığınındaki bu maliyeti yaklaşık olarak tahmin etmenin bir yolu var mı? (örneğin, gerçekte hiçbir yerde görüntülenmeyen bir BSS sayfasını taklit çerçeve tamponu olarak kullanma).

İlgili yazı tipi glifi bir sonraki yenilemede ekranda görünür, ancak donanım taraması gerçekten VRAM'den (veya bir iGPU için DRAM'den) ASCII karakterini okuyor ve anında bitmap yazı tipi glifleriyle eşleştiriyor mu? Ya da her mağazada veya vblank başına bir kez yazılım müdahalesi var, bu yüzden gerçek donanım sadece bit eşlemli bir çerçeve arabelleğini işlemek zorunda mı?

Eski BIOS önyüklemesinin USB kbd / fareyi PS / 2 cihazları olarak taklit etmek için Sistem Yönetim Modu'nu (SMM) kullandığı bilinmektedir . VGA metin modu çerçeve arabelleği için de kullanılıp kullanılmadığını merak ediyorum. Mod ayarı için VGA I / O portları için kullanıldığını varsayıyorum , ancak bir metin çerçevesinin donanım tarafından desteklenebileceği akla yatkın. Ancak, çoğu bilgisayar tüm zamanlarını grafik modunda geçirir, bu nedenle metin modu için HW desteğini bırakmak satıcıların yapmak isteyebileceği bir şey gibi görünür. (OTOH bu blog , bir homebrew verilog VGA denetleyicisinin metin modunu oldukça basit bir şekilde uygulayabileceğini önermektedir.)

Özellikle Intel Skylake'te iGPU kullanan sistemlerle ilgileniyorum, ancak Intel ve AMD'nin önceki / sonraki iGPU'ları ve yeni veya eski ayrık GPU'lar ile ilgileniyorum.

(AMD ve NVidia dışındaki satıcılar dahil; PCIe değil, PCI yuvalarına sahip bazı Skylake anakartlar vardır. Modern GPU ürün yazılımı sürücüleri metin modunu taklit ederse, muhtemelen donanım VGA metin moduna sahip bazı eski PCI ekran kartları vardır. mağazaların bir SMI yerine bir PCI işlemi olmasını sağlayabilir.)

Kendi masaüstüm Asus Z170 Pro Gaming mobo'da bir i7-6700k, eklenti kartı yok sadece DVI-D çıkışında 1920x1200 monitörlü iGPU. @Edan'ın test ettiği Kaby Lake i5-7300HQ sisteminin detaylarını bilmiyorum, sadece CPU modeli.

Buldum Phoenix BIOS en patent US20120159520 2011 yılından , UEFI kullanarak eski videoyu öykünen . Bunun yerine UEFI'yi hem tedarik Video donanım satıcıları gerektiren bir ve yerli 16-bit gerçek mod seçeneği-ROM sürücüleri, bunlar gerçek mod VGA sürücüsünü (teklif int 10hSMM kancalar vasıtasıyla bir satıcı tarafından sağlanan UEFI video sürücüsünü çağırır fonksiyonları ve benzeri).

Özet
[...] Genel video seçeneği ROM, genel bir video SMM sürücüsüne video hizmetleri talebini bildirir. Bu bildirim, bir yazılım sistemi yönetim kesmesi (SMI) kullanılarak gerçekleştirilebilir. Bildirim üzerine, genel video SMM sürücüsü üçüncü taraf bir UEFI video sürücüsüne video hizmetleri talebini bildirir. Üçüncü taraf video sürücüsü, işletim sistemine istenen video hizmetlerini sağlar. Bu şekilde, üçüncü taraf bir UEFI grafik sürücüsü, UEFI ekran protokollerini yerel olarak desteklemeyenler de dahil olmak üzere çok çeşitli işletim sistemlerini destekleyebilir.

Açıklamanın çoğu, int 10hçağrıları ve IVT aracılığıyla zaten açık bir şekilde yakalanan şeyleri ele alır , böylece bir SMI'yi tetikleyen özel kodu kolayca çalıştırabilir. İlgili bölüm, herhangi bir yazılım veya donanım kesintisini tetiklemeyen kodlar için bile çalışması gereken metin modu çerçeve arabelleğine doğrudan mağazalar için tanımladıkları şeydir. (Bu tür mağazalarda SMI'yi tetikleyen HW dışında, desteklendiklerinde kullanabileceklerini söylüyorlar.)

Metin Arabellek Desteği

Bazı düzeneklerde uygulamalar, VGA'nın metin tamponunu doğrudan manipüle edebilir . Böyle bir düzenlemede, jenerik video SMM sürücüsü 130 , donanımın 740 KB-768 KB bellek bölgesine (metin arabelleklerinin bulunduğu yer) okuma / yazma erişiminde SMI yakalama sağlayıp sağlamadığına bağlı olarak bunu iki yoldan biriyle destekler .

SMI yakalama mevcut olduğunda, donanım her okuma veya yazma erişiminde bir SMI oluşturur. SMI tuzağının tuzak adresi kullanılarak, tam metin sütunu ve satırı hesaplanabilir ve sanal metin ekranındaki ilgili satır ve sütuna erişilebilir.

Alternatif olarak, bu bölge için normal bellek etkinleştirilir ve periyodik bir SMI kullanılarak, jenerik video SMM sürücüsü 130 taklit edilmiş donanım metin arabelleğindeki değişiklikleri tarar ve video sürücüsü tarafından tutulan ilgili sanal metin ekranını günceller. Her iki durumda da, bir değişiklik algılandığında, karakter sanal metin ekranında yeniden çizilir.

Bu sadece bir BIOS satıcısının patentidir ve bize çoğu donanımın gerçekte hangi şekilde çalıştığını veya diğer satıcıların farklı şeyler yapıp yapmadığını söylemez. Yine de , bu aralıktaki mağazalarda sıkışabilecek bazı donanımların var olduğunu doğrular. (Bu, patentlerinde ele almaya karar verdikleri varsayımsal bir olasılık olmadığı sürece.)

Aklımda kullandığım kullanım için, sadece ekran yenilemede bindirme her mağazada bindirmekten çok daha hızlı olacaktır, bu yüzden hangi donanımın / ürün yazılımının hangi şekilde çalıştığını merak ediyorum.

Bu soru için motivasyon

7. nesil Intel Core'da video RAM'de artan bir ASCII ondalık sayacını optimize etme - bir ASCII metin sayacı için yeni basamakları aynı birkaç bayt video RAM'e tekrar tekrar kaydetme.

Kodun bir sürümünü Linux altında 32 bit kullanıcı alanında, WB bellekte, duruma yaklaşık olarak yaklaşmayı movntive CPU'nun WC arabelleğini her mağazadan sonra (veya belki de zaman zaman bir zamanlayıcı kesmesi). Ancak, gerçek mod önyükleyici durumu sadece DRAM'a depolamak değil, bunun yerine bir SMI'yi tetikliyorsa bu gerçekçi değildir.

WB bellekte, movntia ile depoları yıkamak, yıkamaktan lock xor byte [esp], 0biraz daha hızlıdır clflushopt. Ancak @Eldan, bir MTRR'yi WC yapmak için programladıktan sonra VGA belleğinde olanlar için hız artışı olmadığını bildiriyor. (Ve normal mağazalar yapan orijinalin hızıyla aynıdır, bu da varsayılan olarak VGA çerçeve arabelleğinin UC olduğunu gösterir. Bazı eski BIOS'larda , USWC = Unchached Spekülatif Yazma Kombinasyonu olarak adlandırdıkları VGA belleği WC yapma seçeneği vardı .)

Gerçek bir sorun değil, bu yüzden gerçek çözümler aramıyorum ; piksel baytlarını bir VGA grafik moduna manuel olarak kaydetmenin çok daha hızlı olabileceğini bilmek ilginç olurdu.

özet

1. Herhangi bir / tüm gerçek modern sistemler, her mağazada metin modu çerçeve arabelleğine bir SMI tetikliyor mu?
2. Hayır ise, WB belleğindeki kullanıcı boşluğunda movnti + bir şey kullanarak çerçeve ara belleğine bir WC deposu + clflush'a yaklaşabilir miyiz? Böylece perfperformans sayaçları için kolayca profil oluşturabiliriz .
3. Farklı BIOS'lar ve / veya donanımlar farklı stratejiler kullanıyorsa, bu stratejiler nelerdir? (Ayrıntıları istemiyorum, sadece "SMI her vblank gibi VGA çerçeve tamponunu gerçek donanım çerçeve tamponuyla senkronize etmek" gibi yüksek bir seviye)
4. Donanım VGA metin modlu bir PCIe veya PCI ekran kartı, entegre GPU'lardan daha hızlı mıdır? Gerçek bir PCIe yazma işleminin bir mağazanın DRAM'a ulaşmasını beklemekten daha yavaş olacağını düşünüyorum, ancak PCIe yazma işlemi her mağazadaki bir SMI'dan daha ucuz olurdu. Bir basketbol sahası / büyüklük karşılaştırması ilginç olurdu.

Bu soruların hepsi oldukça alakalı, ancak beklediğim kadar fazla çakışma yoksa bunu bölebilirim.

Herhangi bir / tüm gerçek modern sistemler, her mağazada metin modu çerçeve arabelleğine bir SMI tetikliyor mu?

Ekran kartları için bundan çok şüpheliyim. Ekran kartı üreticileri 1980'lerden beri donanıma "char + niteliğinden piksel verileri al" mantığını taktılar (VGA'dan önce ve CGA'dan beri çok değişmedi) ve sadece bu mantığı çok fazla önemsemeden her yeni tasarıma kesip yapıştırın .

Hiç video kartı olmayan şeyler için (örneğin LAN kullanan uzaktan sistem yönetim araçları) Bilmiyorum ama şüphelenmiyorum (genellikle ana CPU / lar yerine özel bir yönetim CPU'su kullanıyorlar, böylece bilgisayar bile çalışıyor kapalı").

Hayır ise, WB belleğindeki kullanıcı boşluğunda movnti + bir şey kullanarak çerçeve ara belleğine bir WC deposu + clflush'a yaklaşabilir miyiz?

Kullanıcı alanında değilseniz, RAM alanını "önbelleğe alınmamış" hale getirmek için MTTR'leri değiştirebilirsiniz (tüm CPU'larda - MTRR'ler eşleşmelidir ve özel bir sıra vardır); veya sayfa tablolarında PAT kullanın (özellikle zaten disk belleği kullanıyorsanız, önbellek tutarlılığına ihtiyaç duyduğunuzdan biraz farklı davranışlar varsa, MTRR'lerle uğraşmaktan çok daha kolay). Kullanıcı alanındaysanız, OS / çekirdeğin sağladığı her şeye güvenmeniz gerekir ve (hangi işletim sistemine bağlı olduğuna bağlı olarak) OS / çekirdek bunu yapmak için herhangi bir yol sağlayamayabilir.

Ancak; RAM'i önbelleğe almanın bir yolunu bulsanız bile, hala çok benzer olmayacaktır, çünkü doğrudan CPU'da yerleşik bir bellek denetleyicisine bağlı bir şeye yazacaksınız (bu CPU son derece hızlı bir şekilde yazabilir) ) PCI bağlantısının diğer ucundaki bir şeyle konuşmak yerine (CPU tarafından daha yüksek gecikme süresine ve daha düşük bant genişliğine sahip olacaktır). VRAM'a yazılan entegre video (teknik olarak aynı RAM yongalarının olduğu yerlerde) bile çok farklı bir yoldan geçer (video kartında yeniden yazma / GART / sayfalamaya tabi olarak, etkilenen "yazma modu" VGA kaydı bit / düzlem maskesi VGA kayıtları vb.).

Donanım VGA metin modlu bir PCIe veya PCI ekran kartı, entegre GPU'lardan daha hızlı mıdır?

CPU'dan VRAM'a yazma için; tipik olarak tümleşik video, ayrı kartlardan önemli ölçüde daha hızlıdır (en azından CPU'nun "yazma mantığının" hiçbirinin yer almadığı doğrusal çerçeve arabelleklerine düz yazma için).

Son derece kaba basketbol sahası tahminleri için; RAM'e tek bir yazma işleminin yaklaşık 150 döngü ve PCI'ya tek bir yazma işleminin 1000 döngüye yakın olmasını beklerdim. SMI için, SMI CPU'ya ulaşmadan önce birkaç yüz gecikme döngüsü, daha sonra CPU boru hattının durması, ardından CPU durumunu (ve dönüş yolundaki aynı yükleme durumunu) kurtarmak için yaklaşık 500 döngü beklerdim; donanım yazılımının kodu, başka bir şey değil VRAM'a bir yazma olduğunu bilmeden önce SMI'nin nedenini (birkaç yüz döngü daha?) bulmak zorunda kalacaktı; o zaman kaydedilen CPU durumunu incelemek ve yazma işlemini yapan talimatı bulmak ve deşifre etmek gerekir (çünkü hangi verinin yazıldığını bilmiyor, çünkü bir bayt / kelime / dword yazma vb.) önceki CPU durumunu hesapla (CPU'nun hangi modda olduğu, kod boyutu,XADD, vb). Daha sonra (taklit edilmiş) VGA kayıtlarının durumunu (yazma modu, yazma maskesi, düzlem etkinleştirme, hangi 64 KiB bankasının eski alana eşlendiğini kontrol eden, yazı tipi yüksekliği, ...) analiz etmesi gerekir. Temelde; metin modu çerçeve arabelleğine yazma SMI öykünmesi için; Ürün yazılımının kodu, büyük miktarda karmaşıklık arasında gömülü küçük ama önemli bir ayrıntıya bakmadan on binlerce döngü almasını beklerdim, bu da yanlış bir şey yapmasına ve olağandışı bir şekilde kırılmasına neden olur.

Diğer notlar

Uefi kullanarak Phoenix BIOS'un US20120159520 patentini 2011'den buldum.

Bunun uygulandığından şüpheliyim, çünkü çalışabileceğinden şüpheliyim. Eski arayüzlerle yapabileceğiniz çok fazla (yaygın ve belirsiz) şey var (örn. Dikey yenilemeyi algılama, "mod X" gibi standart olmayan video modlarını ayarlama, düzgün kaydırma ve / veya sayfa çevirme uygulamak için "ekran başlangıcı" ile keman , video zamanlamalarını vb. değiştirmek için VBE'deki "CRTC bilgileri" ni kullanın) ve UEFI tarafından desteklenmeyen ve yapılamayan. UEFI için üçüncü taraf bir video sürücüsü.

Bunun yerine, ekran kartı üreticileri yaklaşık 10 yıldır UEFI sürücüleri sağlamaya zahmet etmedi ve UEFI ürün yazılımı, UEFI hizmetlerini taklit etmek için eski arayüzü kullandı (genellikle bu sırada güvenli önyüklemeyi kırdı); Neredeyse her şey UEFI olana kadar.

Mod ayarı için VGA I / O portları için (SMM) kullanıldığını varsayıyorum.

Sanmıyorum. SMM'nin kullanılabileceğinden şüphelendiğim videoyla ilgili belirsiz olan tek şey, ekranın arka plan ışığının dizüstü bilgisayarlardaki parlaklığını kontrol etmektir (özellikle eski dizüstü bilgisayarlar için ve özellikle "kapak açma / kapama olayları" için) alır).

.. metin modu için HW desteğini dışarıda bırakmak satıcıların yapmak isteyebileceği bir şey gibi görünüyor

Hâlâ (zaten, çok uzun "hibrit BIOS + UEFI" geçiş aşamasından sonra) donanımdan 30 yıldan fazla birikmiş eski karışıklığın (A20, VGA, PS / 2, PIT, PIC, ...) kaldırıldığına inanıyorum. donanım üreticilerinin (Intel) UEFI'nin benimsenmesi için başlıca nedenlerinden biridir.

Çeşitli modern Intel CPU ve Platform Controller Hub (PCH) veri sayfalarını okurken, gerekli donanımın uygulandığı görünmüyor. VGA çerçeve arabelleğinin (fiziksel adresler 0xA0000 - 0xBFFFF) işlemci erişimine yanıt olarak bir SMI (Sistem Yönetimi Kesintisi) oluşturmanın bir yolu yok gibi görünüyor.

CPU'daki bellek denetleyicisi, VGA çerçeve arabelleğine erişimi entegre grafik denetleyicisine, doğrudan CPU'ya bağlı PCI Express bağlantı noktasına veya CPU'yu PCH'ye bağlayan DMI arabirimine yönlendirir. Parçaları VGA çerçeve arabelleğini ayrı ayrı yönlendirmek mümkün olsa da, bu sadece ayrı bir MDA (Monokrom Ekran Adaptörü) cihazını desteklemek içindir. Tümleşik grafik denetleyicisi iyi belgelenmemiştir, bu nedenle VGA çerçeve arabellek erişimlerinde bir SMI oluşturmak üzere yapılandırılabilmesi mümkündür, ancak bu olası görünmemektedir. Her durumda, ayrık grafiklerle çalışmaz.

Intel PCH'lerin VGA çerçeve arabellek erişimine yanıt olarak SMI oluşturma desteği de yok gibi görünüyor. Klavye denetleyicisine, IDE denetleyicisine ve diğer eski aygıtlara G / Ç erişimine yanıt olarak zaten SMI oluşturma desteği olduğu için burası en doğal yer olacaktır. Bunu yapan belgelenmemiş bir özellik olması mümkündür, ancak PCH veri sayfalarında verilen olası SMI kaynakları listesine dahil edilmemiştir.

Teorik olarak, bir anakart imalatının sahte bir VGA cihazını PCH'ye bir PCI Express portu üzerinden bağlaması ve ardından bir PCH GPIO pini kullanarak SMI üretmesi mümkün olacaktır. Ancak bunun uygulamada işe yarayacağından emin değilim. CPU SMI'ye ulaştığında, diğer talimatları uygulamaya geçebilirdi ve çerçeve arabelleği erişimi sırasında CPU durumunu incelemek mümkün olmazdı.

(SoundBlaster Live'daki SoundBlaster 16 emülasyonunda da benzer bir sorun yaşandı. Eski SoundBlaster portlarına erişildiğinde bir PCI SERR # üretecek ve bu da CPU'da bir NMI oluşturacaktı. Ne yazık ki emülasyon birçok Pentium 4 anakartta kırılacak NMI bir sonraki veya sonraki talimatlara ulaşacaktır.)