（0x31）などのバイトを物理線形アドレスのVGAテキスト（モード03）フレームバッファーに格納すると、16ビットのレガシーBIOS MBRモードで起動した最新のPCハードウェアで実際に何が起こりますか？ そのリージョンのMTRRがUCに設定されているストアはどのくらい遅いですか？ （Kaby Lake iGPUラップトップ1台での実験的テスト'1'B8000mov [es:di], eax、WC上のclflushoptがVGAメモリのUCとほぼ同じ速度であることを示しています。しかし、clflushopt movがないと、WCメモリへのストアはCPUを離れず、画面をまったく更新せず、超高速で実行されます。）

すべてのストアのSMIではない場合、実際にリアルモードで再起動せずにパフォーマンスを実験するために、ユーザー空間のWBメモリのチャンクでこのコストを概算する方法はありますか？（たとえば、実際にはどこにも表示されないふりフレームバッファとしてBSSページを使用する）。

対応するフォントグリフは次の更新時に画面に表示されますが、ハードウェアスキャンアウトは実際にVRAM（またはiGPUの場合はDRAM）からASCII文字を読み取り、ビットマップフォントグリフに即座にマッピングしていますか？または、各ストアまたはvblankごとに1つのソフトウェアインターセプトがあるため、実際のハードウェアはビットマップフレームバッファーのみを処理する必要がありますか？

レガシBIOSブートは、システム管理モード（SMM）を使用して USB kbd /マウスをPS / 2デバイスとしてエミュレートすることで知られています。VGAテキストモードのフレームバッファーにも使用されているのでしょうか。モード設定用のVGA I / Oポートに使用されていると思いますが、テキストフレームバッファがハードウェアでサポートされている可能性があります。ただし、ほとんどのコンピューターはすべての時間をグラフィックスモードで費やしているため、テキストモードのHWサポートを除外することは、ベンダーがしたいことのようです。（OTOH このブログは、自作のVerilog VGAコントローラーがテキストモードをかなり単純に実装できることを示唆しています。）

私は特にIntel SkylakeのiGPUを使用するシステムに興味がありますが、IntelおよびAMDの以前/後期のiGPU、および新旧のディスクリートGPUに興味があります。

（AMDとNVidia以外のベンダーを含みます。PCIeではなくPCIスロットを備えたSkylakeマザーボードがいくつかあります。最新のGPUファームウェアドライバーがテキストモードをエミュレートする場合、ハードウェアVGAテキストモードを備えた古いPCIビデオカードがいくつかあると考えられます。そしておそらくそのようなカードストアをSMIではなくPCIトランザクションにすることができます。）

私のデスクトップは、Asus Z170 Proゲーミングモボのi7-6700kです。アドオンカードはなく、DVI-D出力に1920x1200モニターを備えたiGPUのみです。@EldanがテストしているKaby Lake i5-7300HQシステムの詳細はわかりません。CPUモデルのみです。

私は2011年に uefiを使用してレガシービデオをエミュレートするフェニックスBIOSの特許US20120159520を見つけました。ビデオハードウェアベンダーにUEFI とネイティブの16ビットリアルモードオプションROMドライバーの両方の提供を要求する代わりに、SMMフックを介してベンダー提供のUEFIビデオドライバーを呼び出すリアルモードVGAドライバー（関数など）を提案します。int 10h

要約
[...]汎用ビデオオプションROMは、汎用ビデオSMMドライバーにビデオサービスの要求を通知します。このような通知は、ソフトウェアシステム管理割り込み（SMI）を使用して実行できます。通知されると、汎用ビデオSMMドライバーは、サードパーティのUEFIビデオドライバーにビデオサービスの要求を通知します。サードパーティのビデオドライバーは、要求されたビデオサービスをオペレーティングシステムに提供します。このようにして、サードパーティのUEFIグラフィックスドライバーは、UEFIディスプレイプロトコルをネイティブでサポートしていないオペレーティングシステムであっても、さまざまなオペレーティングシステムをサポートできます。

説明の多くは、int 10hすでに明らかにIVTを介してトラップするような呼び出しの処理をカバーしているため、意図的にSMIをトリガーするカスタムコードを簡単に実行できます。関連する部分は、ソフトウェアまたはハードウェアの割り込みをトリガーしないコードでも機能する必要があるテキストモードフレームバッファーへの直接保存について説明している部分です。（そのようなストアでSWをトリガーするHW以外、サポートされている場合は使用できると彼らは言っています。）

テキストバッファのサポート

特定の実施形態では、アプリケーションは、ＶＧＡのテキストバッファを直接操作することができる。そのような実施形態では、汎用ビデオＳＭＭドライバ１３０は、ハードウェアが７４０ＫＢ〜７６８ＫＢメモリ領域（テキストバッファが配置されている）への読み取り／書き込みアクセス時にＳＭＩトラッピングを提供するかどうかに応じて、２つの方法のうちの１つでこれをサポートする。

ＳＭＩトラッピングが利用可能な場合、ハードウェアは、各読み取りまたは書き込みアクセスでＳＭＩを生成する。SMIトラップのトラップアドレスを使用して、正確なテキストの列と行を計算し、仮想テキスト画面の対応する行と列にアクセスできます。

代わりに、この領域では通常のメモリが有効になり、定期的なSMIを使用して、汎用ビデオSMMドライバー130はエミュレートされたハードウェアテキストバッファーの変更をスキャンし、ビデオドライバーによって維持される対応する仮想テキスト画面を更新します。どちらの場合も、変更が検出されると、文字が仮想テキスト画面に再描画されます。

これはBIOSベンダーの特許の1つに過ぎず、ほとんどのハードウェアが実際にどのように機能するか、または他のベンダーが異なることを行っているかどうかはわかりません。それは本質的にことを確認しないいくつかのハードウェアがいますが、その範囲内の店舗にどの缶トラップが存在します。（それが彼らが彼らの特許でカバーすることを決めた仮説的な可能性でない限り）

私が念頭に置いているユースケースでは、画面の更新時にのみトラップする方が、すべてのストアでトラップするよりもはるかに高速なので、どのハードウェア/ファームウェアがどのように機能するか知りたいです。

この質問の動機

第7世代Intel CoreのビデオRAMでインクリメントするASCII 10進カウンターを最適化-ASCIIテキストカウンターの新しい数字をビデオRAMの同じ数バイトに繰り返し保存します。

Linuxの32ビットユーザー空間のコードのバージョンをWBメモリでテストしました。movnti各ストアの後にCPUがWCバッファーをビデオRAMに同期するさまざまな方法（および場合によってはときどき）タイマー割り込み）。ただし、リアルモードブートローダーの状況がDRAMへの格納だけでなく、SMIをトリガーする場合、これは現実的ではありません。

WBメモリでは、movntiaを使用したスト​​アのフラッシュは、を使用したフラッシュlock xor byte [esp], 0よりもいくらか高速ですclflushopt。しかし、@ Eldanは、MTRRをWCにするようにプログラミングした後、VGAメモリのユーザーに対して速度の向上を報告していません。（また、通常のストアを行う元の速度と同じ速度で、デフォルトでVGAフレームバッファーがUCであることを示します。一部の古いBIOSには、VGAメモリをWCにするオプションがありました USGA = Uncached Speculative Write Combiningと呼ばれる。）

これは実際の問題ではないため、実際の回避策は探していません。ピクセルバイトをVGAグラフィックモードに手動で格納する方がはるかに高速であるかどうかを知ることは興味深いでしょう。

概要

1. すべての実際の最新システムは、すべてのストアでSMIをトリガーしてテキストモードのフレームバッファーを作成しますか？
2. いいえの場合、WBメモリーのユーザー空間でmovnti +を使用して、WCストア+ clflushをフレームバッファーに近似できますか？したがって、簡単にプロファイリングできますperfため、パフォーマンスカウンターでます。
3. 異なるBIOSやハードウェアが異なる戦略を使用している場合、それらの戦略は何ですか？（詳細は必要ありません。「SMIすべてのvblankでVGAフレームバッファーを実際のハードウェアフレームバッファーに同期させる」のような高レベル）
4. ハードウェアVGAテキストモードを備えたPCIeまたはPCIビデオカードは、統合されたGPUが実際に実行するものよりも高速でしょうか？実際のPCIe書き込みトランザクションは、ストアがDRAMにヒットするのを待つよりも遅いと思いますが、PCIe書き込みは、すべてのストアでSMIよりも安価です。球場/規模の比較は興味深いでしょう。

これらの質問はすべて関連性が高いですが、期待するほどの重複がない場合は、これを分割することができます。

すべての実際の最新システムは、すべてのストアでSMIをトリガーしてテキストモードのフレームバッファーを作成しますか？

ビデオカードについては、私はそれを非常に疑っています。ビデオカードの製造元は、1980年代からハードウェアに「文字+属性からピクセルデータを取得する」ロジックを組み込んでおり（VGAよりも古く、CGAからあまり変更されていません）、そのロジックを気にせずに新しいデザインにカットアンドペーストするだけです。

ビデオカードではないもの（LANを使用したリモートシステム管理ツールなど）についてはわかりませんが、疑っています（多くの場合、メインCPUではなく特別な管理CPUを使用しているため、コンピューターが動作している場合でも機能します） 「オフ」になっています）。

いいえの場合、WBメモリーのユーザー空間でmovnti +を使用して、WCストア+ clflushをフレームバッファーに近似できますか？

ユーザースペースにいない場合は、MTTRを変更して（すべてのCPUで-MTRRが一致している必要があり、特別なシーケンスが必要です）、RAMの領域を「キャッシュしない」にすることができます。または、ページテーブルでPATを使用します（特にページングを使用している場合、MTRRをいじるよりもはるかに簡単ですが、キャッシュの一貫性が必要なために動作が少し異なります）。ユーザー空間にいる場合は、OS /カーネルが提供するものに依存する必要があり、（OSによっては）OS /カーネルがこれを行う方法をまったく提供しない場合があります。

しかしながら; RAM（の領域）を非キャッシュにする方法を見つけたとしても、CPUに組み込まれたメモリコントローラーに接続されているものに直接書き込むため（CPUは非常に高速に書き込むことができるため）、それはあまり似ていません。 ）PCIリンクの反対側で何かと話す代わりに（CPU側からの待ち時間が長くなり、帯域幅が低くなります）。統合されたビデオ（技術的には最終的に同じRAMチップ）の場合でも、VRAMへの書き込みは非常に異なるパスを経由します（ビデオカードのリマッピング/ GART /ページング、 "書き込みモード" VGAレジスタ、影響を受ける）ビット/プレーンマスクVGAレジスタなど）。

ハードウェアVGAテキストモードを備えたPCIeまたはPCIビデオカードは、統合されたGPUが実際に実行するものよりも高速でしょうか？

CPUからVRAMへの書き込み。通常、統合されたビデオは、ディスクリートカードよりもかなり高速です（少なくとも、CPUからVGAの「書き込みロジック」が関与しないリニアフレームバッファーへのプレーンな書き込みの場合）。

非常に大まかな概算の場合。RAMへの1回の書き込みは約150サイクル、PCIへの1回の書き込みは1000サイクルに近いと思います。SMIの場合、SMIがCPUに到達するまでに数百サイクルのレイテンシ、次にCPUパイプラインフラッシュのコスト、次にCPUの状態（および戻りパスの同じロード状態）を保存するための約500サイクルが予想されます。次に、ファームウェアのコードは、それがVRAMへの書き込みであって他のものではないことを知る前に、SMIの原因（さらに数百サイクル？）を見つける必要があります。次に、保存されているCPUの状態を調べ、書き込みを行った命令を見つけてデコードする必要があります（バイト/ワード/ dwordの書き込みの場合など、書き込まれているデータがわからないため）。以前のCPUの状態（CPUがどのモードであったか、コードサイズ、XADD、など）。次に、（エミュレートされた）VGAレジスタの状態を分析する必要があります（書き込みモード、書き込みマスク、プレーンイネーブル、どの64 KiBバンクがレガシーエリアにマッピングされているか、フォントの高さなど）。基本的に; テキストモードフレームバッファーへの書き込みのSMIエミュレーション。ファームウェアのコードが非常に複雑な中に埋もれている重要ではない細部を見落とす前に、何万サイクルもかかり、間違った動作をして、異常に破損する原因になると思います。

その他の注意事項

私は2011年から、uefiを使用してレガシービデオをエミュレートするフェニックスBIOSの特許US20120159520を見つけました。

これが機能することはないと思うので、これが実装されたことはないと思います。レガシーインターフェースで実行できることは多すぎます（一般的でわかりにくい）（たとえば、垂直リフレッシュの検出、「モードX」などの非標準のビデオモードの設定、「表示開始」の調整、スムーズなスクロールやページめくりの実装） 、VBEの「CRTC情報」を使用して、ビデオのタイミングを変更します。これは、UEFIでサポートされておらず、経由することもできません。UEFI用のサードパーティのビデオドライバー。

代わりに、ビデオカードメーカーは約10年間UEFIドライバーを提供することを気にせず、UEFIファームウェアはレガシーインターフェイスを使用してUEFIサービスをエミュレートしました（多くの場合、セキュアブートが中断されていました）。とにかくほとんどすべてがUEFIになるまで。

モード設定用のVGA I / Oポートに（SMM）が使用されていると思います。

そうではないと思います。SMMが使用される可能性があると私が思うビデオに漠然と関連している唯一のことは、初期ブート時（OSの前）のラップトップ（特に古いラップトップ、特に「蓋開閉イベント」）の画面のバックライトの輝度を制御することです奪い取る）。

..テキストモードのハードウェアサポートを除外することは、ベンダがしたいことのようです

私はまだ（結局のところ、非常に長い「ハイブリッドBIOS + UEFI」移行フェーズの後）30年以上蓄積されたレガシー混乱（A20、VGA、PS / 2、PIT、PICなど）をハードウェアから削除したと、私は信じています。ハードウェアメーカー（Intel）がUEFIの採用を推進している主な理由の1つです。

さまざまな最新のIntel CPUおよびPlatform Controller Hub（PCH）データシートを読んでも、必要なハードウェアが実装されているようには見えません。VGAフレームバッファー（物理アドレス0xA0000-0xBFFFF）のプロセッサアクセスに応答してSMI（システム管理割り込み）を生成する方法はないようです。

CPUのメモリコントローラーは、VGAフレームバッファーへのアクセスを統合グラフィックスコントローラー、CPUに直接接続されたPCI Expressポート、またはCPUをPCHに接続するDMIインターフェイスのいずれかにルーティングします。VGAフレームバッファーを個別にルーティングすることは可能ですが、これは別のMDA（Monochrome Display Adapter）デバイスをサポートすることのみを目的としています。統合されたグラフィックスコントローラーは十分に文書化されていないため、VGAフレームバッファーアクセスでSMIを生成するように構成できる可能性がありますが、これはありそうにありません。いずれにせよ、個別のグラフィックスでは機能しません。

Intel PCHは、VGAフレームバッファーアクセスに応答してSMIを生成することもサポートしていないようです。これは、キーボードコントローラー、IDEコントローラー、およびその他のレガシーデバイスへのI / Oアクセスに応答してSMIを生成するためのサポートを既に備えているため、最も自然な場所です。これを行う文書化されていない機能がいくつかある可能性がありますが、PCHデータシートに記載されている可能なSMIソースのリストには含まれていません。

理論的には、マザーボードメーカーが偽のVGAデバイスをPCI Expressポートを介してPCHに接続し、PCH GPIOピンを使用してSMIを生成することが可能です。ただし、これが実際に機能するかどうかはわかりません。CPUがSMIを取得するまでに、他の命令の実行に移る可能性があり、フレームバッファーアクセス時のCPU状態を調べることはできません。

（SoundBlaster LiveのSoundBlaster 16エミュレーションでも同様の問題が発生しました。レガシーのSoundBlasterポートにアクセスすると、PCI SERR＃が生成され、CPUでNMIが生成されます。残念ながら、エミュレーションは多くのPentium 4マザーボードで機能しません。 NMIは次または後続の命令で到着します。）