以下の詳細な説明では、本明細書の一部を形成する添付の図面への参照が行われ、同様の符号が全体を通じて同様の部品を指し、実践され得る例示的な実施形態を用いて示される。他の実施形態が利用されてよく、構造的又は論理的な変更が本開示の範囲から逸脱することなく行われてよいことが理解されるべきである。したがって、以下の詳細な説明は、限定的な意味にとられるべきでなく、実施形態の範囲は、添付の特許請求の範囲及びこれらの同等物により規定される。
様々なオペレーションが、特許請求の範囲に記載の主題を理解する際に最も役立つ態様で、複数の別個の動作又は処理として順番に説明され得る。しかしながら、説明の順序は、これらの処理が必然的に順序に依存することを示唆するものとして解釈されるべきではない。特に、これらの処理は、提示の順序で実行されないくてもよい。説明される処理は、説明される実施形態とは異なる順序で実行されてよい。追加の実施形態では、様々な追加の処理が実行されてよく、及び/又は、説明される処理が省略されてもよい。
本開示の目的のために、「A及び/又はB」という用語は、(A)、(B)又は(A及びB)を意味する。本開示の目的のために、「A、B及び/又はC」という用語は、(A)、(B)、(C)、(A及びB)、(A及びC)、(B及びC)又は(A、B及びC)を意味する。
説明では、「一実施形態において」又は「複数の実施形態において」という用語を用いてよく、同じ又は異なる実施形態のうちの1又は複数をそれぞれ指し得る。さらに、「備える(comprising)」、「含む(including)」及び「有する(having)」などの用語は、本開示の実施形態に関して用いられる場合、同義である。
背景技術に記載したように、アクセラレータの様々な混合を実装する幅広いストックユニット及びプラットフォームがあるので、アクセラレータの解決手段を展開し、ポータブルに利用するアクセラレータの複雑性を管理することは困難であり得る。さらに、非常に多数のオペレーティングシステム(及びバージョン、パッチなど)を考慮すると、デバイスドライバモデルを用いてアクセラレータを配置するには、ビッグデータ処理についての開発者の取り組み、非移植性及び厳密な性能要件に起因する採用に対するハードルを含む制限がある。アクセラレータは、典型的には、汎用プロセッサ上で実行するソフトウェアよりも効率的に機能を実行するハードウェアデバイス(回路)である。例えば、ハードウェアアクセラレータは、特定のアルゴリズム/タスク(例えば、ビデオエンコーディング又はデコーディング、特定のハッシュ関数など)、又は、アルゴリズム/タスクのクラス(例えば、機械学習、疎データ操作、暗号化、グラフィックス、物理学、正規表現、パケット処理、人工知能、デジタル信号プロセッシングなど)の実行を改善するために用いられ得る。アクセラレータの例は、限定されることはないが、グラフィックス処理ユニット(「GPU」)、固定機能フィールドプログラマブルゲートアレイ(「FPGA」)アクセラレータ、及び、固定機能特定用途向け集積回路(「ASIC」)を含む。アクセラレータは、いくつかの実施例において、CPUがシステム内の他のプロセッサよりも効率的である場合、汎用の中央処理装置(「CPU」)であってよいことに留意する。
所与のシステム(例えば、システムオンチップ(「SoC」)、プロセッサストックユニット、ラックなど)の電力量は、利用可能なシリコンエリアの一部上のみで処理要素により消費され得る。これは、たとえ、ハードウェアブロックのすべてが同時にアクティブになり得ることはないとしても、特定の処理に対するエネルギー消費を低減する様々な特化型のハードウェアブロックを構築することを有利にする。
スレッドを処理する処理要素(例えば、コア又はアクセラレータ)を選択し、処理要素とインタフェース接続し、及び/又は、ヘテロジニアマルチプロセッサ環境内の電力消費を管理するためのシステム、方法及び装置の実施形態が詳細に説明される。例えば、様々な実施形態において、ヘテロジニアマルチプロセッサは、スレッド及び/又は処理要素の対応するワークロードの特性に基づいて、ヘテロジニアマルチプロセッサの異なるタイプの処理要素間でスレッドを動的に移行し、処理要素の1又は複数にプログラムインタフェースを提供し、特定の処理要素上での実行のためのコードを変換し、ワークロード及び選択された処理要素又はこれらの組み合わせについての特性に基づいて、選択された処理要素と共に用いる通信プロトコルを選択するように、(例えば、設計により、又は、ソフトウェアにより)構成される。
第1態様において、ワークロードディスパッチインタフェース、すなわち、ヘテロジニアススケジューラは、ホモジニアスマルチプロセッサプログラミングモデルをシステムプログラマに提示する。特に、この態様では、プログラマが特定のアーキテクチャをターゲットとするソフトウェア又は同等の抽象化を開発することを可能にし得る一方、開発されるソフトウェアへの対応する変更を要求することなく、基礎となるハードウェアに対する連続的な改善を容易する。
第2態様において、マルチプロトコルリンクは、第1のエンティティ(ヘテロジニアススケジューラなど)が、通信と関連付けられたプロトコルを用いて、多数のデバイスと通信することを可能にする。これは、デバイス通信用に別々のリンクを有する必要性に取って代わるものである。特に、このリンクは、リンク上で動的に多重化される3又はそれより多いプロトコルを有する。例えば、共通のリンクは、1)1又は複数の独自又は業界標準(例えば、PCIエクスプレス仕様又は同等の代替手段など)において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、DMAスタイルのデータ転送及び様々なサービスを可能にする生産者/消費者、発見、構成、割込み(PDCI)プロトコル、2)デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス(CAC)プロトコル、及び、3)処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス(MA)プロトコルからなるプロトコルをサポートする。
第3態様において、スレッドのスケジューリング、移行若しくはエミュレーション、又は、これらの一部が、スレッドのフェーズに基づいて行われる。例えば、スレッドのデータ並列フェーズは、典型的には、スケジューリングされ、又は、SIMDコアに移行され、スレッドのスレッド並列フェーズは、典型的には、スケジューリングされ、又は、1又は複数のスカラコアに移行され、直列フェーズは、典型的には、スケジューリングされ、又は、アウトオブオーダコアに移行される。コアタイプのそれぞれは、両方ともスレッドのスケジューリング、移行又はエミュレーションについて考慮されるエネルギー又はレイテンシのいずれか一方を最小化する。エミュレーションは、スケジューリング又は移行が可能でない又は有利でない場合に用いられてよい。
第4態様において、スレッド又はこれらの一部は、オポチュニスティックに(opportunistically)、アクセラレータへオフロードされる。特に、スレッドのアクセラレータ開始(ABEGIN)命令及びアクセラレータ終了(AEND)命令又はこれらの一部、ブックエンド命令が、アクセラレータ上で実行可能であり得る。アクセラレータが利用可能でない場合、次に、ABEGINとAENDとの間の命令が通常通り実行される。しかしながら、アクセラレータが利用可能である場合、アクセラレータを用いる(例えば、少ない電力を用いる)ことが好ましく、次に、ABEGINとAEND命令との間の命令は、そのアクセラレータ上で実行するために変換され、そのアクセラレータの実行のためにスケジューリングされる。その結果、アクセラレータの使用はオポチュニスティックである。
第5態様において、スレッド又はその一部は、ABEGIN又はAENDを用いることなく、アクセラレータに(オポチュニスティックな)オフロードのために解析される。ソフトウェア又はハードウェアパターンマッチは、アクセラレータ上で実行可能であり得るコード用に、スレッド又はその一部に対して実行される。アクセラレータが利用可能でない場合、又は、スレッド又はその一部それ自体がアクセラレータの実行に役立たない場合、スレッドの命令は、通常通りに実行される。しかしながら、アクセラレータが利用可能である場合、アクセラレータを用いる(例えば、少ない電力を用いる)ことが好ましく、次に、命令は、そのアクセラレータで実行するために変換され、そのアクセラレータ上での実行のためにスケジューリングされる。その結果、アクセラレータの使用はオポチュニスティックである。
第6態様において、選択された宛先処理要素をより良く適合させるコードフラグメント(スレッドの一部)の変換が実行される。例えば、コードフラグメントは、1)異なる命令セットを利用するために変換され、2)より多く並列化され、3)あまり並列化されず(直列化され)、4)データを並列化し(例えば、ベクトル化され)、及び/又は、5)データをあまり並列化しない(例えば、非ベクトル化される)。
第7態様において、(共有又は専用のいずれか一方の)ワークキューは、デバイスにより行われるワークの範囲を定義する記述子を受信する。専用のワークキューは、単一のアプリケーション用の記述子を格納する一方、共有のワークキューは、複数のアプリケーションによりサブミットされる記述子を格納する。ハードウェアインタフェース/アービタは、特定のアービトレーションポリシに従って(例えば、各アプリケーション及びQoS/公平性ポリシの処理要件に基づいて)、記述子をワークキューからアクセラレータ処理エンジンにディスパッチする。
第8態様において、密行列乗算に対する改善は、単一の命令の実行と共に2次元行列の乗算を考慮する。複数のパックドデータ(SIMD、ベクトル)ソースは、単一のパックドデータソースに対して乗算される。いくつかの例において、2分木が乗算に用いられる。
図1は、ヘテロジニアスマルチプロセッシングの実行環境を表現したものである。この例において、第1のタイプのコードフラグメント(例えば、ソフトウェアスレッドと関連付けられた1又は複数の命令)がヘテロジニアススケジューラ101により受信される。コードフラグメントは、任意の数のソースコード表現の形式であってよく、例えば、マシンコード、中間表現、バイトコード、テキストベースのコード(高水準言語、例えばC++などのアセンブリコード、ソースコード)などを含む。ヘテロジニアススケジューラ101は、(例えば、すべてのスレッドがスカラコア上で実行中であるかのように、それらがユーザ及び/又はオペレーティングシステムに見えるように)ホモジニアスマルチプロセッサプログラミングモデルを提示し、受信したコードフラグメントに関するワークロードタイプ(プログラムフェーズ)を判断し、判断したワークロードタイプに対応する処理要素のタイプ(スカラ、アウトオブオーダ(OOO)、単一命令複数データ(SIMD)又はアクセラレータを選択して、ワークロード(例えば、スレッド並列コード用のスカラ、直列コード用のOOO、データ並列用のSIMD、及び、データ並列用のアクセラレータ)を処理し、対応する処理要素による処理のためにコードフラグメントをスケジューリングする。図1に示される特定の実施例において、処理要素タイプは、スカラコア103(例えば、インオーダコア)、連続的に格納された複数のデータ要素をレジスタが有するパックドデータオペランドに対して演算を行う単一命令複数データ(SIMD)コア105、低レイテンシのアウトオブオーダコア107及びアクセラレータ109を含む。いくつかの実施形態において、スカラコア103、単一命令複数データ(SIMD)コア105、低レイテンシのアウトオブオーダコア107は、ヘテロジニアプロセッサ内にあり、アクセラレータ109は、このヘテロジニアプロセッサの外部にある。しかしながら、処理要素の様々な異なる構成が利用されてよいことに留意されたい。いくつかの実施例において、ヘテロジニアススケジューラ101は、受信したコードフラグメント又はその一部を、処理要素の選択されたタイプに対応するフォーマットに変換又は解釈する。
処理要素103〜109は、異なる命令セットアーキテクチャ(ISA)をサポートしてよい。例えば、アウトオブオーダコアは、第1のISAをサポートしてよく、インオーダコアは、第2のISAをサポートしてよい。この第2のISAは、第1のISAの(サブ又はスーパー)セットであってよく、又は、異なっていてもよい。さらに、処理要素は、異なるマイクロアーキテクチャを有してよい。例えば、第1のアウトオブオーダコアは、第1のマイクロアーキテクチャをサポートし、インオーダコアは、異なる第2のマイクロアーキテクチャをサポートする。たとえ処理要素の特定のタイプ内であったとしても、ISA及びマイクロアーキテクチャは、異なっていてもよいことに留意する。例えば、第1のアウトオブオーダコアは、第1のマイクロアーキテクチャをサポートしてよく、第2のアウトオブオーダコアは、異なるマイクロアーキテクチャをサポートしてよい。命令は、それらがISAの一部であるという点で、特定のISAに対して「ネイティブ」である。ネイティブ命令は、外部の変更(例えば、変換)を必要とすることなく、特定のマイクロアーキテクチャで実行する。
いくつかの実施例では、処理要素の1又は複数は、例えば、システムオンチップ(SoC)として、単一のダイに統合される。そのような実施例では、例えば、改善された通信レイテンシ、製造/コスト、低減されたピンカウント、プラットフォームの小型化などからの利益を得る場合がある。他の実施例では、処理要素は、まとめてパッケージ化され、それにより、単一のダイにある必要はなく、上記で参照したSoCの利益の1又は複数を実現する。これらの実施例は、例えば、処理要素タイプ毎に最適化される異なる処理技術、歩留まり向上のためのより小さいダイサイズ、所有の知的財産ブロックの統合などからさらなる利益を得てよい。いくつかの従来のマルチパッケージ制限では、異なるデバイスが追加されるときに、それらと通信することが困難であるかもしれない。本明細書で説明されるマルチプロトコルリンクは、異なるタイプのデバイスに共通のインタフェースをユーザ、オペレーティングシステム(「OS」)などに提示することにより、この課題を最小化又は緩和する。
いくつかの実施例において、ヘテロジニアススケジューラ101は、プロセッサコア(例えば、OOOコア107)での実行のために、コンピュータ可読媒体(例えば、メモリ)に格納されたソフトウェアにおいて実装される。これらの実施例において、ヘテロジニアススケジューラ101は、ソフトウェアヘテロジニアススケジューラと称される。このソフトウェアは、バイナリトランスレータ、実行時(「JIT」)コンパイラ、コードフラグメントを含むスレッドの実行をスケジューリングするOS117、パターンマッチャ、内部モジュールコンポーネント又はこれらの組み合わせを実装してよい。
いくつかの実施例では、ヘテロジニアススケジューラ101は、回路及び/又は回路により実行される有限ステートマシンとして、ハードウェア内に実装される。これらの実施例では、ヘテロジニアススケジューラ101は、ハードウェアヘテロジニアススケジューラと称される。
プログラム(例えば、OS117、エミュレーション層、ハイパーバイザ、セキュアモニタなど)の観点から、各タイプの処理要素103−109は、共有メモリアドレス空間115を利用する。いくつかの実施例において、共有メモリアドレス空間115は、図2に示されるように、2つのタイプのメモリ、メモリ211及びメモリ213を選択的に有する。そのような実施例において、メモリのタイプは、限定されることはないが、メモリ位置における差(例えば、異なるソケット上に配置される、など)、対応するインタフェース標準における差(例えば、DDR4、DDR5など)、所要電力における差、及び/又は、使用される基礎となるメモリ技術における差(例えば、高帯域幅メモリ(HBM)、シンクロナスDRAMなど)を含む様々な方式で区別されてよい。
共有メモリアドレス空間115は、各タイプの処理要素によりアクセス可能である。しかしながら、いくつかの実施形態において、例えば、ワークロードの必要性に基づいて、異なるタイプのメモリが異なる処理要素に対して優先的に割り当てられてよい。例えば、いくつかの実施例では、プラットフォームのファームウェアインタフェース(例えば、BIOS又はUEFI)又はメモリストレージは、プラットフォームにおいて利用可能なメモリリソースのタイプ、及び/又は、特定のアドレス範囲又はメモリタイプに関する処理要素の共通性を示すフィールドを含む。
ヘテロジニアススケジューラ101は、スレッドが所与の時点のどこで実行されるかを判断するためにスレッドを解析する場合、この情報を利用する。典型的には、スレッド管理メカニズムは、既存のスレッドを管理する方法に応じて、情報に基づいた決定を通知するために、それに利用可能な情報の全体を調べる。これは、多数の方式でそれ自体を明らかにし得る。例えば、処理要素に対して物理的に近いアドレス範囲の共通性を有する特定の処理要素上で実行するスレッドは、処理要素上で実行されるであろう通常状況の下、スレッドにわたる優先処理を与え得る。
別の例は、特定のメモリタイプ(例えば、DRAMのより高速なバージョン)から利益を得るであろうスレッドは、そのデータをメモリタイプに物理的に移動させ、コード内のメモリ参照を共有アドレス空間の一部を指し示すように調整させ得るということである。例えば、SIMDコア105上のスレッドが第2のメモリタイプ213を利用し得る一方、それは、アクセラレータ109がアクティブであり、そのメモリタイプ213を必要とする(又は、SIMDコア105のスレッドに割り当てられた部分を少なくとも必要とする)場合、この利用から移動させてもよい。
例示的なシナリオは、メモリが一方よりも他方の処理要素に物理的に近い場合である。よくある例は、アクセラレータがコアとは異なるメモリタイプに直接接続されている場合である。
これらの例では、典型的には、データ移動を開始するOSである。しかしながら、下位レベル(例えば、ヘテロジニアススケジューラ)が、独自で又は別のコンポーネント(例えば、OS)からの支援を伴ってこの機能を実行することを拒むものは何もない。前の処理要素のデータががフラッシュされ、ページテーブルエントリが無効にされるか否かは、データ移動を行うための実装及び不利益に依存する。データが、すぐ用いられる可能性が高くはない場合、一方のメモリタイプから他方にデータを移動するよりも、むしろストレージから単にコピーした方がより実現可能であるかもしれない。
図117の(A)〜(B)は、共有メモリ内のスレッドに対する移動の例を示す。この例では、2つのタイプのメモリは、それぞれがその空間内のアドレスの独自の範囲を有するアドレス空間を共有する。117の(A)において、共有メモリ11715は、第1のタイプのメモリ11701及び第2のタイプのメモリ11707を含む。第1のタイプのメモリ11701は、第1のアドレス範囲11703を有し、スレッド1 11705に専用のアドレスである範囲内にある。第2のタイプのメモリ11707は、第2のアドレス範囲11709を有する。
スレッド1 11705の実行中のいくつかの時点で、ヘテロジニアススケジューラは、第2のスレッド11711が、スレッド1 11705に割り当てられる前に、第1のタイプのメモリ11701内のアドレスを用いるように、スレッド1 11705を移動することの決定を行う。これは、図117の(B)に示されている。この例では、スレッド1 11705は、第2のタイプのメモリ11707に再割り当てされ、用いるためのアドレスの新たなセットが与えられる。しかしながら、これは、該当のケースである必要はない。メモリのタイプの差が、(例えば、PEへの距離に基づいて)物理的又は空間的であってよいことに留意する。
図118は、ヘテロジニアススケジューラにより実行され得るスレッド移動のための例示的な方法を示す。11801において、第1のスレッドは、共有メモリ空間内の第1のタイプのメモリを用いて、コア又はアクセラレータなどの第1の処理要素(「PE」)上で実行されるよう指示される。例えば、図117の(A)において、これは、スレッド1である。
後のいくつかの時点で、第2のスレッドを実行する要求が11803において受信される。例えば、アプリケーション、OSなどは、実行されるハードウェアスレッドを要求する。
11805において、共有アドレス空間内の第1のタイプのメモリを用いる第2のPEで第2のスレッドが実行されるべきとの判断が行われる。例えば、第2のスレッドは、第1のタイプのメモリに直接結合されるアクセラレータ上で実行され、当該実行(第1のスレッドが使用しているメモリを解放することを含む)は、第2のスレッドに第2のタイプのメモリを使用させるよりも効率的である。
いくつかの実施形態では、11807において、第1のスレッドのデータが第1のタイプのメモリから第2のタイプのメモリに移動される。これは、第1のスレッド実行の実行を単に停止して、その配置において別のスレッドを開始することがより効率的である場合に、必ずしも発生するわけではない。
11809において、第1のスレッドと関連付けられたトランスレーションルックアサイドバッファ(TLB)エントリが無効にされる。さらに、最も多くの実施形態では、データのフラッシュが実行される。
11811において、第2のスレッドは、第2のPEに向けられ、第1のスレッドに対して前に割り当てられていた第1のタイプのメモリ内のアドレスの範囲に割り当てられる。
図3は、ヘテロジニアススケジューラ301の例示的な実施例を示す。いくつかの例において、スケジューラ301は、ランタイムシステムの一部である。図示されるように、プログラムフェーズ検出器313は、コードフラグメントを受信し、対応するプログラムフェーズの実行が、直列、データ並列又はスレッド並列として最良の特徴であるか否かを判断するために、コードフラグメントの1又は複数の特性を識別する。これが判断される方法の例が以下に詳細に説明される。図1に関して詳細に説明したように、コードフラグメントは、任意の数のソースコード表現の形式であってよい。
反復的コードフラグメントについて、パターンマッチャ311は、この「ホット」コードを識別し、さらに、いくつかの例においては、コードフラグメントと関連付けられたワークロードが、異なる処理要素で処理するためにより適し得ることを示す対応する特性も識別する。パターンマッチャ311及びその動作に関するさらなる詳細は、例えば、図20の文脈において以下で説明される。
セレクタ309は、処理要素の特性と、電源マネージャ307により提供された熱及び/又は電力情報とに少なくとも部分的に基づいて、受信したコードフラグメントのネイティブ表現を実行するターゲット処理要素を選択する。当該ターゲット処理要素の選択は、コードフラグメントに対して最も適合するもの(すなわち、ワークロード特性と処理要素機能との間のマッチ)をできるだけ簡単に選択し得るが、システムの現在の電力消費レベル(例えば、電源マネージャ307により提供され得る場合)、処理要素の可用性、一方のタイプのメモリから他方へ移動するデータ量(及び、そのように行うことに対して関連付けられた不利益)などを考慮してもよい。いくつかの実施形態において、セレクタ309は、ハードウェア回路内に実装される、又は、ハードウェア回路により実行される有限ステートマシンである。
いくつかの実施形態において、セレクタ309は、ターゲット処理要素と通信するために、対応するリンクプロトコルも選択する。例えば、いくつかの実施例において、処理要素は、システムファブリック又はポイントツーポイント相互接続に関する複数のプロトコルを動的に多重化又はカプセル化することが可能な対応する共通のリンクインタフェースを利用する。例えば、特定の実施例において、サポートされるプロトコルは、1)1又は複数の独自又は業界標準(例えば、PCIエクスプレス仕様又は同等の代替手段など)において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、DMAスタイルのデータ転送及び様々なサービスを可能にする生産者/消費者、発見、構成、割込み(PDCI)プロトコル、2)デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス(CAC)プロトコル、及び、3)処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス(MA)プロトコルを含む。セレクタ309は、処理要素に通信される要求のタイプに基づいて、これらのプロトコル間の選択を行う。例えば、生産者/消費者、発見、構成又は割込み要求は、PDCIプロトコルを用い、キャッシュコヒーレンス要求は、CACプロトコルを用い、ローカルメモリアクセス要求は、MAプロトコルを用いる。
いくつかの実施例において、スレッドは、フェーズタイプを示すマーカを含み、したがって、フェーズ検出器は利用されない。いくつかの実施例において、スレッドは、処理要素タイプ、リンクプロトコル及び/又はメモリタイプに関する暗示又は明示的な要求を含む。これらの実施例において、セレクタ309は、その選択処理においてこの情報を利用する。例えば、セレクタ309による選択は、スレッド及び/又はユーザによりオーバーライドされてよい。
実装に応じて、ヘテロジニアススケジューラは、受信したコードフラグメントを処理し、ターゲット処理要素に対して対応するネイティブエンコーディングを生成する1又は複数のコンバータを含んでよい。例えば、ヘテロジニアススケジューラは、第1のタイプのマシンコードを第2のタイプのマシンコードに変換する変換器、及び/又は、中間表現をターゲット処理要素にネイティブなフォーマットに変換するJITコンパイラを含んでよい。代替的に又はさらに、ヘテロジニアススケジューラは、反復的コードフラグメント(すなわち、「ホット」コード)を識別し、コードフラグメント又は対応するマイクロオペレーションの1又は複数のネイティブエンコーディングをキャッシュするパターンマッチャを含んでよい。これらの選択的なコンポーネントのそれぞれは、図3に示されている。特に、ヘテロジニアススケジューラ301は、変換器303及びJITコンパイラ305を含む。ヘテロジニアススケジューラ301がオブジェクトコード又は中間表現に対して演算を行う場合、受信したコードフラグメントをターゲット処理要素103、105、107、109のうちの1又は複数にネイティブなフォーマットに変換するために、JITコンパイラ305が呼び出される。ヘテロジニアススケジューラ301がマシンコード(バイナリ)に対して演算を行う場合(例えば、ある命令セットから他の命令セットに変換する場合など)、バイナリトランスレータ303は、受信したコードフラグメントを、ターゲット処理要素のうちの1又は複数にネイティブなマシンコードに変換する。代替的な実施形態において、ヘテロジニアススケジューラ301は、これらのコンポーネントのうちの1又は複数を除外してよい。
例えば、いくつかの実施形態では、バイナリトランスレータは含まれていない。これは、スケジューラにこれを対処させる代わりに、潜在的に利用可能なアクセラレータ、コアなどをプログラムが考慮する必要があるので、プログラミングの複雑性が増すという結果をもたらし得る。例えば、プログラムは、異なるフォーマットにおけるルーチンのためのコードを含む必要があるかもしれない。しかしながら、いくつかの実施形態において、バイナリトランスレータがない場合、より高いレベルでコードを受け入れるJITコンパイラがあり、当該JITコンパイラが必要な変換を実行する。パターンマッチャが存在する場合、特定の処理要素で実行されるべきコードを発見するためにホットコードがさらに検出されてよい。
例えば、いくつかの実施形態では、JITコンパイラは含まれていない。これはまた、スケジューラにこれを対処させる代わりに、プログラムがまず特定のISA用のマシンコードにコンパイルする必要があるので、プログラミングの複雑性が増すという結果をもたらし得る。しかしながら、いくつかの実施形態において、バイナリトランスレータがあり、かつ、JITコンパイラがない場合、スケジューラは、以下で詳細に説明するように、ISA間で変換してよい。パターンマッチャが存在する場合、特定の処理要素で実行されるべきコードを発見するためにホットコードがさらに検出されてよい。
例えば、いくつかの実施形態では、パターンマッチャは含まれていない。これはまた、移動された可能性があるコードが、実行中の特定のタスクにとって効率的とはいえないコアのままである可能性が高いので、効率性が下がるという結果をもたらし得る。
いくつかの実施形態では、バイナリトランスレータ、JITコンパイラ又はパターンマッチャがない。これらの実施形態では、スレッドを移動させるフェーズ検出又は明示的な要求のみが、スレッド/処理要素割り当て/移行に利用される。
図1〜図3を再び参照すると、ヘテロジニアススケジューラ101は、ハードウェア(例えば、回路)、ソフトウェア(例えば、実行可能なプログラムコード)又はこれらの任意の組み合わせで実装されてよい。図114は、ハードウェアヘテロジニアススケジューラ回路及びメモリとのそのインタラクションの例を示す。ヘテロジニアススケジューラは、限定されることはないが、フィールドプログラマブルゲートアレイ(FPGA)ベース又は特定用途向け集積回路(ASIC)ベースのステートマシンとして、本明細書で詳細に説明される機能を提供するソフトウェアを内部に格納するメモリに結合される埋め込み型マイクロコントローラ、他のサブコンポーネントを有する論理回路(例えば、データハザード検出回路など)として、及び/又は、アウトオブオーダコアにより実行されるソフトウェア(例えば、ステートマシン)として、スカラコアにより実行されるソフトウェア(例えば、ステートマシン)として、SIMDコアにより実行されるソフトウェア(例えば、ステートマシン)又はこれらの組み合わせとして含む多くの異なる様式で作成されてよい。図示された例では、ヘテロジニアススケジューラは、様々な機能を実行する1又は複数のコンポーネントを含む回路11401である。いくつかの実施形態において、この回路11401は、プロセッサコア11419の一部であるが、チップセットの一部であってもよい。
スレッド/処理要素(PE)トラッカー11403は、システム及び各PEで実行するスレッドごとにステータス(例えば、PEの可用性、その現在の電力消費など)を維持する。例えば、トラッカー11403は、テーブルなどのデータ構造において、アクティブ、アイドル又はインアクティブのステータスを維持する。
いくつかの実施形態において、パターンマッチャ11405は、「ホット」コード、アクセラレータコード、及び/又は、PE割り当てを要求するコードを識別する。このマッチングに関するさらなる詳細が後で提供される。
PE情報11411は、どのようなPE(及びこれらのタイプ)がシステムにあり、何がOSなどによりスケジューリングされ得るかに関する情報を格納する。
上記では、ヘテロジニアススケジューラ回路11401内の別々のコンポーネントとして詳細に説明されているが、一方、コンポーネントは、組み合わせられてよい、及び/又は、ヘテロジニアススケジューラ回路11401の外部に移動されてもよい。
ヘテロジニアススケジューラ回路11401に結合されるメモリ11413は、追加の機能を提供する(コア及び/又はヘテロジニアススケジューラ回路11401により)実行されるソフトウェアを含んでよい。例えば、ソフトウェアパターンマッチャ11417は、「ホット」コード、アクセラレータコード、及び/又は、PE割り当てを要求するコードを識別するために用いられてよい。例えば、ソフトウェアパターンマッチャ11417は、コードシーケンスを、メモリに格納されたパターンの予め決定されたセットと比較する。メモリは、ある命令セットから他の命令セットに(例えば、1つの命令設定からアクセラレータベースの命令又はプリミティブに)コードを変換する変換器を格納してもよい。
これらのコンポーネントは、どのようなリンクプロトコルが使用され、PEなどで既に実行中のスレッドがある場合にどのような移行が発生するべきかなどを、スレッドを実行するためにそのPEの選択を行うセレクタ11411に供給する。いくつかの実施形態において、セレクタ11411は、ハードウェア回路内に実装される、又は、ハードウェア回路により実行される有限ステートマシンである。
メモリ11413は、例えば、いくつかの実施例において、1又は複数の変換器11415(例えば、バイナリ、JITコンパイラなど)が、選択されたPEのために異なるフォーマットにスレッドコードを変換すべく、メモリに格納されることを含んでもよい。
図115は、ソフトウェアヘテロジニアススケジューラの例を示す。ソフトウェアヘテロジニアススケジューラは、限定されることはないが、フィールドプログラマブルゲートアレイ(FPGA)ベース又は特定用途向け集積回路(ASIC)ベースのステートマシンとして、本明細書で詳細に説明される機能を提供するソフトウェアを内部に格納するメモリに結合される埋め込み型マイクロコントローラ、他のサブコンポーネントを有する論理回路(例えば、データハザード検出回路など)として、及び/又は、アウトオブオーダコアにより実行されるソフトウェア(例えば、ステートマシン)として、スカラコアにより実行されるソフトウェア(例えば、ステートマシン)として、SIMDコアにより実行されるソフトウェア(例えば、ステートマシン)又はこれらの組み合わせとして含む多くの異なる様式で作成されてよい。図示された例では、ソフトウェアヘテロジニアススケジューラは、メモリ11413に格納される。その結果、プロセッサコア11419に結合されるメモリ11413は、スレッドをスケジューリングするために(コアにより)実行されるソフトウェアを含む。いくつかの実施形態において、ソフトウェアヘテロジニアススケジューラはOSの一部である。
実装に応じて、コア内のスレッド/処理要素(PE)トラッカー11403は、システム及び各PEにおいて実行するスレッドごとにステータス(例えば、PEの可用性、その現在の電力消費など)を維持する、又は、スレッド/PEトラッカー11521を用いてソフトウェアでこれが実行される。例えば、トラッカーは、テーブルなどのデータ構造において、アクティブ、アイドル又はインアクティブのステータスを維持する。
いくつかの実施形態において、パターンマッチャ11417は、「ホット」コード、及び/又は、PE割り当てを要求するコードを識別する。このマッチングに関するさらなる詳細が後で提供される。
PE情報11409及び/又は11509は、どのようなPEがシステムにあり、何がOSなどによりスケジューリングされ得るかに関する情報を格納する。
ソフトウェアパターンマッチャ11417は、「ホット」コード、アクセラレータコード、及び/又は、PE割り当てを要求するコードを識別するために用いられてよい。
スレッド/PEトラッカー、処理要素情報、及び/又は、パターンマッチは、PEなどで既に実行中のスレッドがある場合、どのようなリンクプロトコルを用いるか、どのような移行が発生するべきかが、スレッドを実行するPEの選択を行うセレクタ11411に供給される。いくつかの実施形態において、セレクタ11411は、プロセッサコア11419より実装されて実行される有限ステートマシンである。
メモリ11413は、例えば、いくつかの実施例において、1又は複数の変換器11415(例えば、バイナリ、JITコンパイラなど)が選択されたPEのために異なるフォーマットにスレッドコードを変換すべく、メモリに格納されることを含んでもよい。
動作中、OSは、実行環境の抽象化を提示する(例えば、ヘテロジニアススケジューラ101、301など)ヘテロジニアススケジューラを利用して、処理対象のスレッドをスケジューリングし、このスレッドを実行する。
以下の表は、潜在的な抽象化特徴(すなわち、プログラムが何を参照するか)、潜在的な設計自由度及びアーキテクチャの最適化(すなわち、何がプログラマから隠れているか)、及び、抽象化における特定の特徴を提供するための潜在的な利益又は理由を要約したものである。
いくつかの例示的な実装において、ヘテロジニアススケジューラは、他のハードウェア及びソフトウェアリソースとの組み合わせにおいて、すべてを実行し、すべてのプログラミング技術(例えば、コンパイラ、組み込み関数、アセンブリ、ライブラリ、JIT、オフロード、デバイス)をサポートする完全なプログラミングモデルを提示する。他の例示的な実装は、他のプロセッサ開発企業、例えば、ARMホールディングス社、MIPS、IBM又はこれらのラインセンシ若しくは採用者により提供されるものに適合する代替的な実行環境を提示する。
図119は、詳細に上述されたように、抽象実行環境を提示するプロセッサのブロック図である。この例では、プロセッサ11901は、いくつかの異なるコアタイプ、例えば、図1に詳細に説明されているものを含む。各(ワイド)SIMDコア11903は、密な算術のプリミティブをサポートする融合積和演算(FMA)回路、独自のキャッシュ(例えば、L1及びL2)、特定用途実行回路及びスレッド状態用のストレージを含む。
各レイテンシ最適化(OOO)コア11913は、融合積和演算(FMA)回路、独自のキャッシュ(例えば、L1及びL2)及びアウトオブオーダ実行回路を含む。
各スカラコア11905は、融合積和演算(FMA)回路、独自のキャッシュ(例えば、L1及びL2)、特定用途実行及びスレッド状態の格納を含む。典型的には、スカラコア11905は、メモリレイテンシをカバーするのに十分なスレッドをサポートする。いくつかの実施例において、SIMDコア11903及びレイテンシ最適化コア11913の数は、スカラコア11905の数と比較して少ない。
いくつかの実施形態において、1又は複数のアクセラレータ11917が含まれる。これらのアクセラレータ11917は、固定機能又はFPGAベースであってよい。これらのアクセラレータ11917とは代替的に又はこれらに加えて、いくつかの実施形態では、アクセラレータ11917は、プロセッサの外部にある。
プロセッサ11901はまた、プロセッサ内にあるコア及び潜在的に任意のアクセラレータにより共有されるラストレベルキャッシュ(LLC)11907を含む。いくつかの実施形態において、LLC11907は、高速アトミック用の回路を含む。
1又は複数の相互接続11915は、コア及びアクセラレータを互いに、及び、外部インタフェースに結合する。例えば、いくつかの実施形態では、メッシュ型の相互接続が様々なコアを結合する。
メモリコントローラ11909は、コア及び/又はアクセラレータをメモリに結合する。
複数の入力/出力インタフェース(例えば、以下で詳細に説明されるPCIe、共通のリンク)11911は、プロセッサ11901を外部デバイス、例えば、他のプロセッサ及びアクセラレータに接続する。
図4は、コンピュータシステムのシステムブート及びデバイス発見についての実施形態を示す。システムについての知識は、例えば、どのようなコアが利用可能であるか、どれくらいのメモリが利用可能であるか、コアに関連するメモリ位置などがヘテロジニアススケジューラにより利用されるかといった知識を含む。いくつかの実施形態において、この知識は、アドバンスド・コンフィグレーション・アンド・パワー・インタフェース(ACPI)を用いて構築される。
401において、コンピュータシステムがブートされる。
403において、構成設定のクエリが行われる。例えば、いくつかのBIOSベースのシステムでは、ブートされたときに、BIOSは、システムの動作確認を行い、ドライブ及び他の構成設定を独自のメモリバンクにクエリすることにより、オペレーション用のコンピュータを準備する。
405において、プラグインコンポーネントの探索が行われる。例えば、BIOSは、コンピュータ内の任意のプラグインコンポーネントを探索し、メモリ内のポインタ(割込みベクトル)をセットアップしてそれらのルーチンにアクセスする。BIOSは、デバイスドライバ並びにアプリケーションプログラムから、ハードウェア及び他の周辺デバイスとのインタフェース接続に関する要求を受け入れる。
407において、システムコンポーネント(例えば、コア、メモリなど)のデータ構造が生成される。例えば、BIOSは、典型的には、OSが付属デバイスとインタフェースするハードウェアデバイス及び周辺デバイス構成情報を生成する。さらに、ACPIは、システムボードに対する柔軟でスケーラブルなハードウェアインタフェースを定義し、コンピュータが、特に、ノートブックコンピュータなどのポータブルデバイスにおいて、電源管理を改善するために、その周辺機器をオン及びオフすることを可能にする。ACPI仕様は、ハードウェアインタフェースと、ソフトウェアインタフェース(API)と、実装される場合、OS指向構成及び電源管理をサポートするデータ構造とを含む。ソフトウェアの設計者は、ACPIを用いて、ハードウェア、オペレーティングシステム及びアプリケーションソフトウェアを含むコンピュータシステム全体の電源管理機能を統合できる。この統合は、どのデバイスがアクティブであり、コンピュータサブシステム及び周辺機器に対する電源管理リソースのすべてを処理するかをOSが判断することを可能にする。
409において、オペレーティングシステム(OS)がロードされて、制御を獲得する。例えば、BIOSがその起動ルーチンを完了した時点で、BIOSは制御をOSに渡す。ACPIである場合、BIOSは、コンピュータの制御をOSに渡し、BIOSは、ACPI名前空間を含むデータ構造をOSにエクスポートし、それは、ツリーとしてグラフィカルに表され得る。名前空間は、コンピュータに接続されたACPIデバイスのディレクトリとして動作し、各ACPIデバイスに対してステータス情報をさらに定義及び提供するオブジェクトを含む。ツリー内の各ノードは、デバイスと関連付けられており、一方、OSにより評価される場合、デバイスを制御し、ACPI仕様で規定されるような特定の情報をOSに返すノード、サブノード及びリーフがオブジェクトを表す。OS又はOSによりアクセスされるドライバは、名前空間オブジェクトを列挙及び評価する機能のセットを含んでよい。OSが機能をコールして、ACPI名前空間内のオブジェクトの値を返す場合、OSは、そのオブジェクトを評価したといえる。
いくつかの例において、利用可能なデバイスが変わる。例えば、アクセラレータ、メモリなどが加えられる。ポストシステムブートデバイス発見のための方法の実施形態が図116に示される。例えば、この方法の実施形態は、ブート後のシステムに追加されたアクセラレータを発見するために用いられてよい。11601において、電源オン又はリセットされる接続されたデバイスのインジケーションが受信される。例えば、エンドポイントデバイスは、例えば、OSにより、PCIeスロットにプラグ接続される、又は、リセットされる。
11603において、リンクトレーニングが接続されたデバイスを用いて実行され、接続されたデバイスが初期化される。例えば、PCIeのリンクトレーニングは、リンク幅、レーン極性、及び/又は、サポートされる最大データレートなどのリンク構成パラメータを確立するために実行される。いくつかの実施形態において、接続されたデバイスの性能は、(例えば、ACPIテーブルに)格納される。
11605において、接続されたデバイスの初期化が完了した場合、準備完了メッセージ(ready message)が接続されたデバイスからシステムに送信される。
11607において、デバイスが構成を準備できたことを示すために、接続されたデバイスの準備完了ステータスビットが設定される。
11609において、初期化された、接続されたデバイスが構成される。いくつかの実施形態において、デバイス及びOSは、デバイス用のアドレス(例えば、メモリマッピングされたI/O(MMIO)アドレス)について合意する。デバイスは、ベンダ識別番号(ID)、デバイスID、モデル番号、シリアル番号、特性、リソース要件などのうちの1又は複数を含むデバイス記述子を提供する。OSは、記述子データ及びシステムリソースに基づいて、デバイスに対する追加の動作及び構成パラメータを判断してよい。OSは、構成クエリを生成してよい。デバイスは、デバイス記述子に応答してよい。次に、OSは、構成データを生成して、このデータを(例えば、PCIハードウェアを通じて)デバイスに送信する。これは、デバイスと関連付けられるアドレス空間を定義するベースアドレスレジスタの設定を含んでよい。
システムの知識が構築された後に、OSは、ヘテロジニアススケジューラ(例えば、ヘテロジニアススケジューラ101、301など)を利用して、処理対象のスレッドをスケジューリングして、このスレッドを実行する。次に、ヘテロジニアススケジューラは、各スレッドのコードフラグメントを、(例えば、ユーザ及び/又はOSに対して)動的かつ透過的に最も適したタイプの処理要素へマッピングし、それにより、レガシアーキテクチャ機構用のハードウェアを構築する必要性、及び潜在的にシステムプログラマ又はOSにマイクロアーキテクチャの詳細をさらす必要性を潜在的に回避する。
いくつかの例では、最も適したタイプの処理要素は、処理要素の性能及びコードフラグメントの実行特性に基づいて判断される。一般的に、プログラム及び関連するスレッドは、所与の時点で処理されるワークロードに応じて、異なる実行特性を有し得る。例示的な実行特性、又は、実行のフェーズは、例えば、データ並列フェーズ、スレッド並列フェーズ及び直列フェーズを含む。以下のテーブルは、これらのフェーズを識別し、これらの特性を要約したものである。テーブルはまた、例示的なワークロード/オペレーション、各フェーズタイプを処理する場合に有用な例示的なハードウェア、及び、用いられるフェーズ及びハードウェアの典型的な目的を含む。
いくつかの実施例において、ヘテロジニアススケジューラは、スレッド移行及びエミュレーションのどちらかを選択するように構成される。各タイプの処理要素が、任意のタイプのワークロードを処理できる構成(そうするためのエミュレーションを要求する場合)では、例えば、ワークロードのレイテンシ要件、エミュレーションと関連付けられた増加した実行レイテンシ、処理要素の電力及び熱的特性及び制約などを含む1又は複数の基準に基づいて、最も適した処理要素がプログラムフェーズごとに選択される。後で詳細に説明されるように、適した処理要素の選択は、いくつかの実施例において、実行中のスレッドの数を考慮して、コードフラグメント内のSIMD命令又はベクトル化可能コードの存在を検出することにより実現される。
処理要素間でスレッドを移動することは、不利益がないわけではない。例えば、データは、共有キャッシュから下位レベルキャッシュに移動される必要がある可能性があり、元の処理要素及び受け手の処理要素の両方は、移動に順応するために、これらのパイプラインをフラッシュさせるだろう。状況に応じて、いくつかの実施例では、ヘテロジニアススケジューラは、(例えば、上記で参照した1又は複数の基準に対する閾値、又は、同じもののサブセットを設定することによる)非常に頻繁な移行を回避するためにヒステリシスを実装する。いくつかの実施形態において、ヒステリシスは、予め定義されたレート(例えば、1移行毎ミリ秒)を超えないようにスレッド移行を制限することにより実装される。したがって、当該移行のレートは、コード生成、同期及びデータ移行に起因する過剰なオーバーロードを回避するために制限される。
いくつかの実施形態において、例えば、特定のスレッドに対する好ましアプローチであるものとして、ヘテロジニアススケジューラにより移行が選択されない場合、ヘテロジニアススケジューラは、割り当てられた処理要素にスレッドのための欠落した機能をエミュレートする。例えば、オペレーティングシステムに対して利用可能なスレッドの総数を一定に維持する実施形態において、ヘテロジニアススケジューラは、(例えば、ワイド同時マルチスレッディングコアにおいて)利用可能なハードウェアスレッドの数がオーバサブスクライブされる場合に、マルチスレッディングをエミュレートしてよい。スカラ又はレイテンシコア上で、スレッドの1又は複数のSIMD命令がスカラ命令に変換される、又は、SIMDコア上で、より多くのスレッドがスポーンされ、及び/又は、命令が、パックドデータを利用するために変換される。
図5は、処理要素の3つのタイプに対するプログラムフェーズのマッピングに基づいたスレッド移行の例を示す。図示されるように、処理要素の3つのタイプは、レイテンシの最適化(例えば、アウトオブオーダコア、アクセラレータなど)、スカラ(命令毎時間で1つのデータ項目を処理すること)及びSIMD(命令毎に複数のデータ要素を処理すること)を含む。典型的には、このマッピングは、スレッド毎又はコードフラグメント毎に、プログラマ及びオペレーティングシステムに対して透過的な態様で、ヘテロジニアススケジューラにより実行される。
一実施例では、ヘテロジニアススケジューラを用いて、ワークロードの各フェーズを最も適したタイプの処理要素にマッピングする。理想的には、これは、レガシ機能用のハードウェアを構築する必要性を軽減し、コンパイルコード(マシンコード)、組み込み関数(プロセッサ又はアクセラレータ命令に直接マッピングするプログラミング言語論理構成)、アセンブリコード、ライブラリ、中間(JITベース)、オフロード(一方のマシンタイプから別のマシンタイプへの移動)及びデバイスに固有などの複数のコードタイプをサポートする完全なプログラミングモデルをヘテロジニアススケジューラが提示するマイクロアーキテクチャの詳細をさらすことを回避する。
特定の構成において、ターゲット処理要素に対するデフォルトの選択は、レイテンシが最適化される処理要素である。
図5を再び参照すると、ワークロードに対する直列フェーズの実行501では、1又は複数のレイテンシが最適化された処理要素で最初に処理される。(例えば、実行の前又は実行中のコードにおいて得られた命令のタイプにより例えば見られるような、コードがより多くのデータを並列化するような動的なやり方で、又は、実行の前に)位相シフトを検出すると、ワークロードは、データ並列フェーズの実行503を完了するために、1又は複数のSIMD処理要素に移行される。さらに、実行スケジューリング及び/又は変換は、典型的にはキャッシュされる。その後、ワークロードは、1又は複数のレイテンシが最適化された処理要素、又は、1又は複数のレイテンシが最適化された処理要素の第2のセットに戻って移行されて、次の直列フェーズの実行505を完了する。次に、ワークロードは、スレッド並列フェーズの実行507を処理するために、1又は複数のスカラコアに移行される。次に、ワークロードは、次の直列フェーズの実行509の完了のために、1又は複数のレイテンシが最適化された処理要素に戻って移行される。
この図示された例は、レイテンシが最適化されたコアへの復帰を示す一方、ヘテロジニアススケジューラは、スレッドが終了されるまで1又は複数の対応するタイプの処理要素において、任意の後続のフェーズの実行についての実行を継続してよい。いくつかの実施例では、処理要素は、ワークキューを利用して、完了していないタスクを格納する。その結果、タスクは、すぐに開始しなくてもよいが、キュー内のこれらのスポットが現れたときに実行される。
図6は、ヘテロジニアススケジューラ、例えば、ヘテロジニアススケジューラ101などにより実行される例示的な実施フローである。このフローは、処理要素(例えば、コア)の選択を図示する。図示されるように、ヘテロジニアススケジューラによりコードフラグメントが受信される。いくつかの実施形態において、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す1又は複数の命令を含むイベントが発生する。
601において、ヘテロジニアススケジューラは、例えば、検出されたデータの依存性、命令タイプ及び/又は制御フロー命令に基づいて、(例えば、直列フェーズ又は並列フェーズにおけるコードフラグメントである)コードフラグメントに並列性があるか否かを判断する。例えば、SIMDコードでいっぱいのスレッドは、並列とみなされるであろう。コードフラグメントが並列処理に適していない場合、ヘテロジニアススケジューラは、1又は複数のレイテンシに敏感なオペレーション要素(例えば、OOOコア)を選択し、直列フェーズの実行603においてコードフラグメントを処理する。典型的には、OOOコアは、(深層)推論及び動的なスケジューリングを有し、通常、より簡単な代替物と比較してワット性能が低い。
いくつかの実施形態では、典型的には、レイテンシに敏感なオペレーション要素はスカラコアより多くの電力及びダイ空間を消費するので、利用可能なレイテンシに敏感なオペレーション要素がない。これらの実施形態では、スカラ、SIMD及びアクセラレータコアのみが利用可能である。
605において、並列コードフラグメント、並列化可能なコードフラグメント及び/又はベクトル化可能コードフラグメントに関し、ヘテロジニアススケジューラは、コードの並列性についてのタイプを判断する。607において、スレッド並列コードフラグメントに関し、ヘテロジニアススケジューラは、スレッド並列処理要素(例えば、マルチプロセッサスカラコア)を選択する。スレッド並列コードフラグメントは、別々のスカラコアで同時に実行され得る独立した命令シーケンスを含む。
各処理要素が異なる数のデータに同じタスクを実行した場合に、データ並列コードが発生する。データ並列コードは、パックド及びランダムという異なるデータレイアウトの形式があり得る。609において、データレイアウトが判断される。ランダムデータは、SIMD処理要素に割り当てられてよいが、異なるメモリ位置からデータを引き出すギャザー命令613、(小型のプログラマブル処理要素のアレイ、例えば、FPGAのアレイ上に計算を空間的にマッピングする)空間計算アレイ615、又は、スカラ処理要素617のアレイを利用することが必要である。パックドデータは、611において密な算術のプリミティブを用いるSIMD処理要素又は処理要素に割り当てられる。
いくつかの実施形態において、選択された宛先処理要素をより良く適合させるようにコードフラグメントの変換が実行される。例えば、コードフラグメントは、1)異なる命令セットを利用するために変換され、2)より多く並列化され、3)あまり並列化されず(直列化され)、4)データを並列化し(例えば、ベクトル化され)、及び/又は、5)データをあまり並列化しない(例えば、非ベクトル化される)。
処理要素が選択された後、コードフラグメントは、実行のために判断された処理要素のうちの1つに送信される。
図7は、ヘテロジニアススケジューラによるスレッド宛先選択のための方法についての例を示す。いくつかの実施形態において、この方法は、バイナリトランスレータにより実行される。701において、評価対象のスレッド又はこれらのコードフラグメントが受信される。いくつかの実施形態において、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す1又は複数の命令を含むイベントが発生する。
703において、コードフラグメントがアクセラレータにオフロードされるか否かの判断が行われる。例えば、アクセラレータに送信されるコードフラグメントである。ヘテロジニアススケジューラは、コードがアクセラレータを用いるという要望を識別するコードを含む場合、これが訂正動作であることを知り得る。この要望は、コードの領域がアクセラレータ上で実行され、又は、ネイティブに(例えば、本明細書で説明されたABEGIN/AEND)実行されてよいことを示す識別子、又は、特定のアクセラレータを用いる明示的なコマンドであってよい。
いくつかの実施形態では、705において、選択された宛先処理要素をより良く適合させるようにコードフラグメントの変換が実行される。例えば、コードフラグメントは、1)異なる命令セットを利用するために変換され、2)より多く並列化され、3)あまり並列化されず(直列化され)、4)データを並列化し(例えば、ベクトル化され)、及び/又は、5)データをあまり並列化しない(例えば、非ベクトル化される)。
典型的には、707において、変換されたスレッドは、後の使用のためにキャッシュされる。いくつかの実施形態において、バイナリトランスレータは、将来におけるバイナリトランスレータの使用のために利用可能となるように変換されたスレッドをローカルにキャッシュする。例えば、コードが「ホット」になる(繰り返し実行される)場合、キャッシュは、(送信コストがあり得るが)変換の不利益なく将来の利用のためのメカニズムを提供する。
709において、(変換された)スレッドは、処理のために宛先処理要素に送信される(例えば、オフロードされる)。いくつかの実施形態において、変換されたスレッドは、将来の利用のためにローカルに利用可能であるように受け手によりキャッシュされる。さらに、受け手又はバイナリトランスレータは、コードが「ホット」であると判断した場合、このキャッシングは、使用されるエネルギーが少ない状態でより高速な実行を可能にする。
711において、ヘテロジニアススケジューラは、例えば、検出されたデータの依存性、命令タイプ及び/又は制御フロー命令に基づいて、(例えば、直列フェーズ又は並列フェーズにおけるコードフラグメントである)コードフラグメントに並列性があるか否かを判断する。例えば、SIMDコードでいっぱいのスレッドは、並列とみなされるであろう。コードフラグメントが並列処理に適していない場合、ヘテロジニアススケジューラは、1又は複数のレイテンシに敏感なオペレーション要素(例えば、OOOコア)を選択し、直列フェーズの実行713においてコードフラグメントを処理する。典型的には、OOOコアは、(深層)推論及び動的なスケジューリングを有し、故に、スカラの代替物と比較してワット性能が良好であり得る。
いくつかの実施形態では、典型的には、レイテンシに敏感なオペレーション要素はスカラコアより多くの電力及びダイ空間を消費するので、利用可能なレイテンシに敏感なオペレーション要素がない。これらの実施形態では、スカラ、SIMD及びアクセラレータコアのみが利用可能である。
715において、並列コードフラグメント、並列化可能なコードフラグメント及び/又はベクトル化可能コードフラグメントに関し、ヘテロジニアススケジューラは、コードの並列性についてのタイプを判断する。717において、スレッド並列コードフラグメントに関し、ヘテロジニアススケジューラは、スレッド並列処理要素(例えば、マルチプロセッサスカラコア)を選択する。スレッド並列コードフラグメントは、別々のスカラコアで同時に実行され得る独立した命令シーケンスを含む。
各処理要素が異なる数のデータに同じタスクを実行した場合に、データ並列コードが発生する。データ並列コードは、パックド及びランダムという異なるデータレイアウトの形式があり得る。719において、データレイアウトが判断される。ランダムデータは、SIMD処理要素に割り当てられてよいが、ギャザー命令723、空間計算アレイ725又はスカラ処理要素727のアレイを利用することが必要である。パックドデータは、721において密な算術のプリミティブを用いるSIMD処理要素又は処理要素に割り当てられる。
いくつかの実施形態において、判断される宛先処理要素をより良く適合させるようにオフロードされていないコードフラグメントの変換が実行される。例えば、コードフラグメントは、1)異なる命令セットを利用するために変換され、2)より多く並列化され、3)あまり並列化されず(直列化され)、4)データを並列化し(例えば、ベクトル化され)、及び/又は、5)データをあまり並列化しない(例えば、非ベクトル化される)。
処理要素が選択された後、コードフラグメントは、実行のために判断された処理要素のうちの1つに送信される。
OSは、コア及びアクセラレータがアクセス可能であることに関わらず、潜在的に利用可能なスレッドの総数を参照する。以下の説明では、論理IDと呼ばれるスレッド識別子(ID)によって各スレッドが列挙される。いくつかの実施例において、オペレーティングシステム及び/又はヘテロジニアススケジューラは、論理IDを利用して、特定の処理要素のタイプ(例えば、コアタイプ)、処理要素ID及びその処理要素上のスレッドID(例えば、コアタイプのタプル、コアID、スレッドID)にスレッドをマッピングする。例えば、スカラコアは、コアID及び1又は複数のスレッドIDを有し、SIMDコアは、コアID及び1又は複数のスレッドIDを有し、OOOコアは、コアID及び1又は複数のスレッドIDを有し、及び/又は、アクセラレータは、コアID及び1又は複数のスレッドIDを有する。
図8は、論理IDに対する縞模様マッピングの使用についての概念を示す。縞模様マッピングは、ヘテロジニアススケジューラにより用いられてよい。この例では、8つの論理的なID、及び、それぞれが1又は複数のスレッドを有する3つのコアタイプがある。典型的には、論理IDから(コアID、スレッドID)へのマッピングは、除算及びモジュロを用いて計算され、ソフトウェアスレッドの共通性を保つために固定されていてよい。論理IDから(コアタイプ)へのマッピングは、OSに利用しやすい将来の新たなコアタイプに順応するように、ヘテロジニアススケジューラにより柔軟に実行される。
図9は、論理IDに対する縞模様マッピングの使用についての例を示す。例では、論理ID1、4及び5が第1のコアタイプにマッピングされ、その他すべての論理IDが第2のコアタイプにマッピングされる。第3のコアタイプは利用されていない。
いくつかの実施例では、コアタイプのグループ化が作成される。例えば、「コアグループ」タプルが、1つのOOOタプル及びすべてのスカラ、SIMD、並びに、論理IDが同じOOOタプルにマッピングするアクセラレータコアタプルからなってよい。図10は、コアグループの例を示す。典型的には、直列フェーズ検出及びスレッド移行が同じコアグループ内で実行される。
図11は、バイナリトランスレータ切替メカニズムを利用するシステムにおけるスレッド実行の方法の例を示す。1101において、スレッドがコア上で実行される。コアは、アクセラレータを含む、本明細書で詳細に説明されるタイプのいずれかであってよい。
1103において、スレッドの実行中のいくつかの時点で、潜在的なコアの再割り当てイベントが発生する。例示的なコアの再割り当てイベントは、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び異なるコアへの所望の再割り当てを示す1又は複数の命令を含む。
1105において、イベントは、処理されて、コア割り当てに変更があるか否かに応じた判断が行われる。ある特定のコア割り当ての処理に関する例示的な方法を以下に詳細に説明する。
いくつかの実施形態において、コアの(再)割り当ては、移動率の制限及び電力消費の制限などの1又は複数の制限要因を対象とする。移動率の制限は、コアタイプ、コアID及びスレッドID毎に追跡される。一旦スレッドがターゲット(コアタイプ、コアID、スレッドID)に割り当てられると、タイマが開始されてバイナリトランスレータにより維持される。タイマが期限切れになるまで、同じターゲットに移行されるスレッドは他にない。その結果、スレッドは、タイマが期限切れになる前にその現在のコアから離れて移行してもよい一方、その逆は成り立たない。
詳細に説明されるように、より多くのコアタイプ(アクセラレータを含む)がコンピューティングシステム(オン又はオフダイのいずれか一方)に追加されるにつれて、電力消費の制限に対する注目が高まる可能性が高い。いくつかの実施形態において、すべてのコア上のすべての実行スレッドにより消費される瞬間的な電力が計算される。計算された電力消費が閾値を超える場合、新たなスレッドが、より低い電力のコア、例えば、SIMD、スカラ及び専用のアクセラレータコアに割り当てられるだけであり、1又は複数のスレッドは、OOOコアからより低い電力のコアに強制的に移行させられる。いくつかの実施例では、電力消費の制限は、移動率の制限よりも優先されることに留意する。
図12は、アクセラレータに対するホットコードのコア割り当てについての例示的な方法を示す。1201において、コードが「ホット」であるという判断が行われる。コードのホット部分は、電力、性能、熱、他の既知のプロセッサ基準又はこれらの組み合わせなどの考慮に基づいて、その他のコアを介して1つのコア上で実行するのにより適しているコードの一部を指し得る。この判断は、任意の数の技術を用いて行われてよい。例えば、動的バイナリオプティマイザが、スレッドの実行をモニタリングするために利用されてよい。ホットコードは、プログラム実行中などに、静的コードの動的な実行頻度を記録するカウンタ値に基づいて検出されてよい。コアがOOOコアであり、別のコアがインオーダコアである実施形態において、次に、コードのホット部分は、直列コア上で実行されるのにより適しているプログラムコードのホットスポットを指してよく、高反復セクションの実行のために、より多くの利用可能なリソースを潜在的に有する。多くの場合、高反復パターンを有するコードのセクションは、インオーダコア上でより効率的に実行されるように最適化され得る。本質的には、この例において、コールドコード(低反復)が、ネイティブOOOコアに分配され、一方、ホットコード(高反復)は、ソフトウェア管理されたインオーダコアに分配される。コードのホット部分は、静的、動的又はこれらの組み合わせで識別されてよい。第1のケースでは、コンパイラ又はユーザは、プログラムコードおセクションがホットコードであると判断してよい。コア内のデコード論理は、一実施形態において、プログラムコードからのホットコード識別子命令をデコードするために適合され、当該命令は、プログラムコードのホット部分を識別する。そのような命令のフェッチ又はデコードは、コア上のコードのホットセクションの変換及び/又は実行をトリガし得る。別の例では、コード実行は、プロファイルされた実行であり、プロファイルの特性−実行と関連付けられた電力及び/又は性能メトリック−に基づいており、プログラムコードの領域は、ホットコードとして識別され得る。ハードウェアのオペレーションと同様に、他のコア上で実行されているプログラムコードのモニタリング/プロファイリングを実行するために、モニタリングコードが1つのコア上で実行されてよい。そのようなモニタリングコードは、コア内のストレージ構造において保持される又はプロセッサを含むシステムにおいて保持されるコードであってよいことに留意する。例えば、モニタリングコードは、マイクロコード又は他のコードであってよく、コアのストレージ構造において保持される。さらに別の例として、ホットコードの静的な識別は、暗示として行われる。しかしながら、プログラムコード実行の動的プロファイリングは、ホットとしてのコードの領域静的な識別を無視することができ、このタイプの静的な識別は、多くの場合、どのコアがコード分散に適切であるかを判断する際に動的プロファイリングが考慮してよいコンパイラ又はユーザ暗示と称される。さらに、動的プロファイリングの特性と同様に、ホットとしてのコードの領域の識別は、そのコードのセクションが常にホットとして識別されるように制限されるわけではない。変換及び/又は最適化の後、コードセクションの変換バージョンが実行される。
1203において、適切なアクセラレータが選択される。バイナリトランスレータ、仮想マシンモニタ又はオペレーティングシステムは、利用可能なアクセラレータ及び所望の性能に基づいてこの選択を行う。多くの例では、アクセラレータは、より大きくてより一般的なコアよりも1ワットあたりの向上した性能でホットコードを実行するのにより適切である。
1205において、ホットコードは、選択されたアクセラレータに送信される。この送信は、本明細書で詳細に説明されるように、適切な接続タイプを利用する。
最後に、1207において、ホットコードは、選択されたアクセラレータにより受信されて実行される。実行の間、ホットコードは、異なるコアへの割り当てについて評価されてよい。
図13は、ページディレクトリベースレジスタイベントに対するウェイクアップ又は書き込みのための可能性があるコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。1301において、ウェイクアップイベント又はページディレクトリベースレジスタ(例えば、タスク切替)イベントのいずれか一方が検出される。例えば、ウェイクアップイベントは、停止されたスレッド又は待機状態終了により受信された割込みのために発生する。ページディレクトリベースレジスタへの書き込みは、直列フェーズの開始又は停止を示し得る。典型的には、この検出は、バイナリトランスレータを実行しているコア上で発生する。
1303において、ウェイクアップした又はタスク切替を経験したスレッドと同じページテーブルベースポインタを共有するコアの数がカウントされる。いくつかの実施例において、テーブルは、論理IDを特定のヘテロジニアスコアにマッピングするために用いられる。テーブルは、論理IDによりインデックス付けされる。テーブルの各エントリは、論理IDが現在有効であるか又は停止されているかを示すフラグ、SIMD又はスカラコアのどちらを好むかを示すフラグ、ページテーブルベースアドレス(例えば、CR3)、論理IDが現在マッピングされているコアのタイプを示す値、及び、移動率を制限するカウンタを含む。
同じ処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する。
1305において、カウントされたコアの数が1より大きいか否かに応じた判断が行われる。このカウントは、スレッドが、直列又は並列フェーズにあるか否かを判断する。カウントが1である場合、次に、イベントを経験しているスレッドは、直列フェーズ1307にある。その結果、直列フェーズスレッドは、同じコアグループ内のすべてのスレッドの中で一意的なページディレクトリベースレジスタ値を有するスレッドである。図14は、直列フェーズスレッドの例を示す。図示されるように、処理は、1又は複数のスレッドを有し、各処理は独自に割り当てられたアドレスを有する。
1313又は1315において、イベントを経験しているスレッドがOOOコアに割り当てられていない場合、それはOOOコアに移行され、OOOコア上の既存のスレッドは、SIMD又はスカラコアに移行される。イベントを経験しているスレッドがOOOコアに割り当てられている場合、それは、多くの状況でそこに留まる。
カウントが1より大きい場合、次に、1309において、イベントを経験しているスレッドは、並列フェーズにあり、並列フェーズのタイプの判断が行われる。イベントを経験しているスレッドがデータ並列フェーズにあるときに、スレッドがSIMDコアに割り当てられていない場合、当該スレッドはSIMDコアに割り当てられ、そうでない場合、1313において、既にそこにあるならば、当該スレッドはSIMDコア上に維持される。
イベントを経験しているスレッドがデータ並列フェーズにあるときに、スレッドがSIMDコアに割り当てられていない場合、当該スレッドはSIMDコアに割り当てられ、そうでない場合、1313において、既にそこにあるならば、当該スレッドはSIMDコア上に維持される。
イベントを経験しているスレッドが、スレッド並列フェーズにあるときに、スレッドがスカラコアに割り当てられていない場合、当該スレッドはスカラコアに割り当てられ、そうでない場合、既に1315においてそこにあるならば、当該スレッドはスカラコア上に維持される。
さらに、いくつかの実施例では、スレッドが実行中であることを示すフラグがスレッドの論理IDに対して設定される。
図15は、スリープコマンドイベントに対するスレッド応答のための潜在的なコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。1501において、スレッドに影響を与えるスリープイベントが検出される。例えば、停止、待機エントリ及びタイムアウト又は一時停止コマンドが発生する。典型的には、この検出は、バイナリトランスレータを実行しているコア上で発生する。
いくつかの実施形態では、1503において、スレッドが実行中であることを示すフラグがスレッドの論理IDに対してクリアされる。
1505において、スリープスレッドと同じページテーブルベースポインタを共有するコアのスレッドの数がカウントされる。いくつかの実施例において、テーブルは、論理IDを特定のヘテロジニアスコアにマッピングするために用いられる。テーブルは、論理IDによりインデックス付けされる。テーブルの各エントリは、論理IDが現在有効であるか又は停止されているかを示すフラグ、SIMD又はスカラコアのどちらを好むかを示すフラグ、ページテーブルベースアドレス(例えば、CR3)、論理IDが現在マッピングされているコアのタイプを示す値、及び、移動率を制限するカウンタを含む。グループからの(任意のページテーブルベースポインタを有する)第1の実行スレッドについて触れる。
1507において、システム内のOOOコアがアイドルであるか否かに応じた判断が行われる。アイドルのOOOコアは、アクティブに実行しているOSのスレッドがない。
ページテーブルベースポインタが、コアグループ内の完全に1つのスレッドにより共有されている場合、次に、1509において、共有スレッドは、SIMD又はスカラコアからOOOコアに移動される。ページテーブルベースポインタが1つより多くのスレッドにより共有されている場合、次に、1511において、前に述べたグループの第1の実行スレッドは、(第1の実行スレッドの場所で実行する)解除されたスレッドのためにスペースを空けるべく、SIMD又はスカラコアからOOOコアに移行されたスレッドである。
図16は、フェーズ変更イベントに応じたスレッドのための可能性があるコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。1601において、潜在的なフェーズ変更イベントが検出される。典型的には、この検出は、バイナリトランスレータを実行するコアで発生する。
1603において、スレッドの論理IDがスカラコア上で有効であり、SIMD命令が存在するか否かに応じた判断が行われる。そのようなSIMD命令がない場合、次に、スレッドは、通常通りに実行を継続する。しかしながら、スカラコアで実行中のスレッドに存在するSIMD命令がある場合、次に、スレッドは、1605においてSIMDコアに移行される。
1607において、スレッドの論理IDがSIMDコア上で有効であり、SIMD命令が存在しないか否かに応じた判断が行われる。SIMD命令がある場合、次に、スレッドは、通常通りに実行を継続する。しかしながら、SIMDコア上で実行中のスレッドに存在するSIMD命令がない場合、次に、スレッドは、1609においてスカラコアに移行される。
この説明を通じて述べたように、バイナリトランスレータからアクセス可能なアクセラレータは、より効率的な実行(よりエネルギーの効率的な実行を含む)を提供し得る。しかしながら、それぞれの潜在的に利用可能なアクセラレータに対してプログラムを作成することを可能にすることは、不可能ではないにしても、難しい課題であるかもしれない。
本明細書において詳細に説明されるのは、スレッドの一部についての潜在的なアクセラレータベースの実行の開始及び終了を明示的に示す記述命令を用いる実施形態である。利用可能なアクセスレータがない場合、記述命令間のコードは、アクセラレータの使用がないままで実行される。いくつかの実施例において、これらの命令間のコードは、実行しているコアのいくつかのセマンティクスを緩和し得る。
図17は、加速領域を記述するコードの例を示す。この領域の第1の命令は、加速開始(ABEGIN)命令1701である。いくつかの実施形態において、ABEGIN命令は、非アクセラレータコアに関する実行についての緩和された(サブ)モードに入るための許可を与える。例えば、いくつかの実施例におけるABEGIN命令は、どのサブモードの特徴が標準モードとは異なるかをプログラマ又はコンパイラが命令のフィールドにおいて示すことを可能にする。例示的な特徴は、限定されることはないが、自己書き換えコード(SMC)を無視すること、メモリ一貫性モデル制限を弱めること(例えば、格納オーダリング要求を緩和する)、浮動小数セマンティクスを変更すること、パフォーマンスモニタリング(perfmon)を変更すること、アーキテクチャフラグの利用を変更すること、などのうちの1又は複数を含む。いくつかの実施例では、SMCは、関連するキャッシュライン(又はライン)を無効にさせるプロセッサに現在キャッシュされているコードセグメント内のメモリ位置への書き込みである。書き込みがプリフェッチ命令に影響を与える場合、プリフェッチキューは無効にされる。この後者のチェックは、命令の線形アドレスに基づいている。ターゲット命令が既にデコードされており、トレースキャッシュ内に存在するコードセグメント内の命令の書き込み又はスヌープは、トレースキャッシュ全体を無効にする。SMCは、トランスレーションルックアサイドバッファ内のSMC検出回路の調整により無視されてよい。例えば、1又は複数のレジスタ又はテーブル(例えば、メモリタイプ範囲レジスタ又はページ属性テーブル)内の設定を変更することにより、メモリ一貫性モデル制限が変更されてよい。例えば、浮動小数セマンティクスを変更する場合、浮動小数点実行回路が浮動小数点計算を実行する方法は、これらの回路の動作を制御する1又は複数の制御レジスタ(例えば、浮動小数点演算ユニット(FPU)制御ワードレジスタを設定する)の使用を通じて変更される。変更する可能性がある浮動小数セマンティクスは、限定されることはないが、丸めモード、例外マスク及びステータスフラグがどのように処理されるか、フラッシュトゥゼロ(flush−to−zero)、非正規化の設定、及び、精度(例えば、単精度、倍精度、拡張精度)制御を含む。さらに、いくつかの実施形態において、ABEGIN命令は、好ましいタイプのアクセラレータが利用可能である場合にそれが選択されるように、明示的なアクセラレータタイプの好みを考慮する。
非アクセラレータコード1703は、ABEGIN命令1701に従う。このコードは、システムのプロセッサコアに対してネイティブである。最悪の場合、利用可能なアクセスレータがない、又は、ABEGINがサポートされていない場合、このコードがそのままコア上で実行されてしまう。しかしながら、いくつかの実施例において、サブモードがその実行のために用いられる。
加速終了(AEND)命令1705を有することにより、アクセラレータが実行を完了したように見えるようになるまで、その実行は、プロセッサコア上でゲート(gated)される。効果的には、ABEGIN及びAENDの使用は、アクセラレータ及び/又は緩和モードの実行を用いて、プログラマがオプトイン/アウトをすることを可能にする。
図18は、ハードウェアプロセッサコアにおけるABEGINを用いた実行についての方法の実施形態を示す。1801において、スレッドのABEGIN命令がフェッチされる。前に述べたように、ABEGIN命令は、典型的には、異なる(サブ)モードの実行を定義するために用いられる1又は複数のフィールドを含む。
1803において、フェッチされたABEGIN命令は、デコード回路を用いてデコードされる。いくつかの実施形態において、ABEGIN命令は、マイクロオペレーションにデコードされる。
1805において、デコードされたABEGIN命令は、ABEGIN命令に従うが、AEND命令の前である命令に対する、(ABEGIN命令の1又は複数のフィールドにより明示的に規定されてよい)異なるモードへとスレッドが入るように実行回路により実行される。実行のこの異なるモードは、アクセラレータの可用性及び選択範囲に応じて、アクセラレータ上又は既存のコア上であってよい。いくつかの実施形態において、アクセラレータの選択は、ヘテロジニアススケジューラにより実行される。
1807において、後続の非AEND命令は、実行の異なるモードで実行される。アクセラレータが実行のために用いられる場合に、当該命令は、まず、バイナリトランスレータにより異なる命令セットに変換されてよい。
図19は、ハードウェアプロセッサコアにおけるAENDを用いた実行についての方法の実施形態を示す。1901において、AEND命令がフェッチされる。
1903において、フェッチされたAEND命令は、デコード回路を用いてデコードされる。いくつかの実施形態において、AENDは、マイクロオペレーションにデコードされる。
1905において、デコードされたAEND命令は、実行回路により実行されて、前にABEGIN命令により設定された実行の異なるモードから戻る。実行のこの異なるモードは、アクセラレータの可用性及び選択範囲に応じて、アクセラレータ上又は既存のコア上であってよい。
1807において、後続の非AEND命令は、実行の元のモードで実行される。アクセラレータが実行のために用いられる場合、当該命令は、まず、バイナリトランスレータにより異なる命令セットに変換され得る。
図124は、ABEGIN/AENDがサポートされていない場合の実行の例を示す。12401において、ABEGIN命令がフェッチされる。12403において、ABEGINがサポートされていないとの判断が行われる。例えば、CPUIDは、サポートがないことを示す。
サポートがない場合、典型的には、12405において、スレッドと関連付けられるコンテキストを変更しないオペレーション(nop)が実行される。12407において、実行モードにおける変更がないので、サポートされていないABEGINに続く命令を通常通り実行する。
いくつかの実施形態では、ABEGIN/AENDの同等の利用法が少なくともパターンマッチングを用いて実現される。このパターンマッチングは、ハードウェア、ソフトウェア及び/又は両方に基づいてよい。図20は、パターンマッチングを用いてABEGIN/AEND等価を提供するシステムを示す。図示されるシステムは、メモリ2005に格納された変換器2001(例えば、バイナリトランスレータ、JITなど)を含むスケジューラ2015(例えば、詳細に上述されたようなヘテロジニアススケジューラ)を含む。コア回路2007は、スケジューラ2015を実行する。スケジューラ2015は、明示的なABEGIN/AEND命令を有しても有していなくてもよいスレッド2019を受信する。
スケジューラ2015は、ソフトウェアベースのパターンマッチャ2003を管理し、オフロード中にトラップ及びコンテキストスイッチを実行し、ユーザ空間保存エリア(後で詳細に説明される)を管理し、アクセラレータコード2011を生成又はアクセラレータコード2011に変換する。パターンマッチャ2003は、アクセラレータの利用及び/又は緩和された実行状態から利益を得てよいが、ABEGIN/AENDを用いて記述されていない受信したスレッド2019において得られるメモリに格納された(予め定義された)コードシーケンスを認識する。典型的には、各自のパターンは、変換器2001に格納されるが、少なくとも、パターンマッチャ2003にアクセス可能である。セレクタ2019は、前に詳細に説明したものとして機能する。
スケジューラ2015は、パフォーマンスモニタリングの特徴を提供してもよい。例えば、コードが、完全なパターンマッチを有していない場合、スケジューラ2015は、コードが、より効率的である要件の緩和をさらに必要とし得ることを認識し、状況に応じて、スレッドと関連付けられる動作モードを調整する。動作モードの関係は、詳細に上述されている。
スケジューラ2015はまた、ABEGIN/AEND領域内でコアを循環させること、アクティブにされ又はストールされるアクセラレータを循環させること、ABEGIN呼び出しをカウントすること、アクセラレータのキューイングを遅延させること(同期処理)、及び、メモリ/キャッシュ統計値のモニタリングのうちの1又は複数を実行する。いくつかの実施形態において、バイナリトランスレータ2001は、ボトルネックを識別する際に有用であり得るアクセラレータコードを解釈するために用いられるアクセラレータに固有のコードを含む。アクセラレータは、この変換されたコードを実行する。
いくつかの実施形態において、コア回路2007は、格納されたパターン2017を用いて、受信したスレッド2019内の(予め定義された)コードシーケンスを認識するハードウェアパターンマッチャ2009を含む。典型的には、このパターンマッチャ2009は、ソフトウェアパターンマッチャ2003と比較して軽量であり、表現が簡単な領域(例えば、rep movs)を探す。認識されたコードシーケンスは、スケジューラ2015によるアクセラレータの使用のために変換されてよく、及び/又は、スレッド用の動作モードの緩和を結果的にもたらし得る。
システムへ結合されているのは、アクセラレータコード2011を受信して実行する1又は複数のアクセラレータ2013である。
図21は、パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。この方法は、パターンマッチャの少なくとも1つのタイプを含むシステムにより実行される。
いくつかの実施形態では、2101において、スレッドが実行される。典型的には、このスレッドは、非アクセラレータコア上で実行される。実行中のスレッドの命令は、パターンマッチャへと供給される。しかしながら、当該スレッドの命令は、任意の実行の前にパターンマッチャへと供給されてもよい。
2103において、スレッド内のパターンが認識(検出)される。例えば、ソフトウェアベースのパターンマッチャ又はハードウェアパターンマッチャ回路は、利用可能なアクセラレータと通常関連付けられているパターンを見つける。
2105において、認識されたパターンは、利用可能なアクセラレータのために変換される。例えば、バイナリトランスレータは、当該パターンをアクセラレータコードに変換する。
変換されたコードは、実行のために、2107において利用可能なアクセラレータに転送される。
図22は、パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。この方法は、図20のシステムに示すように、パターンマッチャの少なくとも1つのタイプを含むシステムにより実行される。
いくつかの実施形態では、2201において、スレッドが実行される。典型的には、このスレッドは、非アクセラレータコア上で実行される。実行中のスレッドの命令は、パターンマッチャへと供給される。しかしながら、当該スレッドの命令は、任意の実行前にパターンマッチャへと供給されてもよい。
2203において、スレッド内のパターンが認識(検出)される。例えば、ソフトウェアベースのパターンマッチャ又はハードウェアパターンマッチャ回路は、利用可能なアクセラレータと通常関連付けられているパターンを見つける。
2205において、バイナリトランスレータは、認識されたパターンに基づいて、緩和要求を用いるために、スレッドと関連付けられた動作モードを調整する。例えば、バイナリトランスレータは、認識されたパターンと関連付けられた設定を利用する。
詳細に説明されたように、いくつかの実施形態では、コードの並列領域は、ABEGIN及びAEND命令により区切られる。ABEGIN/AENDブロック内では、特定のメモリロード及びストア操作の独立性が保証されている。他のロード及びストアは、潜在的な依存性を考慮する。これは、実装が、メモリ依存性をほとんど又は全くチェックしないで、ブロックを並列化することを可能にする。いかなる場合でも、直列の場合は、ブロックを実行するのに可能な方式の中に含まれているので、ブロックの直列実行が許可される。バイナリトランスレータは、静的依存性解析を実行して並列実行のインスタンスを作成し、これらのインスタンスをハードウェアにマッピングする。静的依存性解析は、外側、中間又は内側ループの反復を並列化し得る。スライスは、実装に依存する。ABEGIN/AENDの実装は、実装に最も適切なサイズにおける並列性を抽出する。
ABEGIN/AENDブロックは、ネステッドループについての複数のレベルを含んでよい。実装は、自由に、サポートされる並列実行の量を選択する、又は、直列実行に対してフォールバックする。ABEGIN/AENDは、SIMD命令よりもはるかに大きい領域にわたる並列性を提供する。特定のタイプのコードに関し、ABEGIN/AENDは、マルチスレッディングより効率的なハードウェア実装を可能にする。
ABEGIN/AENDの使用を通じて、プログラマ及び/又はコンパイラは、並列化の基準が満たされていない場合、CPUコアによる従来の直列実行に対してフォールバックすることができる。従来のアウトオブオーダCPUコア上で実行されている場合、ABEGIN/AENDは、緩和されたメモリオーダリングの結果として、エリア、及び、メモリオーダリングバッファ(MOB)の所要電力を縮小する。
ABEGIN/AENDブロック内では、プログラマは、メモリ依存性を規定する。図23は、メモリ依存性の様々なタイプ2301、これらのセマンティクス2303、オーダリング要求2305及び使用事例2307を示す。さらに、いくつかのセマンティクスは、実装に応じて、ABEGIN/AENDブロック内の命令に適用される。例えば、いくつかの実施形態において、レジスタの依存性が許容されているが、レジスタに対する修正は、AENDを超えて持続していない。さらに、いくつかの実施形態において、ABEGIN/AENDブロックは、ABEGIN/AENDブロックへの/からの分岐がない状態で、ABEGINで入り、AENDで終了され(又はパターン認識に基づいて同様の状態に入る)なければならない。最後に、典型的には、命令ストリームは、修正できない。
いくつかの実施例において、ABEGIN命令は、メモリデータブロックに対するポインタを含むソースオペランドを含む。このデータメモリブロックは、ABEGIN/AENDブロック内のコードを処理するために、ランタイム及びコア回路により利用される多くの情報を含む。
図24は、ABEGIN命令により指し示されるメモリデータブロックの例を示す。図示されるように、実装に応じて、メモリデータブロックは、シーケンス番号2401用のフィールド、ブロッククラス2403用のフィールド、実装識別子2405用のフィールド、保存状態エリアサイズ2407用のフィールド及びローカルストレージエリアサイズ2409用のフィールドを含む。
シーケンス番号2401は、割込み前に、プロセッサがどれだけの(並列)計算を経たかを示す。ソフトウェアは、ABEGINの実行前に、シーケンス番号2401をゼロに初期化する。ABEGINの実行は、ゼロ以外の値をシーケンス番号2401に書き込んで、実行の進み具合を追跡する。完了すると、AENDの実行は、ゼロを書き込んで、その次の使用のために、シーケンス番号2401を再度初期化する。
予め定義されたブロッククラス識別子2403(すなわち、GUID)は、予め定義されたABEGIN/AENDブロッククラスを規定する。例えば、DMULADD及びDGEMMは、ブロッククラスとして予め定義され得る。予め定義されたクラスを用いて、バイナリトランスレータは、ヘテロジニアスハードウェアに対するマッピング解析を実行するために、バイナリを解析する必要はない。代わりに、変換器(例えば、バイナリトランスレータ)は、入力値を単に取得することにより、このABEGIN/AENDクラスのために予め生成された変換を実行する。ABEGIN/AENDに同封されたコードは、単に、非特化型コア中でこのクラスを実行するために用いられるコードとしての機能を果たすに過ぎない。
実装IDフィールド2405は、用いられる実行ハードウェアのタイプを示す。ABEGINの実行は、用いられるヘテロジニアスハードウェアのタイプを示すために、このフィールド2405を更新する。これは、実装が、ABEGIN/AENDコードを、異なるアクセラレーションハードウェアタイプを有し、又は、アクセラレータを一切有していないマシンへ移行する助けとなる。このフィールドは、ターゲット実装を適合させるように、保存されたコンテキストの可能な変換を可能にする。すなわち、エミュレータは、ABEGIN/AENDコードが割り込まれ、かつ、同じアクセラレータタイプを有していないマシンに移行される場合の移行後に、それがAENDを抜けるまで、コードを実行するために用いられる。このフィールド2405はまた、ABEGIN/AENDブロックの実行の最中に割り込まれた場合でさえ、システムが、ABEGIN/AENDブロックを同じマシン内の異なるヘテロジニアスハードウェアに動的に再度割り当てられることを可能にし得る。
状態保存エリアフィールド2407は、実装に固有である状態保存エリアのサイズ及びフォーマットを示す。実装は、状態保存エリアの実装に固有の部分が、CPUIDにおいて特定されたある最大値を超えないことを保証する。典型的には、ABEGIN命令の実行は、ABEGIN/AENDブロック、関連するフラグ及び追加の実装に固有の状態内で修正される汎用及びパックドデータレジスタの状態保存エリアへの書き込みを引き起こす。並列実行を容易にするために、レジスタの複数のインスタンスが書き込まれてよい。
ローカルストレージエリア2409は、ローカルストレージエリアとして割り当てられる。予約するための記憶量は、典型的には、ABEGINに対する即値オペランドとして特定される。ABEGIN命令が実行されると、特定のレジスタ(例えば、R9)への書き込みが、ローカルストレージ2409のアドレスを用いて行われる。障害がある場合、このレジスタは、シーケンス番号を指し示すことが行われる。
並列実行の各インスタンスは、一意的なローカルストレージエリア2409を受ける。アドレスは、並列実行のインスタンスごとに異なる。直列実行では、1つのストレージエリアが割り当てられる。ローカルストレージエリア2409は、アーキテクチャの汎用及びパックドデータレジスタを超えた一時的なストレージを提供する。ローカルストレージエリア2409は、ABEGIN/AENDブロックの外部にアクセスされるべきではない。
図25は、ABEGIN/AENDセマンティクスを用いるように構成されるメモリ2503の例を示す。ABEGIN/AENDをサポートし、かつ、このメモリ2503を利用するハードウェア(例えば、本明細書で説明される様々な処理要素)は図示されていない。詳細に説明されるように、メモリ2503は、使用対象のレジスタ2501、フラグ2505及び実装に固有の情報2511のインジケーションを含む保存状態エリア2507を含む。さらに、並列実行インスタンス毎にローカルストレージ2509がメモリ2503に格納される。
図26は、ABEGIN/AENDを用いた実行についての異なるモードでの動作の方法の例を示す。典型的には、この方法は、エンティティの組み合わせ、例えば、変換器及び実行回路により実行される。いくつかの実施形態において、スレッドは、このモードに入る前に変換される。
2601において、実行の異なるモードは、例えば、実行の緩和モード(アクセラレータを用いる又は用いない)などに入る。通常、ABEGIN命令の実行からこのモードに入る。しかしながら、詳細に上述されるように、パターンマッチにより、このモードに入ることもあり得る。このモードに入ることは、シーケンス番号のリセットを含む。
2603において、保存状態エリアへの書き込みが行われる。例えば、修正される汎用及びパックドデータレジスタ、関連するフラグ、追加の実装に固有の情報が書き込まれる。このエリアは、ブロック内で何か不具合(例えば、割込み)があった場合の実行の再開又はロールバックを可能にする。
2605において、並列実行インスタンス毎にローカルストレージエリアが予約される。詳細に上述されたように、このエリアのサイズは、状態保存エリアフィールドにより指示される。
2607において、ブロックの実行中、ブロックの進行具合が追跡される。例えば、命令が、実行に成功してリタイアされた場合、ブロックのシーケンス番号が更新される。
2609において、AEND命令が到達したか否かに応じた判断が、(例えば、ブロックが完了したか否かを判断するために)行われる。AEND命令が到達していない場合、次に、2613において、ローカルストレージエリアは、中間結果を用いて更新される。可能ならば、実行は、これらの結果から取り出す。しかしながら、いくつかの例では、2615において、ABEGIN/AEND前へのロールバックが発生する。例えば、ABEGIN/AENDブロックの実行中に例外又は割込みが発生した場合、命令ポインタは、ABEGIN命令を指し示し、R9レジスタは、中間結果を用いて更新されるメモリデータブロックを指し示す。再開すると、メモリデータブロックに保存された状態は、訂正ポイントで再開するために用いられる。さらに、状態保存エリアを含むメモリデータブロックの初期部が存在しない又はアクセス可能でない場合、ページフォールトが引き起こされる。ローカルストレージエリアに対するロード及びストアについて、通常の方式、すなわち、存在しない又はアクセス可能ではないページへの第1のアクセスでページフォールトが報告される。いくつかの例において、非アクセラレータ処理要素が再開時に用いられる。
2611において、ブロックの完了に成功した場合、次に、破棄されたレジスタがフラグと共に元の状態に戻される。メモリ状態だけがブロック後に異なる。
図27は、ABEGIN/AENDを用いた実行についての異なるモードでの動作の方法の例を示す。典型的には、この方法は、エンティティの組み合わせ、例えば、バイナリ変換器及び実行回路により実行される。
2701において、実行の異なるモードは、例えば、実行の緩和モード(アクセラレータを用いる又は用いない)などに入る。通常、ABEGIN命令の実行からこのモードに入る。しかしながら、詳細に上述されたように、パターンマッチにより、このモードに入ることもあり得る。このモードに入ることは、シーケンス番号のリセットを含む。
2703において、保存状態エリアへの書き込みが行われる。例えば、修正される汎用及びパックドデータレジスタ、関連するフラグ及び追加の実装に固有の情報が書き込まれる。このエリアは、ブロック内で何か不具合(例えば、割込み)があった場合の実行の再開又はロールバックを可能にする。
2705において、並列実行インスタンス毎にローカルストレージエリアが予約される。詳細に上述されたように、このエリアのサイズは、状態保存エリアフィールドにより指示される。
2706において、ブロック内のコードが実行のために変換される。
2707において、変換されたブロックの実行中、ブロックの進行具合が追跡される。例えば、命令が、実行に成功してリタイアされた場合、ブロックのシーケンス番号が更新される。
2709において、AEND命令が到達したか否かに応じた判断が、(例えば、ブロックが完了したか否かを判断するために)行われる。AEND命令が到達していない場合、次に、2713において、ローカルストレージエリアは、中間結果を用いて更新される。可能ならば、実行は、これらの結果から取り出す。しかしながら、いくつかの例では、2715において、ABEGIN/AENDの前へのロールバックが発生する。例えば、ABEGIN/AENDブロックの実行中に例外又は割込みが発生した場合、命令ポインタは、ABEGIN命令を指し示し、R9レジスタは、中間結果を用いて更新されるメモリデータブロックを指し示す。再開すると、メモリデータブロックに保存された状態は、訂正ポイントで再開するために用いられる。さらに、状態保存エリアを含むメモリデータブロックの初期部が存在しない又はアクセス可能でない場合、ページフォールトが引き起こされる。ローカルストレージエリアに対するロード及びストアについて、通常の方式、すなわち、存在しない又はアクセス可能ではないページへの第1のアクセスでページフォールトが報告される。いくつかの例において、非アクセラレータ処理要素が再開時に用いられる。
ブロックの完了に成功した場合、次に、2711において、破棄されたレジスタがフラグと共に元の状態に戻される。メモリ状態だけがブロック後に異なる。
上述したように、いくつかの実施例では、(マルチプロトコル共通リンク(MCL)を呼び出す)共通のリンクが、デバイス(例えば、図1及び図2において説明した処理要素)に到達するために用いられる。いくつかの実施形態において、これらのデバイスは、PCIエクスプレス(PCIe)デバイスとして見られる。このリンクは、リンク上で動的に多重化される3又はそれより多いプロトコルを有する。例えば、共通のリンクは、1)1又は複数の独自又は業界標準(例えば、PCIエクスプレス仕様又は同等の代替手段など)において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、DMAスタイルのデータ転送及び様々なサービスを可能にする生産者/消費者、発見、構成、割込み(PDCI)プロトコル、2)デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス(CAC)プロトコル、及び、3)処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス(MA)プロトコルからなるプロトコルをサポートする。これらのプロトコルの特定の例では、(例えば、インテル(登録商標)オンチップシステムファブリック(IOSF)、インダイ相互接続(IDI)、スケーラブルメモリ相互接続3+(SMI3+))が提供される一方、本発明の基礎となる原理は、任意の特定のプロトコルのセットに限定されない。
図120は、例示的なマルチチップリンク(MCL)12020を用いて通信可能に接続される2又はそれより多いチップ又はダイ(例えば、12010、12015)を含む例示的なマルチチップ構成12005を示す簡易ブロック図12000である。図120は、例示的なMCL12020を用いて相互接続される2つ(又はそれより多い)ダイの例を示す一方、MCLの実装に関して本明細書で説明される原理及び特徴は、数ある潜在的な例の中でも特に、2又はそれより多いダイ(例えば、12010、12015)を接続すること、ダイ(又はチップ)を別のコンポーネントオフダイに接続すること、ダイを別のデバイス又はダイオフパッケージ(例えば、12005)に接続すること、ダイをBGAパッケージ、インターポーザ上のパッチの実装(POINT)を含む、ダイ(例えば、12010)及び他のコンポーネントを接続する任意の相互接続又はリンクに適用され得ることを理解されたい。
いくつかの例において、より大きなコンポーネント(例えば、ダイ12010、12015)は、それら自体を、例えば、システムオンチップ(SoC)、マルチプロセッサチップ、又は、デバイス上、例として単一のダイ(例えば、12010、12015)上の、コア、アクセラレータなどのような複数のコンポーネント(12026〜12030及び12040〜12045)を含む他のコンポーネントなどのICシステムであり得る。MCL12020は、潜在的に複数の別個のコンポーネント及びシステムから複雑かつ多様なシステムを構築すること対する柔軟性をもたらす。例として、ダイ12010、12015のそれぞれが製造されてよく、そうでなければ、2つの異なるエンティティにより提供され得る。さらに、ダイ及び他のコンポーネントは、それら自体が、デバイス(例えば、12010、12015のそれぞれ)内のコンポーネント(例えば、12026〜12030及び12040〜12045)の間の通信のためのインフラストラクチャを提供する相互接続又は他の通信ファブリック(例えば、12031、12050)を含むことができる。様々なコンポーネント及び相互接続(例えば、12031、12050)は、複数の異なるプロトコルをサポートする又は用いる。さらに、ダイ(例えば、12010、12015)の間の通信は、複数の異なるプロトコルを介したダイ上の様々なコンポーネント間のトランザクションを潜在的に含むことができる。
マルチチップリンク(MCL)の実施形態は、複数のパッケージオプション、複数のI/Oプロトコル、並びに、信頼性・可用性・保守性(RAS)機能をサポートする。さらに、物理層(PHY)は、物理的な電気層及び論理層を含むことができ、最大で、いくつかの場合において約45mmを超えるチャネル長を含む、より長いチャネル長をサポートできる。いくつかの実施例では、例示的なMCLは、8〜10Gb/sを超えるデータレートを含む、高データレートで動作できる。
MCLの1つの例示的な実施例において、PHY電気層は、従来のマルチチャネル相互接続解決手段(例えば、マルチチャネルDRAM I/O)を改善し、数ある潜在的な例の中でも特に、例として、調整された中間レール終端、低電力アクティブクロストーク除去、回路冗長、ビット毎のデューティサイクル訂正及びデスキュー、ライン符号化及び送信機等化を含む多数の機能により、例として、データレート及びチャネル構成を拡張する。
MCLの1つの例示的な実施例において、PHY論理層は、データレート及びチャネル構成を拡張する一方、電気層にわたって複数のプロトコルを転送する相互接続もできるようにする場合に(例えば、電気層機能)をさらに支援するように実装される。そのような実施例が、プロトコルに依存せず、潜在的に任意の既存又は将来の相互接続プロトコルと連動するように設計されるモジュラ共通物理層を提供及び定義する。
図121を参照すると、簡易ブロック図12100は、マルチチップリンク(MCL)の例示的な実装を含むシステムの少なくとも一部を表すことを示す。MCLは、第1のデバイス12105(例えば、1又は複数のサブコンポーネントを含む第1のダイ)を、第2のデバイス12110(例えば、1又は複数の他のサブコンポーネントを含む第2のダイ)と接続する物理的な電気接続(例えば、レーンとして実装されるワイヤ)を用いて実装され得る。図12100の高水準表現において示される具体例では、(チャネル12115、12120内の)すべての信号は、単方向であり得、レーンは、アップストリーム及びダウンストリームデータ転送の両方を有するデータ信号を提供し得る。図121のブロック図12100は、アップストリームコンポーネントとしての第1のコンポーネント12105、ダウンストリームコンポーネントとしての第2のコンポーネント12110、ダウンストリームチャネル12115としてデータを送信するときに用いられるMCLの物理レーン及びアップストリームチャネル12120として(コンポーネント12110から)データを受信するために用いられるレーンを指す一方、デバイス12105、12110間のMCLが、デバイス間でデータを送信及び受信の両方を行うために、各デバイスにより用いられ得ることを理解されたい。
1つの例示的な実施例において、MCLは、電気MCL物理層(PHY)12125a,b(又は、総称して12125)を含む物理層と、実行可能な論理実装MCL論理PHY12130a,b(又は、総称して12130)とを提供できる。電気又は物理PHY12125は、デバイス12105、12110間でデータが通信される物理的な接続を提供する。信号調整コンポーネント及び論理は、リンクの高データレート及びチャネル構成機能を確立するために、物理PHY12125と関連して実装されることができ、いくつかのアプリケーションが約45mm又はそれより長い長さでの、密接にクラスタ化された物理的接続に関する。論理PHY12130は、クロック、リンクステート管理(例えば、リンク層12135a、12135b)及びMCLを介した通信に用いられる潜在的に複数の異なるプロトコル間でのプロトコル多重を容易にするための回路を含む。
1つの例示的な実施例において、物理PHY12125は、チャネルごと(例えば、12115、12120)に、インバンドデータが送信されるデータレーンのセットを含む。この具体例では、50個のデータレーンがアップストリーム及びダウンストリームチャネル12115、12120のそれぞれに提供されるが、レイアウト及び電力制約、所望のアプリケーション、デバイス制約などにより許される場合には、その他の数のレーンが用いられ得る。各チャネルは、チャネルに関するストローブ又はクロック信号用の1又は複数の専用レーン、チャネルに関する有効な信号用の1又は複数の専用レーン、ストリーム信号用の1又は複数の専用レーン、及び、リンクステートマシン管理又はサイドバンド信号用の1又は複数の専用レーンをさらに含むことができる。物理PHYは、サイドバンドリンク12140をさらに含むことができ、いくつかの例では、数ある例の中でも特に、デバイス12105、12110を接続するMCLについての状態遷移及び他の属性を調整するために用いられる双方向低周波制御信号リンクであり得る。
上述したように、MCLの実装を用いて、複数のプロトコルがサポートされている。実際には、複数の独立したトランザクション層12150a、12150bが、各デバイス12105、12110において提供され得る。例として、各デバイス12105、12110は、数ある中でも、PCI、PCIe、CACなど、2又はそれより多いプロトコルをサポート及び利用してよい。CACは、コアと、ラストレベルキャッシュ(LLC)と、メモリと、グラフィックスとI/Oコントローラとの間で通信するオンダイに用いられるコヒーレントなプロトコルである。イーサネット(登録商標)プロトコル、インフィニバンドプロトコル及び他のPCIeファブリックベースのプロトコルを含む他のプロトコルもサポートされ得る。論理PHY及び物理PHYの組み合わせは、数ある例の中でも特に、1つのダイ上のSerDes PHY(PCIe、イーサネット(登録商標)、インフィニバンド又は他の高速SerDes)を、他のダイ上に実装されているその上位層に接続するダイ間相互接続として用いられることもできる。
論理PHY12130は、MCLにおけるこれら複数のプロトコル間の多重化をサポートする。例として、専用のストリームレーンは、どのプロトコルが、チャネルのデータレーン上で実質的に同時に送信されるデータに適用されるかを識別するエンコードされたストリーム信号をアサートするために用いられ得る。さらに、論理PHY12130は、様々なプロトコルがサポート又は要求し得る様々なタイプのリンク状態遷移とネゴシエートする。いくつかの例において、チャネルの専用LSM_SBレーンを介して送信されたLSM_SB信号は、デバイス12105、12110間のリンク状態遷移を通信及びネゴシエートするために、サイドバンドリンク12140と一緒に用いられ得る。さらに、リンクトレーニング、エラー検出、スキュー検出、デスキュー及び従来の相互接続についての他の機能が、論理PHY12130を部分的に用いて、置き換えられ又は統制され得る。例として、各チャネルにおける1又は複数の専用の有効な信号レーンを介して送信される有効な信号は、数ある例の中でも特に、リンクアクティビティをシグナリングし、スキュー及びリンクエラーを検出し、及び、他の特徴を実現させるために用いられ得る。図121の具体例では、複数の有効なレーンがチャネル毎に提供されている。例として、チャネル内のデータレーンは、(物理的に及び/又は論理的に)バンドル化又はクラスタ化され得、有効なレーンは、クラスタごとに提供され得る。さらに、複数のストローブレーンは、いくつかの場合において、数ある例の中でも特に、チャネルにおける複数のデータレーンクラスタ内のクラスタごとに専用のストローブ信号を提供するために提供され得る。
上述したように、論理PHY12130は、MCLにより接続されたデバイス間で送信されるリンク制御信号をネゴシエート及び管理する。いくつかの実施例において、論理PHY12130は、MCLを介してリンク層制御メッセージを送信(すなわち、インバンド)するリンク層パケット(LLP)生成回路12160を含む。そのようなメッセージは、数ある例の中でも特に、データがリンク層制御データなどのリンク層−リンク層間メッセージングであることを識別するストリームレーンを有する、チャネルのデータレーンを介して送信され得る。LLPモジュール12160を用いてイネーブルにされたリンク層メッセージは、デバイス12105、12110のリンク層12135a、12135b間のそれぞれの他のリンク層間の特徴の中でも特に、リンク層状態遷移、電源管理、ループバック、ディセーブル、再センタリングスクランブルについてのネゴシエーション及び動作を支援する。
図122を参照すると、例示的なMCLの例示的な論理PHYを示す簡易ブロック図12200が示される。物理PHY12205は、論理PHY12210と、MCLのリンク層をサポートする追加の論理とを含むダイに接続され得る。ダイは、この例において、MCL上に複数の異なるプロトコルをサポートする論理をさらに含み得る。例として、図122の例では、PCIe論理12215がCAC論理12220と共に提供され、その結果、2より多いプロトコル、又は、PCIe及びCAC以外のプロトコルがMCLを介してサポートされる例を含む、潜在的に数多くある例の中でも特に、ダイは、2つのダイを接続する同じMCLを介してPCIe又はCACのいずれか一方を用いて通信できる。ダイ間でサポートされる様々なプロトコルは、サービス及び特徴のレベルを変化させることを提供できる。
論理PHY12210は、(例えば、PCIe又はCACを介して受信した)ダイの上位層論理の要求と関連してリンク状態遷移をネゴシエートするためのリンクステートマシン管理論理12225を含むことができる。いくつかの実施例において、論理PHY12210は、リンク試験及びデバッグ論理(例えば、12230)をさらに含むことができる。上述したように、例示的なMCLは、MCLの(数ある例示的な機能の中でも特に)プロトコルに依存せず、高性能かつ電力効率の良い機能を容易にするために、MCLを介してダイ間で送信される制御信号をサポートできる。例として、論理PHY12210は、上記の例において説明したように、専用のデータレーンを介したデータの送信及び受信と関連して、有効な信号、ストリーム信号及びLSMサイドバンド信号の生成及び送信並びに受信及び処理をサポートできる。
いくつかの実施例では、多重化(例えば、12235)及び逆多重化(例えば、12240)論理は、論理PHY12210に含まれ得る、又は、そうでなければ論理PHY12210にアクセス可能であり得る。例として、多重化論理(例えば、12235)は、MCL上に送信されるデータ(例えば、パケット、メッセージなどとして具現化される)を識別するために用いられ得る。多重化論理12235は、データを統制するプロトコルを識別し、プロトコルを識別するためにエンコードされたストリーム信号を生成できる。例として、1つの例示的な実施例では、ストリーム信号は、1バイトの2つの16進数のシンボル(例えば、CAC:FFh;PCIe:F0h;LLP:AAh;サイドバンド:55hなど)としてエンコードされ得、識別されたプロトコルにより統制されるデータについての同じウィンドウ(例えば、1バイトの時間周期ウィンドウ)中に送信され得る。同様に、逆多重化論理12240は、到着したストリーム信号を解釈してストリーム信号をデコードし、データレーン上のストリーム信号と共に同時に受信したデータに適用されるプロトコルを識別するために使用され得る。次に、逆多重化論理12240は、プロトコルに固有のリンク層の処理を適用(又は確保)し、対応するプロトコル論理(例えば、PCIe論理12215又はCAC論理12220)によりデータを処理させることができる。
論理PHY12210は、電源管理タスク、ループバック、ディセーブル、再センタリング、スクランブルなどを含む様々なリンク制御機能を処理するために用いられ得るリンク層パケット論理12250をさらに含むことができる。LLP論理12250は、数ある機能の中でも特に、MCLPを介したリンク層−リンク層間メッセージを容易にすることができる。LLPシグナリングに対応するデータはまた、そのデータレーンLLPデータを識別するためにエンコードされた専用のストリーム信号レーン上に送信されたストリーム信号により識別され得る。多重化及び逆多重化論理(例えば、12235、12240)は、LLPトラフィックに対応するストリーム信号を生成及び解釈し、並びに、適切なダイ論理(例えば、LLP論理12250)によりそのようなトラフィックを処理させるために用いられこともできる。同様に、MCLPのいくつかの実施例では、専用のサイドバンド(例えば、サイドバンド12255及びサポート論理)、例えば、数ある例の中でも特に、非同期及び/又は低周波サイドバンドチャネルを含むことができる。
論理PHY論理12210は、専用のLSMサイドバンドレーンを介してリンクステート管理メッセージングを生成及び受信(及び使用)できるリンクステートマシン管理論理をさらに含むことができる。例として、LSMサイドバンドレーンは、数ある潜在的な例の中でも特に、リンクトレーニング状態に進むためにハンドシェーキングを実行し、電源管理状態(例えば、L1状態)を終了するために用いられ得る。LSMサイドバンド信号は、数ある例の中でも特に、リンクのデータ信号、有効信号及びストリーム信号と整合していないが、代わりにシグナリング状態遷移に対応し、リンクにより接続された2つのダイ又はチップ間のリンクステートマシンを調整するという点で非同期信号であり得る。専用のLSMサイドバンドレーンを提供することは、いくつかの例では、数ある例示的な利益の中でも特に、アナログフロントエンド(AFE)の従来のスケルチ及び受信検出回路が除去されることを可能にし得る。
図123を参照すると、簡易ブロック図12300は、MCLを実装するために用いられる論理の別の表現を図示することが示されている。例として、論理PHY12210は、複数の異なるプロトコル(例えば、PCIe、CAC、PDCI、MAなど)12315、12320、12325及びシグナリングモード(例えば、サイドバンド)のうちのいずれか一つが、例示的なMCLの物理層とインタフェース接続できる規定の論理PHYインタフェース(LPIF)12305と共に提供される。いくつかの実施例において、多重化及びアービトレーション論理12330は、論理PHY12210から分離した層として提供されることもできる。一例では、LPIF12305は、このMuxArb層1230の両側におけるインタフェースとして提供され得る。論理PHY12210は、別のインタフェースを通じて、物理PHY(例えば、MCL PHYのアナログフロントエンド(AFE)12205)とインタフェース接続できる。
LPIFは、上位層に対して透過的なLPIFの下で完全に異なるPHYが実装され得るように、上位層(例えば、12315、12320、12325)からPHY(論理及び電気/アナログ)を取り除くことができる。これは、モジュール方式を促進することを支援し、設計において再利用でき、数ある例の中でも特に、基礎となるシグナリング技術PHYが更新された場合に、上位層は無傷のままでいることができる。さらに、LPIFは、多重化/逆多重化、LSM管理、エラー検出及びハンドリング、及び、論理PHYの他の機能をイネーブルにする多数の信号を定義できる。例として、以下のテーブルは、例示的なLPIFに関して定義され得る信号の少なくとも一部を要約したものである。
テーブルで触れられているように、いくつかの実施例では、アライメントメカニズムが、AlignReq/AlignAckハンドシェイクを通じて提供され得る。例えば、物理層は、リカバリに入る場合、いくつかのプロトコルは、パケットフレーミングを失うかもしれない。パケットのアライメントは、例として、リンク層による訂正フレーミング識別を保証するために、訂正され得る。物理層は、リカバリに入った場合、StallReq信号をアサートでき、その結果、リンク層は、新たにアラインされたパケットを転送する準備ができた場合に、ストール信号をアサートする。物理層論理は、パケットがアラインされるか否かを判断するために、ストール及び有効の両方をサンプリングできる。例として、パケットアライメントを支援するために有効を使用する他の代替的な実装を含む、数ある潜在的な実装の中でも特に、ストール及び有効がサンプリングされてアサートされるまで、物理層はtrdyを駆動してリンク層パケットを排出することを継続できる。
様々なフォールトトレンランスがMCL上の信号に対して定義され得る。例として、フォールトトレンランスは、有効、ストリーム、LSMサイドバンド、低周波サイドバンド、リンク層パケット及び他のタイプの信号に対して定義され得る。MCLの専用のデータレーンを介して送信されたパケット、メッセージ及び他のデータに対するフォールトトレンランスは、データを統制する特定のプロトコルに基づき得る。いくつかの実施例において、エラー検出及びハンドリングメカニズムは、数ある潜在的な例の中でも特に、巡回冗長検査(CRC)、リトライバッファなどが提供され得る。例として、MCLを介して送信されるPCIeパケットに関して、32ビットのCRCが、((例えば、再生メカニズムを通じた)保証された配信を用いた)PCIeトランザクション層パケット(TLP)に利用され得、16ビットのCRCが、(損失が多くなるように設計され得る(例えば、再生が適用されない))PCIeリンク層パケットに利用され得る。さらに、PCIeフレーミングトークンに関して、特定のハミング距離(例えば、4(4)のハミング距離)は、数ある例の中でも特に、トークン識別子に対して定義され得、パリティ及び4ビットのCRCも利用され得る。他方では、CACパケットに関して、16ビットのCRCが利用され得る。
いくつかの実施例において、フォールトトレンランスは、(例えば、保証ビット及びシンボルロックを支援するために)低から高(すなわち、0から1)に遷移するために有効な信号を利用するリンク層パケット(LLP)に対して定義される。さらに、一例において、MCL上のLLPデータ内の障害を判断する基礎として用いられ得る数ある定義された特性の中でも特に、特定の数の連続的な同一のLLPは、送信されるように定義され得、応答はタイムアウトした後にリトライするリクエスタを用いて、応答は、各要求に対して予期され得る。さらなる例において、フォールトトレンランスは、有効な信号に対してもたらされる可能性があり、例として、(例えば、8つのUIに対して有効な信号を高に保持することにより)、有効な信号を通じて時間周期ウィンドウ又はシンボル全体にわたって広がる。さらに、ストリーム信号内のエラー又は障害は、数ある例の中でも特に、ストリーム信号のエンコーディング値に関するハミング距離を維持することにより、防止され得る。
論理PHYの実装は、エラー検出、エラー報告及びエラー処理論理を含む。いくつかの実施例において、例示的なMCLの論理PHYは、数ある例の中でも特に、(例えば、有効及びストリームレーン上の)PHY層デフレーミングエラー、(例えば、LSM状態遷移に関する)サイドバンドエラー、(例えば、LSM状態遷移にとって重大な)LLP内のエラーを検出する論理を含むことができる。いくつかのエラー検出/解決は、数ある例の中でも特に、PCIeに固有のエラーを検出するのに適合するPCIe論理などの上位層論理に委任され得る。
デフレーミングエラーの場合、いくつかの実施例では、1又は複数のメカニズムが、エラー処理論理を通じて提供され得る。デフレーミングエラーは、関連するプロトコルに基づいて処理され得る。例として、いくつかの実施例では、リンク層が、リトライをトリガするためにエラーを通知できる。デフレーミングは、論理PHYデフレーミングの再再アライメントも引き起こし得る。さらに、数ある技術の中でも特に、論理PHYの再センタリングが実行され得、シンボル/ウィンドウロックが再獲得され得る。センタリングは、いくつかの例において、到着したデータを検出するのに最適なポイントに受信機クロックフェーズを移動するPHYを含むことができる。この文脈における「最適」は、ノイズ及びクロックジッタに対して最も余裕があることを指し得る。数ある例の中でも特に、再センタリングは、例としてPHYが低電力状態からウェイクアップした場合に実行される簡易センタリング機能を含むことができる。
他のタイプのエラーは、他のエラー処理技術に関連し得る。例として、サイドバンドで検出されたエラーは、(例えば、LSMの)対応する状態のタイムアウトメカニズムを通じて捕まえられ得る。エラーは、ログに記録され得、次に、リンクステートマシンは、リセットに遷移され得る。LSMは、再開コマンドがソフトウェアから受信されるまで、リセット状態に維持することができる。別の例では、LLPエラー、例えば、リンク制御パケットエラーは、LLPシーケンスに対する確認応答が受信されなかった場合、LLPシーケンスを再開できるタイムアウトメカニズムを用いて処理され得る。
いくつかの実施形態において、上記のプロトコルのそれぞれは、PCIeの変形である。PCIeデバイスは、バスと関連付けられた共通のアドレス空間を用いて通信する。このアドレス空間は、バスアドレス空間又はPCIeアドレス空間である。いくつかの実施形態において、PCIeデバイスは、PCIeアドレス空間とは異なり得る内部アドレス空間内のアドレスを用いる。
PCIe仕様は、PCIeデバイスがそのローカルメモリ(又はその一部)をバスにさらし得るメカニズムを定義し、ひいては、CPU、又は、そのメモリに直接アクセスするバスに取り付けられる他のデバイスをイネーブルにする。典型的には、各PCIeデバイスは、PCIベースアドレスレジスタ(BAR)と称されるPCIeアドレス空間内の専用の領域を割り当てられる。さらに、デバイスがさらすアドレスは、PCI BAR内のそれぞれのアドレスにマッピングされる。
いくつかの実施形態において、PCIeデバイス(例えば、HCA)は、入力/出力メモリマッピングユニット(IOMMU)を用いて、その内部アドレスとPCIeバスアドレスとを変換する。他の実施形態において、PCIeデバイスは、PCIアドレス変換サービス(ATS)を用いて、アドレス変換及び解決を実行してよい。いくつかの実施形態において、タグ、例えば、処理アドレス空間ID(PASID)タグは、特定の処理の仮想アドレス空間に属するように変換されるアドレスを規定するために用いられる。
図28は、一実施例に関する追加の詳細を示す。上記で説明される実施例に示すように、この実施例は、ホストメモリ2860を有するホストプロセッサ2802にマルチプロトコルリンク2800を介して結合される、アクセラレータメモリ2850を有するアクセラレータ2801を含む。すでに述べたように、アクセラレータメモリ2850は、ホストメモリ2860とは異なるメモリ技術を利用してよい(例えば、アクセラレータメモリは、HBM又はスタック型DRAMであってよく、一方、ホストメモリは、SDRAMであってよい)。
マルチプレクサ2811及び2812は、マルチプロトコルリンク2800がPCDI、CAC及びMAプロトコル(例えば、SMI3+)トラフィックをサポートする動的に多重化されたバスであり、それぞれがアクセラレータ2801及びホストプロセッサ2802内の異なる機能コンポーネントに転送され得るという事実を強調表示するように示されている。例として、制限されるものではないが、これらのプロトコルは、IOSF、IDI及びSMI3+を含んでよい。一実施例において、アクセラレータ2801のPCIe論理2820は、コマンドを実行する場合、1又は複数のアクセラレータコア2830による使用のために仮想−物理アドレス変換をキャッシングするためのローカルTLB2822を含む。すでに述べたように、仮想メモリ空間は、アクセラレータメモリ2850とホストメモリ2860との間で分配される。同様に、ホストプロセッサ2802上のPCIe論理は、PCIe I/Oデバイス2806のメモリアクセスを管理するためのI/Oメモリ管理ユニット(IOMMU)2810、及び、一実施例においてアクセラレータ2801を含む。図示されるように、アクセラレータ上のPCIe論理2820及びホストプロセッサ上のPCIe論理2808では、PCDIプロトコルを用いて通信して、デバイス発見、レジスタアクセス、デバイス構成及び初期化、割込み処理、DMA処理及びアドレス変換サービス(ATS)などの機能を実行する。すでに述べたように、ホストプロセッサ2802上のIOMMU2810は、これらの機能に対する制御及び調整を主要目的として動作し得る。
一実施例において、アクセラレータコア2830は、アクセラレータにより必要とされる機能を実行する処理エンジン(要素)を含む。さらに、アクセラレータコア2830は、ホストメモリ2860に格納されているページをローカルにキャッシングするためのホストメモリキャッシュ2834と、アクセラレータメモリ2850に格納されているページをキャッシングするためのアクセラレータメモリキャッシュ2832とを含んでよい。一実施例において、アクセラレータコア2830は、アクセラレータ2801とホストプロセッサ2802との間で共有されるキャッシュラインがコヒーレントを維持することを確保するために、CACプロトコルを介してホストプロセッサ2802のコヒーレンス及びキャッシュ論理2807と通信する。
アクセラレータ2801のバイアス/コヒーレンス論理2840は、マルチプロトコルリンク2800を介した不必要な通信を減らしつつ、データコヒーレンスを確保するために本明細書で説明される様々なデバイス/ホストバイアス技術(例えば、ページレベルの粒度)を実装する。図示されるように、バイアス/コヒーレンス論理2840は、MAメモリトランザクション(例えば、SMI3+)を用いてホストプロセッサ2802のコヒーレンス及びキャッシュ論理2807と通信する。コヒーレンス及びキャッシュ論理2807は、そのLLC2809、ホストメモリ2860、アクセラレータメモリ2850及びキャッシュ2832、2834、及び、コア2805の個別のキャッシュのそれぞれに格納されるデータのコヒーレンシを維持することを担っている。
要約すると、アクセラレータ2801の一実施例は、ホストプロセッサ2802で実行されるソフトウェアに対するPCIeデバイスとして現れ、(多重化されたバスに対してPCIeプロトコルを効果的に再フォーマット化する)PDCIプロトコルによりアクセスされる。アクセラレータ2801は、アクセラレータデバイスTLB及び標準のPCIeアドレス変換サービス(ATS)を用いて共有仮想メモリに参加してよい。アクセラレータはまた、コヒーレンス/メモリエージェントとして処理され得る。特定機能(例えば、以下で説明されるENQCMD、MOVDIR)は、(例えば、ワークサブミッションのために)PDCI上で利用可能であり、一方、アクセラレータは、CACを用いて、アクセラレータで、及び、特定のバイアス遷移フローにおいて、ホストデータをキャッシュしてよい。ホストからアクセラレータメモリへのアクセス(又は、アクセラレータからのホストバイアスアクセス)は、説明されるように、MAプロトコルを用いてよい。
図29に示されるように、一実施例において、アクセラレータは、デバイスバックエンドリソース2905へのアクセスを提供するようにプログラミングされ得るPCI構成レジスタ2902及びMMIOレジスタ2906を含む。一実施例において、MMIOレジスタ2906用のベースアドレスは、PCI構成空間内のベースアドレスレジスタ(BAR)2901のセットにより特定される。以前の実装とは異なり、本明細書で説明されるデータストリーミングアクセラレータ(DSA)の一実施例は、複数のチャネル又はPCI機能を実装しておらず、そのため、デバイスには、各レジスタについての1つのインスタンスのみがある。しかしながら、単一プラットフォームでは、1より多いDSAデバイスがあってよい。
実施例では、ここでは説明されない追加の性能を提供してよい、又は、レジスタをデバッグしてよい。任意のそのようなレジスタは、実装ごとに決まることが考慮されるべきである。
PCI構成空間アクセスは、アラインされた1バイトアクセス、2バイトアクセス又は4バイトアクセスとして実行される。PCI構成空間において、未実装のレジスタ及び予約されたビットにアクセスする規則については、PCIエクスプレスベースの仕様を参照する。
BAR0領域(機能、構成及びステータスレジスタ)へのMMIO空間アクセスは、アラインされた1バイトアクセス、2バイトアクセス、4バイトアクセス又は8バイトアクセスとして実行される。8バイトアクセスは、8バイトレジスタにのみ用いられるべきである。ソフトウェアは、未実装のレジスタを読み出し又は書き込みすべきではない。BAR2及びBAR4領域へのMMIO空間アクセスは、ENQCMD、ENQCMDS又はMOVDIR64B命令(以下で詳細に説明される)を用いて、64バイトアクセスとして実行されるべきである。ENQCMD又はENQCMDSは、共有されるように構成されるワークキュー(SWQ)にアクセスするために用いられるべきであり、MOVDIR64Bは、専用として構成されるワークキュー(DWQ)にアクセスするために用いられなければならい。
DSA PCI構成空間の一実施例は、3つの64ビットBAR2901を実装する。デバイス制御レジスタ(BAR0)は、デバイス制御レジスタの物理ベースアドレスを含む64ビットBARである。これらのレジスタは、デバイス性能、デバイスを構成及びイネーブルにする制御、及び、デバイスステータスに関する情報を提供する。BAR0領域のサイズは、割込みメッセージストレージ2904のサイズに依存する。サイズは、割込みメッセージストレージエントリ2904の数×16を32KBに加えて、次の2のべき乗に切り上げられる。例えば、デバイスが1024個の割込みメッセージストレージエントリ2904をサポートする場合、割込みメッセージストレージは16KBであり、BAR0のサイズは64KBである。
BAR2は、特権及び非特権ポータルの物理ベースアドレスを含む64ビットBARである。各ポータルは、64バイトのサイズであり、別々の4KBページ上に配置される。これは、ポータルがCPUページテーブルを用いて異なるアドレス空間に独立にマッピングされることを可能にする。ポータルは、記述子をデバイスにサブミットするために用いられる。特権ポータルは、カーネルモードソフトウェアにより用いられ、非特権ポータルは、ユーザモードソフトウェアにより用いられる。非特権ポータルの数は、サポートされるワークキューの数と同じである。特権ポータルの数は、ワークキュー(WQ)の数×(MSI‐Xテーブルのサイズ−1)である。記述子をサブミットするために用いられるポータルのアドレスは、デバイスがどのWQに記述子を配置するか、ポータルは特権が与えられているか又は特権が与えられていないか、及び、どのMSI−Xテーブルエントリが完了割込みのために用いられ得るか、を判断することを可能にする。例えば、デバイスが8つのWQをサポートする場合、所与の記述子に対するWQは、(ポータルアドレス>>12)かつ0x7である。ポータルアドレス>>15が0である場合、ポータルは、特権が与えられていない。そうでなければ、ポータルは、特権が与えられており、完了割込みに用いられるMSI−X2903テーブルインデックスは、ポータルアドレス>>15である。ビット5:0は0でなければならない。ビット11:6は無視される。したがって、ページ上で任意の64バイトでアラインされたアドレスは、同じ効果を伴って用いられ得る。
ワークキュー構成(WQCFG)レジスタを用いて構成される場合、非特権ポータルを用いる記述子サブミッションは、WQの占有閾値を対象とする。特権ポータルを用いた記述子サブミッションは、当該閾値を対象とはしない。SWQに対する記述子サブミッションは、ENQCMD又はENQCMDS用いてサブミットされなければならない。SWQポータルに対するその他の書き込み動作は無視される。DWQに対する記述子サブミッションは、64バイト書き込み動作を用いてサブミットされなければならない。ソフトウェアは、切れ目のない64バイト書き込みを保証するために、MOVDIR64Bを用いる。ディセーブルにされ、又は、専用のWQポータルに対するENQCMD又はENQCMDSは、リトライを返す。DWQポータルに対するその他の書き込み動作は無視される。BAR2アドレス空間に対する任意の読み出し処理は、オール1を返す。カーネルモード記述子は、完了割込みを受信するために、特権ポータルを用いてサブミットされるべきである。カーネルモード記述子が、非特権ポータルを用いてサブミットされた場合、要求され得る完了割込みがない。ユーザモード記述子は、特権又は非特権ポータルのいずれか一方を用いてサブミットされてよい。
BAR2領域内のポータルの数は、デバイスによりサポートされているWQの数×MSI−X2903テーブルのサイズである。MSI‐Xテーブルのサイズは、典型的には、WQの数に1を加えたものである。そのため、例えば、デバイスが8つのWQをサポートする場合、BAR2の有用なサイズは、8×9×4KB=288KBとなるであろう。BAR2合計サイズは、次の2のべき乗に切り上げられる、又は、512KBとなるであろう。
BAR4は、ゲストポータルの物理ベースアドレスを含む64ビットBARである。各ゲストポータルは、64バイトのサイズであり、別々の4KBページに配置される。これは、ポータルがCPU拡張ページテーブル(EPT)を用いて異なるアドレス空間に独立にマッピングされることを可能にする。GENCAP内の割込みメッセージストレージサポートフィールドが0である場合、このBARは実装されていない。
ゲストポータルは、記述子をデバイスにサブミットするために、ゲストカーネルモードソフトウェアにより用いられてよい。ゲストポータルの数は、割込みメッセージストレージ内のエントリの数×サポートされるWQの数である。記述子をサブミットするために用いられるゲストポータルのアドレスは、デバイスが記述子用のWQを判断することを可能にし、また、割込みメッセージストレージエントリが、記述子完成用の完了割込みを生成するために用いることを可能にする(カーネルモード記述子である場合で、要求完了割込みフラグが記述子に設定されている場合)。例えば、デバイスが8つのWQをサポートする場合、所与の記述子に対するWQは、(ゲストポータルアドレス>>12)及び0x7であり、完了割込みに用いられる割込みテーブルエントリインデックスは、ゲストポータルアドレス>>15である。
一実施例において、MSI−Xは、DSAが提供し、かつ、DSAがレガシPCI割込み又はMSIを実装していないPCIe割込み機能のみである。このレジスタ構造の詳細については、PCIエクスプレス仕様に従う。
一実施例において、3つのPCIエクスプレス機能が、アドレス変換を制御する。これらの機能の値の特定の組み合わせのみが、テーブルAに示されるように、サポートされ得る。一般的な制御レジスタ(GENCTRL)内のイネーブルビットが1に設定されるときに、値がチェックされる。
これらの機能のいずれかが、ソフトウェアによりに変更される一方、デバイスがイネーブルである場合、デバイスは、停止してよく、エラーがソフトウェアエラーレジスタに報告される。
一実施例において、ソフトウェアは、デバイスが、PASIDを用いてアドレス変換を実行するか否かを制御するために、PASID機能を構成する。PASIDがディセーブルである場合、物理アドレスのみが用いられてよい。PASIDがイネーブルである場合、仮想又は物理アドレスが、IOMMU構成に応じて用いられてよい。PASIDがイネーブルである場合、アドレス変換サービス(ATS)及びページ要求サービス(PRS)の両方がイネーブルにされるべきである。
一実施例において、ソフトウェアは、メモリアクセスを実行する前に、デバイスがアドレスを変換すべきか否かを制御するために、ATS機能を構成する。アドレス変換がIOMMU2810においてイネーブルである場合、ATSは、受諾可能なシステム性能を取得するために、デバイスにおいてイネーブルでなければならない。アドレス変換がIOMMU2810においてイネーブルにされない場合、ATSは、ディセーブルにされなければならない。ATSがディセーブルである場合、物理アドレスのみが用いられてよく、すべてメモリアクセスは、未変換アクセスを用いて実行される。PASIDがイネーブルにされる場合、ATSがイネーブルにされなければならない。
一実施例において、ソフトウェアは、アドレス変換が失敗した場合に、デバイスがページを要求できるか否かを制御するために、PRS機能を構成する。PASIDがイネーブルにされる場合、PRSは、イネーブルにされなければならず、PASIDがディセーブルにされる場合、PRSは、ディセーブルにされなければならない。
いくつかの実施例では、1又は複数のプロセッサコア、アクセラレータデバイス及び/又は他のタイプの処理デバイス(例えば、I/Oデバイス)間でシームレスに共有される仮想メモリ空間を利用する。特に、一実施例では、同じ仮想メモリ空間がコア、アクセラレータデバイス及び/又は他の処理デバイス間で共有される共有仮想メモリ(SVM)アーキテクチャを利用する。さらに、いくつかの実施例では、共通の仮想メモリ空間を用いてアドレス指定されるヘテロジニアス形式の物理システムメモリを含む。ヘテロジニアス形式の物理システムメモリは、DSAアーキテクチャと接続するために、異なる物理インタフェースを用いてよい。例えば、アクセラレータデバイスは、高帯域幅メモリ(HBM)などのローカルアクセラレータメモリに直接結合されてよく、各コアは、ダイナミックランダムアクセスメモリ(DRAM)などのホスト物理メモリに直接結合されてよい。この例において、共有仮想メモリ(SVM)は、アクセラレータ、プロセッサコア及び/又は他の処理デバイスが、仮想メモリアドレスの整合性セットを用いて、HBM及びDRAMにアクセスできるように、HBM及びDRAMの組み合わせられた物理メモリにマッピングされる。
これら及び他の特徴のアクセラレータは、以下で詳細に説明される。概要の目的で、異なる実装は、以下のインフラストラクチャ機能のうちの1又は複数を含んでよい。
共有仮想メモリ(SVM):いくつかの実施例では、ユーザレベルアプリケーションが、記述子内の仮想アドレスを用いて直接的にDSAにコマンドをサブミットすることを可能にするSVMをサポートする。DSAは、ページフォールトの処理を含む入力/出力メモリ管理ユニット(IOMMU)を用いて、仮想アドレスを物理アドレスに変換することをサポートしてよい。記述子により参照される仮想アドレス範囲は、複数のヘテロジニアスメモリタイプにわたって分散された複数のページにまたがってよい。さらに、一実施例ではまた、データバッファが物理メモリ内で連続的である限り、物理アドレスの使用をサポートする。
部分的な記述子完成:SVMサポートを用いて、動作は、アドレス変換中に、ページフォールトに遭遇する可能性がある。いくつかのケースでは、デバイスは、障害に遭遇した時点で、対応する記述子の処理を終了し、部分的な完了及び障害情報を示す完了記録をソフトウェアに提供して、ソフトウェアが、改善策を講じて、障害の解決後に動作をリトライすることを可能にしてよい。
バッチ処理:いくつかの実施例では、「バッチ」に記述子をサブミットすることをサポートする。バッチ記述子は、実質的に連続的なワーク記述子(すなわち、実際のデータ処理を含む記述子)のセットを指し示す。バッチ記述子を処理する場合、DSAは、特定メモリ及びからワーク記述子をフェッチして、これらを処理する。
ステートレスデバイス:一実施例における記述子は、記述子ペイロード自体に入っている記述子を処理するためにすべての情報が必要とされるように、設計される。これは、デバイスが、そのスケーラビリティを改善するわずかなクライアント固有の状態を格納することを可能にする。用いられる場合に、トラステッドソフトウェアにより構成される1つの例外が、完了割込みメッセージである。
キャッシュ割り当て制御:これは、アプリケーションが、キャッシュに書き込むか、キャッシュをバイパスしてメモリに直接的に書き込むかを規定することを可能にする。一実施例において、完了記録は、常にキャッシュに書き込まれる。
共有のワークキュー(SWQ)サポート:以下で詳細に説明されるように、いくつかの実施例では、エンキューコマンド(ENQCMD)及びエンキューコマンド(ENQCMDS)命令を用いて、共有のワークキュー(SWQ)を通じてスケーラブルなワークサブミッションをサポートする。この実施例において、SWQは、複数のアプリケーションにより共有される。
専用のワークキュー(DWQ)サポート:いくつかの実施例では、MOVDIR64B命令を用いた、専用のワークキュー(DWQ)を通じた高スループットワークサブミッションに対するサポートがある。この実施例では、DWQは、ある特定のアプリケーションに専用のものである。
QoSサポート:いくつかの実施例では、サービス品質(QoS)レベルが、(例えば、カーネルドライバにより)ワークキューごとに特定されることを可能にする。次に、異なるワークキューを異なるアプリケーションに割り当ててよく、異なるアプリケーションからのワーク(work)が、異なる優先度を用いてワークキューからディスパッチされることを可能にする。ワークキューは、ファブリックQoSに対して特定のチャネルを用いるためにプログラミングされ得る。
バイアスキャッシュコヒーレンスメカニズム
一実施例では、スタック型DRAM又はHBMなどの直接的に取り付けられたメモリを用いてアクセラレータの性能を改善し、直接的に取り付けられたメモリを用いてアクセラレータを使用するアプリケーションに関するアプリケーション開発を簡略化する。この実施例では、アクセスレータ付属メモリが、システムメモリの一部としてマッピングされ、(例えば、現在のIOMMU実装において用いられる)共有仮想メモリ(SVM)技術を用いるが、完全なシステムのキャッシュコヒーレンスと関連付けられる典型的な性能上の欠点を被ることなく、アクセスされることを可能にする。
面倒なキャッシュコヒーレンスのオーバヘッドなしで、システムメモリの一部としてアクセスレータ付属メモリにアクセスする能力は、有益な動作環境をアクセラレータオフロードにもたらす。システムアドレスマッピングの一部としてメモリにアクセスする能力は、ホストソフトウェアが、オペランドをセットアップし、従来のI/O DMAデータコピーのオーバヘッドなしで、計算結果にアクセスすることを可能にする。そのような従来のコピーは、簡単なメモリアクセスと比較してすべて非効率であるドライバコール、割込み、及び、メモリマッピングされたI/O(MMIO)アクセスに関する。同時に、キャッシュコヒーレンスのオーバヘッドなしでアクセスレータ付属メモリにアクセスする能力は、オフロードされた計算の実行時間にとって重要であり得る。実質的なストリーミング書き込みメモリトラフィックを伴う場合、例えば、キャッシュコヒーレンスのオーバヘッドは、アクセラレータにより見られる有効な書き込み帯域幅を半分に削減できる。オペランドセットアップの効率性、結果的なアクセスの効率性、アクセラレータ計算の効率性のすべては、どれくらいアクセラレータのオフロードが機能しているかを判断する役割を果たす。(例えば、オペランドをセットアップし、結果を得る)オフロード機能のコストは非常に高く、オフロードしても全く効果がない場合がある、又は、非常に大きなジョブのみにアクセラレータを制限し得る。アクセラレータが計算を実行する効率性は、同じ効果を有し得る。
一実施例では、メモリアクセスを開始するエンティティ(例えば、アクセラレータ、コアなど)及びアクセスされるメモリ(例えば、ホストメモリ又はアクセラレータメモリ)に応じて異なるメモリアクセス及びコヒーレンス技術を適用する。これらの技術は、一般に、アクセスレータ付属メモリを提供する「コヒーレンスバイアス」メカニズムと称され、2つのセットのキャッシュコヒーレンスフローは、1つがその付属メモリへの効率的なアクセラレータのアクセスを最適化し、2つ目が、アクセスレータ付属メモリへのホストアクセス及びアクセスレータ付属メモリに対する共有アクセラレータ/ホストアクセスを最適化する。さらに、これらのフロー間の切り替えに関する2つの技術を含み、1つは、アプリケーションソフトウェアにより駆動され、もう一つは、独立したハードウェアの暗示により駆動される。コヒーレンスフローのセットの両方において、ハードウェアは、完全なキャッシュコヒーレンスを維持する。
図30に概して示されるように、一実施例では、アクセラレータ3001と、プロセッサコア及びI/O回路3003を有する1又は複数のコンピュータプロセッサチップとを含むコンピュータシステムを適用し、アクセラレータ3001は、マルチプロトコルリンク2800を介してプロセッサと結合される。一実施例において、マルチプロトコルリンク3010は、それらに限定されないが、詳細に上述されたものを含む複数の異なるプロトコルをサポートする動的に多重化されたリンクである。しかしながら、本発明の基礎となる原理は、任意の特定のプロトコルのセットに限定されるものではないことに留意されたい。さらに、アクセラレータ3001及びコアI/O3003は、実装に応じて、同じ半導体チップ又は異なる半導体チップ上に集積されてよいことに留意する。
例示された実施例では、アクセラレータメモリバス3012は、アクセラレータ3001をアクセラレータメモリ3005に結合し、別々のホストメモリバス3011は、コアI/O3003をホストメモリ3007に結合する。すでに述べたように、アクセラレータメモリ3005は、高帯域幅メモリ(HBM)又はスタック型DRAM(これらのいくつかの例は、本明細書で説明される)を有してよく、ホストメモリ3007は、DRAM、例えば、ダブルデータレート・シンクロナスダイナミックランダムアクセスメモリ(例えば、DDR3 SDRAM、DDR4 SDRAMなど)を有してよい。しかしながら、本発明の基礎となる原理は、任意の特定のタイプのメモリ又はメモリプロトコルに限定されない。
一実施例において、アクセラレータ3001、及び、プロセッサチップ3003内の処理コア上で実行する「ホスト」ソフトウェアの両方は、「ホストバイアス」フロー及び「デバイスバイアス」フローと称されるプロトコルフローについての2つの別個のセットを用いて、アクセラレータメモリ3005にアクセスする。以下で説明されるように、一実施例では、特定のメモリアクセスのためにプロトコルフローを変調すること及び/又は選択することに関する複数のオプションをサポートする。
コヒーレンスバイアスフローは、アクセラレータ3001と、プロセッサチップ3003のうちの1つとの間のマルチプロトコルリンク3010の2つのプロトコル層、すなわち、CACプロトコル層及びMAプロトコル層上に部分的に実装される。一実施例において、コヒーレンスバイアスフローは、(a)新たな方式でCACプロトコルにおける既存のオペコードを用いること、(b)既存のMA標準に対して新たなオペコードを加えること、及び、(c)(リンクがCAC及びPCDIのみを含む前の)マルチプロトコルリンク3001にMAプロトコルのサポートを加えることにより、イネーブルにされる。マルチプロトコルリンクは、ただ単にCAC及びMAをサポートすることに限定されないことに留意する。一実施例では、少なくともそれらのプロトコルをサポートすることが単に要求される。
本明細書で用いられるように、図30に示される「ホストバイアス」フローは、アクセラレータ3001が取り付けられるプロセッサチップ3003内の標準コヒーレンスコントローラ3009を通じてアクセラレータメモリ3005に、アクセラレータ自体からの要求を含むすべての要求を集中させるフローのセットである。これは、独自のメモリにアクセスするために、アクセラレータ3001に迂回路を取らせるが、アクセラレータ3001及びプロセッサコアI/O3003の両方からのアクセスが、プロセッサの標準コヒーレンスコントローラ3009を用いてコヒーレントに維持されることを可能にする。一実施例において、プロセッサコア3009がコヒーレンスコントローラ3009に要求を発行する方式と同じ又は同様の方式で、フローは、CACオペコードを用いて、マルチプロトコルリンクを介してプロセッサのコヒーレンスコントローラ3009に要求を発行する。例えば、プロセッサチップのコヒーレンスコントローラ3009は、アクセラレータ3001からの要求に起因するUPI及びCACコヒーレンスメッセージ(例えば、スヌープ)を、アクセラレータに代わってすべてのピアプロセッサコアチップ(例えば、3003)及び内部プロセッサエージェントに発行してよく、それらは、プロセッサコア3003からの要求の場合と同じ程度であろう。この態様において、コヒーレンシは、アクセラレータ3001によりアクセスされるデータと、プロセッサコアI/O3003との間で維持される。
一実施例において、コヒーレンスコントローラ3009はまた、マルチプロトコルリンク2800を介してアクセラレータのメモリコントローラ3006にメモリアクセスメッセージを条件付きで発行する。これらのメッセージはまた、データに、マルチプロトコルリンク2800のプロセッサのコヒーレンスコントローラ3009に返されることを強制し、その結果、マルチプロトコルリンク2800を介したCAC応答としてアクセラレータ3001に返される代わりに、コヒーレンスコントローラ3009がこれらのプロセッサダイに対してローカルにあるメモリコントローラに送信し、データがアクセラレータ3001の内部のエージェントに直接返されることを可能にする新たなオペコードを含むメッセージと同様である。
図30に示される「ホストバイアス」モードの一実施例では、アクセスレータ付属メモリ3005をターゲットとするプロセッサコア3003からのすべて要求は、通常のホストメモリ3007をターゲットにしていたのと同様に、直接的にプロセッサコヒーレンシコントローラ3009に送信される。コヒーレンスコントローラ3009は、これらの標準キャッシュコヒーレンスアルゴリズムを適用して、それらがアクセラレータ3001からのアクセスのために行うのと同様に、及び、それらが、通常のホストメモリ3007へのアクセスのために行うのと同様に、これらの標準キャッシュコヒーレンスメッセージを送信してよい。コヒーレンスコントローラ3009はまた、このクラスの要求のためにマルチプロトコルリンク2800を介してMAコマンドを条件付きで送信するが、この場合、MAフローは、マルチプロトコルリンク2800にわたってデータを返す。
図31に示される「デバイスバイアス」フローは、アクセラレータ3001が、ホストプロセッサのキャッシュコヒーレンスコントローラ3007に尋ねることなくそのローカルの付属メモリ3005にアクセスすることを可能にするフローである。より具体的には、これらのフローは、アクセラレータ3001が、マルチプロトコルリンク2800を介して要求を送信することなく、メモリコントローラ3006を介してそのローカルの付属メモリにアクセスすることを可能にする。
「デバイスバイアス」モードにおいて、プロセッサコアI/O3003からの要求は、上記の「ホストバイアス」に関する説明のように発行されるが、これらのフローのMA部分において異なって完了される。「デバイスバイアス」の場合、アクセスレータ付属メモリ3005に対するプロセッサ要求は、あたかも、それらが「未キャッシュ」の要求として発行されていたかのように完了される。この「未キャッシュ」の慣例は、デバイスバイアスフローの対象であるデータがプロセッサのキャッシュ階層に決してキャッシュされることがないように採用されている。これは、アクセラレータ3001が、プロセッサ上のキャッシュコヒーレンスコントローラ3009に尋ねることなくそのメモリ3005内のデバイスバイアスデータにアクセスすることを可能にするという事情がある。
一実施例において、「未キャッシュ」プロセッサコア3003アクセスフローに対するサポートは、プロセッサのCACバス上で、グローバルに監視される1回使用(「GO−UO」)応答で実装される。この応答は、データの一部をプロセッサコア3003に返し、データの値のみを一旦用いるようプロセッサに命令する。これは、データのキャッシングを防止し、「未キャッシュ」フローの要求を満たす。GO−UO応答をサポートしていないコアを有するシステムにおいて、「未キャッシュ」フローは、マルチプロトコルリンク2800のMA層上、及び、プロセッサコア3003のCACバス上のマルチメッセージ応答シーケンスを用いて実装されてよい。
具体的には、プロセッサコアが、アクセラレータ3001における「デバイスバイアス」ページをターゲットとするように得られる場合、アクセラレータは、アクセラレータからターゲットキャッシュラインに対する将来の要求をブロックするように、いくつかの状態をセットアップし、特別な「デバイスバイアスヒット」応答をマルチプロトコルリンク2800のMA層上に送信する。このMAメッセージに応じて、プロセッサのキャッシュコヒーレンスコントローラ3009は、要求するプロセッサコア3003にデータを返し、当該データを返した直後にスヌープ無効メッセージが続く。プロセッサコア3003がスヌープ無効を完了したものとして認めた場合、キャッシュコヒーレンスコントローラ3009は、別の特別なMA「デバイスバイアスBock完了」メッセージをマルチプロトコルリンク2800のMA層上のアクセラレータ3001に送り返す。この完了メッセージは、アクセラレータ3001に前述のブロック状態をクリアにさせる。
図107は、バイアスを用いた実施形態を示す。一実施例において、デバイスとホストバイアスフローとの選択は、アクセラレータメモリ3005内にバイアステーブル10707として維持され得るバイアストラッカーデータ構造により駆動される。このバイアステーブル10707は、アクセラレータ付属メモリページ毎に1又は2ビットを含むページ−グラニュラ構造(page-granular structure)(すなわち、メモリページの粒度で制御される)であってよい。バイアステーブル10707は、(例えば、バイアステーブル10707の頻繁に/最近用いられたエントリをキャッシュする)アクセラレータ内のバイアスキャッシュ10703を用いて、又は、用いることなく、アクセスレータ付属メモリ3005のスティールされたメモリ(stolen memory)範囲で実装されてよい。代替的に、バイアステーブル10707全体が、アクセラレータ3001内に維持されてもよい。
一実施例において、アクセスレータ付属メモリ3005へのそれぞれのアクセスと関連付けられるバイアステーブルエントリは、アクセラレータメモリへの実際のアクセスの前にアクセスされ、以下の動作を実行させる。
・デバイスバイアス内でこれらのページを見つけるアクセラレータ3001からのローカル要求が、アクセラレータメモリ3005に直接的に転送される。
・ホストバイアス内でこれらのページを見つけるアクセラレータ3001からのローカル要求が、マルチプロトコルリンク2800上のCAC要求としてプロセッサ3003に転送される。
・デバイスバイアス内でこれらのページを見つけるプロセッサ3003からのMA要求が、上記で説明した「未キャッシュ」フローを用いて要求を完了する。
・ホストバイアス内でこれらのページを見つけるプロセッサ3003からのMA要求が、通常のメモリ読み出しのように要求を完了する。
ページのバイアス状態は、ソフトウェアベースのメカニズム、ハードウェア支援型のソフトウェアベースのメカニズムのいずれか一方により、又は、制限されたセットの場合、純粋にハードウェアベースのメカニズムにより変更され得る。
バイアス状態を変更するための1つのメカニズムは、APIコール(例えば、OpenCL)を採用し、バイアス状態を変更するように指示するアクセラレータ3001にメッセージを順番に送信(又は、コマンド記述子をエンキュー)するアクセラレータのデバイスドライバを順番に呼び出し、いくつかの遷移に関して、ホストにおいてキャッシュフラッシュ処理を実行する。キャッシュフラッシュ処理は、ホストバイアスからデバイスバイアスへの遷移に必要とされるが、逆の遷移には必須ではない。
いくつかの場合、ソフトウェアが、いつバイアス遷移APIコールを行い、いつページ要求バイアス遷移を識別するかを判断することは難しい。そのような場合、アクセラレータは、バイアス遷移(暗示)メカニズムを実装してよく、バイアス遷移の必要性を検出し、それを示すメッセージをそのドライバに送信する。暗示メカニズムは、ホストバイアスページへのアクセラレータのアクセス、又は、デバイスバイアスページへのホストのアクセスをトリガし、かつ、割込みを介してアクセラレータのドライバにイベントをシグナリングするバイアステーブルルックアップに対応するメカニズムと同じくらい簡単であり得る。
いくつかの実施例では、バイアス遷移状態の値をイネーブルにするために、第2のバイアス状態ビットを必要とし得ることに留意する。これは、システムが、メモリページにアクセスすることを継続することを可能にする一方、それらのページは、バイアス変更の処理にある(すなわち、キャッシュが部分的にフラッシュされ、後続の要求に起因するインクリメントキャッシュ汚染が抑制されなければならない場合)。
一実施例に従う例示的な処理が図32に示される。処理は、本明細書で説明されるシステム及びプロセッサアーキテクチャ上に実装され得るが、任意の特定のシステム又はプロセッサアーキテクチャに限定されない。
3201において、ページの特定のセットがデバイスバイアス内に置かれる。すでに述べたように、これは、(例えば、各ページと関連付けられたビットを設定することにより)ページがデバイスバイアス内にあることを示すために、バイアステーブル内のこれらのページに対するエントリを更新することにより実現され得る。一実施例において、一旦デバイスバイアスに設定されると、ページは、ホストキャッシュメモリにキャッシュされていないことが保証される。3202において、ページがデバイスメモリから割り当てられる(例えば、ソフトウェアが、ドライバ/APIコールを開始することによりページを割り当てる)。
3203において、オペランドがプロセッサコアから割り当てられたページにプッシュされる。一実施例において、これは、(例えば、OpenCL APIコールを介して)ホストバイアスnオペランドページをフリップするために、APIコールを用いるソフトウェアにより実現される。必要とされるデータコピー又はキャッシュフラッシュがなく、オペランドデータは、ホストキャッシュ階層内の一部の任意の位置におけるこのステージで終了してよい。
3204において、アクセラレータデバイスは、オペランドを用いて結果を生成する。例えば、それは、コマンドを実行して、そのローカルメモリから直接的にデータを処理してよい(例えば、上述した3005)。一実施例において、ソフトウェアは、OpenCL APIを用いて、オペランドページをデバイスバイアスにフリップして戻す(例えば、バイアステーブルを更新する)。APIコールの結果として、ワーク記述子は、(例えば、以下で説明されるように、専用のワークキュー上での共有を介して)デバイスにサブミットされる。ワーク記述子は、ホストキャッシュからオペランドページをフラッシュするようデバイスに命令してよく、結果として(例えば、CACプロトコルにおけるCLFLUSHを用いて実行される)キャッシュフラッシュをもたらす。一実施例において、アクセラレータは、ホスト関連コヒーレンスオーバヘッドなしで実行され、データを結果ページにダンプする。
3205において、割り当てられたページから結果が引き出される。例えば、一実施例において、ソフトウェアは、結果ページをホストバイアスにフリップするために、(例えば、OpenCL APIを介して)1又は複数のAPIコールを行う。この動作は、一部のバイアス状態を変更させ得るが、任意のコヒーレンス又はキャッシュフラッシュ動作を生じさせない。次に、ホストプロセッサコアは、必要に応じて、結果のデータにアクセスし、キャッシュし、共有することができる。最後に、3206において、割り当てられたページは、(例えば、ソフトウェアを介して)解放される。
オペランドが1又は複数のI/Oデバイスから解放される同様の処理が、図33に示される。3301において、ページの特定のセットがデバイスバイアス内に置かれる。すでに述べたように、これは、(例えば、各ページと関連付けられたビットを設定することにより)ページがデバイスバイアス内にあることを示すために、バイアステーブル内のこれらのページに対するエントリを更新することにより実現され得る。一実施例において、一旦デバイスバイアスに設定されると、ページは、ホストキャッシュメモリにキャッシュされていないことが保証される。3302において、ページがデバイスメモリから割り当てられる(例えば、ソフトウェアが、ドライバ/APIコールを開始することによりページを割り当てる)
3303において、オペランドは、I/Oエージェントから割り当てられたページにプッシュされる。一実施例において、これは、データを書き込むために、非割り当て格納を用いて、I/Oエージェント及びI/OエージェントにDMA要求をポストするソフトウェアにより実現される。一実施例において、データは、ホストキャッシュ階層に決して割り当てられることはなく、ターゲットページがデバイスバイアス内に留まる。
3304において、アクセラレータデバイスは、オペランドを用いて結果を生成する。例えば、ソフトウェアは、アクセラレータデバイスにワークをサブミットしてよく、必要とされるページ遷移はない(すなわち、ページはデバイスバイアス内に留まる)。一実施例において、アクセラレータデバイスは、ホスト関連コヒーレンスオーバヘッドなしで実行され、アクセラレータは、データを結果ページにダンプする。
3305において、(例えば、ソフトウェアからの指示の下)I/Oエージェントは、割り当てられたページから結果を引き出す。例えば、ソフトウェアは、DMA要求をI/Oエージェントにポストしてよい。ソースページが、デバイスバイアスに留まる場合、必要とされるページ遷移はない。一実施例において、I/Oブリッジは、RdCurr(現在の読み出し)要求を用いて、結果ページからデータのキャッシュ不能なコピーをつかむ。
いくつかの実施例において、ワークキュー(WQ)は、ソフトウェア、サービス品質(QoS)を実装するために用いられるアービタ及び公平性ポリシ、記述子を処理するための処理エンジン、アドレス変換及びキャッシングインタフェース、及び、メモリ読み出し/書き込みインタフェースによりサブミットされた「記述子」を保持する。記述子は、行われるワークの範囲を定義する。図34に図示されるように、一実施例では、専用のワークキュー3400及び共有のワークキュー3401といった2つの異なるタイプのワークキューがある。専用のワークキュー3400は、単一のアプリケーション3413に対する記述子を格納する一方、共有のワークキュー3401は、複数のアプリケーション3410−3412によりサブミットされた記述子を格納する。ハードウェアインタフェース/アービタ3402は、特定のアービトレーションポリシに従って(例えば、各アプリケーション3410−3413及びQoS/公平性ポリシの処理要件に基づいて)、ワークキュー3400−3401からアクセラレータ処理エンジン3405に記述子をディスパッチする。
図108a〜図108Bは、ワークキューベースの実装と共に用いられるメモリマッピングされたI/O(MMIO)空間レジスタを示す。バージョンレジスタ10807は、デバイスによりサポートされているこのアーキテクチャ仕様のバージョンを報告する。
一般的な機能レジスタ(GENCAP)10808は、デバイスの一般的な機能、例えば、最大転送サイズ、最大バッチサイズなどを規定する。テーブルBは、GENCAPレジスタにおいて特定され得る様々なパラメータ及び値を列挙する。
一実施例において、ワークキュー機能レジスタ(WQCAP)10810は、ワークキューの機能、例えば、動作についての専用及び/又は共有モードに関するサポート、エンジンの数、ワークキューの数などを規定する。以下のテーブルCは、構成され得る様々なパラメータ及び値を列挙する。
一実施例において、オペレーション機能レジスタ(OPCAP)10811は、デバイスによりサポートされるオペレーションタイプを規定するビットマスクである。各ビットは、ビット位置と同じコードを有するオペレーションタイプに対応する。例えば、このレジスタのビット0は、No−opオペレーション(コード0)に対応する。ビットは、オペレーションがサポートされている場合に設定され、オペレーションがサポートされていない場合にクリアされる。
一実施例において、一般的な構成レジスタ(GENCFG)10812は、仮想チャネル(VC)ステアリングタグを規定する。以下のテーブルEを参照する。
一実施例において、一般的な制御レジスタ(GENCTRL)10813は、ハードウェア又はソフトウェアエラーに対して割込みが生成したか否かを示す。以下のテーブルFを参照する。
一実施例において、デバイスイネーブルレジスタ(ENABLE)は、エラーコード、デバイスがイネーブルか否かに応じたインジケータ、及び、デバイスリセット値を格納する。さらなる詳細については、以下のテーブルGを参照する。
一実施例において、割込み要因レジスタ(INTCAUSE)は、割込みの要因を示す値を格納する。以下のテーブルHを参照する。
一実施例において、コマンドレジスタ(CMD)10814は、ドレインWQ、ドレインPASID及びドレインオールコマンドをサブミットするために用いられる。アボート領域は、要求されたオペレーションがドレインであるか、アボートであるかを示す。このレジスタに書き込む前に、ソフトウェアは、任意のコマンドが、このレジスタを介してサブミットされる前に完了したことを確保し得る。このレジスタに書き込む前に、ソフトウェアは、コマンド構成レジスタ、及び、完了記録が要求された場合はコマンド完了記録アドレスレジスタも構成してよい。
ドレインオールコマンドは、すべてのWQ及びすべてのエンジン内のすべての未処理の記述子をドレイン又はアボートする。ドレインPASIDコマンドは、すべてのWQ及びすべてのエンジン内の特定のPASIDを用いて記述子をドレイン又はアボートする。ドレインWQは、特定のWQ内のすべての記述子をドレイン又はアボートする。実装に応じて、任意のドレインコマンドは、待機する必要がある記述子に加えて、他の記述子の完了を待ってよい。
アボート領域が1である場合、ソフトウェアは、影響のある記述子が廃棄されることを要求している。しかしながら、ハードウェアは、これらの一部又はすべてをさらに完了してよい。記述子が廃棄された場合、書き込まれる完了記録はなく、その記述子に対して生成される完了割込みはない。他のメモリアクセスの一部又はすべてが発生し得る。
コマンドの完了は、完了割込みを生成することにより(要求された場合)、このレジスタのステータスフィールドをクリアにすることにより示される。完了がシグナリングされたときに、すべての影響のある記述子は、完了又は廃棄のいずれか一方であり、任意の影響のある記述子に起因して生成されるさらなるアドレス変換、メモリ読み出し、メモリ書き込み又は割込みはない。以下のテーブルIを参照する。
一実施例において、ソフトウェアエラーステータスレジスタ(SWERROR)10815は、記述子をサブミットした場合のエラー、記述子内の完了記録アドレスを変換するときのエラー、記述子内の完了記録アドレス有効フラグが0である場合、記述子を検証するときのエラー、及び、記述子内の完了記録アドレス有効フラグが0である場合にページフォールトなど、記述子を処理している間のエラーなど、複数の異なるタイプのエラーを格納する。以下のテーブルJを参照する。
一実施例において、ハードウェアエラーステータスレジスタ(HWERROR)10816は、ソフトウェアエラーステータスレジスタと同様の方式である(上記を参照)。
一実施例において、グループ構成レジスタ(GRPCFG)10817は、ワークキュー/エンジングループごとに構成データを格納する(図36〜図37を参照)。特に、グループ構成テーブルは、エンジンに対するワークキューのマッピングを制御するBAR0におけるレジスタのアレイである。エンジンと同じ数のグループがあるが、ソフトウェアは、必要とするグループの数を構成してよい。それぞれのアクティブなグループは、1又は複数のワークキュー及び1又は複数のエンジンを含む。任意の未使用のグループは、0に等しいWQフィールド及びエンジンフィールドの両方を有していなければならない。グループ内の任意のWQにサブミットされた記述子は、グループ内の任意のエンジンにより処理されてよい。それぞれのアクティブなワークキューは、単一のグループ内になければならない。アクティブなワークキューは、対応するWQCFGレジスタのWQサイズフィールドがゼロ以外のものである。グループ内に無いエンジンはいずれもインアクティブである。
各GRPCFGレジスタ10817は、3つのサブレジスタに分割されてよく、各サブレジスタは、1又は複数の32ビットワードである(テーブルK〜Mを参照)。デバイスはイネーブルである間、これらのレジスタは、読み取り専用であり得る。それらは、WQCAPのワークキュー構成サポートフィールドが0である場合も読み取り専用である。
BAR0内のサブレジスタのオフセットは、グループGごとに、0≦G<エンジンの数であり、一実施例では以下のとおりである。
一実施例において、ワークキュー構成レジスタ(WQCFG)10818は、各ワークキューのオペレーションを規定するデータを格納する。WQ構成テーブルは、BAR0における16バイトレジスタのアレイである。WQ構成レジスタの数は、WQCAP内のWQフィールドの数と一致する。
各16バイトWQCFGレジスタは、4つの32ビットサブレジスタに分割され、アラインされた64ビット読み出し又は書き込み動作を用いて、読み出され又は書き込まれてよい。
デバイスがイネーブルの間、又は、WQCAPのワークキュー構成サポートフィールドが0である場合、各WQCFG−Aサブレジスタは、読み取り専用である。
WQCAPのワークキュー構成サポートフィールドが0でない限り、各WQCFG−Bはいつでも書き込み可能である。WQがイネーブルであるときに、WQ閾値フィールドがWQサイズより大きい値を含む場合、WQはイネーブルにされず、WQエラーコードは4に設定される。WQがイネーブルの間、WQ閾値フィールドがWQサイズより大きい値で書き込まれている場合、WQはディセーブルであり、WQエラーコードは4に設定される。
WQがイネーブルの間、各WQCFG−Cサブレジスタは読み取り専用である。それは、WQイネーブルを1に設定する前又は同時に書き込まれてよい。WQCAPのワークキュー構成サポートフィールドが0である場合、以下のフィールド、すなわち、WQモード、WQ障害のブロック・イネーブル(WQ Fault on Block Enable)及びWQ優先度のフィールドは、常に読み取り専用である。たとえWQCAPのワークキュー構成サポートフィールドが0であるとしても、WQCFG−Cの以下のフィールド、すなわち、WQ PASID及びWQ U/Sのフィールドは、WQがイネーブルにされていない場合に書き込み可能である。
各WQCFG−Dサブレジスタは、いつでも書き込み可能である。しかしながら、デバイスがイネーブルにされていない場合、それは、WQイネーブルを1に設定するエラーである。
WQイネーブルが1に設定されている場合、WQイネーブル及びWQエラーコードフィールドの両方がクリアされる。次に、WQイネーブル又はWQエラーコードのいずれか一方は、WQのイネーブル化に成功したか否かを示すゼロ以外の値に設定される。
すべてのWQCFGレジスタのWQサイズフィールドの合計は、GENCAP内のWQサイズフィールドの合計より大きくすることができない。この制約は、デバイスがイネーブルにされたときにチェックされる。WQサイズフィールドが0であるWQは、イネーブルにされることができず、そのようなWQCFGレジスタのすべての他のフィールドが無視される。デバイスがイネーブルの間、WQサイズフィールドは読み取り専用である。サブレジスタのそれぞれに関するデータについては、テーブルNを参照する。
一実施例において、ワークキュー占有割込み制御レジスタ10819(ワークキュー(WQ)毎に1つ)は、ワークキューの占有率が特定の閾値に低下した場合、ソフトウェアが割込みを要求することを可能にする。WQに対するWQ占有割込みイネーブルが1であり、現在のWQ占有率が、WQ占有率の制限又はそれを下回る場合、以下の動作が実行され得る。1.WQ占有割込みイネーブルフィールドがクリアされる。2.割込み理由レジスタのビット3が1に設定される。3.割込み理由レジスタのビット3が、段階2の前に0であった場合、MSI−Xテーブルエントリ0を用いて割込みが生成される。4.レジスタがイネーブル=1、及び、制限≧現在のWQ占有率で書き込まれた場合、割込みがすぐ生成される。結果として、レジスタがイネーブル=1、及び、制限≧WQサイズで書き込まれた場合、常に割込みはすぐに生成される。
一実施例において、ワークキューステータスレジスタ(WQ毎に1つ)10820は、各WQにおける現在のエントリの数を規定する。この数は、記述子がキューにサブミットされ、又は、キューからディスパッチされるときにはいつでも変更する可能性があるので、WQに空きがあるか否かを判断することに信頼できない。
一実施例において、MSI−Xエントリ10821は、MSI−Xテーブルデータを格納する。オフセット及びエントリの数は、MSI−X機能にある。提案されたエントリの数は、WQの数に2を加えた値である。
一実施例において、MSI−X未処理ビットアレイ10822は、MSI−X機能にあるオフセット及びエントリの数を格納する。
一実施例において、割込みメッセージストレージエントリ10823は、テーブル構造内に割込みメッセージを格納する。このテーブルのフォーマットは、PCIeで規定されるMSI−Xテーブルのフォーマットと同様であるが、サイズは、2048個のエントリに限定されない。しかしながら、いくつかの実施例において、このテーブルのサイズは、異なるDSA実装間で変化してよく、2048個のエントリより少なくてもよい。一実施例において、エントリの数は、一般的な機能レジスタの割込みメッセージストレージサイズフィールド内にある。割込みメッセージストレージサポート機能が0である場合、このテーブルは提示されない。DSAが多数の仮想マシン又はコンテナをサポートするために、サポートされるテーブルのサイズは、かなり大きい必要がある。
一実施例において、IMS内の各エントリのフォーマットは、以下のテーブルPにおいて説明される。
図35は、I/Oファブリックインタフェース3501(例えば、上記で説明されたマルチプロトコルリンク2800など)を介してサブミットされた記述子を受信する複数のワークキュー3511−3512を有するデータストリーミングアクセラレータ(DSA)デバイスの一実施例を示す。DSAは、クライアント(プロセッサコア、ピア入力/出力(IO)エージェント(ネットワークインタフェースコントローラ(NIC)など)及び/又は、ソフトウェアチェーンオフロード要求など)からのダウンストリームワーク要求を受信するために、及び、アップストリーム読み出し、書き込み、及びアドレス変換オペレーションのためにI/Oファブリックインタフェース3501を用いる。例示された実施例では、ワークキュー間のアービトレーションを実行し、複数のエンジン3550のうちの1つにワーク記述子をディスパッチするアービタ3513を含む。アービタ3513及びワークキュー3511−1012の処理は、ワークキュー構成レジスタ3500を通じて構成されてよい。例えば、アービタ3513は、ワークキュー3511−1012のそれぞれからの記述子をエンジン3550のそれぞれにディスパッチするために、様々なQoS及び/又は公平性ポリシを実装するように構成されてよい。
一実施例において、ワークキュー3511−3512にキューイングされる記述子のいくつかは、ワーク記述子のバッチを含む/識別するバッチ記述子3515である。アービタ3513は、変換キャッシュ3520(プロセッサ上の潜在的に他のアドレス変換サービス)を通じて変換されたアドレスを使用いて、メモリから記述子3518のアレイを読み出すことによりバッチ記述子を処理するバッチ処理ユニット3516にバッチ記述子を転送する。一旦物理アドレスが識別されると、データ読み出し/書き込み回路3540は、メモリから記述子のバッチを読み出す。
第2のアービタ3519は、バッチ処理ユニット3516により提供されるワーク記述子3518と、ワークキュー3511−3512から取得される個々のワーク記述子3514とのバッチ間でアービトレーションを実行し、ワーク記述子をワーク記述子処理ユニット3530に出力する。一実施例において、ワーク記述子処理ユニット3530は、(データR/Wユニット3540を介して)メモリを読み出し、データに対して要求されたオペレーションを実行し、出力データを生成し、(データR/Wユニット3540を介して)出力データ、完了記録及び割込みメッセージを書き込むステージを有する。
一実施例において、ワークキュー構成は、ノンポステッドENQCMD/S命令を使用する記述子を受信する共有のワークキュー(SWQ)として、又は、ポステッドMOVDIR64B命令を使用する記述子を受信する専用のワークキュー(DWQ)としての、いずれか一方として、ソフトウェアが(WQ構成レジスタ3500を介して)各WQを構成することを可能にする。図34に関して上記ですでに述べたように、DWQは、単一のアプリケーションからサブミットされたワーク記述子及びバッチ記述子を処理してよく、他方、SWQは、複数のアプリケーションの中で共有されてよい。WQ構成レジスタ3500は、どのWQ3511−3512がどのアクセラレータエンジン3550に供給するか、及び、各エンジンを供給するWQ3511−3512に関連する優先度をソフトウェアが制御することも可能にする。例えば、オーダリングされた優先度のセットは、(例えば、高、中、低:1、2、3などに)規定されてよく、記述子は、一般に、より低い優先度のワークキューの前に、又は、より低い優先度のワークキューからディスパッチするも頻繁に、より高い優先度のワークキューからディスパッチされてよい。例えば、高い優先度及び低い優先度として識別される2つのワークキューを用いて、ディスパッチされる各10個の記述子について、10個の記述子のうちの8個が、高い優先度のワークキューからディスパッチされてよく、一方、10個の記述子のうちの2個が、低い優先度のワークキューからディスパッチされる。様々な他の技術が、ワークキュー3511−3512間で異なる優先度のレベルを実現するために用いられてよい。
一実施例において、データストリーミングアクセラレータ(DSA)は、PCIエクスプレス構成メカニズムとの互換性があるソフトウェアであり、その構成マッピングレジスタセット内にPCIヘッダ及び拡張空間を実装する。構成レジスタは、ルートコンプレックスからCFC/CF8又はMMCFGを通じてプログラミングされ得る。同様に、すべての内部レジスタは、JTAG又はSMバスインタフェースを通じてもアクセス可能であってよい。
一実施例において、DSAデバイスは、そのオペレーションを制御するためにメモリマップレジスタを用いる。機能、構成及びワークサブミッションレジスタ(ポータル)は、BAR0、BAR2及びBAR4レジスタにより規定されるMMIO領域を通じてアクセス可能である(以下で説明される)。各ポータルは、それらがプロセッサページテーブルを用いて異なるアドレス空間(クライアント)に独立にマッピングされ得るように、別々の4Kページ上にあってよい。
すでに述べたように、ソフトウェアは、記述子を通じてDSAに対するワークを規定する。記述子は、DSAに対するオペレーションのタイプを特定して、データ及びステータスバッファのアドレス、即値オペランド、完了属性などを実行する(記述子のフォーマットに関する追加の詳細及び詳細は、以下で説明する)。完了属性は、完了記録を書き込むアドレスと、選択的な完了割込みを生成するのに必要とされる情報とを規定する。
一実施例において、DSAは、デバイス上のクライアント固有の状態を維持することを回避する。記述子を処理するすべての情報は、記述子自体に入っている。これは、ユーザモードアプリケーション間、並びに、仮想化されたシステム内の異なる仮想マシン(マシンコンテナ)間のその共有能力を改善する。
記述子は、オペレーション及び関連するパラメータを含んでよい(ワーク記述子と呼ばれる)、又は、記述子は、ワーク記述子のアレイのアドレスを含むことができる(バッチ記述子と呼ばれる)。ソフトウェアは、メモリに記述子を準備して、デバイスのワークキュー(WQ)3511−3512に記述子をサブミットする。記述子は、WQのモード及びクライアントの特権レベルに応じて、MOVDIR64B、ENQCMD又はENQCMDS命令を用いるデバイスにサブミットされる。
各WQ3511−3512は、固定数のスロットを有し、それによって、重い負荷の下、いっぱいになり得る。一実施例において、デバイスは、ソフトウェアがフロー制御を実装するのを助けるために、必要なフィードバックを提供する。デバイスは、ワークキュー3511−3512から記述子をディスパッチし、さらなる処理のためにエンジンにこれらをサブミットする。エンジン3550が、記述子を完了し、結果的にアボートをもたらす特定の障害又はエラーに遭遇した場合、ホストメモリ内の完了記録に書き込むこと又は割込みを発行することのいずれか一方により、又は、その両方によりホストソフトウェアを通知する。
一実施例において、各ワークキューは、それぞれがデバイスMMIO空間内の別々の4KBページにある複数のレジスタを介してアクセス可能である。各WQに関して、1つのワークサブミッションレジスタは、「非特権ポータル」と呼ばれ、ユーザモードクライアントにより用いられるユーザ空間にマッピングされる。もう一つのワークサブミッションレジスタは、「特権ポータル」と呼ばれ、カーネルモードドライバにより用いられる。残りは、ゲストポータルであり、仮想マシン内のカーネルモードクライアントにより用いられる。
すでに述べたように、各ワークキュー3511−3512は、専用又は共有の2つのモードのうちの1つにおいて実行するように構成され得る。DSAは、専用及び共有モードに対するサポートを示すように、ワークキュー機能レジスタにおける機能ビットをさらす。また、DSAは、モードのうちの1つで動作するように各WQを構成するために、ワークキュー構成レジスタ3500に制御をさらす。WQのモードは、WQがディセーブルの間、すなわち、(WQCFGイネーブル=0)の間だけ、変更され得る。WQ機能レジスタ及びWQ構成レジスタの追加の詳細は、以下で説明する。
一実施例では、共有モードにおいて、DSAクライアントは、ENQCMD又はENQCMDS命令を用いて、記述子をワークキューにサブミットする。ENQCMD及びENQCMDSは、64バイトのノンポステッド書き込みを用いており、完了する前に、デバイスからの応答を待機する。DSAは、ワークキューに空きがある場合には(例えば、要求したクライアント/アプリケーションに)「成功」、又は、ワークキューが満杯の場合には「リトライ」を返す。ENQCMD及びENQCMDS命令は、コマンドサブミッションのステータスをゼロフラグで返してよい(0は成功を示し、1はリトライを示す)。ENQCMD及びENQCMDS命令を用いて、複数のクライアントは、同じワークキューに記述子を直接かつ同時にサブミットし得る。デバイスがこのフィードバックを提供するので、クライアントは、これらの記述子が受け取られたか否かを伝えることができる。
共有モードにおいて、DSAは、カーネルモードクライアント用の特権ポータルを介して、サブミッションのための一部のSWQ容量を予約してよい。非特権ポータルを介したワークサブミッションは、SWQ内の記述子の数が、SWQ用に設定された閾値に達するまで受け取られる。特権ポータルを介したワークサブミッションは、SWQが満杯になるまで受け取られる。ゲストポータルを介したワークサブミッションは、非特権ポータルと同じ方法で閾値により制限される。
ENQCMD又はENQCMDS命令が、「成功」を返した場合、記述子は、デバイスにより受け取られ、処理のためにキューイングされる。命令が、「リトライ」を返した場合、ソフトウェアは、記述子をSWQに再サブミットすることを試み得る、又は、それが非特権ポータルを用いるユーザモードクライアントであった場合、特権ポータルを用いて、ユーザモードクライアントの代わりに記述子をサブミットすることをカーネルモードドライバに要求し得るのいずれか一方を行う。これは、サービス妨害を回避するのに役立ち、将来への前進保証を提供する。代替的に、ソフトウェアは、SWQが満杯になった場合、他の方法(例えば、CPUを用いてワークを実行する)を用いてよい。
クライアント/アプリケーションは、処理アドレス空間ID(PASID)と呼ばれる20ビットのIDを使用してデバイスにより識別される。PASIDは、デバイスTLB1722内のアドレスを検索して、アドレス変換又はページ要求をIOMMU1710に(例えば、マルチプロトコルリンク2800を介して)送信するために、デバイスにより用いられる。共有モードにおいて、各記述子と共に用いられるPASIDは、記述子のPASIDフィールドに含まれる。一実施例において、ENQCMDは、特定のレジスタ(例えば、PASID MSR)から現在のスレッドのPASIDを記述子にコピーする一方、ENQCMDSは、スーパバイザモードのソフトウェアが記述子にPASIDをコピーすることを可能にする。
「専用」モードにおいて、DSAクライアントは、MOVDIR64B命令を用いて、記述子をデバイスのワークキューにサブミットしてよい。MOVDIR64Bは、64バイトのポステッド書き込みを用い、命令は、書き込み動作のポステッド特性に起因してより高速完了する。専用のワークキューに関し、DSAは、ワークキュー内のスロットの総数をさらし、ソフトウェアに依存してフロー制御を提供してよい。ソフトウェアは、ワークキューの満杯条件を検出するために、サブミットされ、完了した記述子の数をトラッキングする役割を担う。ワークキューに空きがないときに、ソフトウェアが、記述子を専用のWQに誤ってサブミットした場合、記述子はドロップされ、エラーが、(例えば、ソフトウェアエラーレジスタに)記録されてよい。
MOVDIR64B命令は、ENQCMD又はENQCMDS命令が行うように、PASIDを書き込まないので、専用モードにおいて、記述子内のPASIDフィールドを用いることができない。DSAは、専用のワークキューにサブミットされた記述子内のPASIDフィールドを無視してよく、代わりに、WQ構成レジスタ3500のWQ PASIDフィールドを用いてアドレス変換を行う。一実施例において、WQ PASIDフィールドは、専用モードでワークキューを構成する場合、DSAドライバにより設定される。
専用モードは、複数のクライアント/アプリケーションにより単一のDWQを共有するものではないが、DSAデバイスは、複数のDWQを有するように構成され得、DWQのそれぞれは、クライアントに独立に割り当てられ得る。さらに、DWQは、異なるクライアント/アプリケーションのために提供された異なる性能レベルに対して同じ又は異なるQoSレベルを有するように構成され得る。
一実施例において、データストリーミングアクセラレータ(DSA)は、ワークキュー3511−1012にサブミットされた記述子を処理する2又はそれより多いエンジン3550を含む。DSAアーキテクチャの一実施例は、0から3の番号が付された4つのエンジンを含む。エンジン0及び1は、それぞれ、最大でデバイスの全帯域幅(例えば、読み出し用に30GB/s及び書き込み用に30GB/s)まで利用することが可能である。もちろん、すべてのエンジンについての組み合わられる帯域幅はまた、デバイスに対して利用可能な最大の帯域幅に制限される。
一実施例において、ソフトウェアは、グループ構成レジスタを用いて、WQ3511−3512及びエンジン3550をグループに構成する。それぞれのグループは、1又は複数のWQ及び1又は複数のエンジンを含む。DSAは、グループ内の任意のエンジンを用いて、グループ内の任意のWQにポステッドされた記述子を処理してよく、各WQ及び各エンジンは、1つのグループのみにあってよい。グループの数はエンジンの数と同じであってよいので、各エンジンは別々のグループにあり得るが、任意のグループが1より多いエンジンを含む場合に、すべてのグループが用いられる必要があるわけではない。
DSAアーキテクチャは、ワークキュー、グループ及びエンジンを構成するときに大きな柔軟性を可能にするが、ハードウェアは、特定の構成の使用のために狭く設計されてよい。エンジン0及び1は、ソフトウェアの要件に応じて、2つの異なる方式のうちの1つで構成されてよい。1つの推奨される構成は、同じグループ内にエンジン0及び1の両方を配置することである。ハードウェアは、グループ内の任意のワークキューから記述子を処理するエンジンのいずれか一方を用いる。この構成において、一方のエンジンが高レイテンシメモリアドレス変換又はページフォールトに起因してストールを有する場合、他方のエンジンは、動作を継続して、全体的なデバイスのスループットを最大化することができる。
図36は、各グループ3611及び3612内の2つのワークキュー3621−3622及び3623−3624をそれぞれ示すが、サポートされるWQの最大数までの任意の数があってよい。グループ内のWQは、異なる優先度を有する共有のWQ、1つの共有のWQ及び他の専用のWQ、又は、同じ又は異なる優先度を有する複数の専用のWQであってよい。図示された例では、グループ3611は、エンジン0及び1 3601によりサービス提供され、グループ3612は、エンジン2及び3 3602によりサービス提供される。
図37に示されるように、エンジン0 3700及びエンジン1 3701を使用する別の構成では、別々のグループ3710及び3711にそれぞれこれらを配置する。同様に、グループ2 3712は、エンジン2 3702に割り当てられ、グループ3は、エンジン3 3703に割り当てられる。さらに、グループ0 3710は、2つのワークキュー3721及び3722から構成され、グループ1 3711は、ワークキュー3723から構成され、ワークキュー2 3712は、ワークキュー3724から構成され、グループ3 3713は、ワークキュー3725から構成される。
レイテンシに敏感なオペレーションが他のオペレーションの背後でブロックされた状態になる可能性を低減したい場合に、ソフトウェアは、この構成を選択してよい。この構成において、ソフトウェアは、レイテンシに敏感なオペレーションをエンジン1 3702に接続されたワークキュー3723に、他のオペレーションをエンジン0 3700に接続されたワークキュー3721−3722にサブミットする。
エンジン2 3702及びエンジン3 3703は、例えば、相変化メモリなどの高帯域幅の不揮発性メモリに書き込むために用いられてよい。これらのエンジンの帯域幅の機能は、このタイプのメモリの予期される書き込み帯域幅に一致するサイズであってよい。この利用に関し、エンジン構成レジスタのビット2及び3は、1に設定されるべきであり、仮想チャネル1(VC1)が、これらのエンジンからのトラフィックに用いられるべきであることを示す。
高帯域幅の不揮発性メモリ(例えば、相変化メモリ)がないプラットフォームにおいて、又は、DSAデバイスがこのタイプのメモリに書き込むために用いられない場合、エンジン2及び3は、未使用であってよい。しかしながら、サブミットされたオペレーションが制限された帯域幅に耐えるという条件で、ソフトウェアが、追加の低レイテンシパスとしてこれらの使用を行うことが可能である。
各記述子がワークキューのヘッドに到着したときに、それは、スケジューラ/アービタ3513により除去され、グループ内のエンジンの1つに転送されてよい。メモリ内のワーク記述子3518を指す、バッチ記述子3515について、エンジンは、メモリから(すなわち、バッチ処理ユニット3516を用いて)ワーク記述子のアレイをフェッチする。
一実施例において、各ワーク記述子3514について、エンジン3550は、完了記録アドレスのための変換をプリフェッチし、ワーク記述子処理ユニット3530にオペレーションを渡す。ワーク記述子処理ユニット3530はソース及び宛先アドレス変換のために、デバイスTLB1722及びIOMMU1710を用いて、ソースデータを読み出し、特定のオペレーションを実行し、宛先データをメモリに書き戻す。オペレーションが完了した場合、エンジンは、ワーク記述子により要求されている場合、予め変換された完了アドレスに完了記録を書き込み、割込みを生成する。
一実施例において、DSAの複数のワークキューは、サービス品質(QoS)の複数のレベルを提供するために用いられ得る。各WQの優先度は、WQ構成レジスタ3500において特定されてよい。WQの優先度は、同じグループ内の他のWQに関連する(例えば、単独でグループ内に存在するWQについての優先度レベルには意味がない)。グループ内のワークキューは、同じ又は異なる優先度を有し得る。しかしながら、単一のSWQは、同じ用途をサービス提供するであろうから、同じグループ内に同じ優先度を有する複数の共有のWQを構成しても意味がない。スケジューラ/アービタ3513は、これらの優先度に従って、ワークキュー3511−3512からエンジン3550にワーク記述子をディスパッチする。
図38は、実行対象となるオペレーションを規定するオペレーションフィールド3801、複数のフラグ3802、処理アドレス空間識別子(PASID)フィールド3803、完了記録アドレスフィールド3804、ソースアドレスフィールド3805、宛先アドレスフィールド3806、完了割込みフィールド3807、転送サイズフィールド3808、及び、(潜在的に)1又は複数のオペレーションに固有のフィールド3809を含む記述子1300の一実施例を示す。一実施例では、完了記録アドレス有効、要求完了記録及び要求完了割込みという3つのフラグがある。
共通のフィールドは、トラステッドフィールド及び非トラステッドフィールドの両方を含む。トラステッドフィールドは、それらがホスト上のCPUにより又は特権(リング0又はVMM)ソフトウェア入力されるので、常にDSAデバイスにより信頼されている。非トラステッドフィールドは、DSAクライアントにょり直接供給される。
一実施例において、トラステッドフィールドは、PASIDフィールド3803、予約フィールド3811及びU/S(ユーザ/スーパバイザ)フィールド3810(すなわち、0のオフセットで始まる4バイト)を含む。記述子が、ENQCMD命令を用いてサブミットされる場合、ソース記述子内のこれらのフィールドは無視されてよい。MSRに含まれる値(例えば、PASID MSR)は、記述子がデバイスに送信される前に、これらのフィールドに置かれてよい。
一実施例において、記述子がENQCMDS命令を用いてサブミットされる場合、ソース記述子内のこれらのフィールドは、ソフトウェアにより初期化される。PCIエクスプレスPASID機能がイネーブルにされていない場合、U/Sフィールド3810は1に設定され、PASIDフィールド3803は0に設定される。
記述子が、MOVDIR64B命令を用いてサブミットされる場合、記述子内のこれらのフィールドは無視されてよい。デバイスは、代わりに、WQコンフィグレジスタ3500のWQ U/S及びWQ PASIDフィールドを用いる。
これらのフィールドは、バッチ内のどの記述子に対しても無視され得る。バッチ記述子3515の対応するフィールドは、バッチ内の各記述子3518に対して用いられる。テーブルQは、これらのトラステッドフィールドのそれぞれについての説明及びビット位置を提供する。
以下のテーブルRは、記述子のオペレーションフィールド3801に従う一実施例において実行されるリストである。
以下のテーブルSは、記述子の一実施例で用いられるフラグを列挙する。
一実施例において、完了記録アドレス3804は、完了記録のアドレスを規定する。完了記録は、32バイトであってよく、完了記録アドレスは32バイト境界上にアラインされる。完了記録アドレス有効フラグが0である場合、このフィールドは予約されている。要求完了記録フラグが1である場合、完了記録は、オペレーションの完了時にこのアドレスに書き込まれる。要求完了記録が0である場合、完了記録は、ページフォールト又はエラーがある場合のみ、このアドレスに書き込まれる。
比較などの結果をもたらす任意のオペレーションについて、完了記録アドレス有効及び要求完了記録フラグは、両方とも1であるべきであり、完了記録アドレスは有効であるべきである。
仮想アドレスを用いる任意の処理について、完了記録アドレスは、要求完了記録フラグが設定されているか否かについて有効であるべきであり、その結果、完了記録は、ページフォールト又はエラーがある場合に書き込まれ得る。
最良の結果について、このフィールドは、記述子をサブミットしたソフトウェアにデバイスがエラーを報告することを可能するので、すべての記述子において有効であるべきである。このフラグが0であり、予期しないエラーが発生した場合、エラーは、SWERRORレジスタに報告され、要求をサブミットしたソフトウェアは、エラーが通知されなくてもよい。
完了記録アドレスフィールド3804は、バッチ記述子において完了キューイネーブルフラグが設定されている場合、バッチ内の記述子を無視し、バッチ記述子内の完了キューアドレスが代わりに用いられる。
一実施例において、メモリからデータを読み出すオペレーションについて、ソースアドレスフィールド3805は、ソースデータのアドレスを規定する。ソースアドレスに対するアライメント要求はない。メモリにデータを書き込むオペレーションについて、宛先アドレスフィールド3806は、宛先バッファのアドレスを規定する。宛先アドレスに対するアライメント要求はない。いくつかのオペレーションタイプについて、このフィールドは、第2のソースバッファのアドレスとして用いられる。
一実施例において、転送サイズフィールド3808は、オペレーションを実行するために、ソースアドレスから読み出されるバイト数を示す。このフィールドの最大値は、232‐1であってよいが、最大の可能な転送サイズは、より小さくてよく、かつ、一般的な機能レジスタの最大転送サイズフィールドから判断されなければならない。転送サイズは0であるべきではない。多くのオペレーションタイプに関して、転送サイズに対するアライメント要求はない。オペレーションの説明において例外が言及されている。
一実施例において、使用割込みメッセージストレージフラグが1である場合、完了割込み処理フィールド3807は、完了割込みを生成するために用いられる割込みメッセージストレージエントリを規定する。このフィールドの値は、GENCAP内の割込みメッセージストレージサイズフィールドの値より小さくするべきである。一実施例において、完了割込み処理フィールド3807は、使用割込みメッセージストレージフラグが0である、要求完了割込みフラグが0である、U/Sビットが0である、一般的な機能レジスタの割込みメッセージストレージサポートフィールドが0である、又は、記述子が、ゲストポータルを介してサブミットされている、という条件のいずれかの下で予約される。
図39に示されるように、完了記録3900の一実施例は、オペレーションが完了又はエラーに遭遇した場合にDSAが書き込むメモリ内の32バイト構造である。完了記録アドレスは、32バイトアラインであるべきである。
このセクションは、多くのオペレーションタイプに共通である完了記録のフィールドを説明する。各オペレーションタイプの説明は、フォーマットがこれとは異なる場合の完了記録図を含む。追加のオペレーションに固有のフィールドは、以下でさらに説明される。完了記録3900は、たとえ、必要とされるフィールドが全くなくても、常に32バイトであり得る。完了記録3900は、ページフォールトに起因して部分的に完了した場合にオペレーションを継続するのに十分な情報を含む。
完了記録は、(記述子3800の完了記録アドレス3804により識別される)メモリ内の32バイトアライン構造として実装され得る。完了記録3900は、オペレーションが完了したか否かを示す完了ステータスフィールド3904を含む。オペレーションの完了に成功した場合、完了記録は、もしあればオペレーションのタイプに応じたオペレーションの結果を含んでよい。オペレーションが完了に成功しなかった場合、完了記録は、障害又はエラー情報を含む。
一実施例において、ステータスフィールド3904は、記述子の完了ステータスを報告する。ソフトウェアは、このフィールドを0に初期化すべきであり、それにより、完了記録が書き込まれたときを検出できる。
上記のテーブルTは、様々なステータスコードを提供し、一実施例に関する説明に関連する。
以下のテーブルUは、障害アドレスが読み出されたか、書き込まれたかを示す第1のビット、及び、フォールトアクセスがユーザモードであったか、スーパバイザモードアクセスであったかを示す第2のビットを含む一実施例において利用可能な障害コード3903を示す。
一実施例において、この完了記録3900がバッチの一部としてサブミットされた記述子のためのものであった場合、インデックスフィールド3902は、この完了記録を生成した記述子のバッチ内のインデックスを含む。バッチ記述子について、このフィールドは、0xffであってよい。バッチの一部ではないその他の記述子について、このフィールドは、予約済であってよい。
一実施例において、オペレーションが、ページフォールトに起因して部分的に完了した場合、バイト完了フィールド3901は、障害が発生した前に処理されたソースバイトの数を含む。このカウントにより表されるソースバイトのすべては、完全に処理されていて、結果は、必要に応じてオペレーションタイプに従って宛先アドレスに書き込まれる。いくつかのオペレーションタイプについて、このフィールドは、障害以外のいくつかの理由に対する完了の前にオペレーションが停止した場合に用いられてもよい。オペレーションが完全に完了した場合、このフィールドは、0に設定されてよい。
この値から出力サイズが容易に判断可能でないオペレーションタイプについて、完了記録は、宛先アドレスに書き込まれるバイト数も含む。
オペレーションがページフォールトに起因して部分的に完了した場合、このフィールドは、障害を発生させたアドレスを含む。一般的な規則として、すべての記述子は、有効な完了記録アドレス3804を有するべきであり、完了記録アドレス有効フラグは1であるべきである。この規則に対するいくつかの例外が以下に説明される。
一実施例において、完了記録の第1のバイトはステータスバイトである。デバイスにより書き込まれるステータス値はすべてゼロ以外の値である。ソフトウェアは、いつデバイスが完了記録に書き込まれたかを示すことを可能にするために、記述子をサブミットする前に、完了記録のステータスフィールドを0に初期化すべきである。完了記録を初期化することはまた、それがマッピングされることを確実にし、そのため、デバイスは、アクセスする場合にページフォールトに遭遇することはない。
要求完了記録フラグは、たとえオペレーションの完了に成功したとしても、完了記録を書き込むべきであることをデバイスに示す。このフラグが設定されていない場合、デバイスは、もしエラーがあれば、完了記録のみを書き込む。
記述子完成は、以下の方法のいずれかを用いるソフトウェアにより検出され得る。
1.完了記録をポーリングして、ステータスフィールドがゼロ以外になるのを待つ。
2.完了記録アドレスに対する(本明細書で説明されるような)UMONITOR/UMWAIT命令を用いて、書き込まれるまで又はタイムアウトするまでブロックする。次に、ソフトウェアは、オペレーションが完了したか否かを判断するために、ステータスフィールドがゼロ以外か否かをチェックすべきである。
3.カーネルモード記述子について、オペレーションが完了した場合、割込みを要求する。
4.記述子がバッチ内にある場合、同じバッチに後続の記述子内のフェンスフラグを設定する。フェンスを有する記述子又は同じバッチ内の任意の後続の記述子の完了は、フェンスに先行するすべての記述子の完了を示す。
5.記述子がバッチ内にある場合、バッチを初期化したバッチ記述子の完了は、バッチ内のすべての記述子の完了を示す。
6.ドレイン記述子又はドレインコマンドを発行して、それが完了するのを待つ。
完了ステータスがページフォールトに起因して部分的な完了を示す場合、完了記録は、(もしあれば、)障害が引き起こされる前に、処理がどれくらい完了していたか、及び、障害が引き起こされた仮想アドレスを示す。ソフトウェアは、(プロセッサから障害アドレスをタッチすることにより、)障害を正常な状態に戻すことを選択し、新たな記述子内のワークの残りを再サブミット、又は、ソフトウェアにおけるワークの残りを完了し得る。記述子リスト及び完了記録アドレス上の障害は、異なって処理され、以下により詳細に説明される。
DSAの一実施例では、メッセージシグナリング割込みのみをサポートする。DSAは、2つのタイプの割込みメッセージストレージ、すわなち、(a)ホストドライバにより用いられる割込みメッセージを格納する、MSI−X機能を通じて列挙されたMSI−Xテーブル、及び、(b)ゲストドライバにより用いられる割込みメッセージを格納するデバイスに固有の割込みメッセージストレージ(IMS)テーブルを提供する。
一実施例において、割込みは、3つのタイプのイベント、すなわち、(1)カーネルモード記述子の完了、(2)ドレイン又はアボートコマンドの完了、及び、(3)ソフトウェア又はハードウェアエラーレジスタにおいてポストされたエラーに対して生成され得る。イベントのタイプごとに、別々の割込みイネーブルがある。エラー及びアボート/ドレインコマンドの完了に起因する割込みは、MSI−Xテーブル内のエントリ0を用いて生成される。割込み理由レジスタは、割込みの理由を判断するために、ソフトウェアにより読み出されてよい。
カーネルモード記述子の完了(例えば、U/Sフィールドが1である記述子)について、用いられる割込みメッセージは、どのように記述子がサブミットされたか、及び、記述子内の使用割込みメッセージストレージフラグに依存する。
特権ポータルを介してサブミットされたカーネルモード記述子に対する完了割込みメッセージは、一般にMSI−Xテーブル内のエントリであり、ポータルアドレスにより判断される。しかしながら、GENCAP内の割込みメッセージストレージサポートフィールドが1である場合、特権ポータルを介してサブミットされた記述子は、記述子内に使用割込みメッセージストレージフラグを設定することによりこの挙動をオーバーライドしてよい。この場合、記述子内の完了割込み処理フィールドは、割込みメッセージストレージへのインデックスとして用いられる。
ゲストポータルを介してサブミットされたカーネルモード記述子に対する完了割込みメッセージは、割込みメッセージストレージ内のエントリであり、ポータルアドレスにより判断される。
DSAにより生成された割込みは、カーネル又はVMMソフトウェアにより構成されるように、割込み再マッピング及びポスティングハードウェアを通じて処理される。
すでに述べたように、DSAは、一度に複数の記述子をサブミットすることをサポートする。バッチ記述子は、ホストメモリ内のワーク記述子のアレイのアドレス及び当該アレイの要素の数を含む。ワーク記述子のアレイは、「バッチ」と呼ばれる。バッチ記述子の使用は、DSAクライアントが、単一のENQCMD、ENQCMDS又はMOVDIR64B命令を用いて複数のワーク記述子をサブミットすることを可能にし、全体的なスループットを潜在的に向上させることができる。DSAは、バッチ内のワーク記述子の数に対する制限を実行する。一般的な機能レジスタにおける最大バッチサイズフィールドにおいて制限が示される。
バッチ記述子は、他のワーク記述子と同じ方法で、ワークキューにサブミットされる。バッチ記述子がデバイスにより処理される場合、デバイスは、メモリからワーク記述子のアレイを読み出して、次に、ワーク記述子のそれぞれを処理する。ワーク記述子は、必ずしも順番通りに処理されるわけではない。
バッチ記述子のPASID3803及びU/Sフラグは、バッチ内のすべての記述子に用いられる。バッチ内の記述子におけるPASID及びU/Sフィールド3810は無視される。バッチ内の各ワーク記述子は、ちょうど、直接サブミットされたワーク記述子と同様に、完了記録アドレス3804を特定できる。代替的に、バッチ記述子は、バッチからのすべてのワーク記述子の完了記録がデバイスにより書き込まれる「完了キュー」アドレスを特定できる。この場合、バッチ内の記述子における完了記録アドレスフィールド3804は無視される。完了キューは、記述子総数よりも1エントリ分大きくすべきであり、そのため、バッチ内のすべての記述子に対する完了記録とバッチ記述子とのための空間がある。完了記録は、記述子が完了した順序で生成され、それらが記述子アレイに現れる順序と同じでなくてよい。各完了記録は、その完了記録を生成したバッチ内の記述子のインデックスを含む。0xffのインデックスは、バッチ記述子自体に用いられる。0のインデックスは、バッチ記述子以外の直接サブミットされた記述子に用いられる。バッチ内のいくつかの記述子は、それらが完了記録を要求せず、それらが完了に成功した場合、完了記録を生成しなくてよい。この場合完了キューに書き込まれる完了記録の数は、バッチ内の記述子の数より少ない可能性がある。バッチ記述子の完了記録(要求された場合)は、バッチ内のすべての記述子に対する完了記録の後に完了キューに書き込まれる。
バッチ記述子は、完了キューを規定せず、バッチ記述子に対する完了記録(要求された場合)は、バッチ内のすべての記述子が完了した後に、自体の完了記録アドレスに書き込まれる。バッチ記述子に対する完了記録は、バッチ内の記述子のいずれもが成功に相当しないステータスで完了したか否かについてのインジケーションを含む。これは、バッチ内のすべての記述子が完了に成功した通常の場合において、ソフトウェアがバッチ記述子に対する完了記録のみを検査することを可能にする。
完了割込みは、必要に応じて、バッチ内の1又は複数のワーク記述子により要求されてもよい。バッチ記述子に対する完了記録(要求された場合)は、バッチ内のすべての記述子に対する完了記録及び完了割込みの後に書き込まれる。バッチ記述子に対する完了割込み(要求された場合)は、ちょうどその他の記述子と同様に、バッチ記述子に対する完了記録の後に生成される。
バッチ記述子はバッチに含まれなくてもよい。ネステッド又はチェーン記述子アレイはサポートされていない。
デフォルト設定で、DSAは、ワーク記述子を実行している間、いずれのオーダリングも保証していない。記述子は、スループットを最大化するようにデバイスが適切と考える任意の順序でディスパッチ及び完了できる。よって、オーダリングが要求された場合、ソフトウェアは、明示的にオーダリングしなければならない。例えば、ソフトウェアは、記述子をサブミットして、完了を確実にするために記述子からの完了記録又は割込みを待ち、それから、次の記述子をサブミットすることができる。
ソフトウェアは、バッチ記述子により規定されたバッチ内の記述子に対するオーダリングも特定できる。各ワーク記述子は、フェンスフラグ(Fence flag)を有する。設定された場合、フェンスは、同じバッチ内の前の記述子が完了するまで、記述子の処理が開始されないことを保証する。これは、フェンスを有する記述子が、同じバッチ内の前の記述子により生成されるデータを消費することを可能にする。
記述子は、オペレーションにより生成されたすべての書き込みがグローバルに観測可能となった後、要求された場合、宛先がリードバックした後、必要とされる場合、完了記録への書き込みがグローバルに観測可能となった後、及び、要求された場合、完了割込みの生成後に、完了する。
バッチの任意の記述子が成功に相当しないステータスで完了した場合、例えば、それがページフォールトに起因して部分的に完了した場合、1に等しいフェンスフラグを有する後続の記述子、及び、バッチ内の任意の後続の記述子が廃棄される。バッチをサブミットするために用いられたバッチ記述子に対する完了記録は、どれくらいの数の記述子が完了したかを示す。部分的に完了され、完了記録が生成された任意の記述子は、完了されたときにカウントされる。廃棄された記述子のみが、完了していないとみなされる。
フェンスはまた、完了記録及び割込みに対するオーダリングを確保する。例えば、設定されたフェンス及び要求完了割込みを有するNo−op記述子は、バッチ内のすべての先行する記述子が完了した(必要とされる場合、これらの完了記録が書き込まれた)後に生成された割込みを発生させる。完了記録書き込みは、常に、同じワーク記述子により生成されたデータ書き込みの背後でオーダリングされ、完了割込み(要求された場合)は、常に、同じワーク記述子に対する完了記録書き込みの背後でオーダリングされる。
ドレインは、クライアントがそれ自体のPASIDに属するすべての記述子が完了するのを待つことを可能にする記述子である。それは、PASID全体に対するフェンスオペレーションとして用いられることができる。ドレインオペレーションは、そのPASIDを有するすべての前の記述子が完了した場合に完了する。ドレイン記述子は、ソフトウェアにより用いられ、そのすべての記述子の完了に対する単一の完了記録又は割込みを要求できる。ドレインは、通常のワークキューにサブミットされる通常の記述子である。ドレイン記述子は、バッチに含まれてよい。(フェンスフラグは、バッチ内の前の記述子が完了するのを待つために、バッチ内で用いられてよい。)
ソフトウェアは、ドレイン記述子がサブミットされた後、かつ、それが完了する前に、デバイスにサブミットされる特定のPASIDを有する記述子がないことを確保しなければならい。追加の記述子がサブミットされた場合、ドレインオペレーションが追加の記述子が完了するのも待つか否かが指定されていない。これは、ドレインオペレーションに長い時間をかけることになり得る。たとえデバイスが、追加の記述子が完了するのを待たなかったとしても、追加の記述子のいくつかは、ドレインオペレーションが完了する前に完了し得る。このように、すべての前のオペレーションが完了するまで、開始する後続のオペレーションがないことをフェンスが確保するので、ドレインは、フェンスとは異なる。
一実施例において、アボート/ドレインコマンドは、アボート/ドレインレジスタに書き込むことにより、特権が与えられたソフトウェア(OSカーネル又はVMM)によりサブミットされる。これらのコマンドの1つを受信したときに、DSAは、特定の記述子の完了を待つ(以下で説明される)。コマンドが完了した場合、ソフトウェアは、デバイスにおいて未処理の特定のカテゴリに記述子がこれ以上ないことを確認できる。
一実施例では、ドレインオール、ドレインPASID及びドレインWQという3つのタイプのドレインコマンドがある。各コマンドは、完了へとこれらを処理するよりもむしろ、任意の未処理の記述子を破棄し得るデバイスを示すアボートフラグを有する。
ドレインオールコマンドは、ドレインオールコマンドの前にサブミットされていたすべての記述子の完了を待機する。ドレインオールコマンドの後にサブミットされた記述子は、ドレインオールが完了したときに進行中であり得る。前の記述子が完了するのをドレインオールコマンドが待っている間に、デバイスは新たな記述子に対するワークを開始してよい。
ドレインPASIDコマンドは、特定のPASIDと関連付けられたすべての記述子を待つ。ドレインPASIDコマンドが完了した場合、デバイス内のPASIDに対する記述子はこれ以上存在しない。ソフトウェアは、ドレインPASIDコマンドがサブミットされた後、かつ、それが完了する前に、デバイスにサブミットされる特定のPASIDを有する記述子がないことを確保し得る。そうでなければ、挙動が定義されていない。
ドレインWQコマンドは、特定のワークキューにサブミットされたすべての記述子を待機する。ソフトウェアは、ドレインWQコマンドがサブミットされた後、かつ、それが完了する前にWQにサブミットされる記述子がないことを確保し得る。
DSAを使用しているアプリケーション又はVMが一時停止された場合、それは、DSAにサブミットされた未処理の記述子を有している可能性がある。このワークは、完了されなければならず、そのため、クライアントは、後で再開され得るコヒーレント状態にある。ドレインPASID及びドレインオールコマンドは、任意の未処理の記述子を待機するために、OS又はVMMにより用いられる。ドレインPASIDコマンドは、単一のPASIDを使用していたアプリケーション又はVMに用いられる。ドレインオールコマンドは、複数のPASIDを使用するVMに用いられる。
DSAを使用しているアプリケーションが抜け出た、又は、オペレーティングシステム(OS)により終了された場合、OSは、アドレス空間、割り当てられたメモリ及びPASIDを解放又は再利用し得る前に、未処理の記述子がないことを確保する必要がある。任意の未処理の記述子を処分するために、OSは、終了されるクライアントのPASIDを有するドレインPASIDコマンドを使用し、アボートフラグは1に設定される。このコマンドを受信したときに、DSAは、さらなる処理を行うことなく特定のPASIDに属するすべての記述子を破棄する。
DSAの一実施例では、複数のWQからワークをディスパッチするためにサービス品質を特定するメカニズムを提供する。DSAは、ソフトウェアがWQ空間の合計を複数のWQに分割することを可能にする。各WQは、ワークをディスパッチするために、異なる優先度が割り当てられ得る。一実施例において、DSAスケジューラ/アービタ3513は、より高い優先度のWQが、より低い優先度のWQより多くサービス提供されるように、WQからワークをディスパッチする。しかしながら、DSAは、より高い優先度のWQが、より低い優先度のWQを枯渇させないことを確保する。すでに述べたように、様々な優先順位付けのスキームは、実装要件に基づいて採用されてよい。
一実施例において、WQ構成レジスタテーブルは、WQを構成するために用いられる。ソフトウェアは、所望のQoSレベルの数に一致するように、アクティブなWQの数を構成できる。ソフトウェアは、WQサイズ及びいくつかの追加のパラメータをWQ構成レジスタテーブルにプログラミングすることにより各WQを構成する。これは、WQ空間全体をWQの所望の数に効果的に分割する。未使用のWQは、0のサイズを有する。
エラーは、1)特定のPASIDの記述子を処理するときに生じた関連エラー、2)事実上広範囲であり、PASIDに特定のものではない非関連エラー、の2つのカテゴリに広く分けられる。DSAは、1つのPASIDからのエラーが、他のPASIDを停止させたり影響を与えたりすることをできる限り回避しようと試みる。PASID固有のエラーは、エラーが完了記録自体(例えば、完了記録アドレス上のページフォールト)にある場合を除き、それぞれの記述子の完了記録に報告される。
記述子サブミッション内又は記述子の完了記録上のエラーは、ソフトウェアエラーレジスタ(SWERROR)を通じてホストドライバに報告されてよい。ハードウェアエラーは、ハードウェアエラーレジスタ(HWERROR)を通じて報告されてよい。
DSAの一実施例では、デバイスイネーブルレジスタ内のイネーブルビットが1に設定されたときに、以下のチェックを実行する。
・バスマスタイネーブルが1である。
・PASID、ATS及びPRS機能の組み合わせが有効である(テーブル6−3、セクション6.1.3を参照)。
・すべてのWQCFGレジスタのWQサイズフィールドの合計が、総WQサイズより大きくない。
・各GRPCFGレジスタについて、WQ及びエンジンフィールドが、両方とも0である、又は、両方ともゼロ以外であるのいずれか一方である。
・WQCFGレジスタ内のサイズフィールドがゼロ以外である各WQが1つのグループにある。
・WQCFGレジスタ内のサイズフィールドがゼロである各WQが、いずれのグループにもない。
・各エンジンが、1つのグループにしかない。
これらのチェックのいずれかが不合格であった場合、デバイスはイネーブルにされず、エラーコードがデバイスイネーブルレジスタのエラーコードフィールドに記録される。これらのチェックは、任意の順序で実行されてよい。したがって、あるタイプのエラーのインジケーションは、他のエラーもあることを示唆するものではない。同じ構成エラーは、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを結果としてもたらす可能性がある。不合格になったチェックが一つもない場合、デバイスはイネーブルにされ、イネーブルフィールドが1に設定される。
デバイスは、WQCFGレジスタ内のWQイネーブルビットが1に設定されたときに、以下のチェックを実行する。
・デバイスがイネーブルである(すなわち、デバイスイネーブルレジスタ内のイネーブルフィールドが1である)。
・WQサイズフィールドがゼロ以外である。
・WQ閾値が、WQサイズフィールドより大きくない。
・WQモードフィールドが、サポートされているモードを選択している。つまり、WQCAP内の共有モードサポートフィールドが0である場合、WQモードは1であり、又はWQCAP内の専用モードサポートフィールドが0である場合、WQモードは0である。共有モードサポート及び専用モードサポートフィールドの両方が1である場合、WQモードの値のいずれか一方は許可されている。
・GENCAP内の障害のブロックサポートビットが0である場合、WQ障害のブロックイネーブルフィールドは0である。
これらのチェックのいずれかが不合格であった場合、WQはイネーブルにされず、エラーコードがWQコンフィグレジスタ3500のWQエラーコードフィールドに記録される。これらのチェックは、任意の順序で実行されてよい。したがって、あるタイプのエラーのインジケーションが、他のエラーもあることを示唆するものではない。同じ構成エラーは、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを結果としてもたらす可能性がある。不合格になったチェックが一つもない場合、デバイスはイネーブルにされ、WQイネーブルフィールドが1に設定される。
一実施例において、DSAは、記述子が受信されたときに、以下のチェックを実行する。
・記述子をサブミットするために用いられるレジスタアドレスにより識別されたWQが、アクティブなWQである(WQCFGレジスタ内のサイズフィールドがゼロ以外である)。このチェックが不合格であった場合、エラーがソフトウェアエラーレジスタ(SWERROR)に記録される。
・記述子が共有のWQにサブミットされていた場合、
・それは、ENQCMD又はENQCMDSと共にサブミットされていた。このチェックが不合格であった場合、エラーがSWERRORに記録される。
・特権が与えられていない又はゲストポータルを介して記述子がサブミットされていた場合、現在のキュー占有率は、WQ閾値より大きくない。このチェックが不合格であった場合、リトライ応答が返される。
・記述子が特権ポータルを介してサブミットされていた場合、現在のキュー占有率がWQサイズより小さい。このチェックが不合格であった場合、リトライ応答が返される。
・記述子が専用のWQにサブミットされていた場合、
・それは、MOVDIR64Bを用いてサブミットされていた。
・キュー占有率がWQサイズより小さい。
これらのチェックのいずれかが不合格であった場合、エラーがSWERRORに記録される。
一実施例において、デバイスは、各記述子が処理されるときに各記述子に対して以下のチェックを実行する。
・オペレーションコードフィールド内の値がサポートされているオペレーションに対応する。これは、サブミットされていたコンテキストにおいてオペレーションが有効であることをチェックすることを含む。例えば、バッチ内のバッチ記述子は、無効なオペレーションコードとして処理されるであろう。
・設定される予約フラグがない。これは、GENCAPレジスタ内の対応する機能ビットが0であるフラグを含む。
・設定される非サポートフラグがない。これは、特定のオペレーションとの使用のために予約されるフラグを含む。例えば、フェンスビットは、バッチの一部としてよりもむしろ、直接的にエンキューされる記述子において予約される。構成内でディセーブルされるフラグ、例えば、障害のブロックフラグも含み、WQCFGレジスタ内の障害のブロックイネーブルフィールドが0である場合に予約される。
・要求されたフラグが設定される。例えば、要求完了記録フラグは、比較オペレーション用の記述子において1でなければならない。
・予約フィールドが0である。これは、特定の動作を意味することが定義されていない任意のフィールドを含む。いくつかの実施例では、すべての予約フィールドをチェックしなくてよいが、ソフトウェアは、最大の互換性のためにすべての未使用のフィールドをクリアする処理を行うべきである。バッチ記述子において、記述子総数フィールドは、GENCAPレジスタ内の最大バッチサイズフィールドより大きくない。
・(記述子タイプに適用可能なものとして)転送サイズ、ソースサイズ、最大差分記録サイズ、差分記録サイズ及び最大宛先サイズが、GENCAPレジスタ内の最大転送サイズフィールドより大きくない。
・デュアルキャストを用いたメモリコピー記述子において、2つの宛先アドレスのビット11:0は同じである。
・使用割込みメッセージストレージフラグが設定されている場合、完了割込み処理は、割込みメッセージストレージサイズより少ない。
一実施例において、完了記録アドレス3804は変換されることができず、記述子3800は破棄され、エラーがソフトウェアエラーレジスタに記録される。そうでなければ、これらのチェックのいずれかが不合格であった場合、完了記録は、不合格のチェックのタイプを示すステータスフィールドと共に書き込まれ、バイト完了は0に設定される。要求された場合、完了割込みが生成される。
これらのチェックは、任意の順序で実行されてよい。したがって、完了記録におけるあるタイプのエラーのインジケーションは、他のエラーもあることを示唆するものではない。同じ無効記述子は、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを報告してよい。
記述子内の予約フィールド3811は、常に予約されているフィールド、いくつかの条件下で(例えば、機能、構成フィールド、どのように記述子がサブミットされたか、又は、記述子自体における他のフィールドの値に基づいて)予約されているフィールド、及び、オペレーションタイプに基づいて予約されているフィールドの3つのカテゴリに分類されてよい。以下のテーブルでは、フィールドが予約される条件を列挙する。
すでに述べたように、DSAは、物理又は仮想アドレスのいずれか一方の使用をサポートする。プロセッサコア上で実行する処理と共有される仮想アドレスの使用は、共有仮想メモリ(SVM)と呼ばれる。SVMをサポートするために、デバイスは、アドレス変換を実行する場合、PASIDを提供し、それは、アドレス用に存在する変換がない場合に発生するページフォールトを処理する。しかしながら、デバイス自体は、仮想アドレスと物理アドレスとを区別しない。この区別は、IOMMU1710のプログラミングにより制御される。
一実施例において、DSAは、ATSを利用するために、PCDIを用いてPCIe論理2808と通信するPCIe論理2820を示す図28に示されるようなアドレス変換サービス(ATS)及びページ要求サービス(PRS)PCIエクスプレス機能をサポートする。ATSは、アドレス変換中のデバイスの挙動を表現する。記述子が記述子処理ユニットに入る場合、デバイス2801は、記述子内のアドレスに対する変換を要求してよい。デバイスTLB2822においてヒットがある場合、デバイスは、対応するホスト物理アドレス(HPA)を用いる。失敗又は許可障害がある場合、DSA2801の一実施例では、変換のためにIOMMU2810に(すなわち、マルチプロトコルリンク2800にわたって)アドレス変換要求を送信する。次に、IOMMU2810は、それぞれのページテーブルを散策することにより変換を探し、変換されたアドレス及び有効な許可を含むアドレス変換応答を返してよい。次に、デバイス2801は、デバイスTLB2822に変換を格納し、オペレーション用に対応するHPAを用いる。IOMMU2810が、ページテーブル内の変換を探すことが不可能である場合、それは、利用可能な変換がないことを示すアドレス変換応答を返してよい。IOMMU2810の応答が、変換がないことを示す、又は、オペレーションにより要求された許可を含まない有効な許可を示す場合、それは、ページフォールトとみなされる。
DSAデバイス2801は、1)完了記録アドレス3804、2)バッチ記述子内の記述子リストアドレス、又は、3)ソースバッファ又は宛先バッファアドレスのうちの1つでのページフォールトに遭遇する可能性がある。DSAデバイス2801は、ページフォールトが解決されるまでブロックすることができる、又は、記述子を早期に完了して、部分的な完了をクライアントに返すことができる。一実施例において、DSAデバイス2801は、完了記録アドレス3804及び記述子リストアドレス上のページフォールトを常にブロックする。
DSAがページフォールトをブロックする場合、それは、OSページフォールトハンドラによりサービス提供するために、当該ページフォールトをページ要求サービス(PRS)要求としてIOMMU2810に報告する。IOMMU2810は、割込みを通じてOSに通知してもよい。OSは、アドレスを有効にして、チェックが成功すると、ページテーブルにマッピングを作成し、IOMMU2810を通じてPRS応答を返す。
一実施例において、各記述子3800は、ページフォールトがソース又は宛先バッファアドレス上で発生した場合、DSA2801が部分的な完了を戻すべきであるか、ブロックするべきであるかを示す障害のブロックフラグを有する。障害のブロックフラグが1であり、障害に遭遇した場合、フォールトに遭遇した記述子は、PRS応答が受信されるまでブロックされる。障害を有する記述子の背後の他のオペレーションもブロックされ得る。
障害のブロックが0であり、ページフォールトがソース又は宛先バッファアドレス上で発生した場合、デバイスは、オペレーションを停止して、部分的な完了ステータスを障害アドレス及び進捗情報と共に完了記録へ書き込む。クライアントソフトウェアが部分的な完了を示す完了記録を受信した場合、それは、(例えば、ページをタッチすることにより)プロセッサ上の障害を正常な状態に戻し、新たなワーク記述子を残りのワークと共にサブミットするオプションを有する。
代替的に、ソフトウェアは、プロセッサ上で残りのワークを完了できる。一般的な機能レジスタ(GENCAP)内の障害のブロックサポートフィールドは、この機能に対するデバイスのサポートを示してよく、ワークキュー構成レジスタ内の障害のブロックイネーブルフィールドは、アプリケーションが機能を使用することが許可されるか否かをVMM又はカーネルドライバが制御することを可能にする。
デバイスページフォールトは、比較的高くつく可能性がある。事実、デバイスページフォールトのために働くコストは、プロセッサページフォールトのために働くコストより高いかも知れない。たとえデバイスが障害のブロックの代わりに部分的なワークの完了を障害時に実行したとしても、ページフォールトのために働き、ワークを再サブミットするために、ソフトウェアの介入を必要とするので、さらにオーバヘッドが発生する。よって、最高のパフォーマンスのためには、ピニング及びアンピニングのオーバヘッドを発生させることなく、ソフトウェアがデバイスページフォールトを最小化することが好ましい。
バッチ記述子リスト及びソースデータバッファは、典型的には、これらをデバイスにサブミットする直前に、ソフトウェアにより生成される。よって、これらのアドレスは、時間的な局所性に起因して障害を発生させる可能性が低い。しかしながら、完了記述子及び宛先データバッファは、デバイスにサブミットする前に、それらがソフトウェアによりタッチされていない場合、障害を発生させる可能性がよい高い。そのような障害は、サブミッション前にこれらのページを明示的に「書き込みタッチ(write touching)」するソフトウェアにより最小限に抑えられ得る。
デバイスTLB無効要求中に、無効にされているアドレスが記述子処理ユニットにおいて用いられている場合、デバイスは、無効要求を完了する前にエンジンがアドレスを用いて行われるのを待つ。
追加の記述子タイプ
いくつかの実施例では、以下の追加の記述子タイプのうちの1又は複数を利用してよい。
No−op
図40は、例示的な非op記述子4000及びno−op完了記録4001を示す。No−opオペレーション4005は、DMAオペレーションを実行しない。それは、完了記録及び/又は完了割込みを要求してよい。それがバッチ内にある場合、バッチ内のすべての前の記述子の完了の後に、No−op記述子の完了が発生することを確保するフェンスフラグを規定してよい。
バッチ
図41は、例示的なバッチ記述子4100及びno−op完了記録4101を示す。バッチオペレーション4108は一度に複数の記述子をキューイングする。記述子リストアドレス4102は、処理対象のワーク記述子の連続的なアレイについてのアドレスである。一実施例において、アレイ内の各記述子は64バイトである。記述子リストアドレス4102は、64バイトアラインである。記述子総数4103は、アレイ内の記述子の数である。アレイ内の記述子のセットは、「バッチ」と呼ばれる。バッチ内で可能とされる記述子の最大数は、GENCAP内の最大バッチサイズフィールドに与えられる。
バッチ記述子内のPASID4104及びU/Sフラグ4105は、バッチ内のすべての記述子に用いられる。バッチ内の記述子におけるPASID4104及びU/Sフラグフィールド4105は無視される。バッチ記述子4100内の完了キューイネーブルフラグが設定された場合、完了記録アドレス有効フラグは1でなければならず、完了キューアドレスフィールド4106は、バッチ内のすべての記述子に用いられる完了キューのアドレスを含む。この場合、バッチ内の記述子における完了記録アドレスフィールド4106は無視される。一般的な機能レジスタ内の完了キューサポートフィールドが0である場合、完了キューイネーブルフラグが予約されている。
バッチ記述子内の完了キューイネーブルフラグが0である場合、バッチ内の各記述子に対する完了記録は、各記述子内の完了記録アドレス4106に書き込まれる。この場合、バッチ記述子内の要求完了記録フラグが1である場合、完了キューアドレスフィールドは、もっぱらバッチ記述子用の完了記録アドレス4106として用いられる。
バッチ完了記録4101のステータスフィールド4110は、バッチにおける記述子のすべてが完了した場合、成功を示し、そうでなければ、それは、1又は複数の記述子が成功に相当しないステータスで完了したことを示す。完了記録の記述子完了フィールド4111は、それらが成功したか否かに関わらず、処理されていたバッチ内の記述子の総数を含む。記述子完了4111は、バッチ内にフェンスがある場合、又は、バッチを読み出している間にページフォールトが発生した場合、記述子総数4103より少なくてよい。
ドレイン
図42は、例示的なドレイン記述子4200及びドレイン完了記録4201を示す。ドレインオペレーション4208は、ドレイン記述子4200がサブミットされたワークキュー内の、PASID4202と関連付けられたすべての未処理の記述子の完了を待つ。この記述子は、デバイスを使用している処理により、通常のシャットダウン中に用いられ得る。PASID4202と関連付けられたすべての記述子を待つために、ソフトウェアは、PASID4202が用いられていた各ワークキューに別々のドレインオペレーションをサブミットすべきである。ソフトウェアは、ドレイン記述子4201がサブミットされた後、かつ、それが完了する前に、ワークキューにサブミットされる特定のPASID4202を有する記述子がないことを確保すべきである。
ドレイン記述子4201は、バッチに含まれていなくてよく、それは、非サポートオペレーションタイプとして処理される。ドレインは、要求完了記録又は要求完了割込みを規定すべきである。完了通知は、他の記述子が完了した後に行われる。
メモリ移動
図43は、例示的なメモリ移動記述子4300及びメモリ移動完了記録4301を示す。メモリ移動オペレーション4308は、メモリをソースアドレス4302から宛先アドレス4303にコピーする。コピーされるバイト数は、転送サイズ4304により与えられる。メモリアドレス又は転送サイズに対するアライメント要求はない。ソース及び宛先領域が重複する場合、メモリコピーは、ソースバッファ全体が一時的な空間にコピーされ、次に、宛先バッファにコピーされたかのように行われる。これは、宛先バッファの開始が、ソースバッファの終了と重複する場合に、コピーの方向を反転することにより実施され得る。
オペレーションが、ページフォールトに起因して部分的に完了した場合、完了記録の方向フィールド4310は、ソース及び宛先バッファの先頭から開始するコピーが実行された場合に0であり、方向フィールドは、コピーの方向が反転された場合に1である。
部分的な完了後にオペレーションを再開するために、方向が0である場合、連続的な記述子内のソース及び宛先アドレスフィールド4302−4303は、バイト完了により増加されるべきであり、転送サイズは、バイト完了4311により低減されるべきである。方向が1である場合、転送サイズ4304は、バイト完了4311により低減されるべきであるが、ソース及び宛先アドレスフィールド4302−4303は、元の記述子と同じであるべきである。後続の部分的な完了が発生した場合、方向フィールド4310は、第1の部分的な完了に対するものと同じでなくてよいことに留意する。
満杯(フィル(Fill))
図44は、例示的なフィル記述子4400を示す。メモリフィルオペレーション4408は、宛先アドレス4406におけるメモリをパターンフィールド4405内の値で満杯にする。パターンサイズは、8バイトであってよい。より小さいパターンを用いるために、ソフトウェアは、記述子内のパターンを複製しなければならない。書き込まれるバイト数は、転送サイズ4407により与えられる。転送サイズは、パターンサイズの倍数である必要はない。宛先アドレス又は転送サイズに対するアライメント要求はない。オペレーションがページフォールトに起因して部分的に完了した場合、完了記録のバイト完了フィールドは、障害が発生する前に宛先に書き込まれたバイト数を含む。
比較
図45は、例示的な比較記述子4500及び比較完了記録4501を示す。比較オペレーション4508は、ソース1のアドレス4504におけるメモリと、ソース2のアドレス4505におけるメモリとを比較する。比較されるバイト数は、転送サイズ4506により与えられる。メモリアドレス又は転送サイズ4506に対するアライメント要求はない。完了記録アドレス有効及び要求完了記録フラグは1でなければならず、完了記録アドレスは有効でなければならない。比較の結果は、完了記録4501の結果フィールド4510に書き込まれる。0の値は、2つのメモリ領域がマッチすることを示し、1の値は、それらがマッチしないことを示す。結果4510が1である場合、完了記録のバイト完了4511フィールドは、第1の差のバイトオフセットを示す。オペレーションが、ページフォールトに起因して部分的に完了した場合、結果は0である。差が検出された場合、その差は、ページフォールトの代わりに報告されるであろう。
オペレーションが成功し、チェック結果フラグが1である場合、完了記録のステータスフィールド4512は、以下のテーブルに示されるように、結果及び予測結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、比較の結果に基づいてバッチの実行を継続又は停止することを可能にする。
比較中間
図46は、例示的な比較中間記述子4600を示す。比較中間処理4608は、ソースアドレス4601におけるメモリをパターンフィールド4602における値と比較する。パターンサイズは8バイトである。より小さいパターンを用いるために、ソフトウェアは、記述子内のパターンを複製しなければならない。比較されるバイト数は、転送サイズ4603により与えられる。転送サイズは、パターンサイズの倍数である必要はない。完了記録アドレス有効及び要求完了記録フラグは、1でなければならない。完了記録アドレス4604は有効でなければならない。比較の結果は、完了記録の結果フィールドに書き込まれる。0の値は、メモリ領域がパターンにマッチすることを示し、1の値は、それがマッチしないことを示す。結果が1である場合、完了記録のバイト完了フィールドは、第1の差の位置を示す。正確なバイト位置ではないかも知れないが、第1の差より大きくないことが保証される。オペレーションが、ページフォールトに起因して部分的に完了した場合、結果は0である。差が検出された場合、その差は、ページフォールトの代わりに報告されるであろう。一実施例において、比較中間に関する完了記録フォーマットと、チェック結果及び予測結果の挙動とは比較と同一である。
作成差分記録
図47は、例示的な作成差分記録記述子4700及び作成差分記録完了記録4701を示す。作成差分記録オペレーション4708は、ソース1のアドレス4705におけるメモリとソース2のアドレス4702におけるメモリとを比較して、ソース2に一致するようにソース1を更新するのに必要とされる情報を含む差分記録を生成する。比較されるバイト数は、転送サイズ4703により与えられる。以下で説明されるように、転送サイズは、差分記録に格納され得る最大オフセットの分制限される。メモリアドレス又は転送サイズに対するアライメント要求がない。完了記録アドレス有効及び要求完了記録フラグは、1でなければならず、完了記録アドレス4704は、有効でなければならない。
差分記録の最大サイズは、最大差分記録サイズ4709により与えられる。最大差分記録サイズ4709は、差分サイズ(10バイト)の倍数とするべきであり、GENCAP内の最大転送サイズより大きくないものでなければならない。差分記録の実際のサイズは、ソース1とソース2との間で検出された差の数に依存し、それは、完了記録の差分記録サイズフィールド4710に書き込まれる。差分記録に必要とされる空間が、記述子に規定された最大差分記録サイズ4709を超える場合、オペレーションは、部分的な差分記録で完了する。
比較の結果は、完了記録4701の結果フィールド4711に書き込まれる。2つの領域が正確に一致する場合、結果は0であり、差分記録サイズは0であり、バイト完了は0である。2つの領域が一致しない場合、差分の完全なセットが差分記録に書き込まれ、結果は1であり、差分記録サイズは、得られたすべての差の合計サイズを含み、バイト完了は0である。2つの領域が一致せず、すべての差分を記録するのに必要な空間が最大差分記録サイズを超える場合、結果は2であり、差分記録サイズ4710は、差分記録に書き込まれた差分のセットのサイズ(典型的には、記述子に規定される差分記録サイズに等しい、又は、ほぼ等しい)を含み、バイト完了4712は、差分記録内の空間が超過する前に比較されたバイト数を含む。
オペレーションが、ページフォールトに起因して部分的に完了した場合、前の段落で説明したように、結果4711は0又は1のいずれか一方であり、バイト完了4712は、ページフォールトが発生する前に比較されたバイト数を含み、差分記録サイズは、ページフォールトが発生する前に差分記録で用いられた空間を含む。
差分記録のフォーマットが図48に示される。差分記録は、差分(delta)のアレイを含む。各差分は、2バイトのオフセット4801及びソース1における対応する8バイトとは異なるソース2からの8バイトブロックのデータ4802を含む。差分記録の合計サイズは10の倍数である。オフセット4801は、8バイトの倍数を表す16ビットのフィールドであるので、表現され得る最大オフセットは、0x7FFF8であり、そのため、最大転送サイズは、0x80000バイト(512KB)である。
オペレーションが成功し、チェック結果フラグが1である場合、完了記録のステータスフィールドは、以下のテーブルに示されるように、結果及び予測結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、差分記録作成の結果に基づいてバッチの実行を継続又は停止することを可能にする。予測結果のビット7:2は無視される。
適合差分記録
図49は、例示的な適合差分記録記述子4901を示す。適合差分記録オペレーション4902は、宛先アドレス4903におけるメモリのコンテンツに差分記録を適用する。差分記録アドレス4904は、1に等しい結果で完了した作成差分記録オペレーション4902により作成された差分記録のアドレスである。差分記録サイズ4905は、作成差分記録オペレーション4902の完了記録において報告されるような差分記録のサイズである。宛先アドレス4903は、差分記録が作成された場合、ソース1のアドレスにおけるメモリと同じコンテンツを含むバッファのアドレスである。転送サイズ4906は、差分記録が作成された場合に用いられる転送サイズと同じである。適合差分記録オペレーション4902が完了した後に、宛先アドレス4903におけるメモリは、差分記録が作成された場合に、ソース2のアドレスにおけるメモリにあったコンテンツと一致する。メモリアドレス又は転送サイズに対するアライメント要求はない。
適合差分記録オペレーション4902中にページフォールトが発生した場合、完了記録のバイト完了フィールドは、宛先に適用されることに成功した差分記録のバイト数を含む。ソフトウェアが、オペレーションを再開するために別の記述子をサブミットすることを選択した場合、連続的な記述子は、元と同じ宛先アドレス4903を含む。差分記録アドレス4904は、バイト完了により増加されるはずであり(したがって、第1の未適用の差分を指し示す)、差分記録サイズ4905は、バイト完了により低減されるはずである。
図50は、作成差分記録及び適合差分記録オペレーションの利用についての一実施例を示す。まず、作成差分記録オペレーション5001が実行される。作成差分記録オペレーション5001は、2つのソースバッファ−ソース1及び2−を読み出して、その完了記録5003に実際の差分記録サイズ5004を記録する差分記録5010を書き込む。適合差分記録オペレーション5005は、作成差分記録オペレーション5001により書き込まれた差分記録のコンテンツをそのサイズ及びソース1データのコピーと共に取り出し、元のソース2バッファの複製となるように宛先バッファ5015を更新する。作成差分記録オペレーションは、最大差分記録サイズ5002を含む。
デュアルキャストを用いたメモリコピー
図51は、例示的なデュアルキャストを用いたメモリコピー記述子5100、及び、デュアルキャストを用いたメモリコピー完了記録5102を示す。デュアルキャストオペレーション5104を用いたメモリコピーは、ソースアドレス5105から、宛先1のアドレス5106及び宛先2のアドレス5107の両方にメモリをコピーする。コピーされるバイト数は、転送サイズ5108により与えられる。ソースアドレス又は転送サイズに対するアライメント要求はない。2つの宛先アドレス5106−5107のビット11:0は同じであるべきである。
ソース領域が宛先領域のいずれか一方と重複する場合、メモリコピーは、ソースバッファ全体が一時的な空間にコピーされ、次に、宛先バッファにコピーされたかのように行われる。これは、宛先バッファの先頭がソースバッファの終了と重複する場合にコピーの方向を反転することにより実施され得る。ソース領域が宛先領域の両方と重複する場合、又は、2つの宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、コピーオペレーションは、宛先領域の両方に同じバイト数を書き込んだ後に停止し、完了記録の方向フィールド5110は、ソース及び宛先バッファの先頭から開始するコピーが実行される場合に0であり、方向フィールドは、コピーの方向が反転された場合に1である。
部分的な完了後にオペレーションを再開するために、方向5110が0である場合、連続的な記述子内のソース5105及び両方の宛先アドレスフィールド5106−5107は、バイト完了5111により増加されるべきであり、転送サイズ5108は、バイト完了5111により低減される。方向が1である場合、転送サイズ5108は、バイト完了5111により低減されるべきであるが、ソース5105及び宛先5106−5107アドレスフィールドは、元の記述子と同じであるべきである。後続の部分的な完了が発生した場合、方向フィールド5110は、第1の部分的な完了に対するものと同じでなくてもよいことに留意する。
巡回冗長検査(CRC)生成
図52は、例示的なCRC生成記述子5200及びCRC生成5201を示す。CRC生成処理5204は、ソースアドレスにおけるメモリ上のCRCを計算する。CRC計算に用いられるバイト数は、転送サイズ5205により与えられる。メモリアドレス又は転送サイズ5205に対するアライメント要求はない。完了記録アドレス有効及び要求完了記録フラグは1でなければならず、完了記録アドレス5206は有効でなければならない。計算されたCRC値は、完了記録に書き込こまれる。
オペレーションが、ページフォールトに起因して部分的に完了した場合、部分的なCRC結果は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子のCRCシードフィールドへこの部分的な結果をコピーしなければならない。そうでなければ、CRCシードフィールドは0であるべきである。
CRC生成を用いたコピー
図53は、CRC生成記述子5300を用いた例示的なコピーを示す。CRC生成処理5305を用いたコピーは、ソースアドレス5302から宛先アドレス5303にメモリをコピーし、コピーされたデータに対するCRCを計算する。コピーされたバイト数は、転送サイズ5304により与えられる。メモリアドレス又は転送サイズに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。完了記録アドレス有効及び要求完了記録フラグは1でなければならず、完了記録アドレスは有効でなければならない。計算されたCRC値は、完了記録に書き込まれる。
オペレーションが、ページフォールトに起因して部分的に完了した場合、部分的なCRC結果は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子のCRCシードフィールドへこの部分的な結果をコピーしなければならない。そうでなければ、CRCシードフィールドは0とすべきである。一実施例において、CRC生成を用いたコピー用の完了記録フォーマットは、CRC生成用のフォーマットと同じである。
データ整合性フィールド(DIF)挿入
図54は、例示的なDIF挿入記述子5400及びDIF挿入完了記録5401を示す。DIF挿入オペレーション5405は、ソースアドレス5402から宛先アドレス5403にメモリをコピーし、ソースデータ上のデータ整合性フィールド(DIF)を計算し、DIFを出力データに挿入する。コピーされたソースバイトの数は、転送サイズ5406により与えられる。DIF計算は、例えば、512、520、4096又は4104バイトのソースデータの各ブロックで実行される。転送サイズは、ソースブロックサイズの倍数とすべきである。宛先に書き込まれたバイト数は、ソースブロックごとに、転送サイズに8バイトを加えた値である。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、参照タグ及びアプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子へこれらのフィールドをコピーし得る。
DIFストリップ
図55は、例示的なDIFストリップ記述子5500及びDIFストリップ完了記録5501を示す。DIFストリップオペレーション5505は、ソースアドレス5502から宛先アドレス5503にメモリをコピーし、ソースデータ上のデータ整合性フィールド(DIF)を計算し、計算されたDIFを、データに含まれるDIFと比較する。読み出されるソースバイトの数は、転送サイズ5506により与えられる。DIF計算は、512、520、4096又は4104バイトであり得るソースデータの各ブロックで実行される。転送サイズは、ソースブロックごとに、ソースブロックサイズの倍数に8バイトを加えた値とすべきである。宛先に書き込まれるバイト数は、ソースブロックごとに、転送サイズから8バイトを差し引いた値である。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、参照タグ及びアプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子へこれらのフィールドをコピーしてよい。
DIF更新
図56は、例示的なDIF更新記述子5600及びDIF更新完了記録5601を示す。DIF更新オペレーション5605を用いたメモリ移動は、ソースアドレス5602から宛先アドレス5603にメモリをコピーし、ソースデータ上のデータ整合性フィールド(DIF)を計算し、計算されたDIFを、データに含まれるDIFと比較する。記述子内の宛先DIFフィールドを用いてソースデータ上のDIFを同時に計算し、計算されたDIFを出力データに挿入する。読み出されるソースバイトの数は、転送サイズ5606により与えられる。DIF計算は、512、520、4096又は4104バイトであり得るソースデータの各ブロックで実行される。転送サイズ5606は、ソースブロックごとに、ソースブロックサイズの倍数に8バイトを加えた値とすべきである。宛先に書き込まれるバイト数は、転送サイズ5606と同じである。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、ソース及び宛先参照タグ、及び、アプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子にこれらのフィールドをコピーしてよい。
以下のテーブルAAは、一実施例において用いられるDIFフラグを示す。テーブルBBは、一実施例において用いられるソースDIFフラグを示し、テーブルCCは、一実施例における宛先DIFフラグを示す。
一実施例において、DIF結果フィールドは、DIFオペレーションのステータスを報告する。このフィールドは、DIFストリップ及び更新オペレーションのためだけに、かつ、完了記録のステータスフィールドが成功又は誤った述部を伴う成功である場合のみ定義されてよい。以下のテーブルDDは、例示的なDIF結果フィールドコードを示す。
F検出条件は、テーブルEEに以下に示されるうちの1つが真である場合に検出される。
オペレーションが成功し、チェック結果フラグが1である場合、完了記録のステータスフィールドは、以下のテーブルFFに示されるように、DIF結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、オペレーションの結果に基づいてバッチの実行を継続又は停止することを可能にする。
キャッシュフラッシュ
図57は、例示的なキャッシュフラッシュ記述子5700を示す。キャッシュフラッシュオペレーション5705は、宛先アドレスでプロセッサキャッシュをフラッシュする。フラッシュされるバイト数は、転送サイズ5702により与えられる。転送サイズは、キャッシュラインサイズの倍数である必要はない。宛先アドレス又は転送サイズに対するアライメント要求はない。宛先領域により部分的にカバーされる任意のキャッシュラインがフラッシュされる。
宛先キャッシュフィルタグが0である場合、影響を受けるキャッシュラインは、キャッシュ階層の各レベルから無効にされ得る。キャッシュラインは、キャッシュ階層の任意のレベルで修正されたデータを含み、データは、メモリに書き戻される。これは、いくつかのプロセッサに実装されたCLFLUSH命令の挙動と同様である。
宛先キャッシュフィルタグが1である場合、修正されたキャッシュラインは、メインメモリに書き込まれるが、キャッシュから追い出されない。これは、いくつかのプロセッサにおけるCLWB命令の挙動と同様である。
期限アクセラレータ(term accelerator)は、ホストプロセッサ上で実行中のソフトウェアにより用いられ得る緩く結合したエージェントを参照して、任意の種類の計算又はI/Oタスクをオフロード又は実行するために本明細書でときどき用いられる。アクセラレータ及び使用モデルのタイプに応じて、これらは、メモリ又はストレージ、計算、通信又はこれらの任意の組み合わせに対するデータ移動を実行するタスクであり得る。
「緩く結合」とは、ホストソフトウェアにより、これらのアクセラレータがどのようにさらされ、アクセスされるかを指す。具体的には、これらは、プロセッサISA拡張としてさらされることはなく、代わりに、プラットフォーム上のPCIエクスプレス可算エンドポイントデバイスとしてさらされる。緩い結合は、これらのエージェントが、ホストソフトウェアからのワーク要求を受け入れ、ホストプロセッサに対して非同期的に動作することを可能にする。
「アクセラレータ」は、プログラマブルエージェント(例えば、GPU/GPGPU)、固定機能エージェント(例えば、圧縮又は暗号化エンジン)、又は、フィールドプログラマブルゲートアレイ(FPGA)などの再構成可能エージェントであり得る。これらのいくつかは、計算オフロードに用いられ、一方、その他(例えば、RDMA又はホストファブリックインタフェース)は、パケット処理、通信、ストレージ又はメッセージパッシングオペレーションに用いられてよい。
アクセラレータデバイスは、オンダイ(すなわち、プロセッサと同じダイ)、オンパッケージ、チップセット、マザーボードを含む、異なるレベルで物理的に集積されてよい、又は、別個のPCIe接続型デバイスであり得る。集積されたアクセラレータについて、たとえ、PCIエクスプレスエンドポイントデバイスとして列挙されるとしても、これらのアクセラレータのいくつかは、(オンダイコヒーレントファブリック又は外部コヒーレントインタフェースに)コヒーレントに取り付けられる一方、その他は、内部非コヒーレントインタフェース又は外部のPCIエクスプレスインタフェースに取り付けられ得る。
概念的なレベルでの、「アクセラレータ」及び高性能I/Oデバイスコントローラは同様である。これらを区別するものは、統合/共有仮想メモリ、ページング可能なメモリ上で動作する能力、ユーザモードワークサブミッション、タスクスケジューリング/プリエンプション及び低レイテンシ同期に対するサポートなどの機能である。その結果、アクセラレータは、新たな改良型の高性能I/Oデバイスのカテゴリとみなされ得る。
オフロードオペレーションモデル
アクセラレータオフロードオペレーションモデルは、3つの利用カテゴリに広く分類され得る。
1.ストリーミング:ストリーミングオフロードモデルでは、小さい単位のワークが、高いレートでアクセラレータにストリーミングされる。この利用の典型的な例は、高いレートで、様々なタイプのパケット処理を実行するネットワークデータプレーンである。
2.低レイテンシ:いくつかのオフロード利用に関して、オフロードオペレーション(アクセラレータへのタスクのディスパッチ及びそれを実行するアクセラレータの両方)のレイテンシは重要な意味を持つ。この利用の例は、ホストファブリックを介した遠隔取得、プット及びアトミックオペレーションを含む低レイテンシメッセージパッシング構成モデルである。
3.スケーラブル:スケーラブルなオフロードは、デバイス上でサポートされる複数のワークキュー又は複数のドアベルなどのアクセラレータデバイスにより課される制約なしで、多数(限りない数)のクライアントアプリケーション(仮想マシン内及び仮想マシンを介して)に(例えば、リング3などの階層保護ドメイン内の最も高いリングから)計算アクセラレータのサービスが直接的にアクセス可能な利用を指す。本明細書で説明されるアクセラレータデバイス及びプロセッサ相互接続のいくつかのは、このカテゴリに含まれる。GPU、GPGPU、FPGA又は圧縮アクセラレータ、又は、メッセージパッシングなど、ワークのタイムシェアリング/スケジューリングをサポートする計算オフロードデバイスに適用されるそのようなスケーラビリティは、ロック無しオペレーションに関する大きなスケーラビリティ要件を有するエンタープライズデータベースなどを利用する。
オフロードモデルにわたるワークディスパッチ
上記のオフロードオペレーションモデルのそれぞれは、以下に説明されるような独自のワークディスパッチの課題を負う。
1.ストリーミングオフロードの利用のためのワークディスパッチ
ストリーミングの利用に関して、典型的なワークディスパッチモデルは、メモリに存在するワークキューを用いることである。具体的には、デバイスは、メモリ内のワークキューの位置及びサイズを構成される。ハードウェアは、新たなワーク要素をワークキューに加えた場合にソフトウェアにより更新されるドアベル(テールポインタ)レジスタを実装する。ハードウェアは、ワークキュー要素上の生産者−消費者フロー制御を強化するために、ソフトウェアに関する現在のヘッドポインタを報告する。ストリーミングの利用に関して、典型的なモデルは、(多くの場合、ソフトウェアによるUC MMIO読み出しのオーバヘッドを回避するために、ハードウェアによりホストメモリ内で維持される)ソフトウェアにキャッシュされたヘッドポインタ及びテールポインタを調べることによりワークキュー内に空きがあるか否かをチェックし、新たなワーク要素をメモリに存在するワークキューに加え、デバイスへのドアベルレジスタ書き込みを用いてテールポインタを更新するソフトウェアのためのものである。
ドアベル書き込みは、典型的には、4バイト又は8バイトのキャッシュ不能な(UC)、MMIOへの、書き込みである。いくつかのプロセッサにおいて、UC書き込みは、(生産者−消費者利用のために必要とされる)UC書き込みを発行する前に、より古い格納がグローバルに監視されることを確保するが、UC書き込みがプラットフォームによりポストされるまでに発行されてしまうことからプロセッサパイプライン内のすべての若い方の格納をブロックする直列化されたオペレーションである。Xeonサーバプロセッサ上でのUC書き込み動作に対する典型的なレイテンシは、80〜100ナノ秒のオーダにあり、すべての若い方の格納オペレーションがコアによりブロックされている時間の間、ストリーミングオフロード性能を制限する。
UCドアベル書き込みに続いて若い方の格納の直列化に取り組む1つのアプローチは、ドアベル書き込みのためのライトコンバイニング(WC)格納オペレーション(WCの弱いオーダリングに起因する)を用いることであるが、ドアベル書き込みのためにWC格納を用いることは、いくつかの課題を負う。ドアベル書き込みサイズ(典型的には、DWORD又はQWORD)は、キャッシュラインサイズより小さい。これらの部分的な書き込みは、潜在的なライトコンバイニング機会のためのそのライトコンバイニングバッファ(WCB)において、プロセッサが部分的な書き込みを維持することに起因して、追加のレイテンシを発生させ、プロセッサから発行されるドアベル書き込みに関するレイテンシを発生させる。ソフトウェアは、これらに、明示的な格納フェンスを通じて発行されることができ、UCドアベルと同様に、若い方の格納に同じ直列化を発生させる。
WCにマッピングされたMMIOに関する別の問題点は、(MOVNTDQAを用いた)誤った予測及び推測的な読み出しが、(読み出側に影響を与え得るレジスタを有する)WCにマッピングされたMMIOにさらされることである。UCマッピングMMIOレジスタの残りよりも別々のページにおけるWCマッピングドアベルレジスタをデバイスがホストする必要があるので、これに対処することはデバイスにとって面倒である。これは、仮想化利用での課題も負うことになり、VMMソフトウェアは、ゲストメモリタイプを無視して、EPTページテーブルを用いてゲストにさらされる任意のデバイスMMIOに対するUCマッピングを強制することはもはやできない。
本明細書で説明されるMOVDIRI命令は、これらのストリーミングオフロードの利用でのドアベル書き込みのためにUC又はWC格納を用いる上記の制限に対処する。
2.低レイテンシオフロードの利用のためのワークディスパッチ
いくつかのタイプのアクセラレータデバイスは、最小のレイテンシで要求されたオペレーションを完了するために高度に最適化されている。(スループットを最適化された)ストリーミングアクセラレータとは異なって、これらのアクセラレータは、一般に、メモリホスト型ワークキューからワーク要素(及び、いくつかの場合では、同一のデータバッファ)をフェッチするためにDMAの読み出しレイテンシを回避するために、(デバイスMMIOを通じてさらされる)デバイスホスト型ワークキューを実装する。代わりに、ホストソフトウェアは、ワーク記述子(及び、いくつかの場合では、データも)を直接的に書き込むことによりワークを、デバイスMMIO通じてさらされたデバイスホスト型ワークキューにサブミットする。そのようなデバイスの例では、ホストファブリックコントローラ、リモートDMA(RDMA)デバイス、及び、不揮発性メモリ(NVM)エクスプレスなどの新たなストレージコントローラを含む。デバイスホスト型ワークキューの利用は、既存ISAに関して課題を発生させることはほとんどない。
UC書き込みの直列化オーバヘッドを回避するために、デバイスホスト型ワークキューのMMIOアドレスは、典型的には、WCとしてマッピングされる。これは、ストリーミングアクセラレータのためにWCにマッピングされたドアベルと同じ課題をさらす。
さらに、デバイスホスト型ワークキューへのWC格納を用いるには、デバイスがいくつかのプロセッサの書き込みアトミック性挙動を守る必要がある。例えば、最大で8バイトサイズの書き込み動作のアトミック性がいくつかのプロセッサは、キャッシュライン境界内(及び、ロックオペレーションのため)に書き込むことを保証するだけで、保証されたいずれの書き込み完了のアトミック性を定義するものではない。書き込み動作のアトミック性は、プロセッサ格納オペレーションが他のエージェントにより監視される粒度であり、プロセッサ命令セットアーキテクチャ及びコヒーレンシプロトコルの特性である。書き込み完了のアトミック性は、キャッシュ不可能な格納処理が受信機(メモリの場合では、メモリコントローラ、又は、MMIOの場合ではデバイス)により監視される粒度である。書き込み完了のアトミック性は、書き込み動作のアトミック性より強く、プロセッサ命令セットアーキテクチャだけでなくプラットフォームの機能でもある。書き込み完了のアトミック性なしで、Nバイトのキャッシュ不可能な格納処理を実行するプロセッサ命令は、デバイスホスト型ワークキューによる複数の(トーン)書き込みトランザクションとして受信され得る。現在では、デバイスハードウェアは、デバイスホスト型ワークキューに書き込まれたワーク記述子の各ワード又はデータをトラッキングすることにより、そのようなトーン書き込みを守る必要がある。
本明細書で説明されるMOVDIR64B命令は、保証された64バイト書き込み完了のアトミック性で、64バイト書き込みをサポートすることにより、上記の制限に対処する。MOVDIR64Bは、永続性メモリ(メモリコントローラに取り付けられたNVM)への書き込み、及び、非透過型ブリッジ(NTB)を通じたシステムを介したデータの複製など、その他の利用にとっても有用である。
3.スケーラブルなオフロードの利用のためのワークディスパッチ
アプリケーションからI/Oデバイスにワークをサブミットするための従来のアプローチは、I/Oコントローラデバイスに対してカーネルデバイスドライバを通じた要求を転送するカーネルI/Oスタックにシステムコールを行うことに関する。このアプローチは、スケーラブルである(任意の数のアプリケーションがデバイスのサービスを共有できる)一方、多くの場合、高性能デバイス及びアクセラレータに関する性能のボトルネックとなる直列化カーネルI/Oスタックのレイテンシ及びオーバヘッドを発生させる。
低オーバヘッドのワークディスパッチをサポートするために、いくつかの高性能デバイスは、デバイスに対する直接的なワークディスパッチを可能にし、ワーク完了をチェックするダイレクトリング3アクセスをサポートする。このモデルでは、デバイスいくつかのリソース(ドアベル、ワークキュー、完了キューなど)がアプリケーションの仮想アドレス空間に割り当てられ、マッピングされる。一旦マッピングされると、リング3ソフトウェア(ユーザモードのドライバ又はライブラリ)は、アクセラレータにワークを直接ディスパッチできる。共有仮想メモリ(SVM)機能をサポートするデバイスに関して、ドアベル及びワークキューがマッピングされるアプリケーション処理の処理アドレス空間識別子(PASID)を識別するために、ドアベル及びワークキューは、カーネルモードドライバによりセットアップされる。特定のワークキューを通じてディスパッチされたワークアイテムを処理する場合、デバイスは、I/Oメモリ管理ユニット(IOMMU)を通じた物理アドレス変換に対して仮想的なそのワークキューに構成されるそれぞれのPASIDを用いる。
ダイレクトリング3ワークサブミッションに関する課題の1つは、スケーラビリティ問題である。アクセラレータデバイスに直接的にワークをサブミットできるアプリケーションクライアントの数は、アクセラレータデバイスによりサポートされるキュー/ドアベル(又は、デバイスホスト型ワークキュー)の数に依存する。これは、ドアベル又はデバイスホスト型ワークキューが、アプリケーションクライアントに静的に割り当てられ/マッピングされ、アクセラレータデバイス設計によりサポートされるこれらのリソースの数が固定されるからである。いくつかのアクセラレータデバイスは、(アプリケーションに対する要求についてドアベルを動的に取り外して再度取り付けることにより)それらが有するドアベルのリソースを過度に収容することで、このスケーラビリティの課題に「対処する」しようとしているが、多くの場合、拡大することが煩雑で難しい。これらが異なる仮想マシンに割り当てられる様々な仮想機能(VF)にわたって区分化される必要があるので、I/O仮想化(例えば、単一のルートI/O仮想化(SR−IOV))をサポートするデバイスに関して、制限されたドアベル/ワークキューのリソースは、さらに制約される。
スケーリング問題は、ロック無しオペレーション用のデータベースなどの企業アプリケーションにより用いられる(64K〜1MのキューペアをサポートするRDMAデバイスのいくつかを有する)高性能なメッセージパッシングアクセラレータにとって、及び、多数のクライアントからサブミットされたタスクにわたるアクセラレータのリソースを共有することをサポートする計算アクセラレータにとって、最も重要な意味を持つ。
本明細書で説明されるENQCMD/S命令は、アクセラレータ上のワークキューのリソースをサブスクライブし共有する限りない数のクライアントをイネーブルにするために、上記のスケーリングの制限に対処する。
一実施例では、直接格納及びエンキュー格納を含むプロセッサコアによる新たなタイプの格納オペレーションを含む。
一実施例において、直接格納は、本明細書で説明されるMOVDIRI及びMOVDIR64B命令により生成される。
キャッシュ可能性:UC及びWC格納と同様に、直接格納は、キャッシュ可能ではない。キャッシュされるアドレスに直接格納が発行された場合、直接格納前に、ラインは、キャッシュからライトバック(修正される場合)及び無効にされる。
メモリオーダリング:WC格納と同様に、直接格納は、弱くオーダリングされる。具体的には、それらは、より古いWB/WC/NT格納、CLFLUSHOPT及びCLWBに対して、異なるアドレスへのオーダリングは行われない。異なるアドレスへのより若いWB/WC/NT格納、CLFLUSHOPT又はCLWBは、より古い直接格納をパスできる。同じアドレスに対する直接格納は、同じアドレスに対する(直接格納を含む)より古い格納を用いて常にオーダリングされる。直接格納は、格納フェンシング(例えば、SFENCE、MFENCE、UC/WP/WT格納、ロック、IN/OUT命令など)を強化する任意のオペレーションによりフェンスされる。
ライトコンバイニング:直接格納は、通常のWC格納とは異なるライトコンバイニングの挙動を有する。具体的には、直接格納は、ライトコンバインバッファからの即時エビクションの対象となり、ひいては、同じアドレスへの若い方の格納(直接格納を含む)と組み合わせられない。ライトコンバイニングバッファにおいて保持されるより古いWC/NT格納は、同じアドレスへの若い方の直接格納と組み合わせられてよく、そのような組み合わせを回避する必要がある利用は、同じアドレスへの直接格納を実行する前にフェンスWC/NT格納を明示的に格納しなければならない。
アトミック性:直接格納は、直接格納を発行する命令の書き込みサイズに関する書き込み完了のアトミック性をサポートする。MOVDIRIの場合では、宛先が4バイトアライン(又は、8バイトアライン)の場合、書き込み完了のアトミック性は、4バイト(又は、8バイト)である。MOVDIR64Bに関して、宛先は、64バイトアラインに強制され、書き込み完了のアトミック性は、64バイトである。書き込み完了のアトミック性は、メモリコントローラ又はルートコンプレックスにより処理されるような複数の書き込みトランザクションに直接格納が分裂(torn)されていないことを保証する。直接格納をサポートするプロセッサ上のルートコンプレックス実装は、単一の非トーン・ポステッド(non−torn posted)書き込みトランザクションとして、外部のPCIエクスプレスファブリック(及び、PCIエクスプレスのオーダリングに従うSoC内の内部I/Oファブリック)上で直接格納が転送されることを保証する。任意のエージェント(プロセッサ又は非プロセッサエージェント)からメモリ位置への読み出し処理は、直接格納オペレーションを発行する命令により書き込まれたデータのすべてか、そのいずれでもないかのいずれか一方を参照する。
宛先メモリタイプの無視:直接格納は、(UC/WPタイプを含む)宛先アドレスメモリタイプを無視し、常に弱いオーダリングに従う。これは、マッピングされたUCのメモリタイプ毎のUCオーダリングに従う通常のMOVオペレーションを用いて、厳密な直列化要件を有し得る他のレジスタにアクセスし続けている間、ソフトウェアが、直接格納命令(MOVDIRI又はMOVDIR64B)を用いて、デバイスMMIOをUCとしてマッピングし、特定のレジスタ(例えば、ドアベル又はデバイスホスト型ワークキューレジスタ)にアクセスすることを可能にする。これは、直接格納命令をゲストソフトウェア内から動作させることも可能にする一方、(デバイスに固有の知識を有していない)仮想マシンモニタ(VMM)ソフトウェアは、プロセッサ拡張ページテーブル(EPT)内のUCとしてゲスト露出MMIOをマッピングし、ゲストメモリタイプを無視する。
直接格納をサポートするSoCは、以下のように、直接格納に関する書き込み完了のアトミック性を確保する必要がある。
メインメモリへの直接格納:メインメモリへの直接格納に関して、コヒーレントファブリック及びシステムエージェントは、直接格納内のすべてのデータバイトが、単一の(非トーン(non−torn))書き込みトランザクションとして、メモリへの要求に対してホームエージェント又は他のグローバルな可観測性(GO)ポイントに発行されることを確保する。永続性メモリをサポートするプラットフォームに関して、ホームエージェント、メモリコントローラ、メモリ側キャッシュ、インラインメモリ暗号化エンジン、永続性メモリを取り付けるメモリバス(例えば、DDR−T)、及び、永続性メモリコントローラの各自が、直接格納に対して同じ又はより高い粒度の書き込み完了のアトミック性をサポートしなければならない。したがって、ソフトウェアは、メモリ(揮発性又は永続性)へのMOVDIR64Bを用いた64バイトの直接格納を実行でき、すべての64バイト書き込みがすべてのエージェントによりアトミックに処理されることが保証され得る。永続性メモリへの通常の書き込みと同様に、ソフトウェアが永続性に明示的にコミットする必要がある場合、ソフトウェアは、フェンス/コミット/フェンスシーケンスで直接格納を行う。
メモリマッピングされたI/Oへの直接格納:メモリマッピングされたI/O(MMIO)への直接格納に関して、コヒーレントファブリック及びシステムエージェントは、直接格納におけるすべてのデータバイトが、単一の(非トーン(non−torn))書き込みトランザクションとして、ルートコンプレックス(MMIOへの要求に対してグローバルな可観測性ポイント)に発行されることを確保しなければならない。ルートコンプレックス実装は、PCIエクスプレスルートコンプレックス統合エンドポイント(RCIEP)及びルートポート(RP)を取り付ける内部I/Oファブリック上で単一の(非トーン(non−torn))ポステッド書き込みトランザクションとして、各直接格納が処理及び転送されることを確保しなければならない。PCIエクスプレスルートポート及びスイッチポートは、単一のポステッド書き込みトランザクションとして各直接格納を転送しなければならない。書き込み完了のアトミック性は、セカンダリブリッジ(例えば、レガシPCI、PCI−Xブリッジ)又はセカンダリバス(例えば、USB、LPCなど)上、又は、その背後でデバイスをターゲットとする直接格納のために規定又は保証されていない。
いくつかのSoCの実装は、WC書き込み要求に対する書き込み完了のアトミック性を既に保証していることに留意する。具体的には、部分的なラインWC書き込み(WCiL)及び全ラインWC書き込み(WCiLF)は、システムエージェント、メモリコントローラ、ルートコンプレックス及びI/Oファブリックにより、書き込み完了のアトミック性で既に処理されている。そのような実施例に関して、プロセッサが直接書き込みをWC書き込みと区別する必要はなく、直接格納とWC格納との挙動の違いは、プロセッサコアの内部にある。したがって、直接書き込みのための内部又は外部ファブリック仕様に対して提案される変更はない。
PCIエクスプレスエンドポイント又はRCIEPにより受信された直接書き込みの処理は、デバイス実装に固有のものである。デバイスのプログラミングインタフェースに応じて、デバイス及びそのドライバは、直接格納命令(例えば、MOVDIR64B)を用いて常に書き込まれるそのレジスタのいくつか(例えば、ドアベルレジスタ又はデバイスホスト型ワークキューレジスタ)を必要とし、デバイス内でアトミックにこれらを処理してよい。デバイス上の他のレジスタへの書き込みは、アトミック性をなんら考慮又は期待することなく、デバイスにより処理され得る。RCIEPに関して、書き込みのアトミック性要件を有するレジスタがサイドバンド又はプライベートワイヤインタフェースを通じたアクセスのために実装されている場合、そのような実施例は、実装に固有の手段を通じて書き込みのアトミック性の特性を確保しなければならない。
一実施例におけるエンキュー格納は、本明細書で説明されるENQCMD及びENQCMDS命令により生成される。エンキュー格納の指定されたターゲットは、アクセラレータデバイス上の共有のワークキュー(SWQ)である。一実施例において、エンキュー格納は、以下の特性を有する。
ノンポステッド:エンキュー格納は、ターゲットアドレスへの64バイトの非ポスト書き込みトランザクションを生成し、成功又はリトライステータスを示す完了応答を受信する。完了応答で返される成功/リトライステータスは、ENQCMD/S命令により(例えば、ゼロフラグにおいて)ソフトウェアに返されてよい。
キャッシュ可能性:一実施例において、エンキュー格納は、キャッシュ可能ではない。エンキュー格納をサポートするプラットフォームは、エンキュー・ノン・ポステッドライトが、これらの格納を受け入れるために、明示的に可能とされるアドレス(MMIO)範囲に転送されることのみに強制する。
メモリオーダリング:エンキュー格納は、ノンポステッド書き込み完了ステータスを有するアーキテクチャの状態(例えば、ゼロフラグ)を更新してよい。したがって、多くても1つのエンキュー格納は、所与の論理プロセッサから未処理となる可能性がある。その意味では、論理プロセッサからのエンキュー格納は、同じ論理プロセッサから発行される別のエンキュー格納を渡すことができない。エンキュー格納は、より古いWB/WC/NT格納、CLFLUSHOPT又はCLWBに対して、異なるアドレスへのオーダリングは行わない。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納の後、かつ、エンキュー格納前に明示的な格納フェンシングを用いてよい。エンキュー格納は、常に、より古い格納で同じアドレスにオーダリングされる。
アライメント:ENQCMD/S命令は、エンキュー格納宛先アドレスが64バイトアラインであることを強制する。
アトミック性:ENQCMD/S命令により生成されるエンキュー格納は、64バイト書き込み完了のアトミック性をサポートする。書き込み完了のアトミック性は、ルートコンプレックスにより処理されるような複数のトランザクションにエンキュー格納が分裂(torn)されていなことを保証する。エンキュー格納をサポートするプロセッサ上のルートコンプレックス実装は、単一の(非トーン(non−torn))64バイトの非ポスト書き込みトランザクションとして、各エンキュー格納がエンドポイントデバイスに転送されることを保証する。
宛先メモリタイプの無視:直接格納と同様に、エンキュー格納は、宛先アドレスメモリタイプ(UC/WPタイプを含む)を無視し、上記で説明されるようなオーダリングに常に従う。これは、通常のMOVの命令を用いて、又は、直接格納(MOVDIRI又はMOVDIR64B)命令を通じて、他のレジスタにアクセスし続けている間、ソフトウェアが、ENQCMD/S命令を用いて、デバイスMMIOをUCとしてマッピングし、共有のワークキュー(SWQ)レジスタにアクセスし続けることを可能にする。これは、エンキュー格納命令をゲストソフトウェア内から動作させることも可能にする一方、(デバイスに固有の知識を有していない)VMMソフトウェアは、プロセッサ拡張ページテーブル(EPT)内のUCとしてゲスト露出MMIOをマッピングし、ゲストメモリタイプを無視する。
エンキュー格納に対するプラットフォームの検討
いくつかの実施例について、プラットフォーム統合デバイスの特定のセットは、共有のワークキュー(SWQ)機能をサポートする。これらのデバイスは、内部I/Oファブリックを通じてルートコンプレックスに取り付けられてよい。これらのデバイスは、PCIエクスプレスルートコンプレックス統合エンドポイント(RCIEP)、又は、仮想ルートポート(VRP)の背後のPCIエクスプレスエンドポイントデバイスのうちのいずれか一方としてホストソフトウェアにさらされ得る。
SWQを有する統合デバイスをサポートするプラットフォームは、そのようなデバイスのみに対する内部I/Oファブリック上でのエンキュー・ノン・ポステッドライト要求の転送を制限すべきである。これは、新たなトランザクションタイプ(エンキュー・ノン・ポステッドライト)が、エンキューが認識していないエンドポイントデバイスによる不正な形式のトランザクション層パケット(TLP)として処理されないことを確保するためのものである。
(メインメモリアドレス範囲及びすべての他のメモリマップアドレス範囲を含む)すべての他のアドレスへのエンキュー格納は、プラットフォームにより終了し、通常の(エラーでない)応答が、リトライ完了ステータスと共に発行元のプロセッサに返される。特権のないソフトウェア(VMX非ルートモードにおけるリング3ソフトウェア、又は、リング0ソフトウェア)が、ENQCMD/S命令を実行することによりエンキュー・ノンポステッド・書き込みトランザクションを生成できるので、そのようなエンキュー格納の終端上で生成されるプラットフォームのエラーはない。
ルートコンプレックス実装は、SWQをサポートする統合デバイスに対する内部I/Oファブリック上での単一の(非トーン(non−torn))ノンポステッド書き込みトランザクションとしてエンキュー格納が処理及び転送されることを確保すべきである。
プラットフォーム性能の検討
このセクションは、システムエージェント及びシステムエージェントによりエンキュー格納の処理におけるいくつかの性能の検討を説明する。
エンキュー格納のためのシステムエージェントトラッカー(TOR)エントリ割り当てに対して緩和されたオーダリング。
メモリの整合性を維持するために、システムエージェント実装は、典型的には、コヒーレントメモリ及びMMIOに対するキャッシュラインアドレス(TORエントリを割り当てる場合)への要求に対して厳密なオーダリングを強制する。これは、コヒーレントメモリアクセスに対して総合的なオーダリングをサポートするために必要とされる一方、エンキュー格納に対するこの厳密なオーダリングは、性能の問題を負う。これは、エンキュー格納が、デバイス上の共有のワークキュー(SWQ)をターゲットとしており、それによって、同じ宛先SWQアドレスを有する複数の論理プロセッサからエンキュー格納要求を発行させることが一般的だからである。また、システムエージェントにポストされた通常の格納とは異なり、エンキュー格納は、ノンポステッドであり、読み出しと同様のレイテンシを発生させる。共有のワークキューに対して未処理のエンキュー格納1つだけ許可するという条件を無効にするためには、システムエージェント実装は、同じアドレスへのエンキュー格納要求に対する厳密なオーダリングを緩和することが必要とされ、代わりに、同じアドレスに対する複数のインフライト(in−flight)エンキュー格納のためのTOR割り当てを許可する。論理プロセッサは、同時に多くても1つのエンキュー格納だけを発行し得るので、システムエージェント/プラットフォームは、オーダリングを心配することなく独立に各エンキュー格納を処理できる。
I/Oブリッジエージェントにおける複数の未処理のエンキュー・ノン・ポステッドライトのサポート。
I/Oブリッジ実装は、典型的には、少数への(多くの場合、単一の要求への)ダウンストリームパスにおいてサポートされるノンポステッド(読み出し)要求の数を制限する。これは、(通常UC読み出しである)MMIOへのプロセッサからの読み出しは、ほとんどの利用にとって重大な性能ではなく、返されるデータの読み出しに必要なバッファのために大きなキューデプスをサポートしているからであり、ハードウェア費用を増大させる。エンキュー格納が、アクセラレータデバイスに対するワークディスパッチに通常用いられることが予期されるので、エンキュー・ノン・ポステッドライトに対するこの制限されたキューイングを適用してしまうと、性能に弊害をもたらす可能性がある。I/Oブリッジ実装は、改善されたエンキュー・ノン・ポステッドライト帯域幅のために、(論理プロセッサの数のいくつかの実際の割合、論理プロセッサは、一度に1つの未処理のエンキュー格納要求しか有することができないので)増加したキューデプスをサポートすることが推奨される。読み出し要求とは異なり、エンキュー格納は、エンキュー・ノン・ポステッドライト完了が単に完了ステータス(成功対リトライ)を返すだけでデータを返さないので、データバッファのハードウェア費用を発生させない。
エンキュー・ノン・ポステッドライトに対する仮想チャネルサポート
(例えば、PCIエクスプレストランザクションオーダリングにより特定される)生産者−消費者オーダリング要求を有するI/Oバス上の典型的なメモリ読み出し及び書き込み要求とは異なり、エンキュー・ノン・ポステッドライトは、I/Oバス上でのオーダリング要求を行わない。これは、エンキュー・ノン・ポステッドライトを発行し、それぞれの完了を返すために、非VC0仮想チャネルの使用を可能にする。非VC0チャネルを用いすることの利益は、エンキュー・ノン・ポステッドライト完了が、デバイスからホストにVC0上のアップストリームポステッド書き込みの背後でオーダリングされることを回避することにより、より良好なレイテンシ(コアを遅延させるより少ないサイクル)を有することができる。実装では、統合デバイスの利用を慎重に考慮して、エンキュー・ノンポステッド完了レイテンシを最小化することが推奨される。
エンキュー・ノン・ポステッドライトの中間停止
高レイテンシな状況(例えば、内部リンクをウェイクアップさせる、又は、ロックフロー上での電源管理)で特定のフロー制御を処理するために、中間エージェント(システムエージェント、I/Oブリッジなど)は、正規のエンキュー格納要求をドロップして、発行したコアに、完了をリトライ応答と共に返すことを可能にする。エンキュー格納を発行するソフトウェアは、リトライ応答が、中間エージェント又はターゲットからのものである場合、又は、ソフトウェアにおいて、通常のリトライする(潜在的にいくつかのバックオフを伴う)場合、直接的な可視性を有していない。
そのような中間停止を実行する実装では、そのような挙動は、SWQを共有するソフトウェアクライアントにわたる任意のサービス妨害攻撃をさらすことができないことを確認するように、非常に注意しなければならない。
エンドポイントデバイス上での共有のワークキューのサポート
図34は、共有のワークキュー(SWQ)の概念を示し、複数の非協同ソフトウェアエージェント(アプリケーション3410−3412)が、本明細書で説明されるENQCMD/S命令を利用して、共有のワークキュー3401を通じてワークをサブミットすることを可能にする。
以下の検討は、共有のワークキュー(SWQ)を実装するエンドポイントデバイスに適用可能である。
SWQ及びその列挙:デバイス物理ファンクション(PF)は、1又は複数のSWQをサポートしてよい。各SWQは、デバイスMMIOアドレス範囲内の64バイトアライン、及び、サイズレジスタ(ここでは、SWQ_REGと称される)を通じてエンキュー・ノン・ポステッドライトがアクセス可能である。デバイス上のそのような各SWQ_REGは、一意的なシステムページサイズ(4KB)領域に配置されることが推奨される。デバイス用のデバイスドライバは、SWQ機能、サポートされるSWQの数、及び、対応するSWQ_REGアドレスを、適切なソフトウェアインタフェースを通じてソフトウェアに報告/列挙する役割を担う。ドライバは、(これは、機能の正確性にとって必須ではないが)ソフトウェアのチューニング又は情報の用途のためにサポートされるSWQのデプスを選択的に報告してもよい。複数の物理ファンクションをサポートするデバイスについては、物理ファンクションごとに独立してSWQをサポートすることが推奨される。
単一のルートI/O仮想化(SR−IOV)デバイス上でのSWQサポート:SR−IOVをサポートするデバイスは、それぞれのVFベースアドレスレジスタ(BAR)におけるSWQ_REGを通じてさらされる仮想機能(VF)ごとに独立してSWQをサポートしてよい。この設計のポイントは、VFにわたるワークサブミッションに関する最大の性能分離を考慮している点にあり、少数から中程度の数のVFに適切し得る。多数のVFをサポートするデバイス(VF毎の独立したSWQは実用的ではない)について、単一のSWQは、複数のVFにわたって共有されてよい。たとえこの場合であっても、各VFは、SWQを共有するVFにわたって共通のSWQにより補助されることを除いて、そのVF BARに自体のプライベートなSWQ_REGを有する。そのようなデバイス設計について、SWQを共有するVFは、ハードウェア設計により静的に決定されてよく、又は、SWQインスタンスに対する所与のVFのSWQ_REG間のマッピングは、物理ファンクション及びそのドライバを通じて動的にセットアップ/トーンダウンされてよい。VFにわたってSWQを共有するデバイス設計は、このセクションにおいて後で説明されるように、サービス妨害攻撃に対するQoS及び保護に特別な注意を払う必要がある。VFにわたってSWQを共有する場合、どのVFがSWQに受け入れられたエンキュー要求を受信したかを識別するように、デバイス設計において注意払われなければなければならない。SWQからワーク要求をディスパッチする場合、デバイスは、アップストリーム要求が、(エンキュー要求ペイロード内で伝達されたPASIDに加えて)それぞれのVFのリクエスタID(バス/デバイス/機能#)と適切にタグ付けされているかを確認すべきである。
エンキュー・ノン・ポステッドライトアドレス:SWQをサポートするエンドポイントデバイスは、これらのPF又はVFメモリBARを通じて転送される任意のアドレスへのエンキュー・ノン・ポステッドライトを受け入れることが必要とされる。SWQ_REGアドレスではないアドレスへの、エンドポイントデバイスにより受信された任意のエンキュー・ノン・ポステッドライト要求について、デバイスは、エラー(例えば、不正な形式のTLPなど)としてこれを処理しない代わりに、リトライの完了ステータス(MRS)と共に完了を返すことが必要とされ得る。これは、SWQ可能なデバイス上の非SWQ_REGアドレスにエンキュー格納を誤って又は悪意をもって発行するENQCMD/S命令の非特権(リング3又はリング0VMXゲスト)ソフトウェアの使用は、プラットフォーム固有のエラー処理結果と共に致命的でないエラー又は致命的なエラーを報告するという結果をもたらすことができないことを確保するために行われてよい。
SWQ_REGに対する非エンキュー要求処理:SWQをサポートするエンドポイントデバイスは、致命的又は致命的でないエラーとしてこれらを処理することなく、SWQ_REGアドレスに対する非エンキュー要求(通常のメモリ書き込み及び読み出し)を無許可でドロップしてよい。SWQ_REGアドレスに対する読み出し要求は、要求されたデータバイトに対してオール1の値を有する正常完了応答(UR又はCAとは対照的に)を返してよい。SWQ_REGアドレスへの通常のメモリ(ポステッド)書き込み要求は、エンドポイントデバイスによる動作なしで単にドロップされる。これは、特権のないソフトウェアが、プラットフォーム固有のエラー処理結果と共に致命的でないエラー又は致命的なエラーを誤って又は悪意をもって報告させるようにSWQ_REGアドレスへの通常の読み出し及び書き込み要求を生成できないことを確保するために行われ得る。
SWQキューデプス及びストレージ:SWQキューデプス及びストレージは、デバイス実装に固有のものである。デバイス設計は、デバイスの最大限の利用を実現するために、十分なキューデプスがSWQにサポートされることを確保すべきである。SWQに対するストレージは、デバイス上に実装されてよい。SoC上の統合デバイスは、SWQのバッファ溢れとして、スティールされたメインメモリ(デバイスの使用のために予約された非OS可視プライベートメモリ)を利用してよく、オンデバイスストレージを用いて実現するよりも、より大きなSWQキューデプスを可能にする。そのような設計について、バッファ溢れの使用は、デバイスハードウェアが、(エンキュー要求をドロップして、リトライ完了ステータスを送信することと対比して)いつあふれさせ、コマンド実行に対するバッファ溢れからフェッチし、任意のコマンドに固有のオーダリング要求を維持するかを決定するので、ソフトウェアに対して透過的である。すべての用途に対して、そのようなバッファ溢れの利用は、SWQストレージに対してローカルデバイスが取り付けられたDRAMを用いる別個のデバイスと同等である。スティールされたメモリ(stolen memory)内のバッファ溢れを伴うデバイス設計は、そのようなスティールされたメモリ(stolen memory)が、割り当てられたデバイスによりバッファ溢れの読み出し及び書き込み以外の任意のアクセスから保護されることを確認するために非常に注意しなければならない。
非ブロックSWQの挙動:性能上の理由で、デバイス実装は、成功又はリトライ完了ステータスを有するエンキュー・ノン・ポステッドライト要求に迅速に応答すべきであり、要求を受け入れるために解放されるSWQ容量のエンキュー完了をブロックすべきでない。SWQに対するエンキュー要求を受け入れ又は拒絶する決定は、容量、QoS/占有率又はその他のポリシに基づき得る。いくつかの例示的なQoSの検討が次に説明される。
SWQ QoSの検討:SWQ_REGアドレスをターゲットととするエンキュー・ノン・ポステッドライトについて、エンドポイントデバイスは、承認制御を適用して、それぞれのSWQに対する要求を受け入れ(及び、成功完了ステータスを送信する)、又は、それをドロップする(及び、リトライ完了ステータスを送信する)ことを決定してよい。承認制御は、デバイス及び利用に固有のものであってよく、ハードウェアによりサポート/強制される特定のポリシは、物理ファンクション(PF)ドライバインタフェースを通じてソフトウェアにさらされてよい。SWQが、複数の生産者クライアントを有する共有リソースであるので、デバイス実装は、生産者にわたるサービス妨害攻撃に対して適切な保護を確保しなければならない。SWQに対するQoSは、単にSWQに対する(エンキュー要求を通じた)ワーク要求の受け入れのみを指し、異なる生産者によりサブミットされたワーク要求を処理する場合、デバイスの実行リソースを共有するために、QoSがどのように適用されるかについて、デバイスハードウェアにより適用される任意のQoSに直交する。SWQに対するエンキュー要求を受け入れるための承認ポリシを強制するようにエンドポイントデバイスを構成することについて、いくつかの例示的なアプローチが以下に説明される。これらは、単に例示の目的で記録され、正確な実施例の選択はデバイスに固有である。
一実施例において、MOVDIRI命令は、直接格納処理を用いて、ソースオペランド(第2のオペランド)内のダブルワード整数を宛先オペランド(第1のオペランド)移動させる。ソースオペランドは、汎用レジスタであってよい。宛先オペランドは、32ビットのメモリ位置であってよい。64ビットモードにおいて、命令のデフォルトの処理サイズは32ビットである。MOVDIRIは、ダブルワード又はクワッドワードアラインとなるように宛先を定義する。
直接格納は、データを書き込むためのライトコンバイニング(WC)メモリタイププロトコルを用いることにより実装され得る。このプロトコルを用いることで、プロセッサは、キャッシュ階層にデータを書き込むことも、キャッシュ階層にメモリから対応するキャッシュラインをフェッチすることもしない。宛先アドレスがキャッシュされる場合、直接格納前に、ラインは、キャッシュからライトバック(修正される場合)及び無効にされる。宛先に対する未キャッシュ(UC)及び書き込み保護(WP)メモリタイプが非一時的な暗示をオーバーライドすることを可能にする非一時的な暗示を用いた格納とは異なり、直接格納は、(UC及びWPタイプを含む)宛先アドレスメモリタイプに拘わらず、WCメモリタイププロトコルに常に従う。
WC格納及び非一時的な暗示を用いた格納とはことなり、直接格納は、ライトコンバイニングバッファからの即時エビクションの対象となり、ひいては、同じアドレスへの若い方の格納(直接格納を含む)と組み合わせられない。ライトコンバインバッファにおいて保持されるより古いWC及び非一時的な格納は、同じアドレスへの若い方の直接格納と組み合わせられてよい。
直接格納により用いられるWCプロトコルは、弱くオーダリングされたメモリ整合性モデルに従うので、フェンシング処理は、必要なときに、オーダリングを強制するためにMOVDIRI命令に従うはずである。
宛先へMOVDIRIにより発行された直接格納は、4バイト境界にアラインされ、4バイト書き込み完了のアトミック性を保証する。これは、データが、単一の非トーン4バイト(又は、8バイト)書き込みトランザクションにおける宛先に到達することを意味する。宛先が書き込みサイズに整合しない場合、MOVDIRIにより発行された直接格納は、2つの部分の宛先に分割されて到達する。そのような分割直接格納の各部は、若い方の格納とマージすることはないが、任意の順序で宛先に到達できる。
図59は、MOVDIRI命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
5901において、命令がフェッチされる。例えば、MOVDIRIがフェッチされる。MOVDIRI命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)、宛先オペランドを表す宛先フィールド、及び、ソースレジスタオペランドを表すソースフィールドを含む。
5903において、フェッチされた命令がデコードされる。例えば、MOVDIRI命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
5905において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
5907において、デコードされた命令は、データをキャッシングすることなく、ソースレジスタオペランドから宛先レジスタオペランドにダブルワードサイズのデータを移動する、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。
いくつかの実施形態では、5909において、命令がコミット又はリタイアされる。
64バイト書き込みアトミック性を有する直接格納として、ソースメモリアドレスから宛先メモリアドレスに64バイトを移動する。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリ位置である。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくESセグメントへのオフセットとして解釈される。64ビットモードにおいて、レジスタオペランド幅は、64ビット(又は、32ビット)である。64ビットモードの外部では、レジスタ幅は、32ビット又は16ビットである。MOVDIR64Bは、宛先アドレスが64バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
MOVDIR64Bは、ソースメモリアドレスから64バイトを読み出して、宛先アドレスに対する64バイトの直接格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。直接格納は、データを書き込むためのライトコンバイニング(WC)メモリタイププロトコルを用いることにより実装される。このプロトコルを用いることで、プロセッサは、キャッシュ階層にデータを書き込まなくてよく、キャッシュ階層にメモリから対応するキャッシュラインをフェッチしなくてよい。宛先アドレスがキャッシュされる場合、直接格納前に、ラインは、キャッシュからライトバック(修正される場合)及び無効にされる。
宛先に対するUC/WPメモリタイプが、非一時的な暗示をオーバーライドすることを可能にする非一時的な暗示を用いた格納とは異なり、直接格納は、(UC/WPタイプを含む)宛先アドレスメモリタイプに拘わらず、WCメモリタイププロトコルに従ってよい。
WC格納及び非一時的な暗示を用いた格納とは異なり、直接格納は、ライトコンバイニングバッファからの即時エビクションの対象となり、ひいては、同じアドレスへお若い方の格納(直接格納を含む)と組み合わせられない。ライトコンバインバッファにおいて保持されるより古いWC及び非一時的な格納は、同じアドレスへの若い方の直接格納と組み合わせられてよい。
直接格納により用いられるWCプロトコルは、弱くオーダリングされたメモリ整合性モデルに従うので、フェンシング処理は、必要なときに、オーダリングを強制するためにMOVDIR64B命令に従うはずである。
ソースアドレスから64バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて、64バイトを読み出すしてよい。MOVDIR64Bにより発行される64バイト直接格納は、64バイト書き込み完了のアトミック性を保証する。これは、データが、単一の非トーン64バイト書き込みトランザクションにおける宛先に到達することを意味する。
図60は、MOVDIRI64B命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6001において、命令がフェッチされる。例えば、MOVDIRI64Bがフェッチされる。MOVDIRI64B命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)、宛先オペランドを表す宛先フィールド、及び、ソースレジスタオペランドを表すソースフィールドを含む。
6003において、フェッチされた命令がデコードされる。例えば、MOVDIRI64B命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6005において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6007において、デコードされた命令は、データをキャッシングすることなく、ソースレジスタオペランドから宛先レジスタオペランドに64バイトデータを移動する、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。
いくつかの実施形態では、6009において、命令がコミット又はリタイアされる。
一実施例において、ENQCMDコマンドは、ソースメモリアドレス(第2のオペランド)から宛先オペランド内のデバイス共有型ワークキュー(SWQ)メモリアドレスに64バイト書き込みアトミック性を有するノンポステッド書き込みを用いて、64バイトのコマンドをエンキューする。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリアドレスである。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくESセグメントへのオフセットとして解釈される。64ビットモードにおいて、レジスタオペランド幅は、64ビット又は32ビットである。64ビットモードの外部では、レジスタ幅は、32ビット又は16ビットである。ENQCMDは、宛先アドレスが64バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
一実施例において、ENQCMDは、ソースメモリアドレスから64バイトのコマンドを読み出し、64バイトのエンキュー格納データをフォーマット化し、宛先アドレスに対する格納データの64バイトのエンキュー格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。一般的な保護エラーは、ソースメモリアドレスから読み出される64バイトのコマンドデータの下位4バイトが、ゼロ以外の値を有する場合、又は、PASID有効フィールドビットが0である場合に引き起こされ得る。そうでなければ、64バイトのエンキュー格納データは、以下のようにフォーマット化される。
エンキュー格納データ[511:32]=コマンドデータ[511:32]
エンキュー格納データ[31]=0
エンキュー格納データ[30:20]=0
エンキュー格納データ[19:0]=PASID MSR[19:0]
一実施例において、ENQCMDにより生成された64バイトのエンキュー格納データは、図58に示されるフォーマットを有する。コマンド記述子内の上位60バイトは、ターゲットデバイスに固有のコマンド5801を規定する。PRIVフィールド5802(ビット31)は、ENQCMD命令により生成されたエンキュー格納に対するユーザ特権を伝達するために0に強制されてよい。PASIDフィールド(ビット19:0)5804は、ENQCMD1を実行するソフトウェアスレッド用のシステムソフトウェアにより割り当てられる(PASID MSRにおいてプログラミングされるような)処理アドレス空間識別を伝達する。
エンキュー格納処理は、64バイトのデータを書き込むためにノンポステッド書き込みプロトコルを用いる。ノンポステッド書き込みプロトコルは、キャッシュ階層にデータを書き込まなくてよく、キャッシュ階層に対応するキャッシュラインをフェッチしなくてよい。エンキュー格納は、(UC/WPタイプを含む)宛先アドレスメモリタイプに拘わらず、ノンポステッド書き込みプロトコルに常に従う。
ノンポステッド書き込みプロトコルは、ノンポステッド書き込みに対する成功又はリトライステータスを示すために、完了応答を返してよい。ENQCMD命令は、ゼロフラグでこの完了ステータスを返してよい(0は成功を示し、1はリトライを示す)。成功ステータスは、ノンポステッド書き込みデータ(64バイト)が、目標の共有のワークキューにより受け入れられることを示す(が、必ずしも作用を受けるわけではない)。リトライステータスは、ノンポステッド書き込みが容量又は他の一時的な理由に起因して(又は、宛先アドレスが有効な共有のワークキューアドレスではないことに起因して)、宛先アドレスによって受け入れられなかったことを示す。
一実施例において、多くても1つのエンキュー格納は、所与の論理プロセッサから未処理となる可能性がある。その意味では、エンキュー格納は、別のエンキュー格納を渡すことができない。エンキュー格納は、より古いWB格納、WC及び非一時的な格納、CLFLUSHOPT又はCLWBに対して、異なるアドレスへのオーダリングは行わない。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納の後、かつ、エンキュー格納前に明示的な格納フェンシングを用いなければならない。ENQCMDは、他の格納により影響されない共有のワークキュー(SWQ)アドレスだけに影響を与える。
ソースアドレスから64バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて64バイトを読み出してよい。ENQCMDにより発行された64バイトのエンキュー格納は、64バイト書き込み完了のアトミック性を保証する。データは、単一の非トーン(non−torn)64バイトの非ポステッド書き込みトランザクションとして宛先に到達し得る。
いくつかの実施形態において、PASIDアーキテクチャのMSRがENQCMD命令により用いられる。
図61は、ENCQMD命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6101において、命令がフェッチされる。例えば、ENCQMDがフェッチされる。ENCQMD命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)、宛先メモリアドレスオペランドを表す宛先フィールド、及び、ソースメモリオペランドを表すソースフィールドを含む。
6103において、フェッチされた命令がデコードされる。例えば、ENCQMD命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6105において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6107において、デコードされた命令は、コマンド(取得したデータ)を宛先メモリアドレスに書き込む、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。いくつかの実施形態において、宛先メモリアドレスは共有のワークキューである。
いくつかの実施形態では、6109において、命令がコミット又はリタイアされる。
一実施例において、ENQCMDS命令は、ソースメモリアドレス(第2のオペランド)から宛先オペランド内のデバイス共有型ワークキュー(SWQ)メモリアドレスに64バイト書き込みアトミック性を有するノンポステッド書き込みを用いて、64バイトのコマンドをエンキューする。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリアドレスである。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくESセグメントへのオフセットとして解釈されてよい。64ビットモードにおいて、レジスタオペランド幅は、64ビット又は32ビットである。64ビットモードの外部では、レジスタ幅は32ビット又は16ビットである。ENQCMDは、宛先アドレスが64バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
(任意の特権レベルから実行され得る)ENQCMDとは異なり、ENQCMDSは、特権命令である。プロセッサが、保護モードで実行している場合、CPLは、この命令を実行する0でなければならない。ENQCMDSは、ソースメモリアドレスから64バイトのコマンドを読み出して、宛先アドレスに対して、このデータを用いて64バイトのエンキュー格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。64バイトのエンキュー格納データは、以下のようにフォーマット化される。
エンキュー格納データ[511:32]=コマンドデータ[511:32]
エンキュー格納データ[31]=コマンドデータ[31]
エンキュー格納データ[30:20]=0
エンキュー格納データ[19:0]=コマンドデータ[19:0]
ENQCMDSにより生成された64バイトのエンキュー格納データは、ENQCMDと同じフォーマットを有してよい。一実施例において、ENQCMDSは、図62に示されるフォーマットを有する。
コマンド記述子内の上位60バイトは、ターゲットデバイスに固有のコマンド6201を規定する。PRIVフィールド(ビット31)6202は、ENQCMDS命令により生成されるエンキュー格納のためのユーザ(0)又はスーパバイザ(1)特権のいずれか一方を伝達するために、ソースオペランドアドレスにおけるコマンドデータ内のビット31により規定される。PASIDフィールド(ビット19:0)6204は、ソースオペランドアドレス1におけるコマンドデータ内のビット19:0に規定されるような処理アドレス空間識別を伝達する。
一実施例において、エンキュー格納処理は、64バイトのデータを書き込むために、ノンポステッド書き込みプロトコルを用いる。ノンポステッド書き込みプロトコルは、キャッシュ階層にデータを書き込むことも、キャッシュ階層に対応するキャッシュラインをフェッチすることもしない。エンキュー格納は、(UC/WPタイプを含む)宛先アドレスメモリタイプに拘わらず、ノンポステッド書き込みプロトコルに常に従う。
ノンポステッド書き込みプロトコルは、ノンポステッド書き込みに対する成功又はリトライステータスを示すために、完了応答を返す。ENQCMD命令は、ゼロフラグでこの完了ステータスを返す(0は成功を示し、1はリトライを示す)。成功ステータスは、ノンポステッド書き込みデータ(64バイト)が、目標の共有のワークキューにより受け入れられることを示す(が、必ずしも作用を受けるわけではない)。リトライステータスは、ノンポステッド書き込みが、容量又は他の一時的な理由に起因して(又は、宛先アドレスが有効な共有のワークキューアドレスではないことに起因して)宛先アドレスにより受け入れられなかったことを示す。
多くても1つのエンキュー格納(ENQCMD又はENQCMDS)は、所与の論理プロセッサから未処理となる可能性がある。その意味では、エンキュー格納は、別のエンキュー格納を渡すことができない。エンキュー格納は、より古いWB格納、WC及び非一時的な格納、CLFLUSHOPT又はCLWBに対して、異なるアドレスへのオーダリングは行われなくてよい。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納後、かつ、エンキュー格納前に明示的な格納フェンシングを用いてよい。
ENQCMDSは、他の格納により影響されない共有のワークキュー(SWQ)アドレスだけに影響を与える。
ソースアドレスから64バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて64バイトを読み出してよい。ENQCMDSにより発行された64バイトのエンキュー格納は、64バイト書き込み完了のアトミック性を保証する(すなわち、単一の非トーン(non−torn)64バイトの非ポステッド書き込みトランザクションとしての宛先に到達する)。
図63は、ENCQMD命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6301において、命令がフェッチされる。例えば、ENCQMDがフェッチされる。ENCQMD命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)、宛先メモリアドレスオペランドを表す宛先フィールド、及び、ソースメモリオペランドを表すソースフィールドを含む。
6303において、フェッチされた命令がデコードされる。例えば、ENCQMD命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6305において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6307において、デコードされた命令は、コマンド(取得したデータ)を宛先メモリアドレスに書き込む、本明細書で詳細に説明されるような実行回路(ハードウェア)により、特権モードで実行される。いくつかの実施形態において、宛先メモリアドレスは、共有のワークキューである。
いくつかの実施形態では、6309において、命令がコミット又はリタイアされる。
一実施例では、アクセラレータとホストプロセッサ、すなわち、UMONITORとUMWAITとの間の効率的な同期を確実にするために2つの命令を利用する。簡潔に、UMONITOR命令は、ソースレジスタにおいて特定されたアドレスを用いて、アドレスモニタリングハードウェアを作動可能にし、UMWAIT命令は、アドレスの範囲をモニタリングしている間、実装に依存して最適化された状態に入れるようプロセッサに命令する。
UMONITOR命令は、r32/r64ソースレジスタにおいて特定されるアドレスを用いてアドレスモニタリングハードウェアを作動可能にする(格納オペレーションに対するモニタリングハードウェアがチェックするアドレス範囲が、CPUIDモニタリーフ機能を用いることにより判断され得る)。特定のアドレス範囲内のアドレスへの格納は、モニタリングハードウェアをトリガする。モニタハードウェアの状態は、UMWAITにより用いられる。
以下のオペランドのエンコーディングは、UMONITOR命令の一実施例に用いられる。
r32/r64ソースレジスタのコンテンツはが有効なアドレスである(64ビットモードにおいて、r64が用いられる)。デフォルト設定により、DSセグメントは、モニタリングされる線形アドレスを作成するために用いられる。セグメントオーバーライドが用いられ得る。アドレス範囲は、ライトバックタイプのメモリを用いなければならない。ライトバックメモリだけが、モニタリングハードウェアを正確にトリガすることを保証する。
UMONITOR命令は、他のメモリトランザクションに関するロードオペレーションとしてオーダリングされる。命令は、バイトロードと関連付けられる許可チェック及びフォールトを対象とする。ロードと同様に、UMONITORは、ページテーブル内のDビットではなく、Aビットを設定する。
UMONITOR及びUMWAITは、任意の特権レベルで実行されてよい。命令のオペレーションは、非64ビットモード及び64ビットモードにおいて同じである。
UMONITORは、レガシMWAIT命令と同時に使用しない。MWAITを実行し、続けて、レガシMONITOR命令の最新の実行の前に、UMONITORが実行された場合、MWAITは、最適化された状態に入らなくてよい。実行は、MWAITの後に続く命令において再開する。
UMONITOR命令は、トランザクション領域内で用いられる場合、トランザクションをアボートさせる。
UMONITORは、有効なアドレスとしてソースレジスタのコンテンツを用いてモニタハードウェアのアドレス範囲をセットアップし、モニタハードウェアを作動可能状態(armed state)に置く。特定のアドレス範囲に対する格納は、モニタハードウェアをトリガする。
図64は、UMONITOR命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6401において、命令がフェッチされる。例えば、UMONITORがフェッチされる。UMONITOR命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)、及び、明示的なソースレジスタオペランドを含む。
6403において、フェッチされた命令がデコードされる。例えば、UMONITOR命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6405において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6407において、デコードされた命令は、取得したソースレジスタデータにより規定されるアドレスへの格納のためにモニタリングハードウェアを作動可能にする、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。
いくつかの実施形態では、6409において、命令がコミット又はリタイアされる。
UMWAITは、アドレスの範囲をモニタリングしている間に、実装に依存して最適化された状態に入るようプロセッサに命令する。最適化された状態は、軽量電力/性能が最適化された状態又は改善された電力/性能が最適化された状態のいずれか一方であってよい。その2つの状態の選択は、明示的な入力レジスタビット[0]ソースオペランドにより統制される。
UMWAITは、任意の特権レベルで実行されてよい。この命令のオペレーションは、非64ビットモード及び64ビットモードにおいて同じである。
入力レジスタは、以下のテーブルにおいて説明さるように、プロセッサが入るべきである好ましく最適化された状態などの情報を含んでよい。ビット0以外のビットは、予約済みであり、ゼロ以外である場合、#GPを結果としてもたらす。
命令は、タイムスタンプカウンタが暗黙的な64ビット入力値に達した又はこれを超えた場合(モニタリングハードウェアが予めトリガされていなかった場合)にウェイクアップする。
UMWAIT命令を実行する前に、オペレーティングシステムは、2つの電力/性能が最適化された状態のいずれか一方を含み得るそのオペレーションをプロセッサが一時停止することを可能にする最大遅延を規定してよい。それは、以下の32ビットMSRにTSC量子値を書き込むことによりそうすることができる。
UMWAIT_CONTROL[31:2]−C0.1又はC0.2のいずれか一方にプロセッサが存在し得るTSC量子における最大時間を判断する。ゼロの値は、OSがプロセッサに対して課した制限がないことを示す。最大時間値は、上位30bがこのフィールドから来ており、下位2ビットがゼロであると仮定される32bの値である。
UMWAIT_CONTROL[1]−予約済。
UMWAIT_CONTROL[0]−C0.2はOSにより許可されていない。1の値は、すべてのC0.2要求がC0.1に戻ることを意味する。
一実施例において、UMWAIT命令を実行したプロセッサがオペレーティングシステム時間制限の期限切れに起因して起きた場合、命令は、キャリーフラグを設定し、そうでなければ、そのフラグがクリアされる。
UMWAIT命令は、トランザクション領域内で用いられる場合、トランザクションをアボートさせる。一実施例において、UMWAIT命令は、UMONITOR命令と共に動作する。2つの命令は、待機するアドレス(UMONITOR)の定義を可能にし、実装に依存して最適化されたオペレーションが待機アドレス(UMWAIT)で開始することを可能にする。UMWAITの実行は、UMONITORにより作動可能なアドレス範囲に対するイベント又は格納処理を待機している間に、実装に依存して最適化された状態に入ることができるプロセッサに対する暗示である。
次のような場合には、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。UMONITOR命令により作動可能なアドレス範囲への格納、非マスク可能な割込み(NMI)又はシステム管理割込み(SMI)、デバッグ例外、マシンチェック例外、BINIT#信号、INIT#信号及びRESET♯信号。他の実装に依存するイベントは、プロセッサに、実装に依存して最適化された状態を抜けさせてもよい。
さらに、外部の割込みは、マスク可能割込みが阻害されるか否かに関わらず、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。
実装に依存して最適化された状態からの抜け出しに続いて、制御が、UMWAIT命令に続く命令に渡される。マスクされていない未処理の割込み(NMI又はSMIを含む)は、命令の実行前に配信されてよい。
HLT命令とは異なり、UMWAIT命令は、SMIの処理に続くUMWAIT命令での再開をサポートしていない。先行するUMONITOR命令が、アドレス範囲を正常に作動可能していなかった場合、又は、UMWAITを実行し、続けてレガシMONITOR命令の最新の実行の前に、UMONITORが実行されなかった(UMWAITがMONITORと同時に使用されていない)場合、プロセッサは、最適化された状態に入らない。実行は、UMWAITの後に続く命令において再開する。
UMWAITが、C1より数値的に低いC0−サブ状態に入るために用いられ、従って、UMONITOR命令により作動可能なアドレス範囲に対する格納は、他のプロセッサエージェントにより格納が発せられた場合、又は、非プロセッサエージェントにより格納が発せられた場合のいずれか一方の場合、プロセッサにUMWAITを終了させることに留意する。
図65は、UMWAIT命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6501において、命令がフェッチされる。例えば、UMWAITがフェッチされる。UMWAIT命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)及び明示的なソースレジスタオペランドを含む。
6503において、フェッチされた命令がデコードされる。例えば、UMWAIT命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6505において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6507において、デコードされた命令は、アドレスの範囲をモニタリングしている間に、プロセッサ(又は、コア)を、明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に入れる、本明細書で詳細に説明されるような、実行回路(ハードウェア)により実行される。
いくつかの実施形態では、6509において、命令がコミット又はリタイアされる。
TPAUSEは、実装に依存して最適化された状態に入るようプロセッサに命令する。軽量電力/性能が最適化された状態、及び、改善された電力/性能が最適化された状態の中から選択するそのような2つの最適化された状態がある。当該2つの中からの選択は、明示的な入力レジスタビット[0]ソースオペランドにより統制される。
TPAUSEは、任意の特権レベルで実行されてよい。この命令のオペレーションは、非64ビットモード及び64ビットモードにおいて同じである。
PAUSEとは異なり、TPAUSE命令は、トランザクション領域の内部で用いられるときにアボートを生じさせない。入力レジスタは、以下のテーブルで説明されるように、プロセッサが入る好ましく最適化された状態のような情報を含む。ビット0以外のビットは、予約済みであり、ゼロ以外である場合、#GPをもたらす。
命令は、タイムスタンプカウンタが暗黙的な64ビット入力値に達した又はこれを超えた場合(モニタリングハードウェアが予めトリガされていなかった場合)にウェイクアップする。TPAUSE命令を実行する前に、オペレーティングシステムは、2つの電力/性能が最適化された状態のいずれか一方におけるそのオペレーションをプロセッサが一時停止することを可能にする最大遅延を規定してよい。それは、以下の32ビットMSRにTSC量子値を書き込むことによりそうすることができる。
UMWAIT_CONTROL[31:2]−C0.1又はC0.2のいずれか一方にプロセッサが存在し得るTSC量子における最大時間を判断する。ゼロの値は、OSがプロセッサに対して課した制限がないことを示す。最大時間値は、上位30bがこのフィールドから来ており、下位2ビットがゼロであると仮定される32bの値である。
UMWAIT_CONTROL[1]−予約済。
UMWAIT_CONTROL[0]−C0.2はOSにより許可されていない。'1の値は、すべてのC0.2要求がC0.1に戻ることを意味する。
OSの時間制限の期限切れに起因するウェイクアップ理由は、キャリーフラグを設定することにより示されてよい。
TPAUSE命令を実行したプロセッサがオペレーティングシステム時間制限の期限切れに起因して起きた場合、命令は、キャリーフラグを設定し、そうでなければ、そのフラグがクリアされる。
複数のアドレス範囲をモニタリングすることに関して、TPAUSE命令は、モニタするためのアドレスのセット及び後続のTPAUSE命令から構成されるトランザクション領域内に置かれ得る。トランザクション領域は、待機するアドレスのセットの定義を可能にし、実装に依存して最適化されたオペレーションがTPAUSE命令の実行時に開始することを可能にする。一実施例において、TPAUSEの実行は、読み出しセットにより規定される範囲内のアドレスに対するイベント又は格納処理を待機している間に、実装に依存して最適化された状態に入るようプロセッサに指示する。
トランザクションメモリ領域内でのTPAUSEの用は、C0.1(軽量電力/性能が最適化された状態)に制限され得る。たとえ、ソフトウェアが、C0.2(改善された電力/性能が最適化された状態)に対するその優先度を示すべく、ビット[0]=0を設定したとしても、プロセッサは、C0.1に入ってよい。
次のような場合は、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。トランザクション領域内の読み出しセット範囲への格納、NMI又はSMI、デバッグ例外、マシンチェック例外、BINIT#信号、INIT#信号及びRESET♯信号。すべてのこれらのイベントはまた、トランザクションをアボートする。
他の実装に依存するイベントは、プロセッサに、実装に依存して最適化された状態を抜けさせてよく、TPAUSEに続く命令に進んで、アボートされていないトランザクション領域を結果としてもたらし得る。さらに、外部の割込みは、いくつかの実施形態において、マスク可能割込みが阻害されるか否かに関わらず、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。マスク可能割込みが阻害される場合、実行はTPAUSEに続く命令に進み、一方、割込みがイネーブルにされたフラグが設定されている場合、トランザクション領域がアボートされることに留意されたい。
図66は、TPAUSE命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
6601において、命令がフェッチされる。例えば、TPAUSEがフェッチされる。TPAUSE命令は、オペコード(及び、いくつかの実施形態において、プレフィックス)及び明示的なソースレジスタオペランドを含む。
6603において、フェッチされた命令がデコードされる。例えば、TPAUSE命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
6605において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
6607において、デコードされた命令は、明示的なソースレジスタオペランドについてのデータにより規定される実装ごとに決まる状態にプロセッサ(又は、コア)を入れる、本明細書で詳細に説明されるような、実行回路(ハードウェア)により実行される。
いくつかの実施形態では、6609において、命令がコミット又はリタイアされる。
図67は、UMWAIT及びUMONITOR命令を用いた実行の例を示す。
6701において、UMWAIT命令は、モニタリングするためにアドレスの範囲を設定するように実行される。
6703において、UMONITOR命令は、モニタされているアドレスの範囲に対して、命令の明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に、命令を実行するコアを入れるように実行される。
6705において、実装依存状態は、モニタリングされたアドレスへの格納、NMI、SMI、デバッグ例外、マシンチェック例外、init信号又はリセット信号のうちの1つに応じて抜ける。
図68は、TPAUSE及びUMONITOR命令を用いた実行の例を示す。
6801において、TPAUSE命令は、モニタリングするためにアドレスの範囲を設定するように実行される。
6803において、UMONITOR命令は、モニタリングされているアドレスの範囲に対して、命令の明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に、命令を実行するコアを入れるように実行される。
6805において、実装依存状態は、モニタリングされたアドレスへの格納、NMI、SMI、デバッグ例外、マシンチェック例外、init信号又はリセット信号のうちの1つに応じて抜ける。
6807において、スレッドと関連付けられたトランザクションは、実装依存状態から抜け出たときにアボートされる。
いくつかの実施例では、アクセラレータは、特定のタイプのオペレーション、数例をあげると、グラフィックスオペレーション、機械学習オペレーション、パターン解析オペレーション、及び、(以下で詳細に説明されるような)疎行列乗算演算などを加速させるプロセッサコア又は他の処理要素に結合される。アクセラレータは、バス又は他の相互接続(例えば、ポイントツーポイント相互接続)を介してプロセッサ/コアに通信可能に結合されてよい、又は、プロセッサと同じチップ上に統合され、内部プロセッサバス/相互接続を介してコアに通信可能に結合されてよい。アクセラレータが接続される態様に関わらず、プロセッサコアは、これらのタスクを効率的に処理する専用の回路/論理を含むアクセラレータに、特定の処理タスク(例えば、命令又はUOPのシーケンスの形式で)を割り当ててよい。
図69は、アクセラレータ6900が、キャッシュコヒーレントインタフェース6930を通じて複数のコア6910−6911に通信可能に結合される例示的な実装を示す。コア6910−6911のそれぞれは、仮想−物理アドレス変換を格納するためのトランスレーションルックアサイドバッファ6912−6913と、データ及び命令をキャッシングするための1又は複数のキャッシュ6914−6915(例えば、L1キャッシュ、L2キャッシュなど)とを含む。メモリ管理ユニット6920は、ダイナミックランダムアクセスメモリDRAMであり得るシステムメモリ6950へのコア6910−6911によるアクセスを管理する。L3キャッシュなどの共有キャッシュ6926は、プロセッサコア6910−6911間で、及び、キャッシュコヒーレントインタフェース6930を介してアクセラレータ6900と共有されてよい。一実施例において、コア6910−1011、MMU6920及びキャッシュコヒーレントインタフェース6930は、シングルプロセッサチップ上に統合される。
図示されたアクセラレータ6900は、キャッシュ6907及び複数の処理要素6901−6902、Nに対するスケジューリングオペレーションのためのスケジューラ6906を有するデータ管理ユニット6905を含む。例示された実施例において、各処理要素は、独自のローカルメモリ6903−6904、Nを有する。以下で詳細に説明されるように、各ローカルメモリ6903−6904、Nは、スタック型DRAMとして実装されてよい。
一実施例において、キャッシュコヒーレントインタフェース6930は、コア6910−6911とアクセラレータ6900との間にキャッシュコヒーレントな接続性をもたらし、実際には、アクセラレータをコア6910−6911のピアとして扱う。例えば、キャッシュコヒーレントインタフェース6930は、アクセラレータ6900によりアクセス/修正され、かつ、アクセラレータキャッシュ6907及び/又はローカルメモリ6903−6904、Nに格納されるデータが、コアキャッシュ6910−6911、共有キャッシュ6926及びシステムメモリ6950に格納されるデータとコヒーレントであることを確保するために、キャッシュコヒーレンシプロトコルを実装してよい。例えば、キャッシュコヒーレントインタフェース6930は、共有キャッシュ6926及びローカルキャッシュ6914−6915内のキャッシュラインの状態を検出するために、コア6910−6911及びMMU6920により用いられるスヌーピングメカニズムに参加してよく、プロキシとして動作してよく、処理要素6901−6902、Nにより、キャッシュラインに対するアクセス及び試みた修正に応じてスヌープ更新を提供する。さらに、キャッシュラインが、処理要素6901−6902、Nにより修正された場合、キャッシュコヒーレントインタフェース6930は、共有キャッシュ6926又はローカルキャッシュ6914−6915内にそれらが格納されている場合にキャッシュラインのステータスを更新してよい。
一実施例において、データ管理ユニット1005は、システムメモリ6950及び共有キャッシュ6926へのアクセスをアクセラレータ6900に提供するメモリ管理回路を含む。さらに、データ管理ユニット6905は、必要に応じて(例えば、キャッシュラインに対する状態の変化を判断するために)、キャッシュコヒーレントインタフェース6930への更新を提供、及び、キャッシュコヒーレントインタフェース6930から更新を受信する。例示された実施例において、データ管理ユニット6905は、処理要素6901−6902により実行される命令/処理をスケジューリングするためのスケジューラ6906を含む。そのスケジューリング処理を実行するために、スケジューラ6906は、命令/処理間の依存性を評価して、命令/処理がコヒーレントな順序で実行されることを確保する(例えば、第1の命令が、第1の命令からの結果に依存する第2の命令の前に実行することを確保する)。内部依存していない命令/処理は、処理要素6901−6902で並列に実行されてよい。
図70は、(例えば、一実施例においてスタックされたローカルのDRAMを用いて実装された)データ管理ユニット6905、複数の処理要素6901−N及び高速オンチップストレージ7000を含む前述のアクセラレータ6900及び他のコンポーネントの別の図を示す。一実施例において、アクセラレータ6900は、ハードウェアアクセラレータアーキテクチャであり、処理要素6901−Nは、疎/密行列に対する演算を含む行列×ベクトル及びベクトル×ベクトル演算を実行するための回路を含む。特に、処理要素6901−Nは、列及び行方向の行列処理に対するハードウェアサポートを含んでよく、機械学習(ML)アルゴリズムで用いられるような「スケール及び更新」オペレーションに対するマイクロアーキテクチャ上のサポートを含んでもよい。
説明される実装は、高速オンチップストレージ7000において、頻繁に用いられ、ランダムにアクセスされ、潜在的に疎な(例えば、ギャザー/スキャッタ)ベクトルデータを保持することにより、ストリーミング様式で、可能なときにはいつでもアクセスされるオフチップメモリ(例えば、システムメモリ6950)において、大きくて低い頻度で用いられる行列データを維持することにより、及び、スケールアップするためにイントラ/インター行列ブロック並列処理をさらすことにより、最適化される行列/ベクトル演算を実行する。
処理要素6901−Nの実施例では、疎行列、密行列、疎ベクトル及び密ベクトルの様々な組み合わせを処理する。本明細書で用いられるように、「疎(sparse)」行列又はベクトルは、成分のほとんどがゼロである行列又はベクトルである。一方、「密(dense)」行列又はベクトルは、成分のほどんとがゼロ以外である行列又はベクトルである。行列/ベクトルの「まばら(sparsity)」は、ゼロの値の成分の数を成分の総数(例えば、m×n行列に対してm×n)で割ることに基づいて規定され得る。一実施例において、行列/ベクトルは、そのまばらさが特定の閾値を上回る場合、「疎(sparse)」であるとみなされる。
処理要素6901−Nにより実行される処理の例示的なセットが図71内のテーブルに示される。特に、オペレーションタイプは、疎行列を用いる第1の乗算7100、密行列を用いる第2の乗算7101、スケール及び更新演算7102及びドット積演算7103を含む。列には、第1の入力オペランド7110及び第2の入力オペランド7111(それぞれが、疎又は密行列/ベクトルを含み得る)、出力フォーマット7112(例えば、密ベクトル又はスカラ)、行列データフォーマット(例えば、圧縮された疎行、圧縮された疎列、行方向など)7113、及び、オペレーション識別子7114が規定されている。
いくつかの現在のワークロードにおいて得られるランタイムドメイン計算パターンは、行方向及び列方向の様式でベクトルに対する行列の乗算の変形を含む。周知の行列上のそれらの機能は、圧縮された疎行(CSR)及び圧縮された疎列(CSC)の形式を合わせる。図72aは、ベクトルyを生成するために、ベクトルxに対する疎行列間の乗算の例を図示する。図72bは、各値が(値、行インデックス)ペアとして格納される行列AのCSR表現を示す。例えば、行0に対する(3、2)は、3の値が、行0の成分位置2に格納されていることを示す。図72cは、(値、列インデックス)ペアを用いる行列AのCSC表現を示す。
図73a、図73b及び図73cは、各計算パターンの擬似コードを示し、以下に詳細に説明される。特に、図73aは、行方向の疎行列・密ベクトル乗算(spMdV_csr)を示し、図73bは、列方向の疎行列・疎ベクトル乗算(spMspC_csc)を示し、図73cは、スケール及び更新演算(scale_update)を示す。
A.行方向の疎行列・密ベクトル乗算(spMdV_csr)
これは、高性能な計算など多くのアプリケーション分野で重要な周知の計算パターンである。ここで、行列Aの各行に対して、ベクトルxに対するその行のドット積が実行され、その結果が、行インデックスにより指し示されるyベクトル成分に格納される。この計算は、サンプリングのセット(すなわち、行列の行)にわたって解析を実行する機械学習(ML)アルゴリズムにおいて用いられる。それは、「ミニバッチ」などの技術において用いられてもよい。例えば、学習アルゴリズムの確率論的な確率変数において、MLアルゴリズムが、密ベクトルに対する疎ベクトルのドット積を単に実行する場合(すなわち、spMdV_csrループの反復)もある。
この計算の性能に影響を与え得る既知の要因は、ドット積計算において、疎xベクトル成分にランダムにアクセスする必要があることである。従来のサーバシステムに関して、xベクトルが大きい場合、これは、メモリ又はラストレベルキャッシュへの不規則なアクセス(収集)を結果としてもたらしたであろう。
これに対処するために、処理要素の一実施例では、行列Aを列ブロックに、xベクトルを(行列Aの列ブロックにそれぞれ対応する)複数のサブセットに分割する。ブロックサイズは、xベクトルのサブセットがチップに合致できるように選択され得る。よって、それへのランダムなアクセスは、局在化されたオンチップであり得る。
B.列方向の疎行列・疎ベクトル乗算(spMspV_csc)
疎ベクトルに対して疎行列を乗算するこのパターンは、spMdV_csrほど周知ではない。しかしながら、いくつかのMLアルゴリズムにおいて重要である。それは、アルゴリズムが特徴のセットに作用する場合に用いられ、データセット内の行列の列として表される(よって列方向の行列アクセスが必要になる)。
この計算パターンでは、行列Aの各列が、読み出されて、ベクトルxの対応する非ゼロ成分に対して乗算される。その結果は、yベクトルで保持される部分的なドット積を更新するために用いられる。ゼロ以外のxベクトル成分と関連付けられたすべての列が処理されると、yベクトルは、最終的なドット積を含むことになる。
行列Aへのアクセス(すなわち、Aの列におけるストリーム)が正常である一方、部分的なドット積を更新するyベクトルへのアクセスは不規則である。アクセスするy成分は、処理されるAベクトル成分の行インデックスに依存する。これに対処するために、行列Aは、行ブロックに分割され得る。その結果、ベクトルyは、これらのブロックに対応するサブセットに分割され得る。この方式では、行列の行ブロックを処理する場合に、そのyベクトルサブセットに不規則にアクセス(ギャザー/スキャッタ)することのみが必要である。適切にブロックサイズを選択することにより、yベクトルサブセットは、オンチップで保持され得る。
C.スケール及び更新(scale_update)
このパターンは、典型的には、行列内の各サンプルにスケーリングファクタを適用するMLアルゴリズムにより用いられ、それぞれが特徴(すなわち、A内の列)に対応する、それらが重みのセットへと低減される。ここで、xベクトルはスケーリングファクタを含む。(CSRフォーマットにおける)行列Aの各行に対して、その行に対するスケーリングファクタは、xベクトルから読み出され、次に、その行におけるAの各成分に適用される。その結果は、yベクトルの成分を更新するために用いられる。すべて行が処理されると、yベクトルは、低減された重みを含むことになる。
前の計算パターンと同様に、yベクトルに対する不規則なアクセスは、yが大きい場合の性能に影響を与え得る。行列Aを列ブロックに、yベクトルをこれらのブロックに対応する複数のサブセットに分割することは、各yサブセット内に不規則なアクセスを局所化するのに役立てることができる。
一実施例では、上述した計算パターンを効率的に実行できるハードウェアアクセラレータを含む。アクセラレータは、汎用プロセッサと統合され得るハードウェアIPブロックである。一実施例において、アクセラレータ6900は、プロセッサと共有される相互接続を通じてメモリ6950に独立にアクセスして、計算パターンを実行する。それは、オフチップメモリ内に存在するいずれか任意の大規模行列データセットをサポートする。
図74は、データ管理ユニット6905及び処理要素6901−6902の一実施例に関する処理フローを示す。この実施例において、データ管理ユニット6905は、処理要素スケジューラ7401、読み出しバッファ7402、書き込みバッファ7403及び低減ユニット7404を含む。各PE6901−6902は、入力バッファ7405−7406、乗算器7407−7408、加算器7409−7410、ローカルRAM7421−7422、合計レジスタ(sum register)7411−7412及び出力バッファ7413−7414を含む。
アクセラレータは、いずれか任意の大規模行列データをサポートするために、上述した行列ブロッキングスキーム(すなわち、行及び列のブロック化)をサポートする。アクセラレータは、行列データのブロックを処理するように設計される。各ブロックは、PE6901−6902により並列に処理されるサブブロックにさらに分割される。
動作中、データ管理ユニット6905は、メモリサブシステムからその読み出しバッファ7402に行列の行又は列を読み出し、次に、処理するためにPE6901−6902にわたってPEスケジューラ7401により動的に分配される。それはまた、その書き込みバッファ7403からメモリに結果を書き込む。
各PE6901−6902は、行列のサブブロックを処理する役割を担う。PEは、ランダムにアクセスされる必要があるベクトル(すなわち、上記で説明されたようなx又はyベクトルのサブセット)を格納するオンチップRAM7421−7422を含む。また、乗算器7407−7408及び加算器7409−7410を含む浮動小数点積和(FMA)ユニットと、入力データから行列成分を抽出する入力バッファ7405−7406内のアンパック論理と、累算されたFMA結果を保持する合計レジスタ(sum register)7411−7412と含む。
アクセラレータの一実施例は、(1)不規則にアクセス(ギャザー/スキャッタ)されるデータをオンチップPE RAM7421−7422に配置し、(2)PEが十分に利用されることを確保するためにハードウェアPEスケジューラ7401を利用し、(3)汎用プロセッサを用いる場合とは異なり、アクセラレータが、疎行列演算に不可欠なハードウェアリソースのみからなるので、最高の効率性を実現する。全体的には、アクセラレータは、それに提供される利用可能なメモリ帯域幅を性能へと効率的に変換する。
性能のスケーリングは、1つのアクセラレータブロックにおいて多くのPEを使用して、並列に複数の行列のサブブロックを処理することにより、及び/又は、より多くのアクセラレータブロック(それぞれがPEのセットを有する)を使用して、並列に複数の行列ブロックを処理することにより行われ得る。これらのオプションの組み合わせが以下で検討される。PE及び/又はアクセラレータブロックの数は、メモリ帯域幅に一致するように調整されるべきである。
アクセラレータ6900の一実施例では、ソフトウェアライブラリを通じてプログラミングされ得る。そのようなライブラリは、メモリに行列データを準備し、計算に関する情報(例えば、計算タイプ、行列データに対するメモリポインタ)と共にアクセラレータ6900内に制御レジスタを設定し、アクセラレータを開始させる。次に、アクセラレータは、メモリ内の行列データに独立にアクセスして、計算を実行し、消費するソフトウェアに関する結果をメモリに書き戻す。
アクセラレータは、図75a〜図75bに図示されるように、適切なデータパス構成に対してそのPEを設定することにより、様々な計算パターンを処理する。特に、図75aは、spMspV_csc及びscale_update演算に関する(点線を用いて)パスを強調表示し、図75bは、spMdV_csr演算に関するパスを示す。各計算パターンを実行するアクセラレータのオペレーションが以下に詳細に説明される。
spMspV_cscに関して、DMU6905により、最初のyベクトルサブセットがPEのRAM7421にロードされる。次に、メモリからxベクトル成分を読み出す。各x成分に対して、DMU6905は、メモリから対応する行列の列の成分をストリームして、これらをPE6901に供給する。各行列成分は、PEのRAM7421から読み出すことをy成分に指し示す値(A.val)及びインデックス(A.idx)を含む。DMU6905はまた、積和(FMA)ユニットによりA.valに対して乗算されるxベクトル成分(x.val)も提供する。結果は、A.idxにより指し示されるPEのRAM内のy成分を更新するために用いられる。たとえ、本願のワークロードにより用いられなかったとしても、アクセラレータは、サブセットのみの代わりにすべての行列の列を処理することにより、密xベクトル(spMdV_csc)に対して列のような乗算をサポートすることに留意する(xが密なので)。
scale_updateオペレーションは、CSCフォーマットの代わりにCSRフォーマットに表される行列Aの行をDMU6905が読み出すことを除き、spMspV_cscと同様である。spMdV_csrに関して、xベクトルのサブセットは、PEのRAM7421にロードされる。DMU6905は、メモリから行列の行成分(すなわち、{A.val、A.idx}のペア)にストリームする。A.idxは、RAM7421から適切なxベクトル成分を読み出すために用いられ、FMAによりA.valに対して乗算される。結果は、合計レジスタ(sum register)7412へと累算される。合計レジスタ(sum register)は、DMU6905により供給される行の終わりを示すマーカをPEが参照する度に、出力バッファに書き込まれる。このようにして、各PEは、それが担う行のサブブロックに対する合計を生成する。行についての最終的な合計を生成するために、すべてのPEにより生成されたサブブロックの合計は、DMU内の低減ユニット7404によりまとめて加えられる(図74を参照)。最終的な合計は、出力バッファ7413−7414に書き込まれ、その結果、DMU6905はそれをメモリに書き込む。
グラフデータ処理
一実施例において、本明細書で説明されるアクセラレータアーキテクチャは、グラフデータを処理するように構成される。グラフ分析は、グラフとして表されるデータ間の関係に関する知識を抽出するために、グラフアルゴリズムに依存する。グラフデータの拡散(ソーシャルメディアなどのソースから)は、グラフ分析に対する強い要求及び幅広い利用をもたらしてきた。その結果、できるだけ効率的にグラフ分析をできるようにすることが非常に重要である。
この要求に対処するために、一実施例では、所与の入力グラフアルゴリズムにカスタマイズされるハードウェアアクセラレータアーキテクチャ「テンプレート」にユーザ定義型のグラフアルゴリズムを自動的にマッピングする。アクセラレータは、上記で説明されるアーキテクチャを有してよく、FPGA/ASICとして実装されてよく、それは最高の効率性で実行できる。要約すると、一実施例では以下の構成を含む。
(1)汎用の疎行列ベクトル乗算(GSPMV)アクセラレータに基づくハードウェアアクセラレータアーキテクチャテンプレート。グラフアルゴリズムが行列演算として定式化されることができることが示されているので、任意のグラフアルゴリズムをサポートする。
(2)アーキテクチャテンプレートに対して、広く用いられている「頂点主体」グラフプログラミング抽象化をマッピング及び調整する自動アプローチ。
既存の疎行列乗算ハードウェアアクセラレータがあるが、それらは、グラフアルゴリズムのマッピングを可能にするカスタマイズ性をサポートしていない。
設計フレームワークの一実施例では、以下のように動作する。
(1)ユーザは、頂点−中心のグラフプログラミング抽象化に従う「頂点プログラム」としてグラフアルゴリズムを規定する。この抽象化は、その人気に起因して、ここでは例として選択される。頂点プログラムは、ハードウェアの詳細をさらすことはなく、そのため、ハードウェアの専門的知識(例えば、データ科学者)のないユーザでも、それを作成できる。
(2)(1)のグラフアルゴリズムと共に、フレームワークの一実施例では、以下の入力を受け入れる。
生成させるターゲットハードウェアアクセラレータのパラメータ(例えば、オンチップRAMの最大量)。これらのパラメータは、ユーザにより提供されてよい、又は、既存のシステム(例えば、特定のFPGAボード)をターゲットとする場合、既知のパラメータの既存のライブラリから取得されてよい。
b.設計最適化目標(例えば、最大性能、最小エリア)
c.ターゲットグラフデータの特性(例えば、グラフのタイプ)又はグラフデータ自体これは選択的であり、自動チューニングを補助するために用いられる。
(3)上記の入力を前提として、フレームワークの一実施例では、自動チューニングを実行して、入力グラフアルゴリズムを最適化するために、ハードウェアテンプレートに適用するカスタマイズのセットを判断し、これらのパラメータをアーキテクチャテンプレート上にマッピングして、合成可能なRTLにアクセラレータインスタンスを生成し、入力グラフアルゴリズム仕様から導き出される機能及び性能のソフトウェアモデルに対する、生成したRTLの機能及び性能の検証を行う。
一実施例において、上記で説明されるアクセラレータアーキテクチャは、(1)それをカスタマイズ可能なハードウェアテンプレートにすること、(2)頂点プログラムにより必要とされる機能をサポートすることにより、頂点プログラムの実行をサポートするように拡張される。このテンプレートに基づいて、設計フレームワークは、ユーザ供給型の頂点プログラムをハードウェアテンプレートにマッピングして、頂点プログラムに対して最適化された合成可能なRTL(例えば、Verilog)の実装インスタンスを生成するために説明される。フレームワークはまた、生成したRTLが訂正及び最適化されることを確保するために、自動検証及びチューニングを実行する。このフレームワークに関しては、複数の使用事例がある。例えば、生成された合成可能なRTLは、所与の頂点プログラムを効率的に実行するために、FPGAプラットフォーム(例えば、Xeon−FPGA)に配置され得る。又は、それは、ASICの実装を生成するように、さらに改良され得る。
グラフは、隣接行列として表されることができ、グラフ処理は、疎行列演算として定式化されることができる。図76a〜図76bは、隣接行列としてのグラフを表す例を示す。行列内のそれぞれのゼロ以外は、グラフ内の2つのノード中のエッジを表す。例えば、0行2列における1は、ノードAからCのエッジを表す。
グラフデータの計算を表現するための最もポピュラーなモデルの1つは、頂点プログラミングモデルである。一実施例では、汎用の疎行列ベクトル乗算(GSPMV)として、頂点プログラムを定式化するグラフマットソフトウェアフレームワークからの頂点プログラミングモデルの変形をサポートする。図76cに示されるように、頂点プログラムは、(プログラムコードの最上部に示されるような)グラフ内のエッジ/頂点と関連付けられた複数のタイプのデータ(eデータ/vデータ)、グラフ内の頂点を介して送信されるメッセージ(mデータ)、及び、一時的なデータ(tデータ)、並びに、(プログラムコードの下部に示さるような)グラフデータを読み出して更新する予め定義されたAPIを用いるステートレスなユーザ定義型の計算機能からなる。
図76dは、頂点プログラムを実行するための例示的なプログラムコードを示す。エッジデータは、(図76bに示すように)隣接行列Aとして、頂点データをベクトルyとして、メッセージを疎ベクトルxとして表される。図76eは、GSPMVの策定を示し、SPMVにおける乗算()及び加算()演算は、ユーザ定義型のPROCESS_MSG()及びREDUCE()により一般化される。
ここでの1つの見解は、頂点プログラムを実行するのに必要とされるGSPMVの変形が、疎ベクトルx(すなわち、メッセージ)に対する疎行列A(すなわち、隣接行列)の列方向乗算を実行して、出力ベクトルy(すなわち、頂点データ)を生成することである。この演算は、(上記のアクセラレータに関して前述した)col_spMspVと称される。
設計フレームワークテンプレートマッピングコンポーネント7711、検証コンポーネント7712及び自動チューニングコンポーネント7713を含むフレームワークの一実施例が図77に示される。その材料は、ユーザ規定型の頂点プログラム7701、設計最適化目標7703(例えば、最大性能、最小エリア)及びターゲットハードウェア設計制約7702(例えば、オンチップRAMの最大量、メモリンタフェース幅)である。自動チューニングを補助する選択的な材料として、フレームワークは、グラフデータ特性7704(例えば、タイプ=自然グラフ)又はサンプリンググラフデータも許容する。
これらの材料を前提として、フレームワークのテンプレートマッピングコンポーネント7711は、入力ベクトルプログラムをハードウェアアクセラレータアーキテクチャテンプレートにマッピングし、頂点プログラム7701を実行するために最適化されたアクセラレータインスタンスのRTL実装7705を生成する。自動チューニングコンポーネント7713は、自動チューニング7713を実行して、所与の設計目標のために、生成したRTLを最適化しつつ、ハードウェア設計制約を満たす。さらに、検証コンポーネント7712は、当該材料から導き出された機能及び性能モデルに対して生成したRTLを自動的に検証する。検証テストベンチ7706及びチューニング報告7707は、RTLと共に生成される。
汎用の疎行列ベクトル乗算(GSPMV)ハードウェアアーキテクチャテンプレート
GSPMVに関するアーキテクチャテンプレートの一実施例が図77に示され、それは、上記で説明したアクセラレータアーキテクチャに基づいている(例えば、図74及び関連する文章を参照)。図77に示されるコンポーネントの多くがカスタマイズ可能である。一実施例において、頂点プログラムの実行をサポートするアーキテクチャは、以下のように拡張されている。
図78に示されるように、カスタマイズ可能な論理ブロックが、頂点プログラムにより必要とされるPROCESS_MSG()1910、REDUCE()7811、適用7812及びSEND_MSG()7813をサポートするために、各PE内に提供される。さらに、一実施例では、ユーザ定義型のグラフデータ(すなわち、vデータ、eデータ、mデータ、tデータ)をサポートするカスタマイズ可能なオンチップストレージ構造及びパック/アンパック論理7805を提供する。図示されるデータ管理ユニット6905は、PEスケジューラ7401(上記で説明したようなPEをスケジューリングするためのもの)、補助バッファ7801(アクティブな列、xデータを格納するためのもの)、読み出しバッファ7402、システムメモリへのアクセスを制御するためのメモリコントローラ7803、及び、書き込みバッファ7403を含む。さらに、図78に示される実施例では、古い及び新しいvデータ及びtデータがローカルPEメモリ7421内に格納されている。様々な制御ステートマシンは、頂点プログラムを実行すること、図76d及び図76eにおけるアルゴリズムにより規定される機能に対する不変性をサポートするために修正されてよい。
各アクセラレータタイルの処理が図79に要約されている。7901において、yベクトル(vデータ)がPE RAM7421にロードされる。7902において、xベクトル及び列ポインタが補助バッファ7801にロードされる。7903において、xベクトル成分ごとに、列は(eデータ)にストリーミングされ、PEは、PROC_MSG()7810及びREDUCE()7811を実行する。7904において、PEは、APPLY()7812を実行する。7905において、PEは、SEND_MSG()7813を実行してメッセージを生成し、データ管理ユニット6905は、これらうぃxベクトルとしてメモリに書き込む。7906において、データ管理ユニット6905は、PE RAM7421に格納された、更新されたyベクトル(vデータ)をメモリに書き戻す。上記の技術は、図76d及び図76eに示される頂点プログラム実行アルゴリズムに適合する。性能を高めるするために、アーキテクチャは、設計において、タイル内のPEの数及び/又はタイルの数を増加させることを可能にする。この方式では、アーキテクチャは、(すなわち、(隣接行列の、又は、各サブグラフ内のブロックにわたる)サブグラフにわたる)グラフの並列処理の複数のレベルを利用する。図80a内の表は、テンプレートの一実施例についてのカスタマイズ可能なパラメータを要約したものである。最適化用のタイル(例えば、別のタイルより多くのPEを有する1つのタイル)にわたって非対称なパラメータを割り当てることも可能である。
自動マッピング、検証及びチューニング
チューニング。入力に基づいて、フレームワークの一実施例では、入力ベクトルプログラム及び(選択的に)グラフデータに対してハードウェアアーキテクチャテンプレートを最適化するために、それをカスタマイズするために用いるように最良な設計パラメータを判断する自動チューニングを実行する。多くのチューニング検討事項があり、それらは図80b内のテーブルに要約されている。図示されるように、これらは、データの局所性、グラフデータサイズ、グラフ計算機能、グラフデータ構造、グラフデータアクセス属性、グラフデータタイプ及びグラフデータパターンを含む。
テンプレートマッピング。このフェーズでは、フレームワークは、チューニングフェーズにより判断されたテンプレートパラメータを取得し、テンプレートのカスタマイズ可能な部分において「フィル」することによりアクセラレータインスタンスを生成する。ユーザ定義型の計算機能(例えば、図76c)は、既存の高位合成(HLS)ツールを用いて、入力仕様から適切なPE計算ブロックにマッピングされてよい。ストレージ構造(例えば、RAM、バッファ、キャッシュ)及びメモリンタフェースは、これらの対応する設計パラメータを用いてインスタンス化される。パック/アンパック論理は、データタイプ仕様(例えば、図76a)から自動的に生成されてよい。制御有限ステートマシン(FSM)の一部はまた、提供された設計パラメータ(例えば、PEスケジューリングスキーム)に基づいて生成される。
検証。一実施例において、テンプレートマッピングにより生成されたアクセラレータアーキテクチャインスタンス(合成可能なRTL)は、次に、自動的に検証される。これをするために、フレームワークの一実施例では、「ゴールデン」リファレンスとして用いられる頂点プログラムの関数型モデルを導出する。テストベンチは、アーキテクチャインスタンスのRTL実装のシミュレーションに対して、このゴールデンリファレンスの実行を比較するために生成される。フレームワークはまた、解析性能モデル及びサイクルが正確なソフトウェアシミュレータに対して、RTLシミュレーションを比較することにより、性能検証を実行する。それは、ランタイムの内訳を報告し、性能に影響を与える設計のボトルネックを特定する。
疎データセットの計算−ほとんどの値がゼロであるベクトル又は行列−は、ますます増加する数の商業的に重要なアプリケーションにとって重大であるが、典型的には、今日のCPU上で実行した場合、ピークパフォーマンスのわずか数パーセントしか実現していない。科学コンピューティング分野において、疎行列計算は、数十年間、線形ソルバの重要なカーネルであった。近年では、機械学習及びグラフ分析の爆発的な成長が疎計算を主流へと移動させてきた。疎行列計算は、多くの機械学習アプリケーションの中核をなし、多くのグラフアルゴリズムのコアを形成する。
疎行列計算は、計算上制限されるよりもむしろメモリ帯域幅上制限される傾向があり、それが、CPUの変更によってこれらの性能を向上させることを困難にしている。それらは、行列データ要素毎に演算をほとんど実行しておらず、多くの場合、任意のデータを再利用する前に行列全体にわたって反復するため、キャッシュを役立たせていない。さらに、多くの疎行列アルゴリズムは、かなりの数のデータに依存したギャザー及びスキャッタ、例えば、疎行列−ベクトル乗算において得られる、result[row]+=matrix[row][i].value*vector[matrix[row][i].index]演算、を含み、それらは、プリフェッチャの有効性を予測し低減することが難しい。
従来のマイクロプロセッサより良好な疎行列の性能を実現させるためには、システムは、現在のCPUよりもかなり高いメモリ帯域幅及び非常にエネルギー効率の良いコンピューティングアーキテクチャを提供しなければならない。メモリ帯域幅を増加させることで、性能を向上させることができるが、DRAMアクセスの高いエネルギー/ビットコストが、その帯域幅を処理するために利用可能な電力量を制限する。エネルギー効率の良い計算アーキテクチャなしでは、システムは、そのパワーバジェットを超えることなく、高帯域幅のメモリシステムからのデータを処理することができない状況に置かれるかもしれない。
一実施例では、スタック型DRAMを用いて、エネルギー効率の良い方式でその帯域幅を処理するために、疎行列アルゴリズムがカスタム計算アーキテクチャと組み合わせられる必要がある帯域幅を提供する疎行列計算のためのアクセラレータを有する。
疎−行列概要
多くのアプリケーションは、値の大部分がゼロであるデータ設定を作成する。有限要素方法は、各ポイントの状態がメッシュ内のそれに近いポイントの状態の関数であるポイントのメッシュとしてオブジェクトをモデル化する。数学的には、これは、各行が1つのポイントの状態を表現し、行が表現するポイントの状態に直接的には影響を与えないポイントのすべてに対して行の値がゼロである行列として表される連立方程式になる。グラフは、隣接行列として表されることができ、行列内の各成分{i,j}は、グラフ内の頂点iとjとの間のエッジについての重みを与える。多くの頂点は、グラフ内の他の頂点のごく一部だけを結びつけるので、隣接行列内の成分の大部分はゼロである。機械学習において、モデルは、典型的には、多くのサンプルからなるデータセットを用いてトレーニングされ、それぞれが、特徴のセット(システム又はオブジェクトの状態についての見解)及びその特徴のセットのモデルについての所望の出力を含む。サンプルの多くで、可能な機能の小さなサブセットだけを含めることはよくあることであり、例えば、機能がドキュメント内に存在し得る様々なワードを表す場合、値のほとんどがゼロであるデータセットを再び作成している。
値のほとんどがゼロであるデータセットは、「疎(sparse)」として説明され、それは、これらの要素のうちの1%より少ない要素においてゼロ以外の値を有する、疎データセットが極めて疎であることはよくあることである。これらのデータセットは、多くの場合、行列として表され、行列内のゼロ以外の成分の値だけを規定するデータ構造を用いる。これは、各ゼロ以外の成分を表すのに必要とされる空間の量を増やす一方で、成分の位置及びその値の両方を規定する必要があるので、行列が十分に疎である場合、全体的な空間(メモリ)の節約はかなりのものとなる。例えば、疎行列の最も単純表現のうちの1つは、調整リスト(COO)表現であり、ゼロ以外のそれぞれは、{行インデックス、列インデックス、値}のタプルにより規定される。これは、ゼロ以外の値ごとに必要とされる記憶量を3倍にする一方、たった1%の行列内の成分がゼロ以外の値を有する場合、COO表現は、密な表現(行列内の各成分の値を表すもの)が取るであろう空間のたった3%しか引き上げない。
図81は、最も一般的な疎行列フォーマット、圧縮行格納(CRS、時には、短縮型CSR)フォーマットの1つを示す。CRSフォーマットにおいて、行列8100は、ゼロ以外の成分の値を含む値配列8101、行列のその行内の各ゼロ以外の成分の位置を規定するインデックスアレイ8102、及び、インデックス及び値のリストにおいて行列の各行が始まる位置を規定する行開始アレイ8103、という3つの配列により表現される。したがって、例示的な行列の第2行の第1のゼロ以外の成分は、インデックス及び値アレイ内の位置2において見つけられることができ、タプル{0,7}で表現されており、成分が行内の位置0に存在し、値7を有することを示す。他の一般に用いられる疎行列フォーマットは、CRSに対してデュアルな列優先である圧縮された疎列(CSC)、及び、行列の各行をゼロ以外の値についての固定幅リスト及びこれらのインデックスとして表し、行列内の最長の行より少ないゼロ以外の成分を行が有する場合、明示的なゼロでパディングするELLPACKを含む。
疎行列の計算は、これらの密行列の対応部分と同じ構造を有するが、疎データの特性は、これらの密行列の対応部分よりも、これらをはるかに多くの帯域幅集約的にする傾向がある。例えば、行列−行列乗算の疎及び密の変形の両方は、すべてのi,jについて、Ci,j=Ai,・B,jを計算することにより、C=A・Bであることが分かる。密行列−行列計算では、Aの各成分は、Bの各要素がそうであるように、N回の積和演算(N×N行列と仮定した場合)に関与するので、これは、かなりのデータ再利用につながる。行列−行列乗算がキャッシュの局所性のためにブロック化される限り、この再利用は、低バイト/opレートを有し、計算上制限された計算(computation)の原因となる。しかしながら、疎な変形では、Aの各成分は、Bの対応する行にあるゼロ以外の値と同じ数の積和演算に関与するのみである一方、Bの各成分は、Aの対応する列にあるゼロ以外の成分と同じ数の積和演算に関与するのみである。バイト/opレートがそうであるように、行列のまびき(sparseness)が向上するにつれて、密行列−行列乗算が基準計算−バウンド計算であるという事実にも関わらず、多くの疎行列−行列計算の性能をメモリ帯域幅により制限させている。
4つの演算は、今日のアプリケーション、すなわち、疎行列−疎ベクトル乗算(SpMV)、疎行列−疎ベクトル乗算、疎行列−疎行列乗算及び緩和/平滑化演算、例えば、高性能な共役勾配基準の実装で用いられるガウス−ザイデルスムーザで見られる疎行列計算のバルクを埋め合わせする。これらの演算は、疎行列アクセラレータを実用的にする2つの特性を共有する。第1に、それらは、ベクトルドット積が大半を占め、4つの重要な計算のすべてを実装できるシンプルなハードウェアを実装することを可能にする。例えば、行列−ベクトル乗算は、ベクトルと行列内の各行とのドット積を取ることにより実行される一方、行列−行列乗算は、一方の行列の各列と他方の行列の各行とのドット積を取る。第2に、アプリケーションは、一般に同じ行列に対して複数の計算、例えば、サポートベクトルマシンアルゴリズムがモデルをトレーニングして実行する、同じ行列の異なるベクトルとの数千回もの乗算を実行する。同じ行列のこの繰り返し使用は、データ転送/変換のコストが各行列に対する多くの演算にわたってならされ得るので、ハードウェアのタスクを簡略化する方式でプログラム実行中にアクセラレータへ/から行列を転送し、及び/又は、行列を再フォーマット化することを実用的にする。
疎行列計算は、典型的には、それらが実行するシステムのピークパフォーマンスのわずか数パーセントしか実現していない。なぜこれが発生するかを明らかにするために、図82は、CRSデータフォーマットを用いた疎行列−密ベクトル乗算の実装に関する段階8201−8204を示す。第1に、8201において、行列の行を表すデータ構造がメモリから読み出され、通常、予測及びプリフェッチすることが容易であるシーケンシャルな読み出しのセットに関する。第2に、8202において、行列の行内のゼロ以外の成分のインデックスは、多数のデータ依存型の予測困難なメモリアクセス(ギャザーオペレーション)を必要とする、ベクトルの対応する成分を収集するために用いられる。さらに、これらのメモリアクセスは、多くの場合、各参照されるキャッシュライン内の1又は2ワードしか触れないので、ベクトルがキャッシュに適合していない場合、かなり多くの無駄な帯域幅をもたらす。
第3に、8203において、プロセッサは、行列の行のゼロ以外の成分及びベクトルの対応する成分のドット積を計算する。最後に、8204において、ドット積の結果が、結果ベクトルに書き込まれ、また、連続的にアクセスされ、プログラムは、行列の次の行に進む。これは、計算の概念的/アルゴリズムの観点であり、プログラムが実行するオペレーションの正確なシーケンスは、プロセッサのISA及びベクトル幅に依存することに留意する。
この例は、疎行列計算の多数の重要な特性を示す。32ビットデータタイプ、及び、行列もベクトルもキャッシュに合致していないと仮定して、出力される行の第1の成分を計算するには、DRAMから36バイトを読み出す必要があるが、7.2:1のバイト/opレートに対して、5つの計算命令(3つが乗算及び2つが加算)だけである。
しかしながら、メモリ帯域幅は、高性能な疎行列計算に対する唯一の課題ではない。図82が示すように、SpMVにおけるベクトルへのアクセスは、データ依存しており、予測が困難であるので、アプリケーションへのベクトルアクセスのレイテンシをさらす。ベクトルがキャッシュに適合しない場合、SpMVの性能は、たとえ、データを待機する多くのスレッドがストールされた場合であっても、DRAM帯域幅を飽和させるのに十分な並列性をプロセッサが提供しない限り、DRAMレイテンシ並びに帯域幅に敏感になる。
したがって、疎行列計算のアーキテクチャは、いくつかの事項を有効にしなければならない。疎計算についてのバイト/opの必要性を満たすように高いメモリ帯域幅を実現させなければならない。また、キャッシュに適合しない可能性がある大きなベクトルからの高帯域幅収集をサポートしなければならない。最後に、DRAM帯域幅に追従するために十分な算術演算/秒を実行することそれ自体が課題ではないとはいえ、アーキテクチャは、システムのパワーバジェット内に維持するために、エネルギー効率の良い方式で、それらのオペレーション及びそれらが必要とするメモリアクセスのすべてを実行しなければならない。
一実施例では、高いメモリ帯域幅、大きなベクトルからの高帯域幅収集及びエネルギー効率の良い計算という、高い疎−行列性能に必要な3つの機能を提供するように設計されたアクセラレータを有する。図83に示されるように、アクセラレータの一実施例は、アクセラレータ論理ダイ8305と、DRAMダイの1又は複数のスタック8301−8304とを含む。以下により詳細に説明されるスタック型DRAMは、低エネルギー/ビットで高いメモリ帯域幅を提供する。例えば、スタック型DRAMは、2.5pJ/bitで256−512GB/秒を実現することが予期され、一方、LPDDR4 DIMMは、たった68GB/秒しか実現しないことが予期され、12pJ/bitのエネルギーコストを有する。
アクセラレータスタックの最下層にあるアクセラレータ論理チップ8305は、疎行列計算の必要性に合わせてカスタマイズされ、DRAMスタック8301−8304により提供される帯域幅を消費することができ、一方、エネルギー消費がスタックの帯域幅に比例するが、2〜4ワットの電力しか費やしていない。本願の残りの部分については、273GB/秒のスタックの帯域幅(WIO3スタックの予期される帯域幅)が想定される。より高い帯域幅のスタックに基づいた設計では、メモリ帯域幅を消費するために、より多くの並列性を組み込むであろう。
図84aは、DRAMダイ8301−8304のスタックを貫通する上部視点から配向されたアクセラレータ論理チップ8305の一実施例を示す。スタックDRAMチャネルブロック8405は、論理チップ8305をDRAM8301−8304に接続するシリコンビアを表す図の中心に向いており、一方、メモリコントローラブロック7410は、DRAMチャネルに対する制御信号を生成する論理を含む。8つのDRAMチャネル8405が図に示される一方、アクセラレータチップに実装されるチャネルの実際の数は、用いられるスタック型DRAMに応じて変化する。開発中のスタックDRAM技術のほとんどは、4つ又は8つのチャネルのいずれか一方を提供する。
ドット積エンジン(DPE)8420は、アーキテクチャの計算要素である。図84a〜図84bに示される特定の実施例において、8つのDPEから成る各セットは、ベクトルキャッシュ8415と関連付けられる。図85は、2つのバッファ8505−8506、2つの64ビット積和演算ALU8510及び制御論理8500を含DPEの大まかな概観図を提供する。計算中、チップ制御ユニット8500は、処理されるデータのチャンクをバッファメモリ8505−8506へとストリームする。一旦、各バッファが満杯になると、DPEの制御論理がバッファを通じて順序付けられ、それらが含むベクトルのドット積を計算し、その結果をDPEの結果ラッチ8512に書き込み、他のDPEの結果ラッチと共にデイジーチェーンに接続され、計算の結果をスタックDRAM8301−8304に書き戻す。
一実施例において、アクセラレータ論理チップは、(特定の動作周波数及び電圧が異なるアプリケーションに対して修正され得るが)電力消費を最小化するために、約1GHz及び0.65Vで動作する。14nm設計研究に基づいた解析では、32〜64KBのバッファがその電圧でこの周波数スペックを満たしていることを示しているが、弱いエラーを防止するためには強いECCが必要とされ得る。積和演算ユニットは、0.65Vの供給電圧及び浅いパイプラインでのタイミングを満たすために、基本クロックレートの半分で動作され得る。2つのALUを用いて、DPE毎に1つの倍精度の積和演算/サイクルのスループットを提供する。
273GB/秒及び1.066MHzのクロックレートで、DRAMスタック8301−8304は、論理チップのクロックサイクルあたり256バイトのデータを供給する。アレイインデックス及び値が、少なくとも32ビットの量であると仮定すると、これは、1サイクルあたり32個の疎行列成分(インデックスの4バイト+値の4バイト=8バイト/成分)に変換し、チップが、追従するために1サイクルあたり32個の積和演算を実行することを要求する。(これは、行列−ベクトル乗算に対するものであり、100%のスタックDRAM帯域幅が行列をフェッチするために用いられるようなベクトルキャッシュ内の高いヒット率を前提としている)。図84a及び図84bに示される64個のDPEは、2−4xの必要な計算スループットを提供し、たとえ、ALU8510が100%の時間用いられていないとしても、チップが、ピークスタックDRAM帯域幅で処理データすることを可能にする。
一実施例において、ベクトルキャッシュ8415は、行列−ベクトル乗算内のベクトルの成分をキャッシュする。これは、以下で説明される行列−ブロッキングスキームの効率性を著しく向上させる。一実施例において、各ベクトルキャッシュブロックは、8つのチャネルアーキテクチャにおいて、256〜512KBの総容量に対して、キャッシュの32〜64KBを含む。
チップ制御ユニット8401は、計算のフローを管理し、アクセラレータ内の他のスタック及びシステム内の他のソケットとの通信を処理する。複雑性及び電力消費を低減するために、ドット積エンジンが、メモリからデータを要求することは決してない。代わりに、チップ制御ユニット8401は、メモリシステムを管理し、データの適切なブロックをDPEのそれぞれにプッシュする転送を開始する。
一実施例において、マルチスタックアクセラレータ内のスタックは、図に示される隣接接続8431を用いて実装されるKTIリンク8430のネットワークを介して互いに通信する。チップはまた、マルチソケットシステム内の他のソケットと通信するために用いられる3つの追加のKTIリンクを提供する。マルチスタックアクセラレータにおいて、スタックのオフパッケージKTIリンク8430のうちの1つだけがアクティブにされる。他のスタック上のメモリをターゲットとするKTIトランザクションは、オンパッケージKTIネットワークを介して適切なスタックに転送される。
アクセラレータの一実施例についての疎行列−密ベクトル及び疎行列−疎ベクトル乗算を実装する技術及びハードウェアがここで説明される。これはまた、疎行列演算をサポートするアクセラレータを作成するために、行列−行列乗算、緩和演算及び他の機能をサポートするために拡張されることもできる。
疎−疎及び疎−密行列−ベクトル乗算が、(行列及びベクトル内の各行のドット積を取る)同じ基本アルゴリズムを実行する一方、ベクトルが密である場合と比較して、それが疎である場合に、どのようにこのアルゴリズムが実装されるかについて著しい差があり、それは、以下のテーブルに要約されている。
疎行列−密ベクトル乗算において、ベクトルのサイズは固定され、行列内の列の数に等しい。科学技術計算で得られる行列の多くが、1行あたりおよそ10個の非ゼロ要素が平均であるので、疎行列−密ベクトル乗算内のベクトルが行列自体の5〜10%の空間を占めることは珍しくない。一方で、疎ベクトルは、多くの場合、かなり短く、行列の行に同様の数のゼロ以外の値を含んでおり、これらをンチップメモリ内にかなりキャッシュしやすくする。
疎行列−密ベクトル乗算において、ベクトル内の各成分の位置は、そのインデックスにより判断され、それが行列の領域内のゼロ以外の値に対応するベクトル成分を収集し、行列が乗算される任意の密ベクトルに対して収集される必要があるベクトル成分のセットを予め計算することを実現可能にする。しかしながら、疎ベクトル内の各成分の位置は、予測不可能であり、ベクトル内のゼロ以外の成分の分散に依存する。これは、どの行列内のゼロ以外がベクトル内のゼロ以外の値に対応するかを判断するために、疎ベクトル及び行列の非ゼロ成分を検査する必要がある。
疎行列−疎ベクトルのドット積を計算するために必要とされる命令/処理の数は、予測不可能であり、行列及びベクトルの構造に依存するので、行列及びベクトル内のゼロ以外の成分をインデックスと比較するのに役立つ。例えば、単一のゼロ以外の成分を有する行列の行と多くのゼロ以外の成分を有するベクトルとのドット積を取ることを検討する。行のゼロ以外の値が、ベクトル内のゼロ以外の値のいずれよりも低いインデックスを有する場合、ドット積は、1つのインデックス比較のみを必要とする。行のゼロ以外の値がベクトル内のゼロ以外の値のいずれより高いインデックスを有する場合、ドット積を計算することは、行のゼロ以外の値のインデックスとベクトル内の各インデックスとを比較する必要がある。これは、ベクトルを通じた線形探索を前提としており、一般的なやり方である。バイナリ探索など、他の探索は、最悪の場合においてより高速であろう。しかしながら、行及びベクトル内のゼロ以外の値が重複するよくある例において、著しいオーバヘッドを追加することになるであろう。一方、疎行列−密ベクトル乗算を実行するために必要とされるオペレーションの数が固定され、行列内のゼロ以外の値の数により判断されるので、計算に必要とされる時間を予測し易くする。
これらの違いに起因して、アクセラレータの一実施例では、疎行列−密ベクトル及び疎行列−疎ベクトル乗算を実施するために同じ高水準なアルゴリズムを用いており、ベクトルがドット積エンジンにわたってどのように分配されるかについて、及び、ドット積がどのように計算についての差を有する。アクセラレータは、大きな疎行列計算を対象としているので、行列又はベクトルのいずれか一方がオンチップメモリに合致することができないと仮定される。代わりに、一実施例では、図86に概説されるブロッキングスキームを用いる。
特に、この実施例において、アクセラレータは、オンチップメモリに合致するようなサイズであり、データ8601−8602の固定サイズのブロックに行列を分割し、次のブロックに進む前に、出力ベクトルのチャンクを生成するために、ベクトルによりブロック内の行を乗算する。このアプローチは2つの課題をもたらす。第1に、疎行列の各行における非ゼロの数は、調査対象のデータセットの低くて1から高くても46000まで、データセット間で広く変化する。これは、1又は固定数の行を各ドット積エンジンに割り当てることを非実用的にしている。故に、一実施例では、行列データの固定サイズのチャンクを各ドット積エンジンに割り当て、チャンクが複数の行列の行を含む場合及び単一の行が複数のチャンクにわたって分割される場合に処理する。
第2の課題は、行列のブロックごとにスタックDRAMからベクトル全体をフェッチすると、大量の帯域幅を無駄にする可能性があるということである(すなわち、ブロック内に対応する非ゼロがないベクトル成分をフェッチする)。これは、特に、疎行列−密ベクトル乗算に対する問題点であり、ベクトルは、疎行列のかなりの部分を占め得る。これに対処するために、一実施例は、行列内のブロック8601−8602ごとにフェッチリスト8611−8612を構成し、ブロック内のゼロ以外の値に対応するベクトル8610の成分のセットを列挙し、ブロックを処理する場合にそれらの成分をフェッチするだけである。フェッチリストはまた、スタックDRAMからフェッチされなければない一方、ほとんどのブロックに対するフェッチリストがブロックのごく一部を占めると判断されている。ランレングス符号化などの技術は、フェッチリストのサイズを低減するために用いられてもよい。
したがって、アクセラレータ上の行列−ベクトル乗算は、オペレーションの以下のシーケンスに関する。
1.DRAMスタックから行列データのブロックをフェッチし、それをドット積エンジンにわたって分散する。
2.行列データ内のゼロ以外の成分に基づいてフェッチリストを生成する。
3.スタックDRAMからフェッチリスト内の各ベクトル成分をフェッチし、それをドット積エンジンに分散する。
4.ベクトルを有するブロック内の行のドット積を計算し、スタックDRAMに結果を書き込む。
5.計算と並列して、行列データの次のブロックをフェッチし、行列全体が処理されるまで繰り返す。
アクセラレータが複数のスタックを含む場合、行列の「区分」は、異なるスタックに静的に割り当てられてよく、次に、ブロックアルゴリズムは、各区分に対して並列実行されてよい。このブロック及びブロードキャストスキームは、メモリ参照のすべてが中央制御装置から由来する利点を有しており、ネットワークは、予測不可能な要求及びドット積エンジンとメモリコントローラとの間の応答を転送する必要がないので、オンチップネットワークの設計を大幅に簡略化する。また、個別のドット積エンジンに、それらが計算のこれらの部分を実行する必要があるベクトル成分に対してメモリ要求を発行させることとは対照的に、所与のブロックが必要とするベクトル成分ごとに1つのメモリ要求のみを発行することによりエネルギーを節約する。最後に、インデックスの体系化されたリストからベクトル成分をフェッチすることは、それらがスタック型DRAMにおけるページヒット、ひいては、帯域幅の利用を最大化する方式で要求をフェッチするメモリ要求をスケジューリングし易くする。
本明細書で説明されるアクセラレータの実装で疎行列−密ベクトル乗算を実施する場合の1つの課題は、各ドット積エンジンのバッファにおいて行列成分のインデックスにメモリからストリーミングされるベクトル成分をマッチングさせることである。一実施例において、ベクトルの256バイト(32〜64成分)は、1サイクル毎にドット積エンジンに到達し、行列データの固定サイズのブロックが、各ドット積エンジンの行列バッファにフェッチされているので、各ベクトル成分は、ドット積エンジンの行列バッファ内の非ゼロのうちのいずれかに対応し得る。
サイクルごとにそのほとんどの比較を実行することは、エリア及び電力において非常に高価であろう。代わりに、一実施例では、図87に示されるフォーマットを用いて、多くの疎行列アプリケーションが、同じ又は異なるベクトルのいずれか一方により同じ行列を繰り返し乗算し、各ドット積エンジンが行列のそのチャンクを処理する必要があるフェッチリストの要素を予め計算するという事実を利用する。ベースラインCRSフォーマットにおいて、行列は、その行内の各ゼロ以外の値の位置を定義するインデックス8702のアレイにより説明され、アレイは、各ゼロ以外の値8703及び各行が、インデックス及び値配列において開始する場所を示すアレイ8701を含む。そのために、一実施例では、各ドット積エンジンが全体的な計算のその一部を実行するためにキャプチャするのに必要なベクトルデータのバーストがどれかを識別するブロック記述子8705のアレイを加える。
図87に示されるように、各ブロック記述子は、8つの16ビット値及びバースト記述子のリストからなる。最初の16ビット値は、どれくらいの数バースト記述子がブロック記述子にあるかをハードウェアに示し、一方、残りの7つは、最初のものを除くスタックDRAMデータチャネルのすべてに対するバースト記述子のリスト内の開始ポイントを識別する。これらの値の数は、スタック型DRAMが提供するデータチャネルの数に応じて変更する。各バースト記述子は、注意を払う必要があるデータのバーストがどれかをハードウェアに示す24ビットのバーストカウント、及び、ドット処理エンジンが必要とする値を含むバースト内のワードを識別する「必要とされるワード」ビットベクトルを含む。
一実施例に含まれる他のデータ構造は、行列バッファインデックス(MBI)8704のアレイであり、行列内のゼロ以外毎に1つのMBIである。各MBIは、ゼロ以外に対応する密ベクトル成分が関連するドット積エンジンのベクトル値バッファに格納される位置を与える(例えば、図89を参照)。疎行列−密ベクトル乗算を実行する場合、元の行列インデックスではなくむしろ行列バッファインデックスは、ドット積エンジンの行列インデックスバッファ8704にロードされ、ドット積を計算する場合の対応するベクトル値を検索するために用いられるアドレスの代わりになる。
図88は、1つのスタック型DRAMデータチャネル及び4ワードデータバーストのみを有するシステムにおいて、単一のドット積エンジンのバッファ内に合致する2行行列に対してこれがどのように作用するかを示す。行開始値8801、行列インデックス8802及び行列値8803を含む元のCRS表現が図の左側に示される。2行は、列{2,5,6}及び{2,4,5}内のゼロ以外の成分を有するので、ベクトルの成分2、4、5及び6がドット積を計算するために必要とされる。ブロック記述子は、これを反映し、第1の4ワードバーストのうちのワード2(ベクトルの成分2)及び第2の4ワードバーストのうちのワード0、1及び2(ベクトルの成分4−6)が必要とされることを示す。ベクトルの成分2は、ドット積エンジンが必要とするベクトルの第1のワードであるので、ベクトル値バッファ内の位置0に入る。ベクトルの成分4は、位置1などに入る。
行列バッファインデックスアレイデータ8804は、ハードウェアが、行列内の非ゼロに対応する値を見つけたベクトル値バッファ内の位置を保持する。行列インデックスアレイ内の第1のエントリは、値「2」を有するので、行列バッファインデックスアレイ内の第1のエントリは、ベクトルの成分2がベクトル値バッファに格納される位置に対応する値「0」を取得する。同様に、「4」が行列インデックスアレイに現れるときはいつでも、「1」が行列バッファインデックスに現れ、行列インデックスアレイ内の各「5」は、行列バッファインデックス内で対応する「2」を有し、行列インデックスアレイ内の各「6」は、行列バッファインデックス内の「3」に対応する。
本発明の一実施例は、行列がアクセラレータ上いロードされる場合、密ベクトルからの高速収集をサポートするのに必要な事前計算を実行し、マルチスタックアクセラレータの総帯域幅は、CPUからアクセラレータにデータを転送するために用いられるKTIリンクの帯域幅よりはるかに大きいという事実を利用する。この事前計算された情報は、同じ行列インデックスの複数のコピーがドット積エンジン上にマッピングされる行列のチャンク内でどれくらい発生するかに応じて、最大で75%まで行列を保持するために必要とされるメモリの量を向上させる。しかしながら、16ビットの行列バッファインデックスアレイは、行列−ベクトル乗算が実行される場合、行列インデックスアレイの代わりにフェッチされるので、スタックDRAMからフェッチされるデータ量は、多くの場合、特に、64ビットインデックスを用いる行列に関して、元のCRS表現より少ない。
図89は、このフォーマットを用いるドット積エンジン内のハードウェアの一実施例を示す。行列−ベクトル乗算を実行するために、ブロックを作成する行列のチャンクは、行列インデックスバッファ8903及び行列値バッファ8905にコピーされ(元の行列インデックスの代わりに行列バッファインデックスをコピーし)関連するブロック記述子は、ブロック記述子バッファ8902にコピーされる。次に、フェッチリストは、密ベクトルから必要な要素をロードして、これらをドット積エンジンにブロードキャストするために用いられる。各ドット積エンジンは、各データチャネルを過ぎるベクトルデータのバーストの数をカウントする。所与のデータチャネルのカウントが、バースト記述子において特定される値と一致する場合、マッチ論理8920は、特定されたワードをキャプチャして、これらをそのベクトル値バッファ8904に格納する。
図90は、このキャプチャを行うマッチ論理8920ユニットの内容を示す。ラッチ9005は、カウンタがバースト記述子内の値と一致する場合、データチャネルのワイヤ上の値をキャプチャする。シフタ9006は、バースト9001から必要なワード9002を抽出し、これらを、サイズがベクトル値バッファ内の行とマッチするラインバッファ9007内の適切な位置に転送する。バーストカウント9001が内部カウンタ9004に等しい場合、ロード信号が生成される。ラインバッファが満杯になった場合、(mux9008を通じて)ベクトル値バッファ8904に格納される。このように複数のバーストからラインにワードアセンブルすることで、ベクトル値バッファがサポートする必要がある書き込み/サイクルの数を低減し、そのサイズを低減する。
一旦、ベクトルの必要な成分のすべてが、ベクトル値バッファ内にキャプチャされると、ドット積エンジンは、ALU8910を用いて必要なドット積を計算する。制御論理8901は、サイクル毎に1成分の順番で行列インデックスバッファ8903及び行列値バッファ8904を通る。行列インデックスバッファ8903の出力は、次のサイクルでベクトル値バッファ8904に対する読み出しアドレスとして用いられ、一方、行列値バッファ8904の出力は、ベクトル値バッファ8904から対応する値と同時にALU8910に到達するようにラッチされる。例えば、図88からの行列を用いて、ドット積計算の第1のサイクルにおいて、ハードウェアは、行列値バッファ8905から値「13」と共に行列インデックスバッファ8903から行列バッファインデックス「0」を読み出すであろう。第2のサイクルにおいて、行列インデックスバッファ8903からの値「0」は、ベクトル値バッファ8904に対するアドレスとしての機能を果たし、ベクトル成分「2」の値をフェッチし、次に、サイクル3において「13」を乗算する。
行開始ビットベクトル8901内の値は、いつ行列の行を終了して新しい行が開始するかをハードウェアに示す。ハードウェアが行の終了に到達した場合、その出力ラッチ8911に、行に対して累算されたドット積を配置し、次の行に対するドット積を累算することを開始する。各ドット積エンジンのドット積ラッチは、ライトバックのために出力ベクトルをアセンブルするデイジーチェーンに接続される。
疎行列−疎ベクトル乗算において、ベクトルは、疎行列−密ベクトル乗算におけるものよりもはるかに少ないメモリを占有する傾向があるが、それが疎であるので、所与のインデックスに対応するベクトル成分を直接フェッチすることはできない。代わりに、ベクトルは、検索されなければならず、各ドット積エンジンが必要とする成分のみをドット積エンジンに転送することは実用的ではなく、各ドット積エンジンに割り当てられる行列データのドット積を計算するために必要とされる時間を予測不可能にする。これに起因して、疎行列−疎ベクトル乗算のためのフェッチリストは、行列ブロック内の最低及び最大のゼロ以外の成分のインデックスを規定するだけであり、それらのポイント間のベクトルのゼロ以外の成分のすべてがドット積エンジンにブロードキャストされなければならない。
図91は、疎行列−疎ベクトル乗算をサポートするドット積エンジン設計の詳細を示す。行列データのブロックを処理するために、インデックス(疎−密乗算に用いられる行列バッファインデックスではない)及び行列のドット積エンジンのチャンクの値は、行列インデックス及び値バッファに書き込まれ、ブロックを処理するために必要なベクトルの領域のインデックス及び値である。次に、ドット積エンジン制御論理9140は、インデックスバッファ9102−9103を通じて順序付けし、4×4コンパレータ9120に4つのインデックスのブロックを出力する。4×4コンパレータ9120は、ベクトル9102からのインデックスのそれぞれを、行列9103からのインデックスのそれぞれと比較し、任意の一致したバッファアドレスをマッチしたインデックスキュー9130に出力する。マッチしたインデックスキュー9130の出力は、行列値バッファ9105及びベクトル値バッファ9104の読み出しアドレス入力を駆動し、その一致に対応する値を積和演算ALU9110に出力する。このハードウェアは、マッチしたインデックスキュー9130が空きスペースを有する限り、少なくとも4つで、1サイクルあたり8つのインデックスをドット積エンジンが消費することを可能にし、インデックスのマッチングがまれである場合に、データのブロックを処理するために必要とされる時間を低減する。
疎行列−密ベクトルドット積エンジンと同様に、行開始9101のビットベクトルは、行列の新たな行を開始する行列バッファ9102−9103内のエントリを識別する。そのようなエントリが遭遇された場合、制御論理9140は、ベクトルインデックスバッファ9102の先頭にリセットし、これらの最低値からベクトルインデックスを検査することを開始することで、行列インデックスバッファ9103の出力とこれらを比較する。同様に、ベクトルの最後に到達した場合、制御論理9140は、行列インデックスバッファ9103内の次の行の先頭に進み、ベクトルインデックスバッファ9102の先頭にリセットする。「行われた」出力は、ドット積エンジンがデータのブロック又はベクトルの領域の処理を終了したときにチップ制御ユニットに知らせ、次のものに進む準備をする。アクセラレータの一実施例を簡略化するために、制御論理9140は、ドット積エンジンのすべてが処理を終了するまで、次のブロック/領域に進まない。
多くの場合、ベクトルバッファは、ブロックを処理するために必要とされる疎ベクトルのすべてを保持するのに十分な大きさである。一実施例において、1024個又は2048個のベクトル成分に対するバッファ空間が、32が用いられるか、又は、64ビット値が用いられるかに応じて提供される。
ベクトルの必要な要素がベクトルバッファに適合しない場合、マルチパスアプローチが用いられてよい。制御論理9140は、ベクトルの完全なバッファを各ドット積エンジンにブロードキャストし、その行列バッファ内の行を通じて反復することを開始する。行の最後に到達する前に、ドット積エンジンがベクトルバッファの最後に到達した場合、ベクトルの次の領域が到達したときの行を処理することを再開しなければならない場所を示すべく、現在の行位置のビットベクトル9111にビットを設定し、行の開始が、ここまで処理されてきたベクトルインデックスのいずれより高いインデックス値を有する限り、行の開始に対応する行列値バッファ9105の位置において累算された部分的なドット積を保存し、次の行に進む。行列バッファ内の行のすべてが処理された後に、ドット積エンジンは、ベクトルの次の領域を要求するためにその終了した信号をアサートし、ベクトル全体が読み出されるまで処理を繰り返す。
図92は、特定の値を用いる例を示す。計算の開始時に、行列の4つの成分のチャンクは、行列バッファ9103、9105に書き込まれ、ベクトルの4つの成分の領域は、ベクトルバッファ9102、9104に書き込まれている。行開始9101及び現在の行の位置ビット−ベクトル9106の両方は、「1010の値」を有し、行列のドット積エンジンチャンクが2つの行、行列バッファ内の第1の成分において開始するもののうちの1つ、及び、第3の成分で開始するもののうちの1つを含むことを示す。
第1の領域が処理される場合、チャンク内の第1行は、インデックス3におけるインデックスのマッチングを参照し、行列及びベクトルバッファの対応する要素の積(4×1=4)を計算し、行の開始に対応する行列値バッファ9105の位置にその値を書き込む。第2行は、インデックス1における1つのインデックスのマッチングを参照し、ベクトル及び行列の対応する成分の積を計算し、その開始に対応する位置における行列値バッファ9105に結果(6)を書き込む。現在の行位置のビットベクトルの状態は、各行の第1の成分が処理されており、計算が第2の成分を用いて再開すべきであることを示す「0101」に変更する。次に、ドット積エンジンは、その終了ラインをアサートして、ベクトルの別の領域に対する準備が整ったことをシグナリングする。
ドット積エンジンがベクトルの第2の領域を処理する場合、それは、行1がインデックス4におけるインデックスのマッチングを有することを参照し、行列及びベクトルの対応する値の積(5×2=10)を計算し、その値を、第1のベクトル領域が処理された後に保存されている部分的なドット積に加算し、その結果(14)を出力する。図に示されるように、第2行は、インデックス7における一致を見つけて、結果38を出力する。このように、部分的なドット積及び計算の状態を保存することで、部分的な積に対する大量の追加のストレージを要求することなく、(ベクトルが、昇順でインデックスを用いてソートされているので)ベクトルの後の領域においてインデックスを一致させることができない可能性がある行列の冗長的な作業処理要素を回避する。
図93は、両方のタイプの計算を処理できるドット積エンジンを生じさせるために、上記で説明された疎−密及び疎−疎ドット積エンジンがどのように組み合わせられるかを示す。2つの設計間で類似点を考慮すると、唯一の必要な変更は、疎−密ドット積エンジンのマッチ論理9311及び疎−疎ドット積エンジンのコンパレータ9320の両方と、マッチしたインデックスキュー9330とを、どのモジュールが読み出しアドレスを駆動し、バッファ9104−9105、及び、行列値バッファの出力又は行列値バッファのラッチされた出力が積和演算ALU9110に送信されるかを選択するマルチプレクサ9351のデータ入力を書き込むかを判断するマルチプレクサ9350のセットと共にインスタンス化することである。一実施例において、これらのマルチプレクサは、行列−ベクトル乗算の開始時に設定される制御ユニット9140内の構成ビットにより制御され、オペレーション全体を通じて同じ構成に維持される。
単一のアクセラレータスタックは、疎行列演算上のサーバCPUに相当する性能を実現させており、スマートフォン、タブレット及び他のモバイルデバイスに対してアクセラレータに魅力的にする。例えば、1又は複数のサーバ上でモデルをトレーニングし、次に、到着したデータストリームを処理するために、モバイルデバイス上にそれらのモデルを展開する機械学習アプリケーションに関する多数の提案がある。モデルは、これらをトレーニングするために用いられるデータセットよりはるかに小さい傾向があるので、単一のアクセラレータスタックの制限された容量は、これらのアプリケーションにおいてそれほど制限されることはなく、一方、アクセラレータの性能及び電力効率は、モバイルデバイスが、これらプライマリCPU上で実現可能なものよりもはるかに複雑なモデルを処理することを可能する。非モバイルシステムに対するアクセラレータは、極めて高帯域幅かつ高性能を実現させるべく、複数のスタックを組み合わせる。
マルチスタック実装についての2つの実施例が図94a及び図94bに示される。これらの実施例の両方では、現代のサーバCPUとのピン互換性のあるパッケージ上にいくつかのアクセラレータスタックを統合する。図94aは、12個のアクセラレータスタック9401−9412とのソケット交換の実装を示し、図94bは、プロセッサ/コアのセット9430(例えば、低コアカウントXeon)及び8つのスタック9421−9424を用いたマルチチップパッケージ(MCP)の実装を示す。図94a内の12個のアクセラレータスタックは、現在のパッケージで用いられる39mm×39mmのヒートスプレッダの条件下で合致するアレイに置かれ、一方、図94bにおける実施例では、同じフットプリント内で8つのスタック及びプロセッサ/コアのセットを組み込む。一実施例において、スタックに用いられる物理的な次元は、8GB WIO3スタック用の次元である。他のDRAM技術は、異なる次元を有してよく、パッケージに合致するスタックの数を変更してよい。
これらの実装の両方は、CPUとアクセラレータとの間のKTIリンクを介した低レイテンシなメモリベースの通信を提供する。Xeon実装に関するソケット交換設計は、マルチソケットシステム内のCPUの1又は複数を置換え、96GBの容量及び3.2TB/sのスタックDRAM帯域幅を提供する。予期される電力消費は90Wであり、Xeonソケットのパワーバジェットの範囲内である。MCPのアプローチは、64GBの容量及び2.2TB/sの帯域幅を提供する一方、アクセラレータにおいて、60Wの電力を消費する。これにより、中規模のXeon CPUをサポートするのに十分な、1ソケットあたり150Wのパワーバジェットを想定すると、CPUに対して90Wが残る。詳細なパッケージ設計が、パッケージ内により多くの論理用空間を可能にする場合、追加のスタック又はより多くの強力なCPUが用いられ得るが、これは、ソケットのパワーバジェット内に総電力消費を保持するために、Xeon+FPGAのハイブリッド部分に関して研究されているコアパーキング技術などのメカニズムを必要とするであろう。
これらの設計の両方は、シリコンインターポーザ又は他の精巧な統合技術を必要とすることなく実装され得る。現在のパッケージで用いられている有機基板は、ダイの周囲の1cmあたりおよそ300個の信号を許容し、中間スタックKTIネットワーク及びオフパッケージKTIリンクをサポートするのに十分である。スタック型DRAM設計は、冷却が問題になるまえに、〜10Wの電力を消費する論理チップを典型的にはサポートでき、これは、256GB/秒の帯域幅のを提供するスタックに対する2Wの論理ダイ電力の推定を十分に超える。最後に、マルチチップパッケージは、現在の設計と整合する配線用のチップ間に1〜2mmの空間を必要とする。
実施例では、PCIeカード上に、及び/又は、DDR4−Tベースのアクセラレータを用いて実装されてもよい。PCIeカードに対して300Wの電力制限は、320GBの総容量及び11TB/秒の帯域幅に対して40個のアクセラレータスタックをカードがサポートすることを可能にすることを想定している。しかしながら、PCIeチャネルのレイテンシが長く帯域幅が制限されているということが、PCIeベースのアクセラレータを、CPUとの頻繁でないインタラクションでしか必要としないという大きな問題に制限する。
代替的に、アクセラレータスタックは、図95に示されるように、DDR−T DIMMベースのアクセラレータ9501−9516を実装するために用いられ得る。DDR−Tは、DDR4ソケット及びマザーボードとの互換性を有するように設計されたメモリンタフェースである。DDR4と同じピン配列及びコネクタフォーマットを用いて、DDR−Tは、異なるタイミング特性を有するメモリデバイスの使用を可能にするトランザクションベースのインタフェース9500を提供する。この実施例において、アクセラレータスタック9501−9516は、計算を実行するために用いられていない場合にシンプルなメモリとして動作する。
126〜256GBのメモリ容量及び4〜8TB/秒の総帯域幅を考慮して、カードの両面が用いられる場合、DDR−T DIMMは、16個のアクセラレータスタック又は32個のアクセラレータスタックにとって十分な空間を提供する。しかしながら、そのようなシステムは、DDR4−DIMMにより消費される〜10Wよりはるかに多い120〜240ワットの電力を消費するであろう。これは、マザーボード上のDIMMごとに割り当てられる制限された空間に合致させることを困難にするアクティブな冷却を必要とするであろう。さらに、DDR−Tベースのアクセラレータは、ユーザが、アクセラレーション用の任意のCPU性能を諦めようとせず、ファン又は他の冷却システムに関するアクセラレータDIMM間に十分な空間を含めるカスタムマザーボード設計のコストを進んで払うアプリケーションにとっては魅力的であり得る。
一実施例において、マルチスタックアクセラレータ内のスタックは、別個のKTIノードに分けられ、システムソフトウェアにより別々のデバイスとして管理される。システムファームウェアは、存在するアクセラレータスタックの数に基づいて、ブート時間において静的にマルチスタックアクセラレータ内のルーティングテーブルを判断しており、トポロジを一意に判断すべきである。
一実施例において、アクセラレータに対する低レベルインタフェースは、ソケットベースのアクセラレータに関するその適切性に起因して、アクセラレータ抽象化層(AAL)ソフトウェアを用いて実装される。アクセラレータは、コアキャッシュインタフェース仕様(CCI)により説明されるようなキャッシングエージェントを実装してよく、ホストシステムによりアクセス可能でないアクセラレータ(すなわち、キャッシングエージェント+プライベートキャッシュメモリ構成、例えば、CA+PCM)に対するプライベート(非コヒーレントな)メモリとしてのスタック型DRAMを処理する。CCI仕様は、アクセラレータを制御するドライバにより用いられるアクセラレータごとに別々のコンフィグ/ステータスレジスタ(CSR)アドレス空間を義務付けている。その仕様に従って、各アクセラレータは、デバイスステータスメモリ(DSM)を介してホストにそのステータスを通信し、ピニングされたメモリ領域は、アクセラレータのステータスを示すために用いられるホストメモリにマッピングされている。したがって、12スタックシステムにおいて、単一の統合されたドライバエージェントにより管理される12個の別個のDSM領域がある。これらのメカニズムは、スタックごとにコマンドバッファを作成するために用いられてよい。コマンドバッファは、システムメモリにマッピングされたピニングされたメモリ領域であり、AALドライバにより管理される循環キューとして実装される。ドライバは、各スタックのコマンドバッファにコマンドを書き込み、各スタックは、その専用のコマンドバッファからアイテムを消費する。したがって、コマンドの生産及び消費は、この実施例においてデカップリングされる。
例として、ホストCPUに接続される単一のアクセラレータスタックから構成されるシステムを考慮する。ユーザは、コードを書き込んで以下の計算を実行する。wn+1=wn−αAwn。Aは行列であり、wxはベクトルである。ソフトウェアフレームワーク及びAALドライバは、このコードを以下のシーケンスコマンドにデコンポーズする。
TRANSMIT−一連の区分(wn+1、wn、α、A)をプライベートキャッシュメモリにロードする。
MULTIPLY−一連の区分(tmp=wn×α×A)を乗算する。
SUBTRACT−一連の区分(wn+1=wn−tmp)をサブミットする。
RECEIVE−結果(wn+1)を含むホストメモリに一連の区分を格納する。
これらのコマンドは、ホスト又はプライベートキャッシュメモリのいずれか一方に配置される「区分」、データの粗粒度(およそ16MB〜512MB)単位で演算を行う。区分は、MapReduce又はSpark分散コンピューティングシステムが、アクセラレータを用いて分散された計算の加速を容易にするために用いるデータのブロック上に容易にマッピングすることを目的としている。AALドライバは、ホストメモリ領域又はアクセラレータスタックに対する区分についての静的な1対1のマッピングを作成する役割を担う。アクセラレータスタックは、それぞれ個々に、これらのプライベートキャッシュメモリ(PCM)アドレス空間に対して、これら割り当てられた区分をマッピングする。区分は、一意的な識別子である区分インデックス、さらに(ホストメモリに配置された区分に対して)対応するメモリ領域及びデータフォーマットにより表現される。PCM内に配置された区分は、中央制御装置により管理され、区分に対するPCMアドレス領域を判断する。
一実施例において、アクセラレータのPCMを初期化するために、ホストは、ホストメモリからデータをロードするようアクセラレータに指示する。TRANSMITオペレーションは、アクセラレータにホストメモリを読み出させて、読み出したデータをアクセラレータのPCMに格納させる。送信されるデータは、一連の{区分インデックス、ホストメモリ領域、データフォーマット}のタプルにより説明される。データのオーバヘッドがホストドライバによりまとめられることを回避するために、アクセラレータは、システムプロトコル2(SPL2)共有仮想メモリ(SVM)を実装してよい。
各タプルにおけるデータフォーマットは、メモリ内の区分のレイアウトを表現する。アクセラレータがサポートするフォーマットの例は、圧縮された疎行(CSR)及び多次元密アレイである。上記の例に関して、Aは、CSRフォーマットにあってよく、他方、wnはアレイフォーマットにあってよい。コマンドの仕様は、PCMにTRANSMITオペレーションにより参照される区分をすべてロードするようアクセラレータに指示するために必要な情報及びホストメモリアドレスを含む。
各オペレーションは、一連の区分の形式で少数のオペランドを参照してよい。例えば、乗算演算は、アクセラレータに、スタック型DRAMを読み出させ、行列−ベクトル乗算を実行させる。故に、この例では、4つのオペランド、すなわち、宛先ベクトルtmp、乗算器A、被乗数wn及びスカラαを有する。宛先ベクトルtmpは、オペレーションを含むコマンドの一部として、ドライバにより特定される一連の区分に累算される。コマンドは、必要な場合、一連の区分を初期化するようアクセラレータに指示する。
RECEIVEオペレーションは、アクセラレータに、PCMを読み出させ、ホストメモリを書き込ませる。このオペレーションは、すべての他のオペレーション上の選択的なフィールドとして実装されてよく、ホストメモリに結果を格納する指示を用いてMULTIPLYなどの演算を実行するようにコマンドを潜在的に融合する。RECEIVEオペレーションの宛先オペランドは、オンチップに累算され、次に、ホストメモリ内の区分にストリーミングされ、(アクセラレータがSPL2 SVMを実装しない限り)コマンドのディスパッチの前に、ドライバによりピニングされなければならない。
コマンドのディスパッチフロー
一実施例において、スタック用のコマンドバッファにコマンドを挿入した後に、ドライバは、消費される新たなコマンドをスタックに通知するために、CSR書き込みを生成する。ドライバによるCSR書き込みは、アクセラレータスタックの中央制御装置により消費され、スタックに対してドライバによりディスパッチされたコマンドを読み出すために、コマンドバッファに対する一連の読み出しを制御ユニットに生成させる。アクセラレータスタックがコマンドを完了した場合、ステータスビットをそのDSMに書き込む。AALドライバは、コマンドの完了を判断するために、これらのステータスビットをポーリング又はモニタリングのいずれか一方を行う。DSMへのTRANSMIT又はMULTPLYオペレーションに関する出力は、完了を示すステータスビットである。RECEIVEオペレーションに関して、DSMへの出力は、ホストメモリに書き込まれるステータスビット及び一連の区分である。ドライバは、アクセラレータにより書き込まれるメモリの領域を識別する役割を担う。スタック上の制御ユニットは、スタック型DRAMへの一連の読み出し処理及びホストメモリ内の宛先の区分への対応する書き込みを生成する役割を担う。
ソフトウェアイネーブル
一実施例において、ユーザは、ルーチンのライブラリを呼び出して、データをアクセラレータ上に移動し、疎行列計算を実行するなどを行うことにより、アクセラレータとインタラクトする。このライブラリに対するAPIは、既存のアプリケーションを修正して、アクセラレータを利用するために必要とされる労力を低減するために、既存の疎行列ライブラリと可能な限り同様であり得る。ライブラリベースのインタフェースの別の利点は、アクセラレータ及びそのデータフォーマットの詳細を隠すことであり、プログラムが、ランタイムでライブラリの訂正バージョンを動的に連結することにより異なる実装を利用することを可能にする。ライブラリは、Sparkのような分散コンピューティング環境からアクセラレータを呼び出すために実装されてもよい。
アクセラレータスタックのエリア及び電力消費は、モジュール(メモリ、ALUなど)に設計を分割すること、及び、同様の構造の14nm設計からデータを収集するにより推定されてよい。10nmプロセスにスケールするために、50%のエリアの削減が、25%のCdynの削減及び20%の漏れ電力の削減と共に想定され得る。エリアは、すべてのオンチップメモリ及びALUを含むと推定する。ワイヤが、論理/メモリ上を走るものと仮定する。電力推定は、ALU及びメモリに対するアクティブなエネルギー、メモリに対する漏れ電力、我々の主要なネットワーク所のワイヤ電力を含む。1GHzのベースクロックレートが想定されていて、14nm及び10nmプロセスの両方において、0.65Vの供給電圧であった。上記ですでに述べたように、ALUは、基本クロックレートの半分で実行してよく、これは、電力予測において考慮されるものとする。KTIリンク及び中間スタックネットワークは、アクセラレータが計算を実行している場合にアイドル又はほぼアイドルであると予測されるので、電力推定に含まれていない。一実施例では、これらのネットワークでのアクティビティを追跡し、これらを電力推定に含める。
当該推定は、本明細書で説明されるようなアクセラレータが、14nmプロセスにおけるチップ面積の17mm2及び10nmプロセスにおける8.5mm2を占有すると予測し、チップ面積の大部分がメモリにより占有されている。図96は、64個のドット積エンジン8420、8個のベクトルキャッシュ8415及び統合メモリコントローラ8410を含むWIO3 DRAMスタックの下に位置することを目的とするアクセラレータの潜在的なレイアウトを示す。示されるDRAMスタックI/Oバンプ9601、9602のサイズ及び配置は、WIO3標準により規定されており、アクセラレータ論理は、これらの間の空間に合致する。しかしながら、アセンブリを簡単にするために、DRAMスタックの下方の論理ダイは、少なくともDRAMダイとほぼ同じ大きさとすべきである。故に、実際のアクセラレータチップは、およそ8mm〜10mmであるが、エリアのほとんどが未使用であろう。一実施例において、この未使用のエリアは、帯域幅が制限されたアプリケーションの異なるタイプに関するアクセラレータに用いられ得る。
スタック型DRAMは、その名称が示唆するように、より高い帯域幅、計算ダイとのより密接な物理的統合、DDR4 DIMMなどの従来のDRAMモジュールより低いエネルギー/ビットを実現させるために、複数のDRAMダイを鉛直にスタックするメモリ技術である。図97におけるテーブルでは、7つのDRAM技術、すなわち、非スタック型DDR4及びLPDDR4、ピコモジュール、JEDEC標準の高帯域幅(HBM2)及びワイドI/O(WIO3)スタック、スタック型DRAM、並びに、崩壊型RAM(dis−integrated RAM、DiRAM)を比較する。
スタック型DRAMは、2種類の形式、すなわち、オンダイ及び横側ダイがある。オンダイスタック8301−8304は、図98aに示されるように、スルーシリコンビアを用いて、論理ダイ又はSoC8305に直接的に接続する。一方、横側ダイスタック8301−8304は、図98bに示されるように、シリコンインターポーザ又はブリッジ9802上の論理/SoCダイ8305の横に置かれており、インターポーザ9802及びインタフェース層9801を通じて走るDRAMと論理ダイとの間の接続を有する。オンダイDRAMスタックは、それらが横側ダイスタックより小さいパッケージを可能にするという利点を有するが、1より多くのスタックを論理ダイに取り付けることが難しく、それらがダイ毎に提供できるメモリの量を制限するという短所を有する。一方、シリコンインターポーザ9802の使用は、論理ダイが、エリア内によってはいくらかのコストはあるが、複数の横側ダイスタックと通信することを可能にする。
DRAMについての2つの重要な特性は、それらがパッケージに合致する帯域幅及びその帯域幅を消費するために必要とされる電力を定義するといったような、1スタックあたりの帯域幅及び1ビットあたりのエネルギーである。ピコモジュールだと、十分な帯域幅を提供せず、HBM2のエネルギー/ビットが電力消費を著しく上昇させるので、これらの特性は、WIO3、ITRI及びDiRAMを、本明細書で説明されるようなアクセラレータに対して最も期待できる技術にする。
それら3つの技術について、DiRAMは、最も高い帯域幅及び容量並びに最も低いレイテンシを有しているので、非常に魅力的である。WIO3は、JEDEC標準になることが想定されるさらなる別の有望なオプションであり、良好な帯域幅及び容量を提供する。ITRIメモリは、3つのうちで最も低いエネルギー/ビットを有しており、より多くの帯域幅が所与のパワーバジェットに合致することを可能にする。それはまた、レイテンシが低く、そのSRAMのようなインタフェースは、アクセラレータのメモリコントローラについての複雑性を低減するであろう。しかしながら、ITRI RAMは、3つのうちで最も容量が小さく、その設計は、性能に関して容量とトレードオフになる。
本明細書で説明されるアクセラレータは、コア疎行列ベクトル乗算(SpMV)プリミティブ上に構築されるデータ解析及び機械学習アルゴリズムに取り組むために設計される。SpMVは、多くの場合、これらのアルゴリズムのランタイムを支配する一方、他のオペレーションは、同様にこれらを実装するために必要とされる。
例として、図99に示される幅優先探索(BFS)のリストを検討する。この例では、ワークのバルクがライン4上のSpMVにより実行されている。しかしながら、ベクトル−ベクトル減算(ライン8)、内積演算(ライン9)及びデータ並列マップオペレーション(ライン6)もある。ベクトルの減算及び内積は、ベクトルISAにおいて一般にサポートされている比較的単純な演算であり、説明をほとんど必要としない。
一方、データ並列マップオペレーションは、プログラミング性を概念的に要素単位のオペレーションに導入するので、はるかに興味深いものである。BFSの例は、一実施例のマッピング機能により提供されるプログラミング性を明らかにする。特に、BFSにおけるラムダ関数(図99のライン6を参照)は、頂点が最初にアクセスされていたときのトラックを保持するために用いられる。これは、ラムダ関数に2つのアレイ及び1つのスカラを渡すことにより一実施例において行われる。ラムダ関数に渡される第1のアレイは、SpMV演算の出力であり、どの頂点が現在到達可能であるかを反映する。第2のアレイは、値が、頂点が最初に見られた反復数である、又は、頂点がまだ到達していない場合は0である頂点ごとにエントリを有する。ラムダ関数に渡されるスカラは、単純なループ反復カウンタである。一実施例において、ラムダ関数は、出力ベクトルを生成するために入力ベクトルの各成分に対して実行される一連のスカラ演算にコンパイルされる。
BFSに関する一連のオペレーションの中間表現(IR)が図99に示される。BFSラムダIRは、いくつかの興味深い特性を明らかにする。生成されたラムダコードは、単一の基本ブロックのみを有することが保証されている。一実施例では、ラムダ関数における反復的な構築を防止し、制御フローを回避するためにif変換(if-conversion)を実行する。この制約は、一般的な制御フローをサポートする必要はなので、ラムダを実行するために用いられる計算構造の複雑性を著しく低減させる。
すべてのメモリオペレーションは、基本ブロックの開始(図99のライン2から4)で実行される。アセンブリに変換された場合、メモリオペレーションは、コードレット(codelet)のプリアンブル(ライン2から5)に引き上げられる(hoisted)。
統計値の評価は、ラムダ関数を使用するアクセラレータと共に実装されるベンチマークに関して実行されていた。命令の数が記録されており、レジスタの総数及び関心のある様々なラムダ関数の「複雑性」を定量化するロードの総数であった。さらに、クリティカルパス長は、各ラムダ関数における従属命令の最も長いチェーンを反映する。命令の数が、クリティカルパスよりも著しく長い場合、命令−レベル並列性技術は、性能を向上させるために適用可能な解決手段である。いくつかのロードは、マッピングの所与の呼び出し又は低減コールに関して不変である(ラムダ関数のすべての実行が同じ値をロードする)。この状況は、「ラムダ不変ロード」と称され、それを検出するために解析が実行される。
解析結果に基づいて、比較的少ない命令格納は、ラムダ関数の実行をサポートするレジスタファイルを必要とする。並行処理(複数のラムダ関数の実行をインタリーブする)を向上させる技術は、レジスタファイルのサイズ及び複雑性を改善する。しかしながら、ベースライン設計は、わずか16エントリであり得る。さらに、比較及び条件移動オペレーションで使用するために単一ビット述語レジスタファイルも提供されている場合、2R1Wレジスタファイルは、すべてのオペレーションに対して十分なはずである。
以下で説明されるように、ラムダ不変ロードは、ギャザーエンジンにおいて実行され、その結果、それらは、ラムダ関数を呼び出す毎に一度実行されるだけである。これらのロードにより返される値は、それらが、必要に応じてラムダデータパスのローカルレジスタファイルに読み出され得るように処理要素に渡される。
一実施例において、ラムダ関数の実行は、各ユニットの異なる機能を活用するために、ギャザーエンジンとプロセッサ要素(PE)(例えば、上記で説明されたようなドット積エンジン)との間で分割される。ラムダ関数は、3つのタイプの引数、すなわち、定数、スカラ及びベクトルを有する。定数は、値がコンパイル時に判断され得る引数である。スカラ変数は、上記で説明されたラムダ不変ロードに対応し、ラムダ関数の呼び出し間で値が変化する引数であるが、所与のラムダ関数が動作する要素のすべてにわたって定数を維持する。ベクトル引数は、ラムダ関数が処理するデータのアレイであり、当該関数における命令をベクトル引数内の各要素に適用する。
一実施例において、ラムダ関数は、当該関数を実装するコード、当該関数が参照する任意の定数、及び、その入出力変数に対するポインタを含む記述子データ構造により規定される。ラムダ関数を実行するために、最上位のコントローラは、ラムダ関数の記述子と、ギャザーエンジン及びその関連するPEが処理するためのものである関数のベクトル引数の一部の開始及び終了インデックスとを規定する1又は複数のギャザーエンジンにコマンドを送信する。
ギャザーエンジンがコマンドを受信してラムダ関数を実行する場合、記述子の最後のセクションに到達するまで、メモリから関数の記述子をフェッチして、当該関数のスカラ変数のアドレスを含む当該記述子をその関連するPEに渡す。次に、メモリから関数のスカラ変数のそれぞれをフェッチして、記述子内の各引数のアドレスをその値と置換え、修正した記述子をPEに渡す。
PEが、そのギャザーエンジンから関数記述子の開始を受信した場合、それは、関数のベクトル入力のアドレスを制御レジスタにコピーし、PEのフェッチハードウェアは、PEのローカルバッファにベクトル入力のページをロードすることを開始する。次に、ラムダ関数を実装する命令のそれぞれをデコードし、その結果を、小型のデコードされた命令バッファに格納する。次に、PEは、関数のスカラ変数の値がそのギャザーエンジンから到着するのを待ち、関数のベクトル引数のそれぞれの第1のページが、メモリから到着するのを待つ。関数の引数が到着すると、PEは、入力ベクトルのその範囲内の各成分にラムダ関数を適用することを開始し、PEのフェッチ及びライトバックハードウェアに依存して、入力データのページをフェッチし、必要に応じて、出力値のページをライトバックする。PEが、データの割り当てられる範囲の最後に達した場合、それが行われる最上位のコントローラをシグナリングし、別の処理を開始する準備を行う。
図100は、一実施例に従うラムダ関数を規定するために用いられる記述子のフォーマットを示す。特に、図100は、メモリ10001内のラムダ記述子フォーマットと、PE10002に渡されるラムダフォーマット記述子とを示す。命令を除く記述子内のすべてのフィールドは、64ビット値である。命令は、32ビット値であり、2つが64ビットワードにパックされる。記述子は、スカラ変数が最後に現れるように体系化され、ギャザーエンジンがメモリからスカラ変数をフェッチする前に、それがPEにスカラ変数以外のすべてを渡すことを可能にする。これは、PEが関数の命令をデコードし、そのベクトル引数をフェッチすることを開始することを可能にする一方、スカラ変数をフェッチするためにギャザーエンジンを待機させる。ラムダ関数の記述子及びスカラ変数は、ラムダ関数が複数のギャザーエンジン/PEペアにわたって分散されている場合、冗長化DRAMアクセスを除去するために、ベクトルキャッシュを通じてフェッチされる。図示されるように、メモリ10001内のラムダ記述子フォーマットは、スカラ変数10003に対するポインタを含み得る一方、ギャザーエンジンは、PE10002に渡されるときに、ラムダ記述子フォーマット内のスカラ変数10004の値をフェッチする。
一実施例において、各記述子の第1のワードは、記述子内の各ワードの意味を規定するヘッダである。図101に示されるように、ヘッダワードの下位6バイトは、ラムダ関数10101に対するベクトル引数の数、定数引数10102の数、ベクトル及びスカラ出力10103−10104の数、関数内の命令10105の数、及び、関数におけるスカラ変数10106の数を規定する(各タイプのデータが記述子に現れる場所を一致させるためにオーダリングされる)。ヘッダワードの第7バイトは、関数のコード内のループ開始命令10107(例えば、ハードウェアが、第1のバイトの後の各反復を開始すべき命令)の位置を規定する。ワード内の高次のバイトは未使用10108である。残りのワードは、図に示される順序で、関数命令、定数及び入出力アドレスを含む。
すべての必要なオペレーションが制御論理を修正することによりサポートされ得るので、ラムダ関数をサポートするために必要されるギャザーエンジンデータパスに対する変更がない。ギャザーエンジンがメモリからラムダ記述子をフェッチした場合、それは、ベクトル成分ラインバッファ及び列記述子バッファの両方に記述子のラインをコピーする。スカラ変数のアドレスを含まない記述子ラインは、未変更のPEに渡される一方、それらは、スカラ変数の値がメモリからフェッチされて、これらのアドレスの配置にあるラインバッファに挿入されるまで、ラインバッファ内に実行する維持する既存の収集及び未応答バッファハードウェアは、変更することなくこのオペレーションをサポートできる。
ラムダ関数をサポートするために処理要素に対する変更
一実施例において、ラムダ関数をサポートするために、図102に示されるように、別々のデータパスがPEに追加され、上記で説明される行列値バッファ9105、行列インデックスバッファ9103及びベクトル値バッファ9104を示す。PEのバッファは同じものを維持しつつ、これらの名称は、現在の実装におけるこれらのより一般的な使用を反映するために、入力バッファ1、入力バッファ2及び入力バッファ3に変更されている。SpMVデータパス9110も、ベースアーキテクチャから変更されないままである。ラムダ関数としてSpMVを実装することが可能であろうが、専用のハードウェア10201を構築することで、電力を低減し、SpMVの性能を向上させる。SpMVデータパス9110及びラムダデータパス10201からの結果は、出力バッファ10202に、及び最終的にシステムメモリに送信される。
図103は、ラムダデータパスの一実施例の詳細を示し、述語レジスタファイル10301、レジスタファイル10302、デコード論理10303、デコードされた命令バッファ10305を含み、ロード・ストアISAを実装するインオーダ実行パイプライン10304を中心に展開する。単一の発行実行パイプラインが十分な性能を提供することができない場合、1つは、ラムダオペレーションに固有のデータ並列性を利用して、実行パイプラインをベクトル化して並列に複数のベクトル成分を処理してよく、それは、個別のラムダ関数におけるILPを活用するよりも、並列性を改善するよりエネルギー効率の良い方式とするべきである。実行パイプラインは、1レジスタあたり64ビットを有する16〜32エントリレジスタファイル10302からその入力を読み出し、16〜32エントリレジスタファイル10302に結果を書き戻す。ハードウェアは、整数及び浮動小数点レジスタを区別しておらず、任意のレジスタが任意のタイプのデータを保持してよい。述語レジスタファイル10301は、比較オペレーションの出力を保持しており、それは述語命令実行に用いられる。一実施例において、ラムダデータパス10304は、分岐命令をサポートしていないので、任意の条件実行が述語命令を通じて行われなければならない。
各ラムダ関数の開始時に、ギャザーエンジンは、関数の命令を入力バッファ3 9104(ベクトル値バッファ)に配置する。次に、デコード論理10303は、順次、各命令をデコードし、その結果を32エントリデコードされた命令バッファ10305に配置する。これは、ループ1のすべての反復に対する各命令を繰り返しデコーディングするエネルギーコストを節約する。
ラムダデータパスは、4つの特別な制御レジスタ10306を含む。インデックスカウンタレジスタは、ラムダデータパスが現在処理しているベクトル成分のインデックスを保持し、ラムダの各反復の終了時に自動的にインクリメントされる。最後のインデックスレジスタは、PEが処理するはずの最後のベクトル成分のインデックスを保持する。ループ開始レジスタは、ラムダ関数の繰り返される部分において第1の命令のデコードされた命令バッファ内の位置を保持する一方、ループ終了レジスタは、ラムダ関数内の最後の命令の位置を保持する。
ラムダ関数の実行は、デコードされた命令バッファ内の第1の命令と共に開始し、パイプラインが、ループ終了レジスタにより指し示される命令に到達するまで進める。そのポイントにおいて、パイプラインは、インデックスカウンタレジスタの値を、最後のインデックスレジスタの値と比較し、インデックスカウンタが最後のインデックスより小さい場合、ループ開始レジスタにより指し示される命令に暗黙的な分岐を戻す。インデックスカウンタレジスタが、各反復の終了時にインクリメントされるだけなので、このチェックは、パイプライン内のバブルを回避するために予め行うことができる。
このスキームは、ラムダ関数の第1の反復においてのみ実行される必要がある「プリアンブル」命令を簡単に含めることができる。例えば、2つのスカラ及び1つの定数入力を有するラムダ関数は、3つのロード命令を用いて開始して、それらの入力の値をレジスタファイルにフェッチし、入力が、関数の各反復におけるよりもむしろ、1回が読み出されるのみとなるように、ループ開始レジスタを設定して、デコードされた命令バッファ内の第4の命令を指し示す。
一実施例において、ラムダデータパスは、多くのRISCプロセッサと同様にロード・ストアISAを実行する。ラムダデータパスのロード及びストア命令は、PEのSRAMバッファ内の位置を参照する。SRAMバッファとDRAMとの間のデータのすべての転送は、PEのフェッチ及びライトバックハードウェアにより管理されている。ラムダデータパスは、2つのタイプのロード命令、すなわち、スカラ及び成分をサポートする。スカラロードは、SRAMバッファのうちの1つにおいて特定された位置のコンテンツをフェッチし、それをレジスタ内に配置する。ラムダ関数内のスカラロード命令のほとんどは、関数のプリアンブルにおいて発生するが、レジスタプレッシャは、ループ本体に置かれるスカラロードを時々必要するかもしれない。
成分ロードは、ラムダ関数の入力ベクトルの成分をフェッチする。PEは、そのバッファにマッピングされる第1の入力ベクトルの現在の成分を指し示すバッファごとに計算ポインタを保持する。成分ロードは、計算ポインタからターゲットバッファ及びオフセットを特定する。成分命令が実行される場合、ハードウェアは、特定したオフセットを、適切なバッファのサイズを法とする(modulo)計算ポインタの値に加算し、レジスタ内のその位置からデータをロードする。成分ストア命令は、同様であるが、PE出力バッファ10202内の適切なアドレスにデータを書き込む。
このアプローチは、PEの既存のフェッチハードウェアと共にサポートされる複数の入出力ベクトルを可能にする。入力ベクトルは、ラムダ関数の記述子により特定される順序で、入力バッファ1 9105及び2 9103を交互に行い、フェッチハードウェアは、同時にバッファ内の各ベクトルのページ全体を読み出す。
例として、3つの入力ベクトル、A、B、及びCを有する関数を検討する。入力ベクトルAは、0のオフセットにおいて、PEの入力バッファ1 9105上にマッピングされる。入力Bは、再び0のオフセットにおいて、入力バッファ2 9103上にマッピングされる。入力Cは、256のオフセットにおいて、入力バッファ1 9105上にマッピングされる(Tezzaronスタイルの256バイトのページを想定する)。PEのフェッチハードウェアは、入力A及びCのページを入力バッファ1 9105にインタリーブする一方、入力バッファ2 9103は、入力Bのページで満たされている。ラムダ関数の各反復は、0のオフセットを有するバッファ1 9105から成分ロードを実行することにより、入力Aの適切な成分をフェッチし、0のオフセットを有するバッファ2 9103から成分ロードを有する入力Bの適切な成分をフェッチし、256のオフセットを有するバッファ1 9105から成分ロードを有する入力Cのその成分をフェッチする。各反復の終了時に、ハードウェアは、計算ポインタをインクリメントして、各入力ベクトルの次の成分に進む。計算ポインタが、ページの終了に到達した場合、ハードウェアは、(ページサイズ×(−1上にマッピングされたベクトル入力の#))バイトによりそれをインクリメントして、バッファの第1の入力ベクトルの次のページの第1の成分にそれを進める。同様のスキームが、複数の出力ベクトルを生成するラムダ関数を処理するために用いられる。
図104に示されるように、一実施例において、8ビットは、オペコード10401に専用である。残りの24ビットは、6ビットのレジスタ指示子を結果としてもたらす単一の宛先10402及び3つの入力オペランド10403−10405間で分割される。制御フロー命令は、一実施例において用いられておらず、定数は、補助レジスタファイルから供給され、ビット割り当てアクロバティクスは、命令ワード内の大きな即値に合致させる必要はない。一実施例において、すべての命令は、図104に存在する命令エンコーディングに合致する。ある特定の命令のセットに対するエンコーディングは、図105に示される。
一実施例において、比較命令は、比較述語を用いる。例示的な比較述語のエンコーディングは、図106のテーブルに列挙されている。
詳細に上述されたように、いくつかの例において、所与のタスクに対してアクセラレータを使用することが有利である。しかしながら、実現可能でない及び/又は有利でないインスタンスがあり得る。例えば、利用可能でないアクセラレータ、不利益が大き過ぎるアクセラレータへのデータの異同、アクセラレータの速度がプロセッサコアより遅いなどでる。その結果、いくつかの実施例では、追加の命令が、いくつかのタスクに対する性能及び/又はエネルギー効率性を提供し得る。
行列の乗算の例が図109に示される。行列の乗算は、C[rowsA,colsB]+=A[rowsA,comm]×B[comm,colsB]である。MADD(積和演算命令)に関して本明細書で用いられるように、行列×ベクトル乗算命令は、colsB=1を設定することにより規定される。この命令は、行列入力A、ベクトル入力B及びベクトル出力Cを取る。512ビットベクトルのコンテキストにおいて、倍精度についてrowsA=8であり、単精度について16である。
多くのCPUは、1次元ベクトルに対して演算を行うSIMD命令を介して密行列乗算を実行する。本明細書における詳細では、サイズ8×4、8×8及びそれらより大きい2次元行列(タイル)を含むようにSIMDアプローチを拡張する命令(及び基礎となるハードウェア)である。この命令の使用を通じて、小さな行列が、ベクトルと、宛先ベクトルに追加された結果と共に乗算され得る。すべての演算は、1つの命令で実行されるので、多数の積和演算を介して命令及びデータをフェッチするエネルギーコストをならす。さらに、いくつかの実施例では、2分木を利用して総和(削減)を実行する、及び/又は、レジスタの集合として、入力行列を保持する乗算器アレイに組み込まれるレジスタファイルを含む。
行列の乗算に関して、MADD命令の実施形態の実行では、
(i=0;i<N;i++)ついて//rowsA(例えば、8)のN=8のパックドデータ要素サイズ(例えば、ベクトル長)
(k=0;k<M;k++)について、//comm=M
C[i]+=A[i,k]×B[k]
を計算する。
典型的には、「A」オペランドは、8つのパックドデータレジスタに格納される。「B」オペランドは、1つのパックドデータレジスタに格納されてよい、又は、メモリから読み出されてよい。「C」オペランドは、1つのパックドデータレジスタに格納される。
この命令についての残りの考察を通じて、「octoMADD」バージョンが説明される。このバージョンは、8つのパックドデータ要素のソース(例えば、8つのパックドデータレジスタ)にパックドデータ要素のソース(例えば、単一のレジスタ)を掛ける。内側ループを拡張することにより、シーケンシャルな実装に関して(octoMADD命令に関して)以下のような実行を提供する。
(i=0;i<8;i++)について、C[i]+=A[i,0]×B[0]+
A[i,1]×B[1]+
A[i,2]×B[2]+
A[i,3]×B[3]+
A[i,4]×B[4]+
A[i,5]×B[5]+
A[i,6]×B[6]+
A[i,7]×B[7]。
示されるように、「A」及び「B」オペランドの対応するパックドデータ要素位置からのパックドデータ要素の各乗算の後に続いて加算がある。シーケンシャルな加算は、最小の一時なストレージを用いて複数のより簡単なオペレーションに分解される。
いくつかの実施例では、2分木アプローチが用いられる。2分木は、並列に2つのサブツリーを合計して、次に、結果をまとめて加算することにより、レイテンシを最小化する。これは、2分木全体に再帰的に適用される。最終結果は、「C」宛先オペランドに追加される。
内側ループを拡張することにより、バイナリ実装に関して(octoMADD命令に関して)以下のような実行を提供する。
(i=0;i<8;i++)について、
C[i]+=((A[i,0]×B[0]+A[i,1]×B[1])+
(A[i,2]×B[2]+A[i,3]×B[3]))+
((A[i,4]×B[4]+A[i,5]×B[5])+
(A[i,6]×B[6]+A[i,7]×B[7]))。
図110は、2分木低減ネットワークを用いたoctoMADD命令処理を示す。図は、オペレーションの1つのベクトルレーンを示す。512ビットベクトルを用いて、倍精度のoctoMADDは、8つのレーンを有する一方、単精度のoctoMADDは、16個のレーンを有する。
図示されるように、複数の乗算回路11001−11015は、A[i,0]×B[0]、A[i,1]×B[1]、A[i,2]×B[2]、A[i,3]×B[3]、A[i,4]×B[4]、A[i,5]×B[5]、A[i,6]×B[6]及びA[i,7]×B[7]のそれぞれについての乗算を実行する。この例において、iはAレジスタである。典型的には、乗算は、並列で実行される。
乗算回路11001−11015に結合される加算回路11017−11023は、乗算回路11001−11015の結果を加算する。例えば、加算回路は、A[i,0]×B[0]+A[i,1]×B[1]、A[i,2]×B[2]+A[i,3]×B[3]、A[i,4]×B[4]+A[i,5]×B[5]、及び、A[i,6]×B[6]+A[i,7]×B[7]を実行する。典型的には、総和は、並列で実行される。
最初の総和の結果は、加算回路11025を用いて合計され、まとめて加算される。この加算の結果は、宛先に格納される新たな値11033を生成するために、宛先から元の(古い)値11031に、加算回路11027により加算される。
ほとんどの実施例では、命令は、8つの独立したソースレジスタに加え、他のソース及びレジスタの宛先に対するレジスタ又はメモリオペランドを規定することができない。したがって、いくつかの例では、octoMADD命令は、行列オペランドに対して8つのレジスタの制限された範囲を規定する。例えば、octoMADD行列オペランドは、レジスタ0−7であってよい。いくつかの実施形態において、第1のレジスタが規定され、第1のレジスタに連続したレジスタは、追加の(例えば、7つの)レジスタである。
図111は、積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
11101において、命令がフェッチされる。例えば、積和演算命令がフェッチされる。積和演算命令は、オペコード、第1のパックドデータオペランド(メモリ又はレジスタのいずれか一方)のためのフィールド、第2から第Nのパックドデータソースオペランドのための1又は複数のフィールド、及び、パックドデータ宛先オペランドを含む。いくつかの実施形態において、積和演算命令は、書き込みマスクオペランドを含む。いくつかの実施形態において、命令は、命令キャッシュからフェッチされる。
11103において、フェッチされた命令がデコードされる。例えば、フェッチされた積和演算命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
11105において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。一連の積和演算命令を実行する場合に、メインレジスタファイルから繰り返しこれらの値を読み出す必要性を回避するために、(以下に詳細に説明されるように)これらのレジスタのコピーが、乗算器−加算器のアレイ自体に構築される。当該コピーは、メインレジスタファイルのキャッシュとして維持される。
11107において、デコードされた命令は、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、2)一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)宛先の対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納する、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。Nは、典型的には、オペコード又はプレフィックスにより示される。例えば、octoMADDについて、Nは9(Aに対して8つのレジスタがあるような)である。乗算は、並列で実行されてよい。
いくつかの実施形態では、11109において、命令がコミット又はリタイアされる。
図112は、積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
11201において、命令がフェッチされる。例えば、積和演算命令がフェッチされる。融合積和演算命令は、オペコード、第1のパックドデータオペランド(メモリ又はレジスタのいずれか一方)のためのフィールド、第2から第Nのパックドデータソースオペランドのための1又は複数のフィールド、及び、パックドデータ宛先オペランドを含む。いくつかの実施形態において、融合積和演算命令は、書き込みマスクオペランドを含む。いくつかの実施形態において、命令は、命令キャッシュからフェッチされる。
11203において、フェッチされた命令がデコードされる。例えば、フェッチされた積和演算命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
11205において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。一連の積和演算命令を実行する場合に、メインレジスタファイルから繰り返しこれらの値を読み出す必要性を回避するために、(以下に詳細に説明されるように)これらのレジスタのコピーが、乗算器−加算器のアレイ自体に構築される。当該コピーは、メインレジスタファイルのキャッシュとして維持される。
11207において、デコードされた命令は、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、そのソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、2)対で一時的な結果を合計し、3)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に一時的な結果の合計を加え、4)宛先の対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納する、本明細書で詳細に説明されるような実行回路(ハードウェア)により実行される。Nは、典型的には、オペコード又はプレフィックスにより示される。例えば、octoMADDについて、Nは9(Aに対して8つのレジスタがあるような)である。乗算は、並列で実行されてよい。
いくつかの実施形態では、11209において、命令がコミット又はリタイアされる。
いくつかの実施例において、MADD命令がまず遭遇された場合、リネーマは、マイクロオペレーションを注入して、メインレジスタをキャッシュにコピーすることにより、キャッシュされたコピーをメインレジスタファイルと同期させる。後続のMADD命令は、それらが変更されないままである限り、キャッシュされたコピーを使用し続ける。いくつかの実施例では、octoMADD命令により、レジスタの制限された範囲の使用を予期し、レジスタ値が生成されるときに、メインレジスタファイル及びキャッシュされたコピーの両方に書き込みをブロードキャストする。
図113(A)〜図113(C)は、MADD命令を実行するための例示的なハードウェアを示す。図113(A)は、MADD命令を実行するコンポーネントを示す。図113(B)は、これらのコンポーネントのサブセットを示す。特に、複数の乗算回路11323は、ソースレジスタのパックドデータ要素を、加算回路11327に結合される各乗算回路11323と乗算するために用いられる。各加算回路は、チェーン様式で加算回路11327に供給する。セレクタ11321は、外部入力又は加算回路のフィードバックを選択するために用いられる。レジスタファイルは、レジスタファイルの一部として複数の加算器アレイ内に組み込まれ、マルチプレクサ11325を読み出す。特定のレジスタが、積和演算器の各列に有線で接続される。
図113(B)は、レジスタファイルを示し、マルチプレクサ11325を読み出す。レジスタファイル11327は、キャッシュとしてAを格納する複数のレジスタ(例えば、4つ又は8つのレジスタ)である。訂正されたレジスタは、読み出しmux11329を用いて選択される。
octoMADD命令の予期される使用は、以下のとおりである。
//C+=A×Bを計算する
//Aは、REG0−7における8×8タイルとしてロードされる
//Bは、メモリから1×8タイルとしてロードされる
//Cは、REG8−31における24×8タイルとしてロード及び格納される
for (outer loop) {
load [24,8] tile of C matrix into REG 8-31 // 24 loads
for (middle loop) {
load [8,8] tile of A matrix into REG 0-7 // 8 loads
for (inner loop) {
// 24 iterations
REG [8-31 from inner loop] += REG 0-7 * memory[inner loop];
// 1 load
}
}
store [24,8] tile of C matrix from REG8-31 // 24 stores
}
内側ループは、24個のoctoMADD命令を含む。それぞれは、メモリから1つの「B」オペランドを読み出して、24個の「C」アキュムレータのうちの1つに合計する。中間ループは、新たなタイルを有する8つの「A」レジスタをロードする。外側ループは、24個の「C」アキュムレータをロード及びストアする。内側ループは、octoMADDハードウェアの高利用率(>90%)を実現するために、展開されて、プリフェッチを追加する。
以下の図は、上記の実施形態を実施するための例示的なアーキテクチャ及びシステムを詳細に説明する。特に、上述したコアタイプ(例えば、アウトオブオーダ、スカラ、SIMD)の態様(例えば、レジスタ、パイプラインなど)が説明される。さらに、コプロセッサ(例えば、アクセラレータ、コア)を含むシステム及びチップ上のシステム実装が示される。いくつかの実施形態において、上記で説明された1又は複数のハードウェアコンポーネント及び/又は命令は、以下で詳細に説明されるようにエミュレートされ、ソフトウェアモジュールとして実装される。
例示的なレジスタアーキテクチャ
図125は、本発明の一実施形態に係るレジスタアーキテクチャ12500のブロック図である。図示される実施形態において、512ビット幅である32個のベクトルレジスタ12510があり、これらのレジスタは、zmm0からzmm31として参照される。下位16zmmレジスタの下位256ビットは、レジスタymm0〜16上にオーバーレイされる。下位16zmmレジスタの下位128ビット(ymmレジスタの下位128ビット)は、レジスタxmm0〜15上にオーバーレイされる。特定のベクトルに適した命令フォーマットQAC00は、以下のテーブルに示されるように、これらのオーバーレイされたレジスタファイル上で動作する。
つまり、ベクトル長フィールドQAB59Bは、最大の長さ及び1又は複数の他のより短い長さから選択し、それぞれのそのようなより短い長さは、先行する長の半分の長さであり、ベクトル長フィールドQAB59Bなしで命令テンプレートは、最大ベクトル長で動作する。さらに、一実施形態において、特定のベクトルに適した命令フォーマットQAC00のクラスB命令テンプレートは、パックド又はスカラ単一/倍精度の浮動小数点データ、及び、パックド又はスカラ整数データで動作する。スカラ演算は、zmm/ymm/xmmレジスタ内の最下位のデータ要素位置で実行されるオペレーションである。上位のデータ要素位置は、それらが命令前と同じままであるか、実施形態に応じてゼロにされるかのいずれか一方である。
書き込みマスクレジスタ12515−図示された実施形態中では、8個の書き込みマスクレジスタ(k0からk7)が存在し、各々64ビットのサイズである。代替的な実施形態において、書き込みマスクレジスタ12515は、16ビットのサイズである。前述したように、本発明の一実施形態において、ベクトルマスクレジスタk0は、書き込みマスクとして用いられることができない。k0を通常示すであろうエンコーディングが書き込みマスクに用いられる場合、それは、0xFFFFのハードワイヤ型書き込みマスクを選択し、その命令に対する書き込みマスキングを効果的に無効にする。
汎用レジスタ12525−図示される実施形態において、メモリオペランドをアドレス指定する既存のx86アドレッシングモードと共に用いられる16個の64ビット汎用レジスタが存在する。これらのレジスタは、RAX、RBX、RCX、RDX、RBP、RSI、RDI、RSP及びR8からR15という名称により参照される。
MMXパックド整数フラットレジスタファイル12550がエイリアスされる、スカラ浮動小数点スタックレジスタファイル(x87スタック)12545−図示される実施形態では、x87スタックは、x87命令セット拡張を用いて32/64/80ビットの浮動小数点データに対するスカラ浮動小数点演算を実行するために用いられる8要素スタックである。一方、MMXレジスタは、64ビットのパックド整数データに対する演算を実行するために、並びに、MMX及びXMMレジスタ間で実行されるいくつかの演算用にオペランドを保持するために用いられる。
本発明の代替的な実施形態は、より広い又はより狭いレジスタを用いてよい。さらに、本発明の代替的な実施形態は、より多くの、より少ない又は異なるレジスタファイル及びレジスタを用いてよい。
例示的なコアアーキテクチャ、プロセッサ及びコンピュータアーキテクチャ
プロセッサコアは、様々な目的のために、様々な方式で、及び、様々なプロセッサにおいて実装されてよい。例として、そのようなコアの実装は、1)汎用計算を対象とする汎用インオーダコア、2)汎用計算を対象とする高性能汎用アウトオブオーダコア、3)主にグラフィックス及び/又は科学技術(スループット)コンピューティングを対象とする特定用途コアを含んでよい。様々なプロセッサの実装は、1)汎用計算を対象とする1又は複数の汎用インオーダコア、及び/又は、汎用計算を対象とする1又は複数の汎用アウトオブオーダコアを含むCPU、及び、2)主にグラフィックス及び/又は科学技術(スループット)を対象とする1又は複数の特定用途コアを含むコプロセッサを含んでよい。そのような様々なプロセッサは、異なるコンピュータシステムアーキテクチャもたらし、それは、1)CPUとは別々のチップ上のコプロセッサ、2)CPUと同じパッケージ内の別々のダイ上のコプロセッサ、3)CPUと同じダイ上のコプロセッサ(この場合、当該コプロセッサは、統合グラフィックス及び/又は科学技術(スループット)論理などの特定用途論理又は特定用途コアと称されることもある)、及び、4)同じダイ上に、説明されたCPU(アプリケーションコア又はアプリケーションプロセッサと称されることもある)、上記で説明したコプロセッサ及び追加の機能を含み得るチップ上のシステムを含んでよい。例示的なコアアーキテクチャが次に説明され、後に例示的なプロセッサ及びコンピュータアーキテクチャの説明が続く。
例示的なコアアーキテクチャ
インオーダ及びアウトオブオーダコアブロック図
図126Aは、本発明の実施形態に係る、例示的なインオーダパイプライン及び例示的なレジスタリネーミング・アウトオブオーダ発行/実行パイプラインの両方を示すブロック図である。図126Bは、本発明の実施形態に係るプロセッサに含まれるインオーダアーキテクチャコアの例示的な実施形態及び例示的なレジスタリネーミング・アウトオブオーダ発行/実行アーキテクチャコアの両方を示すブロック図である。図126A〜図126Bの実線の枠は、インオーダパイプライン及びインオーダコアを示し、一方、破線の枠の選択的な追加部分は、レジスタリネーミング・アウトオブオーダ発行/実行パイプライン及びコアを示す。インオーダ態様がアウトオブオーダ態様のサブセットであることを前提に、アウトオブオーダ態様が説明される。
図126Aにおいて、プロセッサパイプライン12600は、フェッチステージ12602、長さデコードステージ12604、デコードステージ12606、割り当てステージ12608、リネーミングステージ12610、スケジューリング(ディスパッチ又は発行としても知られている)ステージ12612、レジスタ読み出し/メモリ読み出しステージ12614、実行ステージ12616、ライトバック/メモリ書き込みステージ12618、例外処理ステージ12622、及び、コミットステージ12624を含む。
図126Bは、実行エンジンユニット12650に結合されるフロントエンドユニット12630を含むプロセッサコア12690を示し、両方とも、メモリユニット12670に結合される。コア12690は、縮小命令セットコンピューティング(RISC)コア、複合命令セットコンピューティング(CISC)コア、超長命令語(VLIW)コア、又は、ハイブリッド又は代替的なコアタイプであってよい。さらなる別のオプションとして、コア12690は、例えば、ネットワーク又は通信コア、圧縮エンジン、コプロセッサコア、汎用コンピューティンググラフィックス処理ユニット(GPGPU)コア又はグラフィックスコアなどの特定用途コアであってよい。
フロントエンドユニット12630は、命令キャッシュユニット12634に結合される分岐予測ユニット12632を含み、命令キャッシュユニット12634は、命令トランスレーションルックアサイドバッファ(TLB)12636に結合され、命令トランスレーションルックアサイドバッファ(TLB)12636は、命令フェッチユニット12638に結合され、命令フェッチユニット12638は、デコードユニット12640に結合される。デコードユニット12640(又は、デコーダ)は、命令をデコードし、1又は複数のマイクロオペレーション、マイクロコードエントリポイント、マイクロ命令、他の命令又は他の制御信号を出力として生成してよく、これらは、元の命令からデコードされる、又は、そうでなければ元の命令を反映する、又は、元の命令から導き出される。デコードユニット12640は、様々な異なるメカニズムを用いて実装されてよい。好適なメカニズムの例では、限定されることはないが、ルックアップテーブル、ハードウェア実装、プログラマブル論理アレイ(PLA)、マイクロコードリードオンリメモリ(ROM)などを含む。一実施形態において、コア12690は、特定のマクロ命令に関するマイクロコードを(例えば、デコードユニット12640内、そうでなければ、フロントエンドユニット12630内に)格納するマイクロコードROM又は他の媒体を含む。デコードユニット12640は、実行エンジンユニット12650内のリネーム/アロケータユニット12652に結合される。
実行エンジンユニット12650は、リタイアメントユニット12654と1又は複数のスケジューラユニット12656のセットとに結合されるリネーム/アロケータユニット12652を含む。スケジューラユニット12656は、予約ステーション、中央命令ウィンドウなどを含む任意の数の様々なスケジューラを表す。スケジューラユニット12656は、物理レジスタファイルユニット12658に結合される。物理レジスタファイルユニット12658のそれぞれは、1又は複数の物理レジスタファイル、1又は複数の異なるデータタイプを格納するもののうちの異なるいくつか、例えば、スカラ整数、スカラ浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点、ステータス(例えば、実行される次の命令のアドレスである命令ポインタ)などを表す。一実施形態において、物理レジスタファイルユニット12658は、ベクトルレジスタユニット、書き込みマスクレジスタユニット及びスカラレジスタユニットを有する。これらのレジスタユニットは、アーキテクチャのベクトルレジスタ、ベクトルマスクレジスタ及び汎用レジスタを提供してよい。物理レジスタファイルユニット12658は、レジスタリネーミング及びアウトオブオーダ実行が、(例えば、リオーダバッファ及びリタイアレジスタファイルを用いて、将来のファイル、履歴バッファ及びリタイアレジスタファイルを用いて、レジスタマッピング及びレジスタのプールなどを用いて)実装され得る様々な方式を示すために、リタイアメントユニット12654により重ね合わせられる。リタイアメントユニット12654及び物理レジスタファイルユニット12658は、実行クラスタ12660に結合される。実行クラスタ12660は、1又は複数の実行ユニット12662のセット及び1又は複数のメモリアクセスユニット12664のセットを含む。実行ユニット12662は、様々なオペレーション(例えば、シフト、加算、減算、乗算)を、様々なタイプのデータ(例えば、スカラ浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点)に対して実行してよい。いくつかの実施形態では、特定の機能又は機能のセットに専用の多数の実行ユニットを含み得る一方、他の実施形態では、1つの実行ユニットのみ、又は、すべての機能をすべてが実行する複数の実行ユニットを含み得る。特定の実施形態では、特定のタイプのデータ/オペレーションに対して別々のパイプライン(例えば、スカラ整数パイプライン、スカラ浮動小数点/パックド整数/パックド浮動小数点/ベクトル整数/ベクトル浮動小数点パイプライン、及び/又は、メモリアクセスパイプラインは、これら自体のスケジューラユニット、物理レジスタファイルユニット、及び/又は、実行クラスタをそれぞれが有する、−別々のメモリアクセスパイプラインの場合、このパイプラインの実行クラスタがメモリアクセスユニット12664のみを有する特定の実施形態で実装される)を作成するので、スケジューラユニット12656、物理レジスタファイルユニット12658及び実行クラスタ12660は、場合によっては複数のものとして示されている。別々のパイプラインが用いられる場合、これらのパイプラインのうちの1又は複数が、アウトオブオーダ発行/実行であってよく、残りがインオーダであってよいことも理解されたい。
メモリアクセスユニット12664のセットは、メモリユニット12670に結合され、メモリユニット12670は、レベル2(L2)キャッシュユニット12676に結合されるデータキャッシュユニット12674に結合されるデータTLBユニット12672を含む。1つの例示的な実施形態において、メモリアクセスユニット12664は、ロードユニット、格納アドレスユニット及び格納データユニットを含んでよく、それぞれが、メモリユニット12670内のデータTLBユニット12672に結合される。命令キャッシュユニット12634は、メモリユニット12670内のレベル2(L2)キャッシュユニット12676にさらに結合される。L2キャッシュユニット12676は、キャッシュの1又は複数の他のレベルに結合されて、最終的にメインメモリに結合される。
例として、例示的なレジスタリネーミング、アウトオブオーダ発行/実行コアアーキテクチャは、以下のようなパイプライン12600を実施してよい。1)命令フェッチ12638は、フェッチ及び長さデコーディングステージ12602及び12604を実行し、2)デコードユニット12640は、デコードステージ12606を実行し、3)リネーム/アロケータユニット12652は、割り当てステージ12608及びリネーミングステージ12610を実行し、4)スケジューラユニット12656は、スケジューリングステージ12612を実行し、5)物理レジスタファイルユニット12658及びメモリユニット12670は、レジスタ読み出し/メモリ読み出しステージ12614を実行し、実行クラスタ12660は、実行ステージ12616を実行し、6)メモリユニット12670及び物理レジスタファイルユニット12658は、ライトバック/メモリ書き込みステージ12618を実行し、7)様々なユニットは、例外処理ステージ12622に関するものであってよく、8)リタイアメントユニット12654及び物理レジスタファイルユニット12658は、コミットステージ12624を実行する。
コア12690は、本明細書で説明される命令を含む1又は複数の命令セット(例えば、x86命令セット(より新しいバージョンで追加されたいくつかの拡張を伴う))、カリフォルニア州サニーベールのMIPS技術のMIPS命令セット、ARM命令セット(カリフォルニア州サニーベールのARMホールディングスのNEONなどの選択的な追加の拡張を伴う)をサポートしてよい。一実施形態において、コア12690は、パックドデータ命令セット拡張(例えば、AVX1、AVX2)をサポートする論理を含み、それにより、パックドデータを用いて実行される多くのマルチメディアアプリケーションにより用いられるオペレーションを可能にする。
コアはマルチスレッディング(オペレーション又はスレッドの2又はそれより多い並列セットを実行する)をサポートしてよく、タイムスライス型マルチスレッディング、同時マルチスレッディング(物理コアが同時にマルチスレッディングするスレッドのそれぞれに対して、単一物理コアが論理コアを提供する)、又は、それらの組み合わせ(例えば、それ以降のインテルのハイパースレッディングテクノロジーなどのタイムスライス型フェッチング及びデコーディング、並びに、同時マルチスレッディング)を含む様々な方式で行われてよいことを理解されたい。
レジスタリネーミングが、アウトオブオーダ実行のコンテキストで説明される一方、レジスタリネーミングは、インオーダアーキテクチャにおいて用いられてよいことに理解されたい。プロセッサの例示された実施形態では、別々の命令及びデータキャッシュユニット12634/12674及び共有のL2キャッシュユニット12676も含み、一方で、代替的な実施形態では、例えば、レベル1(L1)内部キャッシュ又は内部キャッシュの複数のレベルなど、命令及びデータの両方に対して単一の内部キャッシュを有してよい。いくつかの実施形態において、システムは、内部キャッシュと、コア及び/又はプロセッサの外部にある外部キャッシュとの組み合わせを含んでよい。代替的に、キャッシュのすべては、コア及び/又はプロセッサの外部にあってよい。
具体的な例示的インオーダコアアーキテクチャ
図127A〜図127Bは、より具体的な例示的インオーダコアアーキテクチャのブロック図を示し、コアは、チップ内の(同じタイプ及び/又は異なるタイプの他のコアを含む)いくつかの論理ブロックのうちの1つであろう。論理ブロックは、用途に応じて、高帯域幅相互接続ネットワーク(例えば、リングネットワーク)を通じて、いくつかの固定機能論理、メモリI/Oインタフェース及び他の必要なI/O論理と通信する。
図127Aは、本発明の実施形態に係る、シングルプロセッサコアのオンダイ相互接続ネットワーク12702への接続及びそのレベル2(L2)キャッシュ12704のローカルサブセットとの接続と併せたシングルプロセッサコアについてのブロック図である。一実施形態において、命令デコーダ12700は、パックドデータ命令セット拡張を伴うx86命令セットをサポートする。L1キャッシュ12706は、スカラ及びベクトルユニット内のキャッシュメモリへの低レイテンシなアクセスを可能にする。一実施形態において(設計を簡略化するために)、スカラユニット12708及びベクトルユニット12710は、別々のレジスタセット(それぞれ、スカラレジスタ12712及びベクトルレジスタ12714)を用い、これらの間で転送されるデータは、メモリに書き込まれて、次にレベル1(L1)キャッシュ12706からリードバックされ、一方で、本発明の代替的な実施形態では、異なるアプローチ(例えば、単一のレジスタセットを用いる、又は、書き込み及びリードバックされることなく2つのレジスタファイル間でデータが転送されることを可能にする通信パスを含む)を用いてよい。
L2キャッシュ12704のローカルサブセットは、プロセッサコア毎に1つずつ、別々のローカルサブセットに分割されるグローバルL2キャッシュの一部である。各プロセッサコアは、L2キャッシュ12704の独自のローカルサブセットに対して直接的なアクセスパスを有する。プロセッサコアにより読み出されるデータは、そのL2キャッシュサブセット12704に格納され、これら自体のローカルL2キャッシュサブセットにアクセスする他のプロセッサコアと並列に、迅速にアクセスされ得る。プロセッサコアにより書き込まれるデータは、独自のL2キャッシュサブセット12704に格納され、必要な場合には、他サブセットからフラッシュされる。リングネットワークは、共有データに対するコヒーレンシを確保する。リングネットワークは、プロセッサコア、L2キャッシュ及び他論理ブロックなどのエージェントがチップ内で互いに通信することを可能にするために双方向である。各リングデータパスは、一方向あたり1012ビット幅である。
図127Bは、本発明の実施形態に係る、図127Aにおけるプロセッサコアの一部の拡大図である。図127Bは、L1キャッシュ12704のL1データキャッシュ12706A部分、並びに、ベクトルユニット12710及びベクトルレジスタ12714に関するさらなる詳細を含む。具体的には、ベクトルユニット12710は、16幅ベクトル処理ユニット(VPU)(16幅ALU12728を参照)であり、これは、整数、単精度浮動及び倍精度浮動命令のうちの1又は複数を実行する。VPUは、スウィズルユニット12720を用いたレジスタ入力のスウィズル、数値変換ユニット12722A−Bを用いた数値変換、及び、複製ユニット12724を用いたメモリ入力に対する複製をサポートする。書き込みマスクレジスタ12726は、結果としてもたらされるベクトル書き込みのプレディケートを可能にする。
図128は、本発明の実施形態に係る、1つより多くのコアを有してよく、統合メモリコントローラを有してよく、かつ、統合グラフィックスを有してよいプロセッサ12800のブロック図である。図128内の実線の枠は、単一のコア12802A、システムエージェント12810、1又は複数のバスコントローラユニット12816のセットを有するプロセッサ12800を示す一方、破線の枠の選択的な追加部分は、複数のコア12802A−N、システムエージェントユニット12810内の1又は複数の統合メモリコントローラユニット12814のセット、及び特定用途論理12808を有する代替的なプロセッサ12800を示す。
したがって、プロセッサ12800の異なる実装は、1)統合グラフィックス及び/又は科学技術(スループット)論理である特定用途論理12808(1又は複数のコアを含んでよい)、及び、1又は複数の汎用コアであるコア12802A−N(例えば、汎用インオーダコア、汎用アウトオブオーダコア、その2つの組み合わせ)を有するCPU、2)グラフィックス及び/又は科学技術(スループット)を主に対象とする多数の特定用途コアであるコア12802A−Nを有するコプロセッサ、及び、3)多数の汎用インオーダコアであるコア12802A−Nを有するコプロセッサを含んでよい。したがって、プロセッサ12800は、汎用プロセッサ、コプロセッサ又は特定用途プロセッサ、例えば、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、GPGPU(汎用グラフィックス処理ユニット)、高スループットの多集積コア(MIC)コプロセッサ(30又はそれより多いコアを含む)、又は、埋め込み型プロセッサなどであってよい。プロセッサは、1又は複数のチップ上に実装されてよい。プロセッサ12800は、1又は複数の基板の一部であってよい、及び/又は、例えば、BiCMOS、CMOS又はNMOSなどの多数の処理技術のいずれかを用いて1又は複数の基板上に実装されてもよい。
メモリ階層は、コア、1又は複数の共有キャッシュユニット12806のセット、及び、統合メモリコントローラユニット12814のセットに結合される外部メモリ(図示しない)内に1又は複数のレベルのキャッシュを含む。共有キャッシュユニット12806のセットは、レベル2(L2)、レベル3(L3)、レベル4(L4)又は他のレベルのキャッシュなどの1又は複数の中レベルキャッシュ、ラストレベルキャッシュ(LLC)及び/又はその組み合わせを含んでよい。一実施形態において、リングベースの相互接続ユニット12812は、統合グラフィックス論理12808(統合グラフィックス論理12808は、特定用途論理の一例であり、本明細書ではまた特定用途論理と称されている)、共有キャッシュユニット12806のセット及びシステムエージェントユニット12810/統合メモリコントローラユニット12814を相互接続し、一方で、代替的な実施形態では、そのようなユニットを相互接続するための任意の数の周知技術を用いてよい。一実施形態において、コヒーレンシが、1又は複数のキャッシュユニット12806及びコア12802A−Nの間で維持されている。
いくつかの実施形態において、コア12802A−Nのうちの1又は複数は、マルチスレッディングが可能である。システムエージェント12810は、コア12802A−Nを調整し、動作させるそれらのコンポーネントを含む。システムエージェントユニット12810は、例えば、電力制御ユニット(PCU)及びディスプレイユニットを含んでよい。PCUは、コア12802A−N及び統合グラフィックス論理12808の電力状態を調整するために必要とされる論理及びコンポーネントであってよい又は含んでよい。ディスプレイユニットは、1又は複数の外部に接続されたディスプレイを駆動させるためのものである。
コア12802A−Nは、アーキテクチャ命令セットの観点からホモジニアス又はヘテロジニアスであってよい。つまり、コア12802A−Nの2又はそれより多くは、同じ命令セットを実行することが可能であってよく、一方、その他は、その命令セット又は異なる命令セットのサブセットのみを実行することが可能であってよい。
例示的なコンピュータアーキテクチャ
図129〜図132は、例示的なコンピュータアーキテクチャのブロック図である。ラップトップ、デスクトップ、ハンドヘルドPC、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバ、ネットワークデバイス、ネットワークハブ、スイッチ、埋め込み型プロセッサ、デジタル信号プロセッサ(DSP)、グラフィックスデバイス、ビデオゲームデバイス、セットトップボックス、マイクロコントローラ、携帯電話、ポータブルメディアプレーヤ、ハンドヘルドデバイス及び他の様々な電子デバイスに関する技術分野で知られている他のシステム設計及び構成にも適している。一般的に、本明細書に開示されるようなプロセッサ及び/又は他の実行論理を組み込むことができる多様なシステム又は電子デバイスが概して適している。
ここで図129を参照すると、示されているのは、本発明の一実施形態に従うシステム12900のブロック図である。システム12900は、コントローラハブ12920に結合される1又は複数のプロセッサ12910、12915を含んでよい。一実施形態において、コントローラハブ12920は、グラフィックメモリコントローラハブ(GMCH)12990及び入力/出力ハブ(IOH)12950(別々のチップ上にあってよい)を含み、GMCH12990は、メモリ12940及びコプロセッサ12945に結合されるメモリ及びグラフィックスコントローラを含み、IOH12950は、入力/出力(I/O)デバイス12960をGMCH12990に結合する。代替的に、メモリ及びグラフィックスコントローラの一方又は両方は、(本明細書で説明されるように)プロセッサ内に統合されてよく、メモリ12940及びコプロセッサ12945は、プロセッサ12910と、IOH12950を有する単一のチップ内のコントローラハブ12920とに直接的に結合される。
追加のプロセッサ12915の選択的な特性が、破線で図129に示されている。各プロセッサ12910、12915は、本明細書で説明される処理コアのうちの1又は複数を含んでよく、プロセッサ12800のいくつかのバージョンであってよい。
メモリ12940は、例えば、ダイナミックランダムアクセスメモリ(DRAM)、相変化メモリ(PCM)又はその2つの組み合わせであってよい。少なくとも1つの実施形態について、コントローラハブ12920は、例えば、フロントサイドバス(FSB)などのマルチドロップバス、QuickPath相互接続(QPI)などのポイントツーポイントインタフェース、又は、同様の接続12995を介してプロセッサ12910、12915と通信する。
一実施形態において、コプロセッサ12945は、例えば、ハイスループットMICプロセッサ、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、GPGPU、又は、埋め込み型プロセッサなどの特定用途プロセッサである。一実施形態において、コントローラハブ12920は、統合グラフィックスアクセラレータを含んでよい。
アーキテクチャ特性、マイクロアーキテクチャ特性、熱的特性及び電力消費特性などを含む広範な価値基準の観点から、物理リソース12910、12915間には、様々な差異があり得る。
一実施形態において、プロセッサ12910は、一般的なタイプのデータ処理オペレーションを制御する命令を実行する。命令内に組み込まれるものは、コプロセッサ命令であってよい。プロセッサ12910は、取り付けられたコプロセッサ12945により実行されるべきタイプのものとしてこれらのコプロセッサ命令を認識する。状況に応じて、プロセッサ12910は、これらのコプロセッサ命令(又は、コプロセッサ命令を表す制御信号)を、コプロセッサバス又は他の相互接続を介してコプロセッサ12945に発行する。コプロセッサ12945は、受信したコプロセッサ命令を受け入れて実行する。
ここで図130を参照すると、示されているのは、本発明の実施形態に従う第1のより具体的な例示的システム13000のブロック図である。図130に示されるように、マルチプロセッサシステム13000は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続13050を介して結合される第1のプロセッサ13070及び第2のプロセッサ13080を含む。プロセッサ13070及び13080のそれぞれは、プロセッサ12800の何らかのバージョンであってよい。本発明の一実施形態において、プロセッサ13070及び13080は、それぞれプロセッサ12910及び12915であり、一方、コプロセッサ13038はコプロセッサ12945である。別の実施形態において、プロセッサ13070及び13080は、それぞれプロセッサ12910及びコプロセッサ12945である。
統合メモリコントローラ(IMC)ユニット13072及び13082をそれぞれ含むプロセッサ13070及び13080が示されている。プロセッサ13070は、そのバスコントローラユニットの一部として、ポイントツーポイント(P―P)インタフェース13076及び13078も含む。同様に第2のプロセッサ13080は、P−Pインタフェース13086及び13088を含む。プロセッサ13070、13080は、P―Pインタフェース回路13078、13088を用いて、ポイントツーポイント(P―P)インタフェース13050を介して情報を交換してよい。図130に示されるように、IMC13072及び13082は、メモリのそれぞれ、すなわち、メモリ13032及びメモリ13034にプロセッサを結合し、それぞれのプロセッサにローカルに取り付けられたメインメモリの一部であってよい。
プロセッサ13070、13080は、ポイントツーポイントインタフェース回路13076、13094、13086、13098を用いて、個別のP−Pインタフェース13052、13054を介して各チップセット13090と情報を交換してよい。チップセット13090は、高性能インタフェース13092を介してコプロセッサ13038と選択的に情報を交換してよい。一実施形態において、コプロセッサ13038は、例えば、ハイスループットMICプロセッサ、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、GPGPU又は埋め込み型プロセッサなどの特定用途プロセッサである。
共有キャッシュ(図示しない)は、いずれかのプロセッサ内又は両方のプロセッサの外部に含まれてよく、さらに、P―P相互接続を介してプロセッサと接続されてよく、その結果、プロセッサが低電力モードに置かれている場合、一方又は両方のプロセッサのローカルキャッシュ情報は、共有キャッシュに格納されてよい。
チップセット13090は、インタフェース13096を介して第1のバス13016に結合されてよい。一実施形態において、第1のバス13016は、ペリフェラルコンポーネントインターコネクト(PCI)バス、又は、PCIエクスプレスバス又は別の第3世代I/O相互接続バスなどのバスであってよいが、本発明の範囲は制限されることはない。
図130に示されるように、様々なI/Oデバイス13014は、第1のバス13016を第2のバス13020に結合するバスブリッジ13018と共に、第1のバス13016に結合されてよい。一実施形態において、コプロセッサ、ハイスループットMICプロセッサ、GPGPUのアクセラレータ(例えば、グラフィックスアクセラレータ又はデジタル信号プロセッシング(DSP)ユニットなど)、フィールドプログラマブルゲートアレイ又は任意の他のプロセッサなどの1又は複数の追加のプロセッサ13015は第1のバス13016に結合される。一実施形態において、第2のバス13020は、ローピンカウント(LPC)バスであってよい。一実施形態において、様々なデバイスは、例えば、キーボード及び/又はマウス13022、通信デバイス13027、及び、命令/コード及びデータ13030を含み得るディスクドライブ又は他の大容量ストレージデバイスなどのストレージユニット13028を含む第2のバス13020に結合されてよい。さらに、オーディオI/O13024は、第2のバス13020に結合されてよい。他のアーキテクチャが可能であることに留意する。例えば、図130のポイントツーポイントアーキテクチャの代わりに、システムは、マルチドロップバス又は他のそのようなアーキテクチャを実装してよい。
ここで図131を参照すると、示されているのは、本発明の実施形態に従う第2のより具体的な例示的システム13100のブロック図である。図130及び図131内の同様の要素には、同様の参照番号を付しており、図131の他の態様が曖昧になることを回避するために、図130の特定の態様が図131から省略されている。
図131は、プロセッサ13070、13080が、統合メモリ及びI/O制御論理(「CL」)13072及び13082をそれぞれ含み得ることを示す。したがって、CL13072、13082は、統合メモリコントローラユニットを含み、I/O制御論理を含む。図131は、メモリ13032、13034がCL13072、13082に結合されるだけでなく、I/Oデバイス13114も制御論理13072、13082に結合されることを示す。レガシI/Oデバイス13115は、チップセット13090に結合される。
ここで図132を参照すると、示されているのは、本発明の実施形態に従うSoC13200のブロック図である。図128内の同様の要素には同様の参照番号を付している。また、破線の枠は、より高度なSoC上の選択的な特徴である。図132において、相互接続ユニット13202は、キャッシュユニット12804A−Nを含む1又は複数のコア12802A−Nのセットと共有キャッシュユニット12806とを含むアプリケーションプロセッサ13210と、システムエージェントユニット12810と、バスコントローラユニット12816と、統合メモリコントローラユニット12814と、統合グラフィックス論理、画像プロセッサ、オーディオプロセッサ及びビデオプロセッサを含み得る1又は複数のコプロセッサ13220のセットと、スタティックランダムアクセスメモリ(SRAM)ユニット13230と、ダイレクトメモリアクセス(DMA)ユニット13232と、1又は複数の外部ディスプレイに結合するためのディスプレイユニット13240とに結合される。一実施形態において、コプロセッサ13220は、例えば、ネットワーク又は通信プロセッサ、圧縮エンジン、GPGPU、ハイスループットMICプロセッサ又は埋め込み型プロセッサなどの特定用途プロセッサを含む。
本明細書で開示されるメカニズムについての実施形態は、ハードウェア、ソフトウェア、ファームウェア又はそのような実装アプローチの組み合わせで実装されてよい。本発明の実施形態は、少なくとも1つのプロセッサ、ストレージシステム(揮発性及び不揮発性メモリ、及び/又は、ストレージエレメントを含む)、少なくとも1つの入力デバイス及び少なくとも1つの出力デバイスを有するプログラマブルシステム上で実行するコンピュータプログラム又はプログラムコードとして実装されてよい。
プログラムコード、例えば、図130に示されるコード13030は、本明細書で説明される機能を実行し、出力情報を生成するための入力命令に適用されてよい。出力情報は、既知の様式で、1又は複数の出力デバイスに適用されてよい。本願の目的のために、処理システムは、例えば、デジタル信号プロセッサ(DSP)、マイクロコントローラ、特定用途向け集積回路(ASIC)又はマイクロプロセッサなどのプロセッサを有する任意のシステムを含む。
プログラムコードは、処理システムと通信するために、高水準手続き型又はオブジェクト指向プログラミング言語で実装されてよい。プログラムコードは、必要に応じて、アセンブリ言語又は機械語で実装されてもよい。実際には、本明細書で説明されるメカニズムは、任意の特定のプログラミング言語の範囲に限定されない。いずれの場合でも、言語は、コンパイル型言語又はインタープリタ型言語であってよい。
少なくとも1つの実施形態のうちの1又は複数の態様では、マシンにより読み出される場合、本明細書で説明される技術を実行するために、マシンに論理を構築させるプロセッサ内の様々な論理を表す機械可読媒体上に格納された代表的な命令により実施されてよい。「IPコア」として知られるそのような表現は、有形の機械可読媒体上に格納され、論理又はプロセッサを実際に作る製造マシンにロードするために、様々な顧客又は製造施設に供給されてよい。
そのような機械可読記憶媒体は、制限なく、マシン又はデバイスにより製造又は形成される非一時的な有形の構成をした物品を含んでよく、ハードディスク、フロッピーディスクを含むその他のタイプのディスク、光ディスク、コンパクトディスクリードオンリメモリ(CD−ROM)、コンパクトディスクリライタブル(CD−RW)、及び、磁気−光ディスクなどの記憶媒体と、リードオンリメモリ(ROM)、ダイナミックランダムアクセスメモリ(DRAM)などのランダムアクセスメモリ(RAM)、スタティックランダムアクセスメモリ(SRAM)、消去可能プログラマブルリードオンリメモリ(EPROM)、フラッシュメモリ、電気的消去可能プログラマブルリードオンリメモリ(EEPROM)、相変化メモリ(PCM)、磁気又は光カードなどの半導体デバイスと、又は、電子的命令を格納するのに適したその他のタイプの媒体とを含む。
状況に応じて、本発明の実施形態は又はドウェア記述言語(HDL)などの命令を含む又は設計データを含む非一時的な有形の機械可読媒体を含み、本明細書で説明される構造、回路、装置、プロセッサ及び/又はシステム機能を定義する。そのような実施形態では、プログラム製品とも称されてよい。
エミュレーション(バイナリ変換、コード、モーフィングなどを含む)
いくつかの場合では、ソース命令セットからターゲット命令セットに命令を変換するために、命令変換器が用いられてよい。例えば、命令変換器は、コアにより処理されるために、命令を1又は複数の他の命令に、変換(例えば、静的なバイナリ変換、動的なコンパイルを含む動的なバイナリ変換を用いる)、モーフィング、エミュレート又は別の方法でコンバートしてよい。命令変換器は、ソフトウェア、ハードウェア、ファームウェア又はそれらの組み合わせで実装されてよい。命令変換器は、プロセッサ上、プロセッサ外、又は、プロセッサ上の一部及びプロセッサ外の一部にあってよい。
図133は、本発明の実施形態に係る、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令変換器の利用を対比するブロック図である。例示された実施形態では、命令変換器はソフトウェア命令変換器であるが、代替的に、命令変換器は、ソフトウェア、ファームウェア、ハードウェア又はそれらの様々な組み合わせで実装されてよい。図133は、少なくとも1つのx86命令セットコア13316を有するプロセッサにより実質的に実行され得るx86バイナリコード13306を生成するために、高水準言語13302におけるプログラムがx86コンパイラ13304を用いてコンパイルされ得ることを示す。少なくとも1つのx86命令セットコア13316を有するプロセッサは、少なくとも1つのx86命令セットコアを有するインテル(登録商標)プロセッサと実質的に同じ結果を実現するために、(1)インテル(登録商標)x86命令セットコアの命令セットの実質的な部分、又は、(2)少なくとも1つのx86命令セットコアを有するインテル(登録商標)プロセッサ上で実行することを目的としたアプリケーション又は他のソフトウェアのオブジェクトコードのバージョンを、互換性のある状態で実行する又は別の方法で処理することにより、少なくとも1つのx86命令セットコアを有するインテル(登録商標)プロセッサと同じ機能を実質的に実行できる任意のプロセッサを表す。x86コンパイラ13304は、追加のリンケージ処理を用いて又はこれを用いることなく、少なくとも1つのx86命令セットコア13316を有するプロセッサ上で実行され得るx86バイナリコード13306(例えば、オブジェクトコード)を生成するように動作可能なコンパイラを表す。同様に、図133は、高水準言語13302におけるプログラムが、少なくとも1つのx86命令セットコア13314(例えば、カリフォルニア州サニーベールの命令セットMIPS技術のMIPSを実行する、及び/又は、カリフォルニア州サニーベールのARMホールディングスのARM命令セットを実行するコアを有するプロセッサ)なしのプロセッサによりネイティブに実行され得る代替的な命令セットのバイナリコード13310を生成するために、代替的な命令セットのコンパイラ13308を用いてコンパイルされてよいことを示す。命令変換器13312は、x86命令セットコア13314なしのプロセッサによりネイティブに実行され得るコードにx86バイナリコード13306を変換するために用いられる。この変換済みコードは、これができる命令変換器が作成するのが難しいので、代替的な命令セットのバイナリコード13310と同じである可能性が低い。しかしながら、変換済みコードは、一般的なオペレーションを実現し、代替的な命令セットからの命令で構成される。したがって、命令変換器13312は、エミュレーション、シミュレーション又はその他の処理を通じてx86命令セットプロセッサ又はコアを有していないプロセッサ又は他の電子デバイスが、x86バイナリコード13306を実行することを可能にするソフトウェア、ファームウェア、ハードウェア又はそれらの組み合わせを表す。
機能及び態様の例示的な実装、実施形態及び特定の組み合わせが以下に詳細に説明される。これらの例は、有益なものであるが限定するものではない。
例1.複数のヘテロジニアス処理要素と、複数のヘテロジニアス処理要素のうちの1又は複数の実行のために命令のディスパッチを行うハードウェアヘテロジニアススケジューラであって、命令は、複数のヘテロジニアス処理要素のうちの1又は複数により処理されるコードフラグメントに対応し、命令は、複数のヘテロジニアス処理要素の1又は複数のうちの少なくとも1つに対するネイティブ命令である、ハードウェアヘテロジニアススケジューラとを含むシステム。
例2:複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例1に記載のシステム。
例3:複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例2に記載のシステム。
例4:ハードウェアヘテロジニアススケジューラは、コードフラグメントのプログラムフェーズを検出するプログラムフェーズ検出器をさらに含み、複数のヘテロジニアス処理要素は、第1のマイクロアーキテクチャを有する第1の処理要素、及び、第1のマイクロアーキテクチャとは異なる第2のマイクロアーキテクチャを有する第2の処理要素を含み、プログラムフェーズは、第1のフェーズ及び第2のフェーズを含む複数のプログラムフェーズのうちの1つであり、命令のディスパッチは、検出されたプログラムフェーズに部分的に基づいており、第1の処理要素によるコードフラグメントの処理は、第2の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例1−3のいずれかに記載のシステム。
例5:ハードウェアヘテロジニアススケジューラは、受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、ディスパッチを用いて、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングするセレクタをさらに備える、例1−4のいずれかに記載のシステム。
例6:コードフラグメントは、ソフトウェアスレッドと関連付けられた1又は複数の命令である、例1に記載のシステム。
例7:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例5−6のいずれかに記載のシステム。
例8:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例5−7のいずれかに記載のシステム。
例9:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例5−7のいずれかに記載のシステム。
例10:データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素を有する、例5−9のいずれかに記載のシステム。
例11:スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例5−10のいずれかに記載のシステム。
例12:スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐を有する、例5−11のいずれかに記載のシステム。
例13:直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアである、例2−12のいずれかに記載のシステム。
例14:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例2−13のいずれかに記載のシステム。
例15:ハードウェアヘテロジニアススケジューラは、コンパイル、組み込み関数(intrinsic)、アセンブリ、ライブラリ、中間、オフロード及びデバイスを含む複数のコードタイプをサポートする、例1−14のいずれかに記載のシステム。
例16:ハードウェアヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例5−15のいずれかに記載のシステム。
例17:ハードウェアヘテロジニアススケジューラは、利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする、例1−15のいずれかに記載のシステム。
例18:ハードウェアヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例5−15のいずれかに記載のシステム。
例19:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例5−18のいずれかに記載のシステム。
例20:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例5−19のいずれかに記載のシステム。
例21:ハードウェアヘテロジニアススケジューラは、各スレッドがスカラコア上で実行中であるかのようにプログラマに見えるようにするべく、ホモジニアスマルチプロセッサプログラミングモデルを提示する、例1−20のいずれかに記載のシステム。
例22:提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例21に記載のシステム。
例23:複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例1−22のいずれかに記載のシステム。
例24:ハードウェアヘテロジニアススケジューラは、複数のヘテロジニアス処理要素のうちの1つで実行されるバイナリトランスレータを含む、例1−23のいずれかに記載のシステム。
例25:複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例5−24のいずれかに記載のシステム。
例26:ヘテロジニアスハードウェアスケジューラは、ディスパッチされた命令に対してマルチプロトコルインタフェースで用いるプロトコルを選択する、例1−25のいずれかに記載のシステム。
例27:マルチプロトコルバスインタフェースによりサポートされている第1のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例26のいずれかに記載のシステム。
例28:マルチプロトコルバスインタフェースによりサポートされる第2のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例26−27のいずれかに記載のシステム。
例29:マルチプロトコルバスインタフェースによりサポートされる第3のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例26−28のいずれかに記載のシステム。
例30:第3のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス(PCIe)プロトコルを有する、例29に記載のシステム。
例31:アクセラレータを含むヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素と、ヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素のうちの少なくとも1つにより実行可能されるプログラムコードを格納するメモリとを含み、プログラムコードは、複数のヘテロジニアス処理要素のうちの1又は複数の実行のために命令のディスパッチを行うヘテロジニアススケジューラであって、命令は、複数のヘテロジニアス処理要素のうちの1又は複数により処理されるコードフラグメントに対応し、命令は、複数のヘテロジニアス処理要素の1又は複数のうちの少なくとも1つに対するネイティブ命令である、ヘテロジニアススケジューラとを含むシステム。
例32:複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例31に記載のシステム。
例33:複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例32に記載のシステム。
例34:ヘテロジニアススケジューラは、コードフラグメントのプログラムフェーズを検出するプログラムフェーズ検出器をさらに含み、複数のヘテロジニアス処理要素は、第1のマイクロアーキテクチャを有する第1の処理要素、及び、第1のマイクロアーキテクチャとは異なる第2のマイクロアーキテクチャを有する第2の処理要素を含み、プログラムフェーズは、第1のフェーズ及び第2のフェーズを含む複数のプログラムフェーズのうちの1つであり、命令のディスパッチは、検出したプログラムフェーズに部分的に基づいており、第1の処理要素によるコードフラグメントの処理は、第2の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例31−33のいずれかに記載のシステム。
例35:ヘテロジニアススケジューラは、受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、ディスパッチを用いて、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングするセレクタをさらに備える、例31−34のいずれかに記載のシステム。
例36:コードフラグメントは、ソフトウェアスレッドと関連付けられた1又は複数の命令である、例31−35のいずれかに記載のシステム。
例37:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例34−36のいずれかに記載のシステム。
例38:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例34−37のいずれかに記載のシステム。
例39:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例34−38のいずれかに記載のシステム。
例40:データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素を有する、例34−39のいずれかに記載のシステム。
例41:スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例30−35のいずれかに記載のシステム。
例42:スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐を有する、例30−36のいずれかに記載のシステム。
例43:直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアである、例30−37のいずれかに記載のシステム。
例44:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例30−38のいずれかに記載のシステム。
例45:ヘテロジニアススケジューラは、コンパイル、組み込み関数(intrinsic)、アセンブリ、ライブラリ、中間、オフロード及びデバイスを含む複数のコードタイプをサポートする、例31−44のいずれかに記載のシステム。
例46:ヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例31−45のいずれかに記載のシステム。
例47:ヘテロジニアススケジューラは、利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする、例31−46のいずれかに記載のシステム。
例48:ヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例31−47のいずれかに記載のシステム。
例50:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例31−49のいずれかに記載のシステム。
例51:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例31−50のいずれかに記載のシステム。
例52:ヘテロジニアススケジューラは、各スレッドがスカラコア上で実行中であるかのようにプログラマに見えるようにするべく、ホモジニアスプログラミングモデルを提示する、例31−51のいずれかに記載のシステム。
例53:提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例52のいずれかに記載のシステム。
例54a:複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例31−53のいずれかに記載のシステム。
例54b:ヘテロジニアススケジューラは、複数のヘテロジニアス処理要素のうちの1つで実行されるバイナリトランスレータを含む、例31−53のいずれかに記載のシステム。
例55:複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例31−54のいずれかに記載のシステム。
例56:ヘテロジニアスソフトウェアスケジューラは、ディスパッチされた命令に対してマルチプロトコルインタフェースで用いるプロトコルを選択する、例31−55のいずれかに記載のシステム。
例57:マルチプロトコルバスインタフェースによりサポートされる第1のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例56のいずれかに記載のシステム。
例58:マルチプロトコルバスインタフェースによりサポートされる第2のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例56−57のいずれかに記載のシステム。
例59:マルチプロトコルバスインタフェースによりサポートされる第3のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例56−58のいずれかに記載のシステム。
例60:第3のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス(PCIe)プロトコルを有する、例59に記載のシステム。
例61:複数の命令を受信する段階と、複数のヘテロジニアス処理要素のうちの1又は複数の実行のために、受信した複数の命令をディスパッチする段階であって、受信した複数の命令は、複数のヘテロジニアス処理要素のうちの1又は複数により処理されるコードフラグメントに対応し、その結果、複数の命令は、複数のヘテロジニアス処理要素の1又は複数のうちの少なくとも1つに対するネイティブ命令である、段階とを含む方法。
例62:複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例61に記載の方法。
例63:複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例62に記載の方法。
例64:コードフラグメントのプログラムフェーズを検出する段階をさらに含み、複数のヘテロジニアス処理要素は、第1のマイクロアーキテクチャを有する第1の処理要素、及び、第1のマイクロアーキテクチャとは異なる第2のマイクロアーキテクチャを有する第2の処理要素を含み、プログラムフェーズは、第1のフェーズ及び第2のフェーズを含む複数のプログラムフェーズのうちの1つであり、第1の処理要素によりコードフラグメントの処理は、第2の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例61−63のいずれかに記載の方法。
例65:受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングする段階をさらに含む、例61−64のいずれかに記載の方法。
例66:コードフラグメントは、ソフトウェアスレッドと関連付けられた1又は複数の命令である、例61−63のいずれかに記載の方法。
例67:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例64−66のいずれかに記載の方法。
例68:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例64−66のいずれかに記載の方法。
例69:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例64−68のいずれかに記載の方法。
例70:データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素により特徴付けられる、例64−69のいずれかに記載の方法。
例71:スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例64−70のいずれかに記載の方法。
例72:スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐により特徴付けられる、例64−71のいずれかに記載の方法。
例73:直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアでる、例64−72のいずれかに記載の方法。
例74:データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ(SIMD)命令を実行する処理コアである、例64−73のいずれかに記載の方法。
例75:選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする段階をさらに含む、例61−74のいずれかに記載の方法。
例76:利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする段階をさらに含む、例61−74のいずれかに記載の方法。
例77:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例61−76のいずれかに記載の方法。
例78:複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例61−77のいずれかに記載の方法。
例79:各スレッドがスカラコア上で実行中であるかのように見えるようにするべく、ホモジニアスマルチプロセッサプログラミングモデルを提示する段階をさらに含む、例61−74のいずれかに記載の方法。
例80:提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例79に記載の方法。
例81:複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例61−79のいずれかに記載の方法。
例82:複数のヘテロジニアス処理要素のうちの1つで実行されるコードフラグメントをバイナリ変換する段階をさらに含む、例61−81のいずれかに記載の方法。
例83:複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例61−82のいずれかに記載の方法。
例84:ハードウェアにより実行される場合に、プロセッサが、例51−83のうちの1つに記載の方法を実行する命令を格納する非一時的な機械可読媒体。
例85:ヘテロジニアススケジューラにおいてコードフラグメントを受信する段階と、コードフラグメントが並列フェーズにあるか否かを判断する段階と、コードフラグメントが並列フェーズにない場合、レイテンシに敏感なオペレーション要素を選択してコードフラグメントを実行する段階と、コードフラグメントが並列フェーズにある場合、並列性のタイプを判断し、及びスレッド並列コードフラグメントに関して、スカラ処理要素を選択してコードフラグメントを実行する段階と、データ並列コードフラグメントに関して、データ並列コードフラグメントのデータレイアウトを判断する段階と、パックドデータレイアウトに関して、単一命令複数データ(SIMD)処理要素及び算術プリミティブ処理要素のうちの1つを選択し、ランダムデータレイアウトに関して、ギャザー命令、空間計算アレイ、又は、複数のスカラコアのアレイから1つのスカラコアを用いるSIMD処理要素のうちの1つを選択する段階と、実行のために処理要素にコードフラグメントを送信する段階とを含む方法。
例86:コードフラグメントが並列フェーズにあるか否かを判断する段階の前に、コードフラグメントがアクセラレータへのオフロードの対象となるときを判断する段階と、コードフラグメントがオフロードの対象となったときに、アクセラレータにコードフラグメントを送信する段階とをさらに含む、例85に記載の方法。
例87:コードフラグメントが並列フェーズにあるか否かを判断する段階は、検出されたデータの依存性、命令タイプ及び制御フロー命令のうちの1又は複数に基づいている、例85−86のいずれかに記載の方法。
例88:単一の命令、複数のデータ命令についての命令のタイプは、並列フェーズを示す、例87に記載の方法。
例89:ヘテロジニアススケジューラにより処理される各オペレーティングシステムスレッドは、論理スレッド識別子が割り当てられる、例85−88のいずれかに記載の方法。
例90:ヘテロジニアススケジューラは、処理要素タイプ、処理要素識別子及びスレッド識別子から成るタプルに各論理スレッド識別子がマッピングされるように、論理スレッド識別子の縞模様マッピングを利用する、例89に記載の方法。
例91:論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、除算及びモジュロを用いて計算される、例90に記載の方法。
例92:論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、スレッドの共通性を保つために固定される、例91に記載の方法。
例93:論理スレッド識別子から処理要素タイプへのマッピングは、ヘテロジニアススケジューラにより実行される、例90に記載の方法。
例94:論理スレッド識別子から処理要素タイプへのマッピングは、将来の処理要素タイプに順応するように柔軟である、例93に記載の方法。
例95:ヘテロジニアススケジューラは、少なくとも1つのアウトオブオーダタプル、及び、同じアウトオブオーダタプルに論理スレッド識別子がマッピングするスカラ及びSIMDタプルを複数のコアグループのうちの少なくとも1つが有するように、複数のコアグループを利用する、例91に記載の方法。
例96:複数のコアグループのうちの1つに属するスレッド間で一意的なページディレクトリベースレジスタ値を有するスレッドにより、非並列フェーズが判断される、例95に記載の方法。
例97:処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する、例96に記載の方法。
例98:イベントを検出する段階であって、イベントは、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込、スリープコマンド、スレッドのフェーズ変更、異なるコアへの所望の再割り当てを示す1又は複数の命令のうちの1つである、段階をさらに含む、例85−97のいずれかに記載の方法。
例99:イベントがスレッドウェイクアップコマンドである場合、コードフラグメントが並列フェーズにあると判断して、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数をカウントする段階と、カウントされた処理要素の数が1より大きいか否かを判断する段階であって、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが1である場合、当該スレッドは直列フェーズであり、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが1ではない場合、当該スレッドは並列フェーズにある、段階をさらに含む、例98に記載の方法。
例100:イベントがスレッドスリープコマンドである場合、スレッドと関連付けられた実行フラグをクリアする段階と、影響を受けるスレッドと同じページテーブルベースポインタを共有する処理要素のスレッドの数をカウントする段階と、アウトオブオーダ処理要素がアイドルであるか否かを判断する段階とをさらに含み、ページテーブルベースポインタがコアグループ内のちょうど1つのスレッドにより共有されている場合、その共有しているスレッドがアウトオブオーダ処理要素から移動され、ページテーブルベースポインタが1つより多くのスレッドにより共有されている場合、コアグループの第1の実行スレッドがアウトオブオーダ処理要素に移行される、例98に記載の方法。
例101:スレッドスリープコマンドは、停止、待ちエントリ及びタイムアウト又は一時停止コマンドのうちの1つである、例100に記載の方法。
例102:イベントがフェーズ変更である場合、スカラ処理要素上でスレッドが実行中であり、かつ、SIMD命令があることをスレッドの論理スレッド識別子が示す場合、当該スレッドをSIMD処理要素に移行する段階と、SIMD処理要素上でスレッドが実行中であり、かつ、SIMD命令がないことをスレッドの論理スレッド識別子が示す場合、当該スレッドをスカラ処理要素に移行する段階とをさらに含む、例98に記載の方法。
例103:コードフラグメントを送信する前に、選択された処理要素をより良く適合させるようにコードフラグメントを変換する段階をさらに含む、例85−102のいずれかに記載の方法。
例104:ヘテロジニアススケジューラは、変換を実行するバイナリトランスレータを含む、例103に記載の方法。
例105:ヘテロジニアススケジューラは、変換を実行するJITコンパイラを含む、例103に記載の方法。
例106:方法は、例61−83についての方法の例のうちのいずれかの方法の段階をさらに備える、例85−105のいずれかに記載の方法。
例107:複数のヘテロジニアス処理要素と、コードフラグメントのフェーズを判断して、判断されたフェーズに少なくとも部分的に基づく実行のために複数のヘテロジニアス処理要素のうちの1つにコードフラグメントを送信するヘテロジニアススケジューラとを含むシステム。
例108:ヘテロジニアススケジューラは、コードフラグメントが並列フェーズにあるか否かを判断し、コードフラグメントが並列フェーズにない場合、レイテンシに敏感なオペレーション要素を選択してコードフラグメントを実行し、コードフラグメントが並列フェーズにある場合、並列性のタイプを判断し、スレッド並列コードフラグメントに関して、スカラ処理要素を選択してコードフラグメントを実行し、データ並列コードフラグメントに関して、データ並列コードフラグメントのデータレイアウトを判断し、パックドデータレイアウトに関して、単一命令複数データ(SIMD)処理要素及び算術プリミティブ処理要素のうちの1つを選択し、ランダムデータレイアウトに関して、ギャザー命令、空間計算アレイ、又は、複数のスカラコアのアレイから1つのスカラコアを用いるSIMD処理要素のうちの1つを選択する、例107に記載のシステム。
例109:ヘテロジニアススケジューラは、さらに、コードフラグメントが並列フェーズにあるか否かを判断する前に、いつコードフラグメントがアクセラレータへのオフロードの対象になるかを判断し、コードフラグメントがオフロードの対象になったときに、アクセラレータにコードフラグメントを送信する、例108に記載のシステム。
例110:ヘテロジニアススケジューラは、さらに、検出されたデータの依存性、命令タイプ及び制御フロー命令のうちの1又は複数に基づいて、コードフラグメントが並列フェーズにあるか否かを判断する、例108−109のいずれかに記載のシステム。
例111:単一の命令、複数のデータ命令についての命令のタイプは、並列フェーズを示す、例110に記載のシステム。
例112:ヘテロジニアススケジューラにより処理される各オペレーティングシステムスレッドは、論理スレッド識別子が割り当てられる、例108−111のいずれかに記載のシステム。
例113:ヘテロジニアススケジューラは、処理要素タイプ、処理要素識別子及びスレッド識別子から成るタプルに各論理スレッド識別子がマッピングされるように、論理スレッド識別子の縞模様マッピングを利用する、例112に記載のシステム。
例114:論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、除算及びモジュロを用いて計算される、例112に記載のシステム。
例115:論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、スレッドの共通性を保つために固定される、例114に記載のシステム。
例116:論理スレッド識別子から処理要素タイプへのマッピングは、ヘテロジニアススケジューラにより実行される、例115に記載のシステム。
例117:論理スレッド識別子から処理要素タイプへのマッピングは、将来の処理要素タイプに順応するように柔軟である、例116に記載のシステム。
例118:ヘテロジニアススケジューラは、少なくとも1つのアウトオブオーダタプル、及び、同じアウトオブオーダタプルに論理スレッド識別子がマッピングするスカラ及びSIMDタプルをコアグループが有するように、コアグループを利用する、例108−117のいずれかに記載のシステム。
例119:複数のコアグループのうちの1つに属するスレッド間で一意的なページディレクトリベースレジスタ値を有するスレッドにより、非並列フェーズが判断される、例118に記載のシステム。
例120:処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する、例119に記載のシステム。
例121:ヘテロジニアススケジューラは、イベントを検出し、当該イベントは、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す1又は複数の命令のうちの1つである、例108−120のいずれかに記載のシステム。
例122:ヘテロジニアススケジューラは、イベントがスレッドウェイクアップコマンドである場合、コードフラグメントが並列フェーズにあると判断して、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数をカウントし、カウントされた処理要素の数が1より大きいか否かを判断し、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが1である場合、当該スレッドは直列フェーズにあり、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが1ではない場合、当該スレッドは並列フェーズにある、例121に記載のシステム。
例123:ヘテロジニアススケジューラは、イベントがスレッドスリープコマンドである場合、スレッドと関連付けられている実行フラグをクリアし、影響を受けるスレッドと同じページテーブルベースポインタを共有する処理要素のスレッドの数をカウントし、アウトオブオーダ処理要素がアイドルであるか否かを判断し、ページテーブルベースポインタがコアグループ内のちょうど1つのスレッドにより共有されている場合、その共有しているスレッドがアウトオブオーダ処理要素から移動され、ページテーブルベースポインタが1つより多くのスレッドにより共有されている場合、グループの第1の実行スレッドがアウトオブオーダ処理要素に移行される、例121に記載のシステム。
例124:スレッドスリープコマンドは、停止、待ちエントリ及びタイムアウト又は一時停止コマンドのうちの1つである、例123に記載のシステム。
例125:ヘテロジニアススケジューラは、イベントがフェーズ変更である場合、スカラ処理要素上でスレッドが実行中であり、かつ、SIMD命令があることをスレッドの論理スレッド識別子が示す場合、当該スレッドをSIMD処理要素に移行し、SIMD処理要素上でスレッドが実行中であり、かつ、SIMD命令がないことをスレッドの論理スレッド識別子が示す場合、当該スレッドをスカラ処理要素に移行する、例121に記載のシステム。
例126:ヘテロジニアススケジューラは、コードフラグメントを送信する前に、選択された処理要素をより良く適合させるようにコードフラグメントを変換する、例108−125のいずれかに記載のシステム。
例127:ヘテロジニアススケジューラは、実行されると変換を実行するために、非一時的な機械可読媒体に格納されるバイナリトランスレータを含む、例126に記載のシステム。
例128:ヘテロジニアススケジューラは、実行されると変換を実行するために、非一時的な機械可読媒体に格納されるJITコンパイラを含む、例126に記載のシステム。
例129:ヘテロジニアススケジューラを提供するヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素のうちの少なくとも1つにより実行可能なプログラムコードを格納するメモリをさらに含む、例108−128のいずれかに記載のシステム。
例130:ヘテロジニアススケジューラは回路を有する、例108−128のいずれかに記載のシステム。
例131:プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな少なくとも1つの命令をデコードするデコーダと、少なくとも1つのデコードされた命令を実行する1又は複数の実行ユニットであって、少なくとも1つのデコードされた命令は加速開始命令に対応し、加速開始命令はアクセラレータにオフロードされるコードの領域の開始を示す、1又は複数の実行ユニットとを含むプロセッサ。
例132:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例131に記載のプロセッサ。
例133:加速開始命令に対応する少なくとも1つのデコードされた命令の実行に応じて、プロセッサコアは、実行の第1のモードから実行の第2のモードに遷移する、例131に記載のプロセッサ。
例134:実行の第1のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例133に記載のプロセッサ。
例135:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例134に記載のプロセッサ。
例136:実行の第1のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例133−135のいずれか1つに記載のプロセッサ。
例137:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例133−136のいずれか1つに記載のプロセッサ。
例138:プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速開始命令に対応するデコードされた命令を実行する段階であって、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、段階とを含み方法。
例139:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例138に記載の方法。
例140:加速開始命令に対応するデコードされた命令の実行に応じて、プロセッサコアは、実行の第1のモードから実行の第2のモードに遷移する、例138に記載の方法。
例141:実行の第1のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例140に記載の方法。
例142:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例141に記載の方法。
例143:実行の第1のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例140−142のいずれか1つに記載の方法。
例144:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例140−143のいずれか1つに記載の方法。
例145:プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速開始命令に対応するデコードされた命令を実行する段階であって、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、段階とを含む、非一時的な機械可読媒体。
例146:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例145に記載の方法。
例147:加速開始命令に対応するデコードされた命令の実行に応じて、プロセッサコアは、実行の第1のモードから実行の第2のモードに遷移する、例145に記載の方法。
例148:実行の第1のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例147に記載の方法。
例149:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例148に記載の方法。
例150:実行の第1のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例148−149のいずれか1つに記載の方法。
例151:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例148−150のいずれか1つに記載の方法。
例152:プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな少なくとも1つの命令をデコードするデコーダと、少なくとも1つのデコードされた命令を実行する1又は複数の実行ユニットであって、少なくとも1つのデコードされた命令は加速開始命令に対応し、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、1又は複数の実行ユニットとを含む、システム。
例153:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例152に記載のシステム。
例154:加速開始命令に対応する少なくとも1つのデコードされた命令の実行に応じて、プロセッサコアは、実行の第1のモードから実行の第2のモードに遷移する、例152に記載のシステム。
例155:実行の第1のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例154に記載のシステム。
例156:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例155に記載のシステム。
例157:実行の第1のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例152−156のいずれか1つに記載のプロセッサ。
例158:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例152−157のいずれか1つに記載のプロセッサ。
例159:プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな命令をデコードするデコーダと、加速終了命令に対応するデコードされた命令を実行する1又は複数の実行ユニットであって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、1又は複数の実行ユニットとを含むプロセッサ。
例160:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例159に記載のプロセッサ。
例161:実行の第1のモードから実行の第2のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例159に記載のプロセッサ。
例162:実行の第1のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例161に記載のプロセッサ。
例163:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例162に記載のプロセッサ。
例164:実行の第1のモードにおいて、メモリ一貫性モデル制限が弱められる、例161−163のいずれか1つに記載のプロセッサ。
例165:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例161−164のいずれか1つに記載のプロセッサ。
例166:アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例159−165のいずれか1つに記載のプロセッサ。
例167:プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速終了命令に対応するデコードされた命令を実行する段階であって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、段階とを含む方法。
例168:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例167に記載の方法。
例169:実行の第1のモードから実行の第2のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例167に記載の方法。
例170:実行の第1のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例169に記載の方法。
例171:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例170に記載の方法。
例172:実行の第1のモードにおいて、メモリ一貫性モデル制限が弱められる、例169−171のいずれか1つに記載の方法。
例173:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例169−172のいずれか1つに記載の方法。
例174:アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例167−173のいずれか1つに記載の方法。
例175:プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速終了命令に対応するデコードされた命令を実行する段階であって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、段階とを含む、非一時的な機械可読媒体。
例176:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例175に記載の非一時的な機械可読媒体。
例177:実行の第1のモードから実行の第2のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例175に記載の非一時的な機械可読媒体。
例178:実行の第1のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例177に記載の非一時的な機械可読媒体。
例179:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例178に記載の非一時的な機械可読媒体。
例180:実行の第1のモードにおいて、メモリ一貫性モデル制限が弱められる、例177−179のいずれか1つに記載の非一時的な機械可読媒体。
例181:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例177−180のいずれか1つに記載の非一時的な機械可読媒体。
例182:アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例175−181のいずれか1つに記載の非一時的な機械可読媒体。
例183:プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな命令をデコードするデコーダと、加速終了命令に対応するデコードされた命令を実行する1又は複数の実行ユニットであって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、1又は複数の実行ユニットと、オフロードされた命令を実行するアクセラレータとを含むシステム。
例184:コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例183に記載のシステム。
例185:実行の第1のモードから実行の第2のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例184に記載のシステム。
例186:実行の第1のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第2のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例185に記載のシステム。
例187:自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例186に記載のシステム。
例188:実行の第1のモードにおいて、メモリ一貫性モデル制限が弱められる、例185−187のいずれか1つに記載のシステム。
例189:実行の第1のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例185−188のいずれか1つに記載のシステム。
例190:アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例183−190のいずれか1つに記載のシステム。
例191:スレッドを実行するアクセラレータを含むシステム。
システムは、プロセッサコアと、ヘテロジニアススケジューラを実装するソフトウェアを内部に格納したメモリとを含み、プロセッサコアにより実行されるときに、ヘテロジニアススケジューラは、アクセラレータ上で可能な実行に適したスレッドにおいてコードシーケンスを検出し、検出されたコードシーケンスを実行するアクセラレータを選択し、検出されたコードシーケンスを選択されたアクセラレータに送信する。
例192:アクセラレータによる実行に適していないスレッドのプログラムフェーズを実行する複数のヘテロジニアス処理要素をさらに含む、例191に記載のシステム。
例193:ヘテロジニアススケジューラは、コードシーケンスをパターンの予め決定されたセットと比較することにより、コードシーケンスを認識するパターンマッチャをさらに有する、例191−192のいずれかに記載のシステム。
例194:パターンの予め決定されたセットは、メモリに格納される、例193に記載のシステム。
例195:ヘテロジニアススケジューラは、パターンマッチを有するコードを認識し、無視自己書き換えコードが無視されること、メモリ一貫性モデル制限を弱め、浮動小数セマンティクスを変更すること、パフォーマンスモニタリングを変更すること、アーキテクチャフラグの利用を変更することのうちの1又は複数を行うプロセッサコアを構成することによりスレッドと関連付けられた動作モードを調整するパフォーマンスモニタリングを用いる、例191−194のいずれかに記載のシステム。
例196:ヘテロジニアススケジューラは、認識されたコードを、実行するアクセラレータに対するアクセラレータコードに変換する変換モジュールをさらに有する、例191−195のいずれかに記載のシステム。
例197:プロセッサコアは、格納されたパターンを用いて、スレッド内のコードシーケンスを検出するパターンマッチング回路を有する、例191−196のいずれかに記載のシステム。
例198:プロセッサコアは、システムにおいて実行している各スレッドの実行ステータスを維持する、例191−197のいずれかに記載のシステム。
例199:ヘテロジニアススケジューラは、システムにおいて実行している各スレッドのステータスを維持する、例191−197のいずれかに記載のシステム。
例200:ヘテロジニアススケジューラは、プロセッサ要素情報、追跡されたスレッド及び検出されたコードシーケンスのうちの1又は複数に基づいて、アクセラレータを選択する、例191−199のいずれかに記載のシステム。
例201:複数のヘテロジニアス処理要素と、複数の処理要素に結合されるヘテロジニアススケジューラ回路とを含み、ヘテロジニアススケジューラ回路は、実行中の各スレッド及び各処理要素の実行ステータスを維持するスレッド及び処理要素トラッカテーブルと、コードフラグメントを処理する複数のヘテロジニアス処理要素についての処理要素のタイプを選択して、スレッド及び処理要素トラッカからのステータス及び処理要素情報に基づいて、実行のために複数のヘテロジニアス処理要素のうちの1つ上でコードフラグメントをスケジューリングするセレクタとを含む、システム。
例202:プロセッサコアにより実行可能なソフトウェアを格納するメモリをさらに含み、ソフトウェアは、ヘテロジニアススケジューラ回路に結合される複数のヘテロジニアス処理要素のうちの1つであるアクセラレータ上で可能な実行に対するスレッドにおけるコードシーケンスを検出する、例201に記載のシステム。
例203:ソフトウェアパターンマッチャは、格納されたパターンからコードシーケンスを認識する、例202に記載のシステム。
例204:ヘテロジニアススケジューラは、認識されたコードをアクセラレータコードに変換する、例201−203のいずれかに記載のシステム。
例205:セレクタは、ヘテロジニアススケジューラ回路により実行される有限ステートマシンである、例201−204のいずれかに記載のシステム。
例206:スレッドを実行する段階と、実行中のスレッド内のパターンを検出する段階と、認識されたパターンをアクセラレータコードに変換する段階と、変換されたパターンを実行のために利用可能なアクセラレータに転送する段階とを含む方法。
例207:パターンは、ソフトウェアパターンマッチャを用いて認識される、例206に記載の方法。
例208:パターンは、ハードウェアパターンマッチ回路を用いて認識される、例206に記載の方法。
例209:スレッドを実行する段階と、実行中のスレッド内のパターンを検出する段階と、パターンに基づいた緩和要求を用いるために、スレッドと関連付けられた動作モードを調整する段階とを含む方法。
例210:パターンは、ソフトウェアパターンマッチャを用いて認識される、例209に記載の方法。
例211:パターンは、ハードウェアパターンマッチ回路を用いて認識される、例209に記載の方法。
例212:調整された動作モードにおいて、自己書き換えコードが無視されること、メモリ一貫性モデル制限が弱められることと、浮動小数セマンティクスが変更されることと、パフォーマンスモニタリングが変更されることと、アーキテクチャフラグの利用が変更されることとのうちの、1又は複数が適用される、例209に記載の方法。
例213:プロセッサコアに対してネイティブな命令をデコードするデコーダと、デコードされた命令を実行する1又は複数の実行ユニットであって、デコードされた命令の1又は複数は、加速開始命令に対応し、加速開始命令は、同じスレッド内の加速開始命令に従う命令に対する実行の異なるモードにエントリさせる、1又は複数の実行ユニットとを含むシステム。
例214:加速開始命令は、メモリデータブロックに対するポインタを規定するフィールドを含み、メモリデータブロックのフォーマットは、割込み前の進み具合を示すシーケンス番号フィールドを含む、例213に記載のシステム。
例215:加速開始命令は、メモリに格納されたコードの予め定義された変換を規定するブロッククラス識別子フィールドを含む、例213−214のいずれかに記載のシステム。
例216:加速開始命令は、実行のために用いられるハードウェアのタイプを示す実装識別子フィールドを含む、例213−215のいずれかに記載のシステム。
例217:加速開始命令は、加速開始命令が実行した後に修正されるレジスタを格納する状態保存エリアのサイズ及びフォーマットを示す保存状態エリアサイズフィールドを含む、例213−216のいずれかに記載のシステム。
例218:加速開始命令は、ローカルストレージエリアサイズ用のフィールドを含み、ローカルストレージエリアは、レジスタを超えたストレージ(storage beyond register)を提供する、例213−217のいずれかに記載のシステム。
例219:ローカルストレージエリアサイズは、加速開始命令の即値オペランドにより規定される、例218に記載のシステム。
例220:ローカルストレージエリアは、加速開始命令に続く命令を除いてアクセスされない、例218に記載のシステム。
例221:実行の異なるモード内の命令の場合、メモリ依存性タイプが定義可能である、例213−220のいずれかに記載のシステム。
例222:定義可能なメモリ依存性タイプは、ストア−ロード及びストア−ストア依存性が存在しないことが保証されている独立タイプと、ローカルストレージエリアへのロード及びストアが互いに依存し得るが、他のロード及びストアからは独立しているローカルストレージエリアへの潜在的に依存したアクセスタイプと、ハードウェアが命令間の依存性を動的にチェックして強化する潜在的に依存するタイプと、ロード及びストアがそれらの間で依存しており、メモリがアトミックに更新されるアトミック性タイプとのうちの1つを有する、例221に記載のシステム。
例223:使用対象のレジスタを含む保存状態、更新されるフラグ、実装仕様情報を格納するメモリと、レジスタを超える実行(execution beyond register)の間に用いられるローカルストレージとをさらに含む、例213−222のうちのいずれかに記載のシステム。
例224:並列実行の各インスタンスは、独自のローカルストレージを取得する、例223に記載のシステム。
例225:スレッドに対する実行についての異なる緩和モードに入る段階と、異なる緩和モードの実行中、スレッドの実行中に使用対象のレジスタを保存状態エリアに書き込む段階と、異なる緩和モードの実行中に、スレッド内の並列実行毎に用いられるローカルストレージを予約する段階と、スレッドのブロックを実行して、実行の異なる緩和モード内の命令を追跡する段階と、実行の異なるモードの終了が、アクセラレータ終了命令の実行に基づいて到達したか否かを判断する段階と、実行の異なるモードの終了が到達した場合、保存状態エリアからレジスタ及びフラグを元の状態に戻す段階と、実行の異なるモードの終了が到達していない場合、中間結果を用いてローカルストレージを更新する段階とを含む方法。
例226:異なる緩和モード実行の間、自己書き換えコードが無視されることと、メモリ一貫性モデル制限が弱められることと、浮動小数セマンティクスが変更されることと、パフォーマンスモニタリングが変更されることと、アーキテクチャフラグの利用が変更されることとのうちの1又は複数が発生する、例225に記載の方法。
例227:アクセラレータ開始命令の実行に基づいて、実行の異なるモードに入る、例225又は226に記載の方法。
例228:判断されたパターンに基づいて、実行の異なるモードに入る、例225に記載の方法。
例229:アクセラレータ開始命令が実行した後に修正されるレジスタを格納する状態保存エリアのサイズ及びフォーマットは、アクセラレータ開始命令により指し示されるメモリブロックに規定される、例225−228のいずれかに記載の方法。
例230:実行前に、スレッド又はその一部を変換する段階をさらに含む、例225−229のいずれかに記載の方法。
例231:スレッド又はその一部は、アクセラレータコードに変換される、例230に記載の方法。
例232:変換されたスレッド又は変換されたスレッドの一部は、アクセラレータにより実行される、例230又は231に記載の方法。
例233:ブロックの命令は、スレッドの上記ブロックと関連付けられるメモリブロック内のシーケンス番号を更新することにより追跡される、例213−232のいずれかに記載の方法。
例234:命令が実行に成功して、リタイアしたときに、スレッドのブロックのシーケンス番号が更新される、例223−233のいずれかに記載の方法。
例235:アクセラレータ終了命令が実行し、リタイアした場合、実行の異なるモードの終了に到達しない、例223−234のいずれかに記載の方法。
例236:アクセラレータ終了命令実行により判断されたときに、実行の異なるモードの終了に到達しなかった場合、中間結果を用いてブロックの一部を実行しようと試みる、例223−235のいずれかに記載の方法。
例237:非アクセラレータ処理要素は、例外又は割込み後に中間結果と共に実行するために用いられる、例236の方法。
例238:実行の異なるモードの終了に到達しなかった場合、アクセラレータの利用が開始したポイントに実行をロールバックする、例223−237のいずれかに記載の方法。
例239:オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースオペランド用の1又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコードするデコーダと、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、2)一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する実行回路とを含むシステム。
例240:Nはオペコードにより示される、例239に記載のシステム。
例241:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例239−240のいずれかに記載のシステム。
例242:実行回路は2分木低減ネットワークを含む、例239−241のいずれかに記載のシステム。
例243:実行回路はアクセラレータの一部である、例242のいずれかに記載のシステム。
例244:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例242に記載のシステム。
例245:各乗算は並列に処理される、例244に記載のシステム。
例246:パックドデータ要素は、1又は複数の行列の成分に対応する、例239−245のいずれかに記載のシステム。
例247:オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースオペランド用の1又は複数のフィールド及びパックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、一時的な結果を合計し、3)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に一時的な結果の合計を加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する段階とを含む方法。
例248:Nはオペコードにより示される、例247に記載の方法。
例249:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例247−248のいずれかに記載の方法。
例250:実行回路は2分木低減ネットワークを含む、例247−249のいずれかに記載の方法。
例251:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例247に記載の方法。
例252:各パックドデータオペランドは、8つのパックドデータ要素を有する、例251に記載の方法。
例253:各乗算は並列に処理される、例251に記載の方法。
例254:パックドデータ要素は、1又は複数の行列の成分に対応する、例247−253のいずれかに記載の方法。
例255:プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースオペランド用の1又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて一時的な結果を生成し、2)一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する段階とを含む、非一時的な機械可読媒体。
例256:Nはオペコードにより示される、例255に記載の非一時的な機械可読媒体。
例257:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例255−256のいずれかに記載の非一時的な機械可読媒体。
例258:実行回路は2分木低減ネットワークを含む、例255−257のいずれかに記載の非一時的な機械可読媒体。
例259:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例258に記載の非一時的な機械可読媒体。
例260:各パックドデータオペランドは、8つのパックドデータ要素を有する、例259に記載の非一時的な機械可読媒体。
例261:各乗算は並列に処理される、例259に記載の非一時的な機械可読媒体。
例262:パックドデータ要素は、1又は複数の行列の成分に対応する、例255−261のいずれかに記載の非一時的な機械可読媒体。
例263:オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースレジスタオペランド用の1又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、2)一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を格納するように、デコードされた命令を実行する段階とを含む方法。
例264:Nはオペコードにより示される、例263に記載の方法。
例265:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例263−264のいずれかに記載の方法。
例266:実行回路は2分木低減ネットワークである、例265に記載の方法。
例267:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例266に記載の方法。
例268:各パックドデータオペランドは、8つのパックドデータ要素を有する、例263−267のいずれかに記載の方法。
例269:各乗算は並列に処理される、例268−268のいずれかに記載の方法。
例270:プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースレジスタオペランド用の1又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、2)一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を格納するように、デコードされた命令を実行する段階とを含む、非一時的な機械可読媒体。
例271:Nはオペコードにより示される、例270に記載の非一時的な機械可読媒体。
例272:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例270−271のいずれかに記載の非一時的な機械可読媒体。
例273:実行回路は2分木低減ネットワークである、例272に記載の非一時的な機械可読媒体。
例274:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例272に記載の非一時的な機械可読媒体。
例275:各パックドデータオペランドは、8つのパックドデータ要素を有する、例270−274のいずれかに記載の非一時的な機械可読媒体。
例276:各乗算は並列に処理される、例270−275のいずれかに記載の非一時的な機械可読媒体。
例277:オペコード、第1のパックドデータソースオペランド用のフィールド、第2から第Nのパックドデータソースレジスタオペランド用の1又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコードするデコーダと、第2から第Nのパックドデータソースオペランドのパックドデータ要素の位置ごとに、1)そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第1のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて一時的な結果を生成し、2)対で一時的な結果を合計し、3)一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、4)パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する実行回路とを含むシステム。
例278:Nはオペコードにより示される、例277に記載のシステム。
例279:ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例277−278のいずれかに記載のシステム。
例280:実行回路は2分木低減ネットワークである、例279に記載のシステム。
例281:2分木低減ネットワークは、対で加算回路の第1セットに結合される複数の乗算回路を有し、加算回路の第1セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第3セットに結合される加算回路の第2セットに結合される、例279に記載のシステム。
例282:各パックドデータオペランドは、8つのパックドデータ要素を有する、例277−281のいずれかに記載のシステム。
例283:各乗算は並列に処理される、例277−282のいずれかに記載のシステム。
例284:ホストプロセッサにアクセラレータを結合するマルチプロトコルバスインタフェースを含むアクセラレータであって、コマンドを処理する1又は複数の処理要素を含む、アクセラレータと、複数のクライアントによりサブミットされるワーク記述子を格納する複数のエントリを含む共有のワークキューであって、ワーク記述子は、ワーク記述子と、1又は複数の処理要素により実行される少なくとも1つのコマンドと、アドレッシング情報とをサブミットしたクライアントを識別する識別コードを含む、共有のワークキューと、特定のアービトレーションポリシに従って、共有のワークキューから1又は複数の処理要素にワーク記述子をディスパッチするアービタとを含み、1又は複数の処理要素のそれぞれは、アービタからディスパッチされたワーク記述子を受信し、ソース及び宛先アドレス変換を実行し、ソースアドレス変換により識別されたソースデータを読み出し、少なくとも1つのコマンドを実行して宛先データを生成し、宛先アドレス変換を用いてメモリに宛先データを書き込む、システム。
例285:複数のクライアントは、直接ユーザモード入力/出力(IO)要求をアクセラレータにサブミットするユーザモードアプリケーション、アクセラレータを共有する仮想マシン(VM)において実行するカーネルモードドライバ、及び/又は、複数のコンテナにおいて実行するソフトウェアエージェントのうちの1又は複数を有する、例284に記載のシステム。
例286:複数のクライアントのうちの少なくとも1つのクライアントは、VM内で実行されるユーザモードアプリケーション又はコンテナを有する、例285に記載のシステム。
例287:クライアントは、ピア入力/出力(IO)エージェント及び/又はソフトウェアチェーンオフロード要求のうちの1又は複数を有する、例284−286のいずれかに記載のシステム。
例288:ピアIOエージェントのうちの少なくとも1つは、ネットワークインタフェースコントローラ(NIC)を有する、例287に記載のシステム。
例289:1又は複数の処理要素により使用可能な仮想−物理アドレス変換を格納するアドレス変換キャッシュをさらに含む、例284−288のいずれかに記載のシステム。
例290:特定のアービトレーションポリシは、先入先出ポリシを有する、例284−289のいずれかに記載のシステム。
例291:特定のアービトレーションポリシは、第1のクライアントのワーク記述子が第2のクライアントのワーク記述子を上回る優先度が与えられるサービス品質(QoS)ポリシを有する、例284−290のいずれかに記載のシステム。
例292:たとえ第2のクライアントのワーク記述子が、第1のクライアントのワーク記述子の前に共有のワークキューに受信されていたとしても、第1のクライアントのワーク記述子は、第2のクライアントのワーク記述子の前に1又は複数の処理要素にディスパッチされる、例291に記載のシステム。
例293:識別コードは、クライアントに割り当てられるシステムメモリ内のアドレス空間を識別する処理アドレス空間識別子(PASID)を有する、例284−292のいずれかに記載のシステム。
例294:1又は複数の専用のワークキューをさらに含み、各専用のワークキューは、専用のワークキューと関連付けられた単一のクライアントによりサブミットされたワーク記述子を格納する複数のエントリを含む、例284−293のいずれかに記載のシステム。
例295:グループ内の専用のワークキュー及び/又は共有のワークキューのうちの2又はそれより多くを組み合わせるためにプログラミングされるグループ構成レジスタをさらに含み、グループは、複数の処理要素のうちの1又は複数と関連付けられる、例294のシステム。
例296:1又は複数の処理要素は、グループ内の専用のワークキュー及び/又は共有のワークキューからのワーク記述子を処理する、例295に記載のシステム。
例297:マルチプロトコルバスインタフェースによりサポートされる第1のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例284−296のいずれかに記載のシステム。
例298:マルチプロトコルバスインタフェースによりサポートされる第2のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例284−297のいずれかに記載のシステム。
例299:マルチプロトコルバスインタフェースによりサポートされる第3のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例284−298のいずれかに記載のシステム。
例300:第3のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス(PCIe)プロトコルを有する、例299に記載のシステム。
例301:処理要素により処理されるソースデータを格納し、1又は複数の処理要素による処理から生じた宛先データを格納するアクセラレータメモリをさらに含む、例284−300のいずれかに記載のシステム。
例302:アクセラレータメモリは、高帯域幅メモリ(HBM)を有する、例301に記載のシステム。
例303:アクセラレータメモリは、ホストプロセッサにより用いられるシステムメモリアドレス空間の第1の部分に割り当てられる、例301に記載のシステム。
例304:システムメモリアドレス空間の第2の部分に割り当てられるホストメモリをさらに含む、例303に記載のシステム。
例305:システムメモリアドレス空間に格納されたデータのブロックごとに、ブロック内に含まれるデータがアクセラレータに向けてバイアスがかけられているか否かを示すバイアス回路及び/又は論理をさらに含む、例304に記載のシステム。
例306:データの各ブロックはメモリページを有する、例305に記載のシステム。
例307:ホストは、まずアクセラレータに要求を送信することなく、アクセラレータに向けてバイアスがかけられているデータを処理することを控える、例305に記載のシステム。
例308:バイアス回路及び/又は論理は、アクセラレータに向けたバイアスを示すために、データの固定サイズのブロック毎に設定される1ビットを含むバイアステーブルを含む、例307に記載のシステム。
例309:アクセラレータは、アクセラレータメモリに格納されるデータと関連付けられた1又は複数のデータコヒーレンシなトランザクションを実行するホストプロセッサのコヒーレンスコントローラと通信するメモリコントローラを有する、例301−308のいずれかに記載のシステム。
例310:メモリコントローラは、アクセラレータに向けられたバイアスに設定されるアクセラレータメモリに格納されるデータのブロックにアクセスするデバイスバイアスモードで動作し、デバイスバイアスモードにある場合、メモリコントローラは、ホストプロセッサのキャッシュコヒーレンスコントローラに問い合わせることなく、アクセラレータメモリにアクセスする、例309に記載のシステム。
例311:メモリコントローラは、ホストプロセッサに向けたバイアスに設定されるデータのブロックにアクセスするホストバイアスモードで動作し、ホストバイアスモードにある場合、メモリコントローラは、ホストプロセッサ内のキャッシュコヒーレンスコントローラを通じてアクセラレータメモリにすべての要求を送信する、例309に記載のシステム。
例312:共有のワークキューは、ワーク記述子のバッチを識別する少なくとも1つのバッチ記述子を格納する、例284−311のいずれかに記載のシステム。
例313:メモリからワーク記述子のバッチを読み出すことにより、バッチ記述子を処理するバッチ処理回路をさらに含む、例312に記載のシステム。
例314:ワーク記述子は、命令の第1のタイプを実行するホストプロセッサに対応する専用のワークキューに追加され、ワーク記述子は、命令の第2のタイプを実行するホストプロセッサに対応する共有のワークキューに追加される、例292に記載のシステム。
例315:デバイスバイアスでメモリページの第1セットを配置する段階と、ホストプロセッサに結合されるアクセラレータデバイスのローカルメモリからメモリページの第1セットを割り当てる段階と、ホストプロセッサのコア、又は、入力/出力エージェントから割り当てられたページにオペランドデータを転送する段階と、ローカルメモリを用いてアクセラレータデバイスによりオペランドを処理して、結果を生成する段階と、メモリページの第1セットをデバイスバイアスからホストバイアスに変換する段階とを含む方法。
例316:デバイスバイアスでメモリページの第1セットを配置する段階は、ページがアクセラレータデバイスバイアスにあることを示すために、バイアステーブル内のメモリページの第1セットを更新する、例315に記載の方法。
例317:エントリを更新する段階は、メモリページの第1セット内の各ページと関連付けられたビットを設定する段階を有する、例315−316のいずれかに記載の方法。
例318:デバイスバイアスに設定されると、メモリページの第1セットは、ホストキャッシュメモリにキャッシュされないことが保証される、例315−317のいずれかに記載の方法。
例319:メモリページの第1セットを割り当てることは、ドライバ又はアプリケーションプログラミングインタフェース(API)コールを開始する段階を有する、例315−318のいずれかに記載の方法。
例320:オペランドを処理するために、アクセラレータデバイスは、コマンドを実行して、そのローカルメモリから直接データを処理する、例315−319のいずれかに記載の方法。
例321:割り当てられたページにオペランドデータを転送する段階は、アクセラレータデバイスに1又は複数のワーク記述子をサブミットする段階を有し、ワーク記述子は、オペランドを識別する又は含む、例315−320のいずれかに記載の方法。
例322:1又は複数のワーク記述子は、割り当てられたページに、コマンドでホストプロセッサキャッシュからフラッシュさせてよい、例321に記載の方法。
例323:ホストプロセッサは、メモリページの第1セットがホストバイアスに設定されている場合、結果にアクセスし、結果をキャッシュし、結果を共有することが許可されている、例315−323のいずれかに記載の方法。