Apa yang sebenarnya terjadi pada perangkat keras PC modern yang di-boot dalam mode MBR BIOS warisan 16-bit ketika Anda menyimpan byte seperti '1'(0x31) ke dalam teks VGA (mode 03) framebuffer pada alamat linear fisik B8000? Seberapa lambat mov [es:di], eaxtoko dengan MTRR untuk wilayah itu disetel ke UC? ( Pengujian eksperimental pada satu laptop Kaby Lake iGPU menunjukkan bahwa clflushopt pada WC kira-kira sama kecepatannya dengan UC untuk memori VGA. Tetapi tanpa clflushopt, movtoko ke memori WC tidak pernah meninggalkan CPU dan tidak memperbarui layar sama sekali, berjalan sangat cepat .)

Jika itu bukan SMI untuk setiap toko, apakah ada cara untuk memperkirakan biaya ini pada sepotong memori WB di ruang pengguna, untuk percobaan kinerja tanpa benar-benar me-reboot ke mode nyata? (misalnya menggunakan halaman BSS sebagai framebuffer pura-pura yang tidak benar-benar ditampilkan di mana pun).

Mesin terbang font yang sesuai muncul di layar di refresh berikutnya, tetapi apakah pemindaian perangkat keras benar-benar membaca bahwa ASCII char dari VRAM (atau DRAM untuk iGPU) dan memetakan ke bitmap mesin terbang font dengan cepat? Atau ada beberapa intersepsi perangkat lunak di setiap toko atau sekali per vblank sehingga perangkat keras yang sebenarnya hanya perlu menangani framebuffer yang dipetakan?

Boot BIOS lama dikenal menggunakan System Management Mode (SMM) untuk meniru USB kbd / mouse sebagai perangkat PS / 2. Saya bertanya-tanya apakah itu juga digunakan untuk framebuffer mode teks VGA. Saya menganggap itu adalah digunakan untuk VGA port I / O untuk mode-setting tapi itu masuk akal bahwa framebuffer teks dapat didukung oleh perangkat keras. Namun, sebagian besar komputer menghabiskan seluruh waktu mereka dalam mode grafis sehingga meninggalkan dukungan HW untuk mode teks sepertinya sesuatu yang mungkin ingin dilakukan vendor. (OTOH blog ini menunjukkan bahwa pengontrol VGA homebrew Verilog dapat mengimplementasikan mode teks dengan cukup sederhana.)

Saya secara khusus tertarik pada sistem yang menggunakan iGPU di Intel Skylake, tetapi akan tertarik pada iGPU awal / nanti dari Intel dan AMD, dan GPU diskrit baru atau lama.

(Termasuk vendor selain AMD dan NVidia; ada beberapa motherboard Skylake dengan slot PCI, bukan PCIe. Jika driver firmware GPU modern meniru mode teks, mungkin ada beberapa kartu video PCI lama dengan hardware VGA mode teks. Dan mungkin kartu semacam itu dapat membuat toko hanya menjadi transaksi PCI dan bukan SMI.)

Desktop saya sendiri adalah i7-6700k di mobo Asus Z170 Pro Gaming, tidak ada kartu tambahan hanya iGPU dengan monitor 1920x1200 pada output DVI-D. Saya tidak tahu detail sistem Kaby Lake i5-7300HQ yang sedang diuji pada @Eldan, hanya model CPU.

Saya menemukan paten Phoenix BIOS US20120159520 dari 2011 , Mengemulasi video lawas menggunakan uefi . Alih-alih meminta vendor perangkat keras video untuk memasok driver opsi-mode UEFI asli dan 16-bit asli, mereka mengusulkan driver VGA mode-nyata ( int 10hfungsi dan sebagainya) yang memanggil driver video UEFI yang disediakan vendor melalui kait SMM.

Abstrak
[...] ROM opsi video umum memberi tahu driver SMM video generik tentang permintaan layanan video. Pemberitahuan tersebut dapat dilakukan menggunakan interupsi manajemen sistem perangkat lunak (SMI). Setelah pemberitahuan, driver SMM video generik memberi tahu driver video UEFI pihak ketiga tentang permintaan layanan video. Driver video pihak ketiga menyediakan layanan video yang diminta ke sistem operasi. Dengan cara ini, driver grafis UEFI pihak ketiga dapat mendukung berbagai sistem operasi, bahkan yang tidak mendukung protokol tampilan UEFI.

Sebagian besar deskripsi mencakup penanganan int 10hpanggilan dan hal-hal seperti yang sudah jelas menjebak melalui IVT, sehingga dapat dengan mudah menjalankan kode khusus yang memicu SMI sengaja. Bagian yang relevan adalah apa yang mereka gambarkan untuk penyimpanan langsung ke framebuffer mode-teks yang perlu bekerja bahkan untuk kode yang tidak memicu gangguan perangkat lunak atau perangkat keras apa pun. (Selain HW memicu SMI di toko-toko tersebut, yang mereka katakan dapat mereka gunakan jika didukung.)

Dukungan Penyangga Teks

[0066] Dalam perwujudan tertentu, aplikasi dapat memanipulasi buffer teks VGA secara langsung . Dalam perwujudan seperti itu, driver SMM video generik 130 mendukung ini dalam salah satu dari dua cara, tergantung pada apakah perangkat keras tersebut menyediakan perangkap SMI pada akses baca / tulis ke wilayah memori 740 KB-768 KB (tempat buffer teks berada).

[0067] Ketika penjebak SMI tersedia, perangkat keras menghasilkan SMI pada setiap akses baca atau tulis. Menggunakan alamat jebakan dari perangkap SMI, kolom dan baris teks yang tepat dapat dihitung dan baris serta kolom yang sesuai di layar teks virtual diakses.

Secara bergantian, memori normal diaktifkan untuk wilayah ini dan, menggunakan SMI berkala, driver SMM video umum 130 memindai perubahan buffer teks perangkat keras yang diemulasi dan memperbarui layar teks virtual terkait yang dipelihara oleh driver video. Dalam kedua kasus, ketika perubahan terdeteksi, karakter digambar ulang di layar teks virtual.

Ini hanya satu paten vendor BIOS, dan tidak memberi tahu kami ke arah mana sebagian besar perangkat keras bekerja, atau jika vendor lain melakukan hal yang berbeda. Itu pada dasarnya mengkonfirmasi bahwa ada beberapa perangkat keras yang dapat menjebak di toko dalam kisaran itu, meskipun. (Kecuali kalau itu hanya kemungkinan hipotetis yang mereka putuskan untuk dicakup dalam paten mereka.)

Untuk kasus penggunaan yang ada dalam pikiran saya, menjebak hanya pada refresh layar akan jauh lebih cepat daripada menjebak di setiap toko jadi saya ingin tahu perangkat keras / firmware mana yang bekerja dengan cara itu.

Motivasi untuk pertanyaan ini

Mengoptimalkan penghitung desimal ASCII yang bertambah dalam RAM video pada gen ke-7 Intel Core - berulang kali menyimpan digit baru untuk penghitung teks ASCII ke dalam beberapa byte RAM video yang sama.

Saya menguji versi kode dalam ruang pengguna 32-bit di Linux, pada memori WB, berharap untuk memperkirakan situasi dengan movntidan berbagai cara untuk mendapatkan CPU untuk menyinkronkan buffer WC ke video RAM setelah setiap toko (atau mungkin kadang-kadang dalam pengatur waktu). Tapi ini tidak realistis jika situasi bootloader real-mode tidak hanya menyimpan ke DRAM, tetapi malah memicu SMI.

Pada memori WB, flushing movntistore dengan a lock xor byte [esp], 0agak lebih cepat daripada flushing with clflushopt. Tapi @Eldan melaporkan tidak ada peningkatan kecepatan bagi mereka yang menggunakan memori VGA setelah memprogram MTRR untuk membuatnya menjadi WC. (Dan kecepatan yang sama dengan aslinya melakukan toko normal, menunjukkan bahwa secara default VGA framebuffer adalah UC. Beberapa BIOS yang lebih tua memiliki pilihan untuk membuat WC memori VGA , yang mereka sebut USWC = Uncached Speculative Write Combining.)

Ini bukan masalah dunia nyata jadi saya tidak mencari solusi yang sebenarnya ; meskipun akan menarik untuk mengetahui apakah secara manual menyimpan byte pixel ke mode grafis VGA bisa lebih cepat.

Ringkasan

1. Apakah ada / semua sistem modern yang nyata memicu SMI di setiap toko ke framebuffer mode teks?
2. Jika tidak, dapatkah kita memperkirakan WC store + clflush ke framebuffer, menggunakan movnti + sesuatu di ruang pengguna pada memori WB? Jadi kita dapat dengan mudah membuat profilperf untuk penghitung kinerja.
3. Jika BIOS dan / atau perangkat keras yang berbeda menggunakan strategi yang berbeda, apa strategi itu? (Saya tidak ingin detail, hanya tingkat tinggi seperti "SMI setiap vblank untuk menyinkronkan framebuffer VGA ke framebuffer perangkat keras yang sebenarnya")
4. Apakah kartu video PCIe atau PCI dengan hardware VGA textmode akan lebih cepat daripada GPU terintegrasi apa pun sebenarnya? Saya menduga transaksi penulisan PCIe yang sebenarnya akan lebih lambat daripada menunggu toko untuk menekan DRAM, tetapi bahwa penulisan PCIe akan lebih murah daripada SMI di setiap toko. Rata-rata perbandingan besarnya akan menarik.

Semua pertanyaan ini sangat terkait, tetapi saya dapat membaginya jika tidak ada banyak tumpang tindih seperti yang saya harapkan.

Apakah ada / semua sistem modern yang nyata memicu SMI di setiap toko ke framebuffer mode teks?

Untuk kartu video, saya sangat meragukannya. Produsen kartu video telah memiliki logika "dapatkan data piksel dari atribut char +" ke dalam perangkat keras sejak 1980-an (sudah ada sebelum VGA dan tidak banyak berubah sejak CGA), dan cukup potong & tempel logika itu ke setiap desain yang lebih baru tanpa peduli banyak tentang hal itu .

Untuk hal-hal yang bukan kartu video sama sekali (mis. Alat manajemen sistem jarak jauh menggunakan LAN) Saya tidak tahu tetapi tidak curiga (seringkali mereka menggunakan CPU manajemen khusus daripada CPU / s sehingga berfungsi bahkan jika komputer matikan").

Jika tidak, dapatkah kita memperkirakan WC store + clflush ke framebuffer, menggunakan movnti + sesuatu di ruang pengguna pada memori WB?

Jika Anda tidak berada di ruang pengguna, Anda dapat mengubah MTTR (pada semua CPU - MTRR harus cocok dan ada urutan khusus yang terlibat) untuk membuat area RAM "tidak tersentuh"; atau gunakan PAT dalam tabel halaman (jauh lebih mudah daripada mengotak-atik MTRR, terutama jika Anda tetap menggunakan paging, tetapi perilaku yang sedikit berbeda karena masih membutuhkan koherensi cache). Jika Anda berada di ruang pengguna maka Anda harus mengandalkan apa pun yang disediakan oleh OS / kernel, dan (tergantung pada OS mana itu), OS / kernel mungkin tidak menyediakan cara apa pun untuk melakukan ini sama sekali.

Namun; bahkan jika Anda menemukan cara untuk membuat (bidang) RAM tidak terpecah, itu masih tidak akan sangat mirip, karena Anda akan menulis langsung ke sesuatu yang terpasang pada pengontrol memori yang terpasang ke dalam CPU (CPU yang dapat menulis dengan sangat cepat ) daripada berbicara dengan sesuatu di ujung lain dari tautan PCI (yang akan memiliki latensi lebih tinggi dan bandwidth yang lebih rendah dari sisi CPU). Bahkan untuk video terintegrasi (di mana secara teknis chip RAM yang sama pada akhirnya) menulis ke VRAM melalui jalur yang sangat berbeda (tergantung remapping / GART / paging dalam kartu video, dipengaruhi oleh register VGA "mode tulis", dipengaruhi oleh register VGA bit / plane mask, dll).

Apakah kartu video PCIe atau PCI dengan hardware VGA textmode akan lebih cepat daripada GPU terintegrasi apa pun sebenarnya?

Untuk menulis dari CPU ke VRAM; biasanya video terintegrasi secara signifikan lebih cepat daripada kartu diskrit (setidaknya untuk menulis sederhana dari CPU ke buffer bingkai linear di mana tidak ada "logika tulis" VGA yang terlibat).

Untuk perkiraan rata-rata kasarnya; Saya berharap satu tulis ke RAM menjadi sekitar 150 siklus dan satu tulisan ke PCI mendekati 1000 siklus. Untuk SMI, saya mengharapkan beberapa ratus siklus latensi sebelum SMI tiba di CPU, kemudian biaya flush pipeline CPU, kemudian sekitar 500 siklus untuk menghemat keadaan CPU (dan kondisi pemuatan yang sama di jalur pengembalian); maka kode firmware harus menemukan penyebab SMI (beberapa ratus siklus lainnya?) sebelum bisa tahu itu adalah menulis ke VRAM dan bukan sesuatu yang lain; maka ia harus memeriksa status CPU yang disimpan dan menemukan dan mendekode instruksi yang membuat penulisan (karena tidak dapat mengetahui data apa yang sedang ditulis, apakah itu byte / word / dword write, dll) ketika mempertimbangkan akun status CPU sebelumnya (mode CPU yang mana, ukuran kode,XADD, dll). Selanjutnya harus menganalisis keadaan (ditiru) register VGA (mode tulis, tulis topeng, aktifkan pesawat, kontrol apa pun yang 64 Bank KiB dipetakan ke area lawas, ketinggian font, ...). Pada dasarnya; untuk emulasi SMI dari buffer bingkai mode tulis ke teks; Saya berharap untuk mengambil puluhan ribu siklus sebelum kode firmware mengabaikan detail kecil tapi penting terkubur di antara sejumlah besar kompleksitas, menyebabkannya melakukan hal yang salah dan rusak luar biasa.

Catatan lain

Saya menemukan paten Phoenix BIOS US20120159520 dari 2011, Mengemulasi video lawas menggunakan uefi.

Saya ragu ini pernah diterapkan, karena saya ragu itu bisa berhasil. Ada terlalu banyak (umum dan tidak jelas) hal-hal yang dapat Anda lakukan dengan antarmuka lama (mis. Mendeteksi penyegaran vertikal, mengatur mode video non-standar seperti "mode X", bermain-main dengan "tampilan awal" untuk menerapkan pengguliran yang lancar dan / atau membalik halaman) , gunakan "Info CRTC" di VBE untuk mengubah timing video, dll) yang tidak didukung oleh UEFI dan tidak dapat dilakukan melalui. driver video pihak ketiga untuk UEFI.

Sebagai gantinya, produsen kartu video tidak repot-repot memberikan driver UEFI selama sekitar 10 tahun dan firmware UEFI menggunakan antarmuka lama untuk meniru layanan UEFI (sering kali merusak boot aman saat mereka berada di sana); sampai hampir semuanya UEFI.

Saya menganggapnya (SMM) digunakan untuk port I / O VGA untuk pengaturan mode.

Saya berasumsi tidak. Satu-satunya hal yang samar-samar terkait dengan video yang saya duga SMM dapat digunakan untuk mengontrol kecerahan lampu latar layar di laptop (terutama untuk laptop yang lebih tua, dan terutama untuk "tutup buka / tutup acara") selama boot awal (sebelum OS mengambil alih).

..meninggalkan dukungan HW untuk mode teks sepertinya sesuatu yang mungkin ingin dilakukan vendor

Saya masih percaya bahwa (akhirnya, setelah fase transisi "hybrid BIOS + UEFI" yang sudah terlalu lama) menghapus 30 + tahun akumulasi akumulasi warisan (A20, VGA, PS / 2, PIT, PIC, ...) dari perangkat keras adalah salah satu alasan utama produsen perangkat keras (Intel) mendorong untuk adopsi UEFI.

Membaca melalui berbagai lembar data Intel CPU dan Platform Controller Hub (PCH) modern, tampaknya tidak diperlukan perangkat keras yang diperlukan. Sepertinya tidak ada cara untuk menghasilkan SMI (System Management Interrupt) sebagai respons terhadap akses prosesor dari buffer bingkai VGA (alamat fisik 0xA0000 - 0xBFFFF).

Pengontrol memori dalam CPU akan merutekan akses ke buffer bingkai VGA ke pengontrol grafis terintegrasi, port PCI Express yang terhubung langsung ke CPU, atau antarmuka DMI yang menghubungkan CPU ke PCH. Meskipun mungkin bagian rute buffer bingkai VGA secara terpisah, ini muncul hanya dimaksudkan untuk mendukung perangkat MDA (Monochrome Display Adapter) yang terpisah. Pengontrol grafis terintegrasi tidak terdokumentasi dengan baik sehingga mungkin dapat dikonfigurasi untuk menghasilkan SMI pada akses buffer bingkai VGA, tetapi ini sepertinya tidak mungkin. Bagaimanapun, itu tidak akan berfungsi dengan grafis diskrit.

Intel PCH juga tampaknya tidak memiliki dukungan untuk menghasilkan IKM dalam menanggapi akses buffer bingkai VGA. Ini akan menjadi tempat paling alami untuk itu, karena sudah memiliki dukungan untuk menghasilkan IKM sebagai respons terhadap akses I / O ke pengontrol keyboard, pengontrol IDE dan perangkat warisan lainnya. Mungkin ada beberapa fitur tidak berdokumen yang melakukan ini, tetapi itu tidak termasuk dalam daftar sumber SMI yang mungkin diberikan dalam lembar data PCH.

Secara teoritis, adalah mungkin bagi pembuat motherboard untuk menghubungkan perangkat VGA palsu ke PCH melalui port PCI Express dan kemudian menghasilkan IKM menggunakan pin GPIO PCH. Namun, saya tidak yakin ini akan berhasil dalam prakteknya. Pada saat CPU mendapatkan SMI, ia bisa saja pindah ke menjalankan instruksi lain dan tidak mungkin untuk memeriksa keadaan CPU pada saat akses frame buffer.

(Masalah serupa terjadi dengan emulasi SoundBlaster 16 pada SoundBlaster Live. Ini akan menghasilkan PCI SERR # ketika port SoundBlaster lawas diakses, yang akan menghasilkan NMI pada CPU. Sayangnya emulasi akan pecah pada banyak motherboard Pentium 4 karena NMI akan tiba pada instruksi berikutnya atau selanjutnya.)