JP2014500549A - 処理クラスタのためのロード／ストア回路要素 - Google Patents

Abstract

並列処理を実行するための装置が提供される。この装置はメッセージバス（１４２０）、データバス（１４２２）、及びロード／ストアユニット（１４０８）を有する。ロード／ストアユニット（１４０８）はシステムインタフェース（５４１６）、データインタフェース（５４２０）、メッセージインタフェース（５４１８）、命令メモリ（５４０５）、データメモリ（５４０３）、バッファ（５４０６）、スレッドスケジューリング回路要素（５４０１、５４０４）、及びプロセッサ（５４０２）を有する。システムインタフェースはシステムメモリ（１４１６）と通信するように構成される。データインタフェースはデータバスに結合される。メッセージインタフェースはメッセージバスに結合される。バッファ（５４０６）はデータインタフェースに結合される。スレッドスケジューリング回路要素はメッセージインタフェースに結合され、プロセッサはデータメモリ、バッファ、命令メモリ、スレッドスケジューリング回路要素、及びシステムインタフェースに結合される。

Description

本開示は、全般的にプロセッサに関し、より具体的には処理クラスタに関する。

図１はマルチコアシステム（２〜１６コアの範囲）についての実行速度のスピードアップ対並列オーバーヘッドを示すグラフである。スピードアップとは、単一プロセッサの実行時間を並列プロセッサの実行時間で除したものである。図からわかるように、多数のコアから有意な利益を得るために、並列オーバーヘッドはゼロに近くなければならない。しかし並列プログラム間に何らかの相互作用が存在する場合、オーバーヘッドは極めて高くなる傾向があるため、完全に分離されたプログラムでなければ２又は３以上のプロセッサを効率的に使用するのは通常極めて難しい。従って、改善された処理クラスタが必要とされている。

従って、本開示の実施形態は、並列処理を実行するための装置を提供する。この装置は、メッセージバス（１４２０）と、データバス（１４２２）と、ロード／ストアユニット（１４０８）とを特徴とする。ロード／ストアユニットは、システムメモリ（１４１６）と通信するように構成されるシステムインタフェース（５４１６）と、前記データバスに結合されるデータインタフェース（５４２０）と、前記メッセージバスに結合されるメッセージインタフェース（５４１８）と、命令メモリ（５４０５）と、データメモリ（５４０３）と、前記データインタフェースに結合されるバッファ（５４０６）と、前記メッセージインタフェースに結合されるスレッドスケジューリング回路要素（５４０１、５４０４）と、前記データメモリ、前記バッファ、前記命令メモリ、前記スレッドスケジューリング回路要素、及び前記システムインタフェースに結合されるプロセッサ（５４０２）とを有する。

マルチコアのスピードアップパラメータのグラフである。

本開示の実施形態に従ったシステムの図である。

本開示の実施形態に従ったＳＯＣの図である。

本開示の実施形態に従った並列処理クラスタの図である。 本開示の実施形態に従った並列処理クラスタの図である。

グローバルロード／ストア（ＧＬＳ）ユニットの一例の図である。

ＧＬＳプロセッサの概念的動作の例の図である。

ＧＬＳユニットのためのデータフローの例を示す図である。 ＧＬＳユニットのためのデータフローの例を示す図である。

ＧＬＳユニットの更に詳細な例を示す図である。

ＧＬＳユニットのためのスカラロジックを示す図である。

図２では、並列処理を実行するＳＯＣ用アプリケーションの例が見られる。この例では、撮像デバイス１２５０が示される。この（例えば携帯電話又はカメラであり得る）撮像デバイス１２５０は、概して、画像センサ１２５２、ＳＯＣ１３００、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）１３１５、フラッシュメモリ１３１４、ディスプレイ１２５４、及び電力管理集積回路（ＰＭＩＣ）１２５６を含む。動作では、画像センサ１２５２は、（静止画像又はビデオであり得る）画像情報を捕捉することができ、この画像情報はＳＯＣ１３００及びＤＲＡＭ１３１５によって処理され得、不揮発性メモリ（即ち、フラッシュメモリ１３１４）に保存され得る。また、フラッシュメモリ１３１４に保存される画像情報は、ＳＯＣ１３００及びＤＲＡＭ１３１５の使用によって、ディスプレイ１２５４上で使用するために表示され得る。また、撮像デバイス１２５０は、可搬型であることが多く、電源としてバッテリを含む。（ＳＯＣ１３００によって制御され得る）ＰＭＩＣ１２５６は、バッテリ寿命を長持ちさせるために電力使用量の調整を補助し得る。

図３では、本開示の実施形態に従ったシステムオンチップ又はＳＯＣ１３００の例が図示されている。この（典型的には、ＯＭＡＰ（登録商標）等の集積回路又はＩＣである）ＳＯＣ１３００は、（概して上述の並列処理を実行する）処理クラスタ１４００、及び、（上で説明及び参照された）ホスト環境を提供するホストプロセッサ１３１６を概して含む。ホストプロセッサ１３１６は、ワイド（即ち、３２ビット、６４ビット等）ＲＩＳＣプロセッサ（例えばＡＲＭ Ｃｏｒｔｅｘ−Ａ９等）であり得、バスアービトレータ１３１０、バッファ１３０６、（ホストプロセッサ１３１６がインタフェースバス又はＩバス１３３０上で周辺インタフェース１３２４にアクセスすることを許可する）バスブリッジ１３２０、ハードウェアアプリケーションプログラミングインタフェース（ＡＰＩ）１３０８、及び割り込みコントローラ１３２２と、ホストプロセッサバス又はＨＰバス１３２８上で通信する。処理クラスタ１４００は、典型的に、（例えば、荷電結合デバイス、又はＣＣＤインタフェースであり得、オフチップデバイスと通信し得る）機能回路要素１３０２、バッファ１３０６、バスアービトレータ１３１０、及び周辺インタフェース１３２４と、処理クラスタバス又はＰＣバス１３２６上で、通信する。この構成を用いて、ホストプロセッサ１３１６は、ＡＰＩ１３０８を介して情報を提供する（即ち、所望の並列実装に適合するように処理クラスタ１４００を構成する）ことができ、一方、処理クラスタ１４００及びホストプロセッサ１３１６はいずれも、（フラッシュインタフェース１３１２を介して）フラッシュメモリ１３１４に、（メモリコントローラ１３０４を介して）ＤＲＡＭ１３１５に、直接アクセスできる。また、Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ（ＪＴＡＧ）インタフェース１３１８を介して、テスト及びバウンダリスキャンが実行され得る。

図４を参照すると、本開示の実施形態に従った並列処理クラスタ１４００の例が示されている。典型的には、処理クラスタ１４００はハードウェア７２２に対応する。処理クラスタ１４００は、概して、パーティション１４０２−１〜１４０２−Ｒを含む。これらは、ノード８０８−１〜８０８−Ｎ、ノードラッパー８１０−１〜８１０−Ｎ、命令メモリ１４０４−１〜１４０４−Ｒ、及び（以下で詳しく説明する）バスインタフェースユニット又は（ＢＩＵ）４７１０−１〜４７１０−Ｒを含む。ノード８０８−１〜８０８−Ｎは、各々データインターコネクト８１４に（各々のＢＩＵ４７１０−１〜４７１０−Ｒ及びデータバス１４２２を介して）結合され、パーティション１４０２−１〜１４０２−Ｒのための制御及びメッセージが制御ノード１４０６からメッセージ１４２０を介して提供される。また、グローバルロード／ストア（ＧＬＳ）ユニット１４０８及び共有機能メモリ１４１０は、（後述のように）データ移動のための付加的な機能を提供する。それに加えて、レベル３又はＬ３キャッシュ１４１２、（概して、ＩＣ内には含まれない）周辺装置１４１４、（典型的にはフラッシュメモリ１３１４及び／又はＤＲＡＭ１３１５、並びにＳＯＣ１３００内に含まれないその他のメモリである）メモリ１４１６、及びハードウェアアクセラレータ（ＨＷＡ）ユニット１４１８が処理クラスタ１４００と共に用いられる。また、データ及びアドレスを制御ノード１４０６に通信するように、インタフェース１４０５が提供される。

処理クラスタ１４００は、概して、データ転送のために「プッシュ」モデルを使用する。データ転送は要求応答型のアクセスではなく、概してポステッドライトとして現れる。これは、データ転送が一方向であるため要求応答アクセスに比べてグローバルインターコネクト（即ち、データインターコネクト８１４）の占有を２分の１に減らすという利点を有する。概して、インターコネクト８１４を介して要求をルーティングし、その後、応答が要求元へルーティングされ、その結果インターコネクト８１４上で２つの遷移が生成されることは望まれない。プッシュモデルは単一転送を生成する。これは、ネットワークサイズが増大するとネットワークレイテンシが増大するため、またこのことが要求応答型トランザクションのパフォーマンスを低下させることは避けられないことであるため、スケーラビリティに関して重要である。

プッシュモデルは、データフロープロトコル（即ち、８１２−１〜８１２−Ｎ）と同様に、グローバルデータトラフィックを、正確さのために用いられるものまで概して最小化する一方、ローカルノードの利用率に対するグローバルデータフローの影響も概して最小化する。大量のグローバルトラフィックであってもノード（即ち、８０８−ｉ）のパフォーマンスに対する影響は、通常、皆無に近い。ソースはデータを（後述する）グローバル出力バッファに書き込み、転送成功の確認を要求することなく継続する。データフロープロトコル（即ち、８１２−１〜８１２−Ｎ）は、概して、インターコネクト８１４で単一転送を用い、データをあて先へ移動する最初の試みでの転送が成功することを確実にする。（後述する）グローバル出力バッファは（例えば）最大１６出力まで保持することができるため、出力のための瞬時グローバル帯域幅が不充分になることに起因するノード（即ち、８０８−ｉ）のストールの可能性が非常に低くなる。更に、瞬時帯域幅は、要求応答トランザクション又は転送失敗の繰り返しによる影響を受けない。

最後に、プッシュモデルはプログラミングモデルに一層密接に適合する。言い換えるとプログラムは自己データを「フェッチ」せずに、その代わりに、プログラムの入力変数及び／又はパラメータは呼び出される前に書き込まれる。プログラミング環境では、入力変数の初期化は、ソースプログラムによるメモリへの書き込みとして行われる。処理クラスタ１４００内では、これらの書き込みがポステッドライトに変換され、変数の値をノードコンテキストにポピュレートさせる。

（後述する）グローバル入力バッファは、ソースノードからデータを受け取るために用いられる。各ノード８０８−１〜８０８−Ｎのためのデータメモリが単一ポートであるため、入力データの書き込みが、ローカルの単一入力多重データ（ＳＩＭＤ）による読み出しとコンフリクトすることがあり得る。入力データをグローバル入力バッファへ受け入れ、そこで入力データが空きのデータメモリサイクルを待つことができることによって、この競合は回避される（即ち、ＳＩＭＤアクセスとのバンクコンフリクトはない）。データメモリは、（例えば）３２バンクを有し得るため、直ちにバッファがフリーになる可能性が非常に高い。しかしながら、転送を確認するためのハンドシェイキングがないので、ノード（即ち、８０８−ｉ）はフリーのバッファエントリを持つはずである。所望とされる場合は、グローバル入力バッファは、バッファ位置をフリーにするために、ローカルノード（即ち、８０８−ｉ）をストールさせてデータメモリに強制的に書き込みを行うことができるが、このイベントは極めて希であるべきである。典型的には、グローバル入力バッファは２つの別々のランダムアクセスメモリ（ＲＡＭ）として実装されて、一方がデータメモリへ読み出されるべき状態にある間、他方がグローバルデータを書き込むための状態になり得るようにする。メッセージングインターコネクトは、グローバルデータインターコネクトとは分かれているが、同様にプッシュモデルを使用する。

システムレベルでは、所望のスループットにスケーリングされた多数のノードを備えるＳＭＰ又は対称型多重処理のように、ノード８０８−１〜８０８−Ｎが処理クラスタ１４００内で複製される。処理クラスタ１４００は極めて多数のノードにまでスケーリングし得る。ノード８０８−１〜８０８−Ｎはパーティション１４０２−１〜１４０２−Ｒにグループ分けされ、各パーティションは１つ又は複数のノードを有する。パーティション１４０２−１〜１４０２−Ｒは、ノード間のローカル通信を増大させることによって及びより大きなプログラムで一層大量の出力データを計算させることによってスケーラビィリティを促進し、その結果、所望のスループット要件を達成する可能性を更に高める。パーティション（即ち、１４０２−ｉ）内では、ノードはローカルインターコネクトを用いて通信し、グローバルリソースを必要としない。また、パーティション（即ち、１４０４−ｉ）内のノードは、排他的命令メモリを用いる各ノードから共通命令メモリを用いる全てのノードまで、任意の粒度で、命令メモリ（即ち、１４０４−ｉ）を共有することができる。例えば、３つのノードが命令メモリの３つのバンクを共有し、第４のノードが命令メモリの排他的バンクを有することができる。ノードが命令メモリ（即ち、１４０４−ｉ）を共有するとき、それらのノードは、概して、同じプログラムを同期的に実行する。

また、処理クラスタ１４００は非常に多数のノード（即ち、８０８−ｉ）及びパーティション（即ち、１４０２−ｉ）をサポートし得る。しかしながら、１つのパーティションについて４以上のノードを持つと概してノンユニフォームメモリアクセス（ＮＵＭＡ）アーキテクチャに類似するため、パーティション毎のノードの数は通常は４つに限定されている。この例では、パーティションは、（後でインターコネクト８１４に関連して説明する）１つ（又は複数）のクロスバーを介して接続される。クロスバーは概して横断帯域幅が一定している。処理クラスタ１４００は、現在、サイクル毎に１ノード幅のデータ（例えば、６４、１６ビットピクセル）を転送するように設計されており、４サイクルに亘り、１サイクルにつき１６ピクセルの４転送に区分される。処理クラスタ１４００は、概して、レイテンシトレラントであり、インターコネクト８１４がほぼ飽和（この状態を達成するのは合成プログラム以外では極めて難しいことに留意されたい）であっても、ノードバッファリングが、概して、ノードストールを防止する。

典型的には、処理クラスタ１４００はパーティション間で共有する下記のグローバルリソースを含む。
（１） 制御ノード１４０６。これは（メッセージバス１４２０で）システムワイドのメッセージングインターコネクト、イベント処理及びスケジューリング、及びホストプロセッサ及びデバッガ（これらは全て後で詳しく説明する）へのインタフェースを提供する。
（２） ＧＬＳユニット１４０８。これはプログラマブル縮小命令セット（ＲＩＳＣ）プロセッサを含み、システムデータ移動を可能にする。システムデータ移動は、ＧＬＳデータ移動スレッドとして直接コンパイルされ得るＣ＋＋プログラムによって記述され得る。これによって、ソースコードを修正することなく、クロスホスト環境でのシステムコードの実行が可能になり、また、システム又は（後述する）ＳＩＭＤデータメモリ内の任意のアドレス（変数）のセットから別の任意のアドレス（変数）のセットに移動できるため、ダイレクトメモリアクセスよりもより一般的である。ＧＬＳユニット１４０８は、（例えば）０−サイクルのコンテキストスイッチを備え、マルチスレッド化され、例えば、最大１６スレッドまでサポートする。
（３） 共有機能メモリ１４１０。これは、一般のルックアップテーブル（ＬＵＴ）及び統計収集機能（ヒストグラム）を提供する大型共有メモリである。また、これは大型共有メモリを使用して、リサンプリング及び歪補正等のノードＳＩＭＤにより（コストの理由で）充分サポートされていないピクセル処理をサポートし得る。この処理はネイティブタイプとして、スカラ、ベクトル、及び２Ｄアレイを実装する（例えば）６発行命令ＲＩＳＣプロセッサ（即ち、後で詳しく説明するＳＦＭプロセッサ７６１４）を用いる。
（４） ハードウェアアクセラレータ１４１８。これは、プログラマビリティを必要としない機能のため、或いは電力及び／又は面積を最適化するために組み込まれ得る。アクセラレータは、サブシステムにはシステム内の他のノードとして現れ、制御及びデータフローに参加し、イベントを作成可能であり、スケジューリング可能である。またデバッガにとっては可視的である。（ハードウェアアクセラレータは、適用可能であるときは、専用のＬＵＴ及び統計収集を有し得る。）
（５） データインターコネクト８１４及びシステムオープンコアプロトコル（ＯＣＰ）Ｌ３接続１４１２。これらは、ノードパーティション、ハードウェアアクセラレータ、及びシステムメモリ、及び、データバス１４２２上の周辺装置の間のデータ移動を管理する。（ハードウェアアクセラレータは、Ｌ３へのプライベート接続も有し得る）。
（６） デバッグインタフェース。これらは、図には示されていないが、本明細書中に記載される。
ＧＬＳユニット１４０８は、データタイプ、オブジェクト、及び変数の割り振りの一般的Ｃ＋＋モデルを、システムメモリ１４１６、周辺装置１４１４、及びノード８０８−ｉ（適用する場合ハードウェアアクセラレータを含む）等のノード間のデータ移動にマッピングし得る。これにより機能上処理クラスタ１４００の動作と同等の一般的Ｃ＋＋プログラムが可能になり、シミュレーションモデルやシステムダイレクトメモリアクセス（ＤＭＡ）の近似を必要としない。ＧＬＳユニットは、システムデータ構造及びノードデータ構造へのランダムアクセスを用い、Ｃ＋＋コンパイラの対象である充分に一般的なＤＭＡコントローラを実装し得る。この実装は、使用可能なリソースの利用率に関して、たとえデータ移動がＣ＋＋プログラムによって制御されている場合でも、データ移動の効率が従来のＤＭＡコントローラの効率に近くなる。しかしながら、それは、一般に、システムＤＭＡとプログラム変数との間のマッピングの需要を回避し、ＤＭＡペイロードにデータをパック及びアンパックするための多くのサイクルの可能性を回避する。また、それはデータ伝送を自動的にスケジューリングし、それによってＤＭＡレジスタ設定及びＤＭＡスケジューリングのためのオーバーヘッドが回避される。スケジュールミスマッチに起因するオーバーヘッドや非効率性がほとんど無くデータが伝送される。

ＧＬＳユニット１４０８は、データタイプ、オブジェクト、及び変数の割り振りの一般的Ｃ＋＋モデルを、システムメモリ１４１６、周辺装置１４１４、及びノード８０８−ｉ（適用する場合ハードウェアアクセラレータを含む）等のノード間のデータ移動にマッピングし得る。これにより機能上処理クラスタ１４００の動作と同等の一般的Ｃ＋＋プログラムが可能になり、シミュレーションモデルやシステムダイレクトメモリアクセス（ＤＭＡ）の近似を必要としない。ＧＬＳユニットは、システムデータ構造及びノードデータ構造へのランダムアクセスを用い、Ｃ＋＋コンパイラの対象である充分に一般的なＤＭＡコントローラを実装し得る。この実装は、使用可能なリソースの利用率に関して、たとえデータ移動がＣ＋＋プログラムによって制御されている場合でも、データ移動の効率が従来のＤＭＡコントローラの効率に近くなる。しかしながら、それは、一般に、システムＤＭＡとプログラム変数との間のマッピングの需要を回避し、ＤＭＡペイロードにデータをパック及びアンパックするための多くのサイクルの可能性を回避する。また、それはデータ伝送を自動的にスケジューリングし、それによってＤＭＡレジスタ設定及びＤＭＡスケジューリングのためのオーバーヘッドが回避される。スケジュールミスマッチに起因するオーバーヘッドや非効率性がほとんど無くデータが伝送される。

図５を参照すると、ＧＬＳユニット１４０８がより詳細に示されている。ＧＬＳユニット１４０８の主な処理構成要素はＧＬＳプロセッサ５４０２である。ＧＬＳプロセッサ５４０２は、上述したノードプロセッサ４３２２と同様の一般的な３２ビットＲＩＳＣプロセッサであり得るが、ＧＬＳユニット１４０８内での使用にカスタマイズされてもよい。例えば、コンパイルされたプログラムが所望に応じてノード変数のアドレスを生成できるように、ＧＬＳプロセッサ５４０２がノード（即ち、８０８−ｉ）のためのＳＩＭＤデータメモリのためのアドレッシングモードを複製することができるようカスタマイズされてもよい。また、ＧＬＳユニット１４０８は、概して、コンテキスト保存メモリ５４１４、スレッドスケジューリング機構（即ち、メッセージリスト処理５４０２及びスレッドラッパー５４０４）、ＧＬＳ命令メモリ５４０５、ＧＬＳデータメモリ５４０３、リクエストキュー及び制御回路５４０８、データフロー状態メモリ５４１０、スカラ出力バッファ５４１２、グローバルデータＩＯバッファ５４０６、及びシステムインタフェース５４１６を含み得る。また、ＧＬＳユニット５４０２は、インターリーブされたシステムデータをデインターリーブされた処理クラスタデータに変換及びその逆を行う、インターリービング及びデインターリービング用の回路要素、及び構成読み出しスレッド（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅａｄ ｔｈｒｅａｄ）を実装するための回路要素を含み得る。構成読み出しスレッドは、処理クラスタ１４００のための構成（即ち、並列化されたシリアルプログラムのために、処理クラスタ１４００の計算及びメモリリソースに少なくとも部分的に基づくデータ構造）を（プログラム、ハードウェア初期化等を含む）メモリ１４１６からフェッチし、それを処理クラスタ１４００にディストリビュートする。

ＧＬＳユニット１４０８では３つのメインインタフェース（即ち、システムインタフェース５４１６、ノードインタフェース５４２０、及びメッセージングインタフェース５４１８）があり得る。システムインタフェース５４１６では、典型的に、システムメモリ１４１６及び周辺装置１４１４へのアクセスのため、システムＬ３インターコネクトへの接続がある。このインタフェース５４１６は概して、各々２５６ビットＬ３パケットの（例えば）１２８ラインを格納するために充分な大きさの２つのバッファ（ピンポン配置）を有する。メッセージングインタフェース５４１８では、ＧＬＳユニット１４０８は、オペレーショナルメッセージ（即ち、スレッドスケジューリング、シグナルリング終了イベント、及びグローバルＬＳユニット構成）を送信／受信でき、処理クラスタ１４００に対するフェッチされた構成をディストリビュートでき、更に、送信スカラ値を宛先コンテキストに送信することが可能である。ノードインタフェース５４２０では、グローバルＩＯバッファ５４０６は概してグローバルデータインターコネクト８１４に結合される。概して、このバッファ５４０６は、ノードＳＩＭＤデータの６４ライン（例えば、各ラインは１６ビットの６４ピクセルを含み得る）を格納するために充分な大きさである。また、バッファ５４０６は、１サイクル当たり１６ピクセルのグローバル伝送幅にマッチングするように、２５６×１６×１６ビットとして編成され得る。

ここで、メモリ５４０３、５４０５、及び５４１０を参照すると、各々が概してレジデントスレッドに関連する情報を含む。ＧＬＳ命令メモリ５４０５は、スレッドがアクティブであるか否かに拘らず、全てのレジデントスレッドのための命令を概して含む。ＧＬＳデータメモリ５４０３は、全てのレジデントスレッドのための変数、テンポラリ、及びレジスタスピル／フィル値を概して含む。また、ＧＬＳデータメモリ５４０３は、スレッドコンテキスト記述子及び宛先リスト（ノード内の宛先記述子に似ている）を含む、スレッドコードから隠されたエリアを有し得る。また、宛先コンテキストへの出力を含み得るスカラ出力バッファ５４１２がある。このデータは水平グループ内の多数の宛先コンテキストへコピーされるべき順番に概して保たれ、処理クラスタ１４００の処理パイプラインにマッチングするようにスカラデータの伝送をパイプライン化する。データフロー状態メモリ５４１０は処理クラスタ１４００からスカラ入力を受け取る各スレッドのためのデータフロー状態を概して含み、この入力に依存するスレッドのスケジューリングを制御する。

典型的に、ＧＬＳユニット１４０８のためのデータメモリは、いくつかの部分に構成される。データメモリ５４０３のスレッドコンテキストエリアはＧＬＳプロセッサ５４０２のためのプログラムには可視であるが、データメモリ５４０３の残りの部分及びコンテキスト保存メモリ５４１４はプライベートのままである。コンテキスト保存／復元又はコンテキスト保存メモリは、通常、全ての中断されたスレッド（即ち、１６×ｌ６×３２ビットのレジスタコンテンツ）のためのＧＬＳプロセッサ５４０２レジスタのコピーである。データメモリ５４０３内の他の２つのプライベートエリアは、コンテキスト記述子及び宛先リストを含む。

リクエストキュー及び制御５４０８は、ＧＬＳプロセッサ５４０２のためのロード及びストアアクセスをＧＬＳデータメモリ５４０３の外で概して監視する。これらのロード及びストアアクセスは、スレッドにより、システムデータを処理クラスタ１４００へ移動及びその逆を行うように実行されるが、データは通常、ＧＬＳプロセッサ５４０２の中を物理的に流れることはなく、またそれはデータ上で動作を概して実行しない。代わりに、リクエストキュー５４０８がスレッドの「移動」をシステムレベルでの物理的移動に変換し、ロードを移動のためのストアアクセスにマッチングさせ、且つシステムＬ３及び処理クラスタ１４００データフロープロトコルを用いて、アドレス及びデータシーケンシング、バッファ割り付け、フォーマッティング、及び、伝送制御を実行する。

コンテキスト保存／復元エリア又はコンテキスト保存メモリ５４１４は概して、ＧＬＳプロセッサ５４０２のための全てのレジスタを一度に保存及び復元し得るワイドランダムアクセスメモリ又はＲＡＭであり、０−サイクルコンテキスト切り替えをサポートする。スレッドプログラムは、アドレス計算、状態試験、ループ制御等のためのデータアクセス当たり数サイクルを必要とし得る。大量の潜在的スレッドがあるため、且つ、目的が、ピークスループットをサポートするために充分なように全てのスレッドをアクティブに保つことであるため、最小サイクルオーバーヘッドでコンテキスト切り替えが起こることが重要であり得る。また、単一スレッドの「移動」が全てのノードコンテキストのためのデータ（例えば、水平グループ内のコンテキスト当たりの１変数当たり６４ピクセル）を伝送するという事実によって、スレッド実行時間が部分的にオフセットされ得ることに留意すべきであろう。これは、ピークピクセルスループットをサポートする一方で、相当大きな数のスレッドサイクルを可能にし得る。

ここで、スレッドスケジューリング機構を参照すると、この機構はメッセージリスト処理５４０１及びスレッドラッパー５４０４を概して含む。スレッドラッパー５４０４は、典型的に、ＧＬＳユニット１４０８のためのスレッドをスケジューリングするために、入ってくるメッセージをメールボックスに受け取る。概して、スレッド当たり１つのメールボックスエントリがあり、メールボックスエントリは、そのスレッドのための初期プログラムカウントや、スレッドの宛先リストのプロセッサデータメモリ（即ち、４３２８）内の位置等の情報を含み得る。また、このメッセージは、オフセット０で始まり、スレッドのプロセッサデータメモリ（即ち、４３２８）コンテキストエリアに書き込まれる、パラメータリストを含み得る。また、スレッドが中断されるときスレッドプログラムカウントを保存するため、及びデータフロープロトコルを実装するために宛先情報を置くために、スレッド実行中にもメールボックスエントリが用いられる。

ＧＬＳユニット１４０８は、メッセージングに加えて、構成処理も実行する。典型的に、この構成処理は構成読み出しスレッドを実装し得る。構成読み出しスレッドは、処理クラスタ１４００のための構成（プログラム、ハードウェア初期化等を含む）をメモリからフェッチし、それを処理クラスタ１４００の残りの部分にディストリビュートする。典型的に、この構成処理は、ノードインタフェース５４２０で実行される。加えて、ＧＬＳデータメモリ５４０３は、コンテキスト記述子、宛先リスト、及びスレッドコンテキストのためのセクション又はエリアを概して含む。典型的に、スレッドコンテキストエリアはＧＬＳプロセッサ５４０２に対して可視であり得るが、ＧＬＳデータメモリ５４０３の残りのセクション又はエリアは可視でなくてもよい。

ＧＬＳプロセッサ５４０２のためのプログラムが正しく機能するためには、それが、処理クラスタ１４００内の他の３２ビットプロセッサと概して一貫性があり、またノードプロセッサ（即ち、ノードプロセッサ４３２２）及び（以下で説明する）ＳＦＭプロセッサ７６１４と概して一貫性があるメモリの見え方を有するべきであろう。概してＧＬＳプロセッサ５４０２は、他のプロセッサ及び周辺装置（即ち、１４１４）と同等の、システム変数及びデータ構造のためのアドレッシングモードを備える、汎用の３２ビットプロセッサであるため、処理クラスタ１４００と共通のアドレッシングモードを有することは自然なことである。ＧＬＳプロセッサ５４０２がデータタイプ及びコンテキスト編成と共に正しく動作し、Ｃ＋＋プログラミングモデルを使用してデータ伝送を正しく実行するためには、ソフトウェアが問題となる。

概念上、ＧＬＳプロセッサ５４９２はベクトルプロセッサの特殊形式として考えられ得る（ここで、ベクトルは、例えばフレーム内の走査線上の全てのピクセルの形式、又は、例えばノードコンテキスト内の水平グループの形式である）。これらのベクトルは、フレーム幅及びコンテキスト編成に応じて可変数の要素を有し得る。また、ベクトル要素は可変サイズ及びタイプであり得る。また、例えば、ピクセルが同じライン上でピクセルの他のタイプとインターリーブされ得るため、隣接する要素は必ずしも同じタイプではない。ＧＬＳプロセッサ５４０２のためのプログラムは、システムベクトルをノードコンテキストにより用いられるベクトルに変換し得る。これは、オペレーションの一般的なセットではなく、特定の使用例のためのノード−コンテキスト編成から抽象化されたＧＬＳプロセッサ５４０２のためのプログラムの順序付け及び保持に役立つデータフロープロトコルを用い、通常、これらのベクトルの移動及びフォーマッティングに関与する。

システムデータは、異なるピクセルタイプ、データサイズ、インターリービングパターン、パッキング等を反映し得る、多数の異なるフォーマットを有し得る。ノード（即ち、８０８−ｉ）では、ＳＩＭＤデータメモリピクセルデータは、例えばピクセル当たり１６ビットで整合された６４ピクセルの、ワイドで、デインターリーブされたフォーマットである。システムデータとノードデータとの間の通信は、「システムアクセス」が水平グループの全ての入力コンテキストのための入力データを提供することを意図されているという事実によって更に複雑化される。このグループの構成及びその幅は、アプリケーションプログラムの外部のファクタに依存する。このレベルの詳細、即ち特定のノードフォーマットへの及びそれからのフォーマット変換か、又は可変のノードコンテキスト編成のいずれか、をアプリケーションプログラムに晒すことは一般に極めて望まれないことである。これらは、典型的に、アプリケーションレベルで扱うには非常に複雑であり、詳細は実装に依存する。

ＧＬＳプロセッサ５４０２のためのソースコードでは、システム変数のローカル変数への値の割り振りは、システム変数が、ローカルデータタイプに変換され得るデータタイプを有していること、及びその逆を一般に必要とし得る。基本システムデータタイプの例は、文字及び短い整数である。これらは、８、１０、又は１２ビットのピクセルに変換され得る。また、システムデータは、インターリーブされた又はデインターリーブされたかのいずれかのフォーマットの、ピクセルのパックされたアレイ等の合成タイプを有し得る。また、ピクセルは、Ｂａｙｅｒ、ＲＧＢ、ＹＵＶ等のような種々のフォーマットを有し得る。基本ローカルデータタイプの例は、整数（３２ビット）、短い整数（１６ビット）、及び、一対の短い整数（３２ビットにパックされた２つの１６ビット値）である。基本システム及びローカルデータタイプの変数は、アレイ、構造、及びこれらの組合せにおける要素として現れ得る。システムデータ構造は、他のＣ＋＋データタイプとの組合せで、互換性データ要素を含み得る。ローカルデータ構造は、通常、要素としてローカルデータタイプを含み得る。ノード（即ち、８０８−ｉ）は、環状バッファをハードウェア内に直接実装して、トップエッジ及びボトムエッジバウンダリ処理を含む垂直コンテキスト共有をサポートする独自のタイプのアレイを提供する。典型的に、ＧＬＳプロセッサは、ＧＬＳユニット１４０８に含まれ、以下を行なう。
（１）Ｃ＋＋オブジェクトクラスを使用して、ユーザから上述の詳細を抽象化する。
（２）プログラミングモデルにマッピングするシステムへ及びそのシステムからのデータフローを提供する。
（３）処理クラスタ１４００のデータ依存性フレームワークに適合する、非常に一般的な高性能ダイレクトメモリアクセスと同等のことを実行する。
（４）効率的な処理クラスタ１４００動作のために自動的にデータフローをスケジューリングする。

アプリケーションプログラムは、インターリーブされたフォーマット（インスタンスのフォーマットは属性によって特定される）でシステムピクセルを表すために、フレーム（Ｆｒａｍｅ）と称されるクラスのオブジェクトを用いる。Ｆｒａｍｅは、所与の垂直オフセットでの走査線の位置を特定するアレイインデックスを備えて、ラインのアレイとして編成される。Ｆｒａｍｅオブジェクトの異なるインスタンスは、異なるピクセルタイプの異なるインターリーブされたフォーマットを表し得る。これらのインスタンスの多数が同じプログラムで用いられ得る。Ｆｒａｍｅオブジェクト内の割り振り演算子は、データが処理クラスタ１４００に伝送されるか、又は処理クラスタ１４００から伝送されるかに依存して、そのフォーマットに適切なデインターリービング又はインターリービング動作を実行する。

ローカルデータタイプ及びコンテキスト編成の詳細は、クラスライン（Ｌｉｎｅ）の概念を導入することによって抽象化される（ＧＬＳユニット１４０８ではＢｌｏｃｋデータは、ブロックに多数のラインを提供する明示的な繰り返しを備える、Ｌｉｎｅデータのアレイとして扱われる）。Ｌｉｎｅオブジェクトは、ＧＬＳプロセッサ５４０２のためのプログラムによって実装されると、互換性のシステムデータタイプからの変数の割り振り、又は互換性のシステムデータタイプへの割り振り以外の動作は概してサポートしない。Ｌｉｎｅオブジェクトは、例えば、ピクセルタイプ、ノードの入力及び出力の両方、データがパックされるか否か、データがどのようにパックされアンパックされるか、データがインターリーブされるか否か、インターリービング及びデインターリービングパターン、及びノードのコンテキスト構成などの、システム／ローカルデータ通信の全ての属性を通常、カプセル化する。

図６を参照すると、ＧＬＳプロセッサ５４０２の画像処理アプリケーションのための読み出し及び書き込みスレッドの概念的動作の例が示されている。プログラマーから見ると、この例では、フレームはインターリーブされたＢａｙｅｒピクセルのバッファで概して構成される。インターリーブされたピクセル上で動作するのは、共有機能メモリ１４１０内のノード（即ち、８０８−ｉ）又はＳＩＭＤにとって概して非効率である。理由は、通常、異なる動作は異なるピクセルタイプ上で実行され、そのため、単一命令は概してインターリーブされたフォーマットの全てのピクセルに適用され得ないからである。この理由により、図６のノードコンテキストに示されるＬｉｎｅデータは、デインターリービングによって取得される。システムデータは必ずしもインターリーブされる必要はない。例えば、アプリケーションはシステムメモリ１４１６を、処理クラスタ１４００によって使用されるデインターリーブされたフォーマットのままの中間結果を得るために使用し得る。しかしながら、殆どの入力及び出力フォーマットはインターリーブされる。ＧＬＳユニット１４０８はこれらのフォーマットとデインターリーブされた処理クラスタ１４００表現との間の変換を行なうべきであろう。

ＧＬＳプロセッサ５４０２は、システムフォーマット又はノードコンテキストフォーマットのいずれかでピクセルのベクトルを処理する。しかしながら、この例のＧＬＳプロセッサ５４０２のためのデータパスは、これらのベクトル上ではどの動作も直接実行しない。この例で、プログラミングモデルによってサポートされ得る動作は、ＦｒａｍｅからＬｉｎｅ、又は共有機能メモリ１４１０ブロックタイプへの割り振り、及びその逆であり、Ｌｉｎｅ又はＢｌｏｃｋオブジェクト上で動作する処理クラスタノードによってＦｒａｍｅオブジェクト上での直接動作と同等のことを達成するために必要とされる任意のフォーマッティングを実行する。

フレームのサイズは幾つかのパラメータによって決定される。幾つかのパラメータとは、ピクセルタイプの数、ピクセル幅、バイトバウンダリーへのパディング、及び、走査線当たりのピクセルの数及び走査線の数におけるフレームの幅及び高さを含む。これらのパラメータは解像度に応じて変化し得る。フレームは処理クラスタ１４００コンテキストにマッピングされる。処理クラスタ１４００コンテキストは実際の像よりもより幅が狭い水平グループ、フレーム分割、として通常編成される。フレーム分割は、Ｌｉｎｅ又はＢｌｏｃｋタイプとしての処理のために、処理クラスタ１４００の中でスワップされる。この処理は結果を生成し、結果が別のＦｒａｍｅであるとき、その結果は通常、フレーム分割上の処理クラスタ１４００動作の部分的中間結果から、再構築される。

クロスホストのＣ＋＋プログラミング環境では、フレーム分割を処理するためにハードウェアで必要とされる複雑性を概して除去するために、クラスＬｉｎｅのオブジェクトは、この例の像の全体の幅であるとみなされる。この環境では、Ｌｉｎｅオブジェクトのインスタンスが走査線全体に亘る水平方向の繰り返しを含む。Ｆｒａｍｅオブジェクトの詳細は、オブジェクト実装によって抽象化されず、デインターリービング及びインターリービングのために必要とされるビットレベルのフォーマッティングを隠すために、及び、ＧＬＳプロセッサ５４０２のための命令に変換可能にするために、Ｆｒａｍｅオブジェクト内のイントリンシックによって抽象化される。これによって、クロスホストのＣ＋＋プログラムが、処理クラスタ１４００の環境に依存せずに、処理クラスタ１４００の環境での実行と同等の結果を得ることが可能になる。

処理クラスタ１４００のためのコード生成環境では、Ｌｉｎｅはスカラタイプ（一般に整数に等しい）であり、例外は、コード生成が、ＳＩＭＤデータメモリからのアクセスのための水平ピクセルオフセットに対応するアドレッシング属性をサポートすることである。この例の走査線上の繰り返しは、ＳＩＭＤでの並列動作、ノード（即ち、８０８−ｉ）上のコンテキスト間の繰り返し、及びノードの並列動作の組合せによって達成される。フレーム分割は、（フレーム及びフレーム分割のパラメータを知っている）ホストソフトウェア、（ホストから送られるパラメータを使用する）ＧＬＳソフトウェア、及び（データフロープロトコルを用いて右端のバウンダリを検出する）ハードウェアの組合せによって制御され得る。ＦｒａｍｅはＧＬＳプログラムによって実装されるオブジェクトクラスである。例外は、クラス実装のほとんどが、後述するように、ＧＬＳプロセッサ５４０２のための命令によって直接達成されることである。Ｆｒａｍｅオブジェクトのために定義されるアクセス関数は、ハードウェアがアクセス及び動作フォーマッティングを制御し得るように、所与のインスタンスの属性をハードウェアにロードするという副次的な効果を有する。これらの動作は、所望のスループットでソフトウェアに実装するには、概して非効率過ぎるであろうし、多数のスレッドがアクティブである場合は特にそうである。

Ｆｒａｍｅオブジェクトの幾つかのアクティブなインスタンスがあり得るので、任意の所与の時点で、ハードウェア内でアクティブな幾つかの構成があることが予想される。オブジェクトが例示されると、コンストラクタがそのオブジェクトに属性を関連付けする。所与のインスタンスのアクセスは、そのインスタンスの属性をハードウェアにロードする。これは概念上は、インスタンスのデータタイプを定義するハードウェアレジスタと似ている。各インスタンスがそれ自体の属性を有するため、多数のインスタンスがアクティブになり得るし、各々が、フォーマッティングを制御するための、それら自体のハードウェア設定を有する。

読み出しスレッド及び書き込みスレッドは、独立プログラムとして書かれる。そのため、それらのそれぞれの制御及びデータフローに基づいて各々が独立してスケジューリングされ得る。下記の２つのセクションは、読み出しスレッド及び書き込みスレッドの例を提供し、スレッドコード、Ｆｒａｍｅクラス宣言、及び、非常に少数の命令を用い、非常に複雑なピクセルフォーマッティングで、これらがどのように大きなデータ伝送を実装するために用いられるかを示す。

読み出しスレッドは、システムデータを表す変数を、処理クラスタ１４００プログラムへの入力を表す変数に割り振る。これらの変数は、スカラデータを含む任意のタイプであり得る。概念的には、読み出しスレッドは、例えば、固定幅のフレーム分割内で垂直方向に、繰り返しの幾つかの形式を実行する。ループ内では、Ｆｒａｍｅオブジェクト内のピクセルは、Ｆｒａｍｅの詳細、及びフレーム分割の編成（Ｌｉｎｅの幅）がソースコードから隠されて、Ｌｉｎｅオブジェクトに割り振られる。また、他のベクトル又はスカラタイプの割り振りもあり得る。各ループ繰り返しの終わりに、宛先処理クラスタ１４００プログラムがＳｅｔ＿Ｖａｌｉｄを用いて呼び出される。ループ繰り返しは通常、データのハードウェア伝送に関して非常に速く実行する。ループ実行は、所望の伝送を実行するようにハードウェアバッファ及び制御を構成する。繰り返しの終わりに、（タスク切り替え命令によって）スレッド実行が中断されるが、ハードウェア伝送は継続する。これは、他のスレッドを実行するためにＧＬＳプロセッサ５４０２をフリーにする。このことは、単一のＧＬＳプロセッサ５４０２プロセッサが最大（例えば）１６スレッドの伝送を制御することがあり得るため、重要なことであり得る。ハードウェア伝送が完了すると、中断されたスレッドが再び実行可能にされる。

ベクトル出力は通常、繰り返しキューのテールでのエントリによって、制御される。このエントリ及び他のエントリはスカラデータを制御する。この理由は、図７に示すように、スレッドから直接ベクトルデータを受け取らないプログラムへのスカラパラメータの出力をサポートするためである。この例では、読み出しスレッドは、プログラムＡにベクトルデータを、プログラムＡ〜Ｄにスカラデータを提供する。データフローのこのスタイルは、プログラムＡ〜Ｄの並列実行の潜在性を消すシリアル化を導入する。このケースでは、並列実行は、パイプライン実行によって達成されて、そのため、プログラムＡが読み出しスレッドの繰り返しＮからデータを受け取り、実行し、プログラムＢの同じ繰り返しＮにデータを出力する、という様に行なわれるようにする。実行の任意の所与の時点で、プログラムＡ〜Ｄは、それぞれ読み出しスレッドの繰り返しＮ〜Ｎ−３に基づいて実行する。これをサポートするために、読み出しスレッドは、繰り返しＮ〜Ｎ−３のためのデータを同時に出力するべきであろう。そうでない場合、読み出しスレッドの繰り返しはその繰り返しの全ての出力とインターロックし、読み出しスレッドの繰り返しＮは、繰り返しＮのための入力を受け取るためにプログラムＤを待たなければならず、このインタバルの間、他のプログラムは中断されることになろう。

処理パイプラインの同レベル（コンテキスト記述子の出力遅延と同じ値を備えるプログラム）に読み出しスレッドを入力させ、それによって、読み出しスレッドがその出力のパイプライン段で動作するようにすることによってこのシリアル化は避けられ得る。これは、入力の各レベルのための追加の読み出しスレッドのコストが発生する。これはベクトル入力の場合、ベクトル入力がシステムからの入力である段の数は概して限られているため、許容可能である。しかしながら、全てのプログラムが、システムから、又は読み出しスレッドによる計算（例えば、各処理段の環状バッファを制御する垂直インデックスパラメータ）のいずれかで、各繰り返しのためにスカラパラメータを更新することを要求し得る可能性が高い。これは、各パイプライン段のために読み出しスレッドを必要とし、読み出しスレッドの数に大きすぎる需要を課すことになろう。

スカラデータはベクトルデータよりはるかに小さいメモリを必要とし得るので、ＧＬＳユニット１４０８はスカラ出力バッファ５４１２内の各繰り返しからのスカラデータをストアし、繰り返しキューを使用して、処理パイプラインをサポートするよう、必要に応じてこのデータを提供し得る。これは、必要とされるバッファリングが全てのノードのＳＩＭＤメモリの規模になるであろうため、ベクトルデータの場合は、通常、実現可能ではない。

ＧＬＳユニット１４０８からのスカラ出力のパイプライン化が図８に示される。図示されるように、ＧＬＳユニット１４０８アクティビティ、プログラム実行、及びプログラム間の伝送がある。一番上のシーケンスはプログラムＡの実行にインターリーブされたＧＬＳスレッドアクティビティを示す。（簡潔さのために、ベクトル及びスカラ伝送が同じ時間量を取って示されている。実際にはベクトル伝送ははるかに長い時間を要し、プログラムＡの多数の宛先コンテキストに書き込み、スカラデータをベクトルデータと共にこれらのコンテキストにコピーする。これは、図示されていないがプログラムＡのインスタンスをパイプライン化する効果を有する。）第１の繰り返しでは、読み出しスレッドは、プログラムＡのためのベクトルデータ、及びプログラムＡ〜Ｄのためのスカラデータの出力をトリガする。これは、ベクトルＡ１及びスカラＡ１〜スカラＤｌによって示される。これは第１の繰り返しであるので、全ての宛先コンテキストはアイドルであり、これらの伝送の全てが実行され得る。従って、この繰り返しのためには、繰り返しキューエントリはこれらの伝送が完了した後にフリーになり得る。この繰り返しの出力はプログラムＡの実行を可能にし、プログラムＡはデータベクトルＢ１を出力する。

後続のプログラムは、入力を受け取ると、実行し、実行パイプラインを反映するように時間がスキュー（ｓｋｅｗ）する。第１の繰り返しの間、各プログラムがＲｅｌｅａｓｅ＿ｌｎｐｕｔを信号送出するまで、読み出しスレッドはスカラデータを宛先コンテキストに出力することができない。この理由のため、宛先コンテキストがＳＰで入力をイネーブルするまで、スカラＢ２〜スカラＤ２は、スカラ出力バッファ５４１２内に保持される。このデータのスカラ出力バッファ５４１２内の期間はグレーの破線矢印によって示され、スカラデータがソースプログラムからのベクトル入力に同期していることを示す。また、この時間の間、他の繰り返しのためのデータは、処理パイプラインの深さまで、この例では、およそ４繰り返しまで、スカラ出力バッファ内に蓄積される。これらの繰り返しの各々は、データタイプ、宛先、及びスカラ出力バッファ内のスカラデータの位置を後続の繰り返しのために記録する、繰り返しキューエントリを有する。

各宛先へのスカラ出力が完了すると、その事実が繰り返しキュー内に記録される（タイプフラグを００’ｂに設定することによって、ＬＳＢが１になる）。全てのタイプのフラグが０になると、これは繰り返しからの全ての出力が完了したことを示し、繰り返しキューエントリはフリーにされ得る。この時点で、スカラ出力バッファ５４１２のコンテンツはこの繰り返しのために無視され、メモリは後続スレッドの実行による割り当てのためにフリーにされる。

ＧＬＳスレッドは、スケジュール読み出しスレッド及びスケジュール書き込みスレッドメッセージによってスケジューリングされる。このスレッドがスカラ入力（読み出し又は書き込みスレッド）又はベクトル入力（書き込みスレッド）に依存しない場合、それは、スケジューリングメッセージを受け取るときに実行レディになる。そうでない場合、スカラ入力に依存するスレッドについてはそのスレッドはＶｉｎが設定されるときレディになり、又はグローバルインターコネクト（書き込みスレッド）でベクトルデータが受け取られるまでレディになる。レディスレッドはラウンドロビン順に実行するようにイネーブルされる。

スレッドが実行を開始すると、所与の繰り返し分の全ての伝送が開始されるまで実行を継続し、全ての伝送が開始された時点で、スレッドは明示的タスク切り替え命令によって中断され、その間ハードウェア伝送が完了する。タスク切り替えは、変数割り振り及びフロー分析に依存して、コード生成によって決定される。読み出しスレッドについては、全ての宛先への、全てのベクトル及びスカラの処理クラスタ１４００への割り振りは、スレッド中断時点で完了していなければならない（典型的に、これは繰り返し内の任意のコードパスに沿った、最後の割り振りの後である）。タスク切り替え命令は、各宛先への最終伝送のための、Ｓｅｔ＿Ｖａｌｉｄをアサートさせる（ハードウェアが伝送の数を知っていることに基づく）。書き込みスレッドについては、分析は同様であるが、例外は、割り振りがシステムに対して行なわれ、Ｓｅｔ＿Ｖａｌｉｄは、明示的には設定されないことである。スレッドが中断されると、ハードウェアは、中断されたスレッドの全てのコンテキストを保存し、次のレディスレッドがある場合は、それをスケジューリングする。

スレッドが中断されると、ハードウェアがそのスレッドによって開始された全てのデータ伝送を完了するまで、中断のままになり得る。これは、以下の伝送条件に依存して幾つかの異なる方法で指示され得る。
− 水平グループ（多数の処理ノードコンテキスト又は単一のＳＦＭコンテキスト）に対して走査線を出力する読み出しスレッドの場合、データ伝送の完了は、右端のコンテキスト又は共有機能メモリ入力への最後の伝送によって指示され、伝送をイネーブルするＳＰ内にＲｔ＝１を有するコンテキストへ伝送されるＳｅｔ＿Ｖａｌｉｄフラグによって指示される。
− ＳＦＭコンテキストへブロックを出力する読み出しスレッドの場合、ハードウェアは、ラインに似た水平次元の全てのデータを提供し、最終伝送はＢｌｏｃｋ＿Ｗｉｄｔｈによって決定される。明示的ソフトウェア繰り返しが垂直次元のブロックデータを提供する。
− ノード又はＳＦＭコンテキストから入力を受け取る書き込みスレッドの場合、最終データ伝送は、ＨＧ＿Ｓｉｚｅ又はＢｌｏｃｋ＿Ｗｉｄｔｈにマッチングする伝送のためのＳｅｔ＿Ｖａｌｉｄによって指示される。

スレッドが実行のために再度イネーブルされると、伝送の別のセットを開始するか、又は終了し得る。読み出しスレッドはＥＮＤ命令の実行によって終了し、その結果、初期宛先ＩＤを使用して、ＯＴｅ＝ｌを有する全ての宛先にＯＴ信号が送られる。書き込みスレッドは１つ又は複数のソースからＯＴを受け取るため概して終了するが、ＥＮＤ命令を実行するまで、完全に終了したとはみなされない。そのホワイルループは終了するが、プログラムは終了に基づいて後続のホワイルループで継続することが可能である。いずれの例でも、ＥＮＤを実行し、全てのデータ伝送が完了し、全てのＯＴが送信された後、スレッドはスレッド終了メッセージを送り得る。

読み出しスレッドは繰り返しの２つの形式を有し得る。即ち、明示的ＦＯＲループ又は他の明示的繰り返し、或いは、書き込みスレッドと同様の処理クラスタ１４００からのデータ入力でのループ（終了がなければループする）である。第１の例では、任意のスカラ入力は全てのループ繰り返しが実行されるまでリリースされているとはみなされない。スカラ入力はスレッドのための実行の全期間に適用される。第２の例では、各繰り返しの後、（Ｒｅｌｅａｓｅ＿ｌｎｐｕｔのシグナルが送られて）入力がリリースされ、新しい入力が受け取られるべきであり、スレッドが実行のためにスケジューリングされ得る前に、Ｖｉｎを設定する。スレッドは、書き込みスレッドと同様、ＯＴの受け取りの後データフロー上で終了する。

ＧＬＳプロセッサ５４０２は、読み出し及び書き込みスレッドの動作に基づいてハードウェア制御をサポートするための専用インタフェースを含み得る。このインタフェースは、ＧＬＳデータメモリ５４０３へのＧＬＳプロセッサ５４０２の通常のアクセスと、特定の又は特殊化されたアクセスとを区別することを可能にし得る。また、ＧＬＳプロセッサ５４０２にこのインタフェースを制御させるための、以下の命令があり得る。
− ロードシステム（ＬＤＳＹＳ）命令。この命令は特定されたシステムアドレスからＧＬＳプロセッサ５４０２のレジスタをロードし得る。これは概して、ハードウェアに対してターゲットレジスタ及びシステムアドレスを識別する目的のダミーロードであり得る。また、この命令は、Ｌｉｎｅ又はＢｌｏｃｋとして処理クラスタ１４００に伝送されるべきシステムＦｒａｍｅのためのフォーマッティング情報を含む、ＧＬＳデータメモリ５４０３からの属性ワードにアクセスする。属性アクセスは、ＧＬＳプロセッサ５４０２レジスタをターゲットとしないが、代わりに、この情報をハードウェアレジスタにロードし、ハードウェアがこの伝送を制御できるようにする。最後に、この命令はインターリーブされたＦｒａｍｅフォーマットでアクセスされたピクセルの相対位置をハードウェアに示す３ビットフィールドを含む。
− スカラ及びベクトル出力命令（ＯＵＴＰＵＴ、ＶＯＵＴＰＵＴ）。これらの命令はＧＬＳプロセッサ５４０２のレジスタをコンテキスト内にストアし得る。スカラ出力では、ＧＬＳプロセッサ５４０２はデータを直接提供する。ベクトル出力では、これは、（出力を前のＬＤＳＹＳアドレスに関連付ける）ソースレジスタを識別する目的のため、及び宛先コンテキストにオフセットを指定するための、ダミーストアである。Ｌｉｎｅ又はＢｌｏｃｋ出力はＨＧ＿Ｓｉｚｅ又はＢｌｏｃｋ＿Ｗｉｄｔｈを指定するための関連付けられた垂直インデックスパラメータを有し、それによって、ライン又はブロックに伝送するための（例えば）３２ピクセル要素の数をハードウェアが知る。
− ベクトル入力命令（ＶＩＮＰＵＴ）。この命令は、データメモリ５４０３位置をＧＬＳプロセッサ５４０２仮想レジスタにロードする。これはデータメモリ５４０３からの仮想Ｌｉｎｅ又はＢｌｏｃｋ変数のダミーロードであり、その目的は、ターゲット仮想レジスタ、及び仮想変数のためのデータメモリ５４０３内のオフセットを識別するためである。Ｌｉｎｅ又はＢｌｏｃｋ出力はＨＧ＿Ｓｉｚｅ又はＢｌｏｃｋ＿Ｗｉｄｔｈを指定するための、関連付けられた垂直インデックスパラメータを有する。それによって、ライン又はブロックに伝送するための（例えば）３２ピクセル要素の数をハードウェアが知る。
− ストアシステム（ＳＴＳＹＳ）命令。この命令は仮想ＧＬＳプロセッサ５４０２レジスタを指定されたシステムアドレスにストアする。これは、（このストアを前のＶＩＮＰＵＴオフセットに関連付ける）仮想ソースレジスタを識別し、（通常は、受け取った他の入力とのインターリービングの後）それがストアされるべき箇所のシステムアドレスを指定するためのダミーストアである。また、この命令は、処理クラスタ１４００Ｌｉｎｅ又はＢｌｏｃｋから伝送されるべきシステムＦｒａｍｅのためのフォーマッティング情報を含む、データメモリ５４０３からの属性ワードにアクセスする。属性アクセスはＧＬＳプロセッサ５４０２をターゲットにしないが、代わりに、この情報をハードウェアレジスタにロードして、それによって、ハードウェアがその伝送を制御できるようにする。最後に、命令は、インターリーブされたＦｒａｍｅフォーマットで、アクセスされたピクセルの相対位置をハードウェアに示す３ビットフィールドを含む。
ＧＬＳプロセッサ５４０２のためのデータインタフェースは、以下の情報及び信号を含み得る。
− 以下を指定するアドレスバス。
１）ＬＤＳＹＳ及びＳＴＳＹＳ命令のためのシステムアドレス。
２）ＯＵＴＰＵＴ及びＶＯＵＴＰＵＴ命令のための処理クラスタ１４００オフセット、又は
３）ＶＩＮＰＵＴ命令のためのデータメモリ５４０３オフセット
これらは、アドレスを提供する命令により区別される。
− 伝送の数を指定し、Ｌｉｎｅ又はＢｌｏｃｋ伝送のためのアドレスシーケンシングを制御するパラメータＨＧ＿Ｓｉｚｅ／Ｂｌｏｃｋ＿Ｗｉｄｔｈ。
− ロードタイプ又はストアタイプ命令のためのダミーターゲット又はソースである仮想レジスタ識別子。
− ＯＵＴＰＵＴ及びＶＯＵＴＰＵＴ命令のための、命令からのＤｓｔ＿Ｔａｇのための値。
− データメモリ５４０３からＧＬＳハードウェアレジスタへフォーマッティング属性をロードするためのストローブ。
− ＯＵＴＰＵＴ命令に対しスカラ伝送の幅を指示するための、又はＶＯＵＴＰＵＴ命令に対しノードＬｉｎｅ、ＳＦＭＬｉｎｅ、及びＢｌｏｃｋ出力を区別するための、２ビットフィールド。ベクトル出力は、データタイプに依存する異なるアドレスシーケンシング及びデータフロープロトコル動作を必要とし得る。また、このフィールドは、ベクトル出力ではＢｌｏｃｋ＿Ｅｎｄを、スカラ及びベクトル出力ではＩｎｐｕｔ＿Ｄｏｎｅをエンコードする。
− ＳＦＭＬｉｎｅ入力に対し、環状バッファ内の最後のラインを指定するための信号。これは、Ｐｏｉｎｔｅｒ＝Ｂｕｆｆｅｒ＿Ｓｉｚｅのときに、環状バッファ垂直インデックスパラメータに基づき、また、ＬｉｎｅＡｒｒａｙ出力に対しＦｉｌｌを信号送信するために用いられる。
− スレッドがアクティブにされるとき、Ｏｕｔｐｕｔ＿Ｔｅｒｍｉｎａｔｅ信号を受け取ったスレッドのためにアサートされるＧＬＳプロセッサ５４０２への入力。これは、ＧＬＳプロセッサ５４０２条件状態レジスタビットとしてテストされ、アサートされるとスレッドを終了させる。

この例のＧＬＳユニット１４０８は以下のいずれかの特徴を有し得る。
− 同時に最大８の読み出し及び書き込みスレッドをサポート。
− ＯＣＰ接続１４１２は読み出し及び書き込みデータのために、１２８ビット接続を有し得る（通常の読み出し、書き込みスレッド動作では最大８ビート、構成読み出し動作では１６ビートの読み出し）。
− 処理クラスタ１４００内でノード／パーティションからデータを送受信するための２５６ビット、２ビートのバーストインターコネクトマスター及び、２５６ビット、２ビートのバーストスレーブインタフェース。
− ＧＬＳユニット１４０８が処理クラスタ１４００の残りにメッセージを送るための３２ビット、３２ビート（最大）のメッセージングマスターインタフェース。
− ＧＬＳユニット１４０８が処理クラスタ１４００の残りからメッセージを受け取るための３２ビット、３２ビート（最大）のメッセージングスレーブインタフェース。
− インターコネクト８１４上のデータアクティビティをモニターし、アクティビティがないときに、制御ノードにシグナルを送って、制御ノードが処理クラスタ１４００のサブシステムの電源をダウンすることができるようにするための、インターコネクトモニターブロック。
− システムインタフェース５４１６上の多数のタグの割り振り及び管理（最大３２タグ）。
− 読み出しスレッドデータパス内のデインターリーバ。
− 書き込みパス内のインターリーバ。
− 読み出し及び書き込み双方のスレッドでは、ライン当たり最大８カラー(位置)をサポート。
− 読み出しスレッドに対し、最大８ライン（ピクセル＋データ）をサポート。
− 読み出しスレッドに対し、最大４ライン（ピクセル＋データ）をサポート。

図９を参照すると、ＧＬＳユニット１４０８のより詳細な例が示されている。図示されるように、ＧＬＳユニット１４０８のコアは、ＧＬＳプロセッサ５４０２であり、これは、様々なスレッドプログラムを走らせ得る。スレッドプログラムは、（概して命令メモリＲＡＭ６００５及び命令メモリアービタ６００６を含む）命令メモリ５４０５内の様々な位置に、命令として予めロードされ得、スレッドがアクティブのときはいつでも呼び出され得る。スレッド／コンテキストは、読み出しスレッド又は書き込みスレッドがスケジューリングされるときはいつでも、アクティブにされ得る。スレッドは、（マスターメッセージングインタフェース６００３及びスレーブメッセージングインタフェース６００４を概して含む）メッセージングインタフェース５４１８を介してＧＬＳユニット１４０８によって受け取られるメッセージを介して実行するようにスケジューリングされる。

読み出しスレッドデータフローを先ず参照すると、データがＯＣＰ接続１４１２からインターコネクト８１４へ伝送されるべきとき、読み出しスレッドがＧＬＳユニット１４０８によって処理される。読み出しスレッドはスケジュール読み出しスレッドメッセージによってスケジューリングされ、スレッドがスケジューリングされると、ＧＬＳユニット１４０８は、スレッドのためのパラメータ（即ち、ピクセルパラメータ）を得るようにＧＬＳプロセッサ５４０２をトリガし得、データ（即ち、ピクセルデータ）をフェッチするようにＯＣＰ接続１４１２にアクセスし得る。データがフェッチされると、（ＧＬＳプロセッサ５４０２から受け取り）ストアされた構成情報に従ってデインターリーブ及びアップサンプリングされ得、データインターコネクト８１４を介して適切な宛先に送られる。データフローは、ソース通知、ソース許可、及び出力終了メッセージを使用して、スレッドが終了する（ＧＬＳプロセッサ５４０２によって通知される）まで維持される。スカラデータフローは更新データメモリメッセージを使用して維持される。

もう１つのデータフローは構成読み出しスレッドである。構成読み出しスレッドは、構成データがＯＣＰ接続１４１２からＧＬＳ命令メモリ５４０５に、又は処理クラスタ１４００内部の他のモジュールのいずれかに伝送されるべきときに、ＧＬＳユニット１４０８によって処理される。構成読み出しスレッドは、スケジュール構成読み出しメッセージによってスケジューリングされる。メッセージがスケジューリングされると、基本構成情報を得るためにＯＣＰ接続１４１２がアクセスされる。この基本構成情報は、実構成データを得るためにデコードされ、適切な宛先（宛先が処理クラスタ１４００内の外部モジュールではデータインターコネクト８１４を介して）に送られる。

更に別のデータフローは、書き込みスレッドである。書き込みスレッドは、データがデータインターコネクト８１４からＯＣＰ接続１４１２に伝送されるべきときに、ＧＬＳユニット１４０８によって処理される。書き込みスレッドは、スケジュール書き込みスレッドメッセージによってスケジューリングされ、スレッドがスケジューリングされると、ＧＬＳユニット１４０８は、そのスレッドのためのパラメータ（即ち、ピクセルパラメータ）を得るように、ＧＬＳプロセッサ５４０２をトリガする。その後、ＧＬＳユニット１４０８は、データ（即ち、ピクセルデータ）がデータインターコネクト８１４を介して到着するのを待ち、データインターコネクト８１４からのデータが受け取られると、それは、（ＧＬＳプロセッサ５４０２から受け取り）ストアされた構成情報に基づいて、インターリーブ及びダウンサンプリングされ、ＯＣＰ接続１４１２に送られる。データフローは、ソース通知、ソース許可、及び出力終了メッセージを使用して、スレッドが終了（ＧＬＳプロセッサ５４０２によって通知されるように）するまで維持される。スカラデータフローは更新データメモリメッセージを使用して維持される。

ここで、（データメモリＲＡＭ６００７及びデータメモリアービタ６００８を概して含む）ＧＬＳデータメモリ５４０３のための編成を参照すると、このメモリ５４０３は、全てのレジデントスレッドのための、種々の変数、一時変数、及び、レジスタスピル／フィル値をストアするように構成される。また、それは、スレッドコンテキスト記述子及び宛先リスト（ノードの宛先記述子に似ている）を含むスレッドコードから隠されたエリアを有し得る。具体的には、この例の場合、データメモリＲＡＭ６００７の最初の８個の位置は、１６のコンテキスト記述子を保持するように、コンテキスト記述子のために割り当てられる。この例のための、宛先リストは、データメモリＲＡＭ６００７の次の１６個の位置を占有する。更には、各コンテキスト記述子が、他の処理ノード（又は他のスレッド）からのスカラ値に依存するか否か、及びもしそうであれば、スカラデータのためにデータソースが幾つあるかを指定する。この例では、ＧＬＳデータメモリ５４０３の残りは、（変数割り当てを有する）スレッドコンテキストを保持する。

ＧＬＳデータメモリ５４０３は、多数のソースによってアクセスされ得る。多数のソースは、ＧＬＳユニット１４０８のための内部ロジック（即ち、ＯＣＰ接続１４１２及びデータインターコネクト８１４へのインタフェース）、（動作のデバッグモードの間、データメモリ５４０３コンテンツを変更し得る）ＧＬＳプロセッサ５４０２のためのデバッグロジック、メッセージングインタフェース５４１８（スレーブメッセージングインタフェース６００３及びマスターメッセージングインタフェース６００４の両方）、及びＧＬＳプロセッサ５４０２である。データメモリアービタ６００８は、データメモリＲＡＭ６００７へのアクセスをアービトレート可能である。

ここで、（コンテキスト状態ＲＡＭ６０１４及びコンテキスト状態アービタ６０１５を概して含む）コンテキスト保存メモリ５４１４を参照すると、このメモリ５４１４は、ＧＬＳユニット１４０８内でコンテキスト切り替えが行なわれるとき、コンテキスト情報を保存するために、ＧＬＳプロセッサ５４０２によって用いられ得る。コンテキストメモリは、各スレッドのための位置を有する（即ち、合計１６がサポートされている）。各コンテキスト保存ラインは、例えば、６０９ビットであり、各ラインの編成の例は、上で詳しく説明されている。アービタ６０１５は、ＧＬＳプロセッサ５４０２からのアクセスのためのコンテキスト状態ＲＡＭ６０１４へのアクセス、及び（動作のデバッグモードの間、コンテキスト状態メモリＲＡＭ６０１４のコンテンツを変更し得る）ＧＬＳプロセッサ５４０２のためのデバッグロジックをアービトレートする。典型的に、読み出し又は書き込みスレッドがＧＬＳラッパーによってスケジューリングされるときはいつでも、コンテキスト切り替えが起こる。

（命令メモリＲＡＭ６００５及び命令メモリアービタ６００６を概して含む）命令メモリ５４０５を用いる場合、それはＧＬＳプロセッサ５４０２のための命令を全てのラインにストアし得る。典型的にアービタ６００６は、ＧＬＳプロセッサ５４０２からのアクセスのための命令メモリＲＡＭ６００５へのアクセス、及び（動作のデバッグモードの間に、命令メモリＲＡＭ６００５のコンテンツを変更し得る）ＧＬＳプロセッサ５４０２のためのデバッグロジックをアービトレートする。命令メモリ５４０５は通常、構成読み出しスレッドメッセージの結果として、初期化され、命令メモリ５４０５が初期化されると、スケジュール読み出しスレッド又は書き込みスレッド内に存在するＤｅｓｔｉｎａｔｉｏｎ Ｌｉｓｔ Ｂａｓｅアドレスを使用して、プログラムがアクセスされ得る。メッセージ内のアドレスは、コンテキスト切り替えが起こると必ずスレッドのためのアドレスを開始する命令メモリ５４０５として用いられる。

ここで、（スカラＲＡＭ６００１及びアービタ６００２を概して含む）スカラ出力バッファ５４１２を参照すると、スカラ出力バッファ５４１２（及び特に、スカラＲＡＭ６００１）は、データメモリ更新メッセージを介して、ＧＬＳプロセッサ５４０２及びメッセージングインタフェース５４１８によって書き込まれるスカラデータをストアし、アービタ６００２は、これらのソースをアービトレートし得る。また、スカラ出力バッファ５４１２の一部として関連ロジックがある。このスカラロジックのためのアーキテクチャが図１０に示される。

図１０では、読み出しスレッドのためのスカラロジックが従うステップの例が示される。この例では、読み出しスレッドがスケジューリングされるときに起こる２つの並列プロセスステップがある。１つのプロセスでは、スカラ情報を抽出するためにＧＬＳプロセッサ５４０２がトリガされ、抽出されたスカラ情報がスカラＲＡＭ６００１に書き込まれる。スカラ情報は、データメモリライン、宛先タグ、スカラデータ、及びＨＩ及びＬＯ情報を典型的に含む。これらは、通常、ＲＡＭ６００１にリニアに書き込まれる。また、スレッドのためのスカラ開始アドレス６０２８及びスカラ終了アドレス６０２９も、（カウント６０２６を介して）メールボックス６０１３内にラッチされる。ＧＬＳプロセッサ５４０２が、（コンテキスト切り替えによって指示されるように）書き込みプロセスを完了すると、スカラ出力バッファ５４１２は、（ストアされた宛先タグによって示されるように）スカラＲＡＭ６００１内の全ての宛先にソース通知メッセージの送信を開始する。更に、スカラロジックは（各スレッドに対し維持され、８個の繰り返しに対し維持され得る）スカラ繰り返しカウンタ６０２７を含む。繰り返しカウンタ６０２７は、スレッドがスケジュールされた状態から実行状態へ最初に移動するときに初期化され、ＧＬＳプロセッサ５４０２がトリガされる毎に増分される。

（スカラ−オンリー読み出しスレッドの場合に通常、起こる）この例のもう１つの並列プロセスでは、且つ、（ＧＬＳユニット１４０８によって事前に送られたＳＲＣ通知に応答して）スケジュールされた読み出しスレッドに対するＳＲＣ許可を受け取るとき、そのメッセージから抽出された情報でメールボックス６０１３が更新される。なお、ソース通知メッセージは、スカラ−オンリー伝送がイネーブされた読み出しスレッドでは、スカラ出力バッファ５４１２によって、（例えば）送られ得ることに留意されたい。スカラ及びベクトルの両方がイネーブルされた読み出しスレッドの場合、ソース通知メッセージは送られなくてもよい。次いでソース許可メッセージで送られたＤＳＴ＿ＴＡＧがそのスレッドＩＤのためにストアされた（前のソース通知メッセージがＤＳＴ＿ＴＡＧを書き込んでいるであろう）ものとマッチするかを判定するために、ペンディング許可テーブルが読み出され得る。マッチングが得られると、スカラ有限状態機械（ＦＳＭ）６０３１のためのそのスレッドのためのペンディング許可テーブルのビットが更新される。次いで、スレッドＩＤと共に新しい宛先ノード及びセグメントＩＤでＧＬＳデータメモリ５４０３が更新される。宛先リストエントリからＰＩＮＣＲ値を取得し、それを更新するために、ＧＬＳデータメモリ５４０３が読み出される。スカラ伝送の場合、宛先が送るＰＩＮＣＲ値は「０」になると推測される。次いで、スレッドＩＤと、それが左端のスレッドであるか否かを示す状態表示と共に、スレッドＩＤ先入れ先出しメモリ（ＦＩＦＯ）６０３０内にラッチされる。

これで、ＧＬＳユニット１４０８は、スカラデータを宛先に伝送するための許可を有する。ラッチされたスレッドＩＤを抽出するためにスレッドＦＩＦＯ６０３０が読み出される。抽出されたスレッドＩＤは宛先タグとともに、スカラＲＡＭ６００１から適切なデータをフェッチするためのインデックスとして用いられる。データが読み出されると、データ内に存在する宛先インデックスが、抽出され、リクエストキュー内にストアされた宛先タグとマッチングされる。マッチングが得られると、メールボックス６０１３にインデックスをつけ、ＧＬＳデータメモリ５４０３宛先アドレスをフェッチするために、抽出されたスレッドＩＤが使用される。次いで、マッチングされたＤＳＴ＿ＴＡＧは、ＧＬＳデータメモリ５４０３への最終アドレスを決定するために、ＧＬＳデータメモリ５４０３宛先アドレスに追加される。次いで、宛先リストエントリをフェッチするために、ＧＬＳデータメモリ５４０３がアクセスされる。ＧＬＳユニット１４０８は、更新ＧＬＳデータメモリ５４０３メッセージを、（ＧＬＳデータメモリ５４０３から抽出されたｎｏｄｅ ｉｄ、ｓｅｇ ＩＤによって識別される）宛先ノードへ、スカラＲＡＭ６００１からのデータを用い、送信する。繰り返しのための全体のデータが送られるまでこれが繰り返される。スレッドのためのデータの終わりに到達すると、ＧＬＳユニット１４０８は、次のスレッドＩＤに移動し（そのスレッドが、アクティブとして、ＦＩＦＯに入れられた場合）、また、グローバルインターコネクトロジックに、スレッドの終了に到達したことを示す。スカラデータは、出力命令を用いて、ＧＬＳプロセッサ５４０２によって書き込まれる。

実行に含まれるスカラデータは、プログラム自体から、又はＯＣＰ接続１４１２を介して周辺装置１４１４から、又はスカラ依存性がイネーブルされている場合、更新データメモリ更新メッセージを介して、処理クラスタ１４００内の他のブロックから、のいずれかである。スカラがＧＬＳプロセッサ５４０２によって、ＯＣＰ接続１４１２からフェッチされるときは、それは、そのデータメモリアドレスラインに（例えば）０−＞１Ｍのアドレスを送るであろう。ＧＬＳユニット１４０８は、そのアクセスを、ＯＣＰ接続１４１２マスター読み出しアクセス（即ち、１ワードのバースト）に変換する。ＧＬＳユニット１４０８がそのワードを読み出すと、データをスカラＲＡＭ６００１に送るＧＬＳプロセッサ５４０２（即ち、３２ビットであり、どの３２ビットかはＧＬＳプロセッサ５４０２によって送られるアドレスに依存する）にそれを送る。

スカラデータが別の処理クラスタ１４００モジュールから受け取られるべきケースでは、そのスレッドのためのコンテキスト記述子内にスカラ依存性ビットが設定される。入力依存性ビットが設定されるとき、スカラデータを送るであろうソースの数も、同じ記述子の中に設定される。ＧＬＳユニット１４０８が、全てのソースからの及びＧＬＳデータメモリ５４０３にストアされたスカラデータを受け取ると、スカラ依存性が満たされる。スカラ依存性が満たされると、ＧＬＳプロセッサ５４０２がトリガされる。この時点で、ＧＬＳプロセッサ５４０２は、ストアされたデータを読み出し、（通常は、読み出しスレッドのための）ＯＵＴＰＵＴ命令を用いて、スカラＲＡＭ６００１に書き込む。

また、ＧＬＳプロセッサ５４０２は、ＯＣＰ接続１４１２にデータ（又は任意のデータ）を書き込むことを選択してもよい。データが、ＧＬＳプロセッサ１４０８によってＯＣＰ接続１４１２に書き込まれるべきときは、それは、ＧＬＳデータメモリ５４０３アドレスラインのアドレス（例えば）０−＞１Ｍを送るであろう。ＧＬＳユニット１４０８は、そのアクセスをＯＣＰ接続マスター書き込みアクセス（即ち、１ワードのバースト）に変換し、（例えば）３２ビットをＯＣＰ接続１４１２に書き込む。

ＧＬＳユニット１４０８内のメールボックス６０１３は、メッセージング、スキャナ、及びデータパス間の情報フローを扱うために使用され得る。スケジュール読み出しスレッド、スケジュール構成読み出しスレッド、又はスケジュール書き込みスレッドメッセージがＧＬＳユニット１４０８によって受け取られるとき、メッセージから抽出された値がメールボックス６０１３内にストアされる。次いで、対応するスレッドがスケジュールされた状態に置かれ（スケジュール読み出しスレッド、又はスケジュール書き込みスレッドの場合）、それによってスキャナがそれを、ＧＬＳプロセッサ５４０２をトリガするための実行状態へ移動し得る。また、メールボックス６０１３は、ＧＬＳユニット１４０８によって使用されるべき、ソース通知メッセージ（書き込みスレッドの場合）、ソース許可メッセージ（読み出しスレッドの場合）からの値をラッチする。ＧＬＳユニット１４０８内の種々の内部ブロック間の相互作用は、（例えば、図１０に示すような）様々な時点で、メールボックス６００７を更新する。

イングレスメッセージプロセッサ６０１０は、制御ノード１４０６から受け取るメッセージを扱う。表１は、ＧＬＳユニット１４０８によって受け取られるメッセージのリストを示す。ＧＬＳは、処理クラスタ１４００サブシステム内で、Ｓｅｇ＿ＩＤ、Ｎｏｄｅ＿ＩＤをそれぞれ｛３、１｝としてアクセスされ得る。

本発明が関連する分野の当業者であれば、本発明の特許請求の範囲から逸脱することなく、説明した実施形態への変更、及び追加の実施形態が可能であることが理解されるであろう。

Claims (12)

1. 装置であって、
   メッセージバス（１４２０）と、
   データバス（１４２２）と、
   ロード／ストアユニット（１４０８）と、
   を特徴とし、
   前記ロード／ストアユニットが、
   システムメモリ（１４１６）と通信するように構成されるシステムインタフェース（５４１６）と、
   前記データバスに結合されるデータインタフェース（５４２０）と、
   前記メッセージバスに結合されるメッセージインタフェース（５４１８）と、
   命令メモリ（５４０５）と、
   データメモリ（５４０３）と、
   前記データインタフェースに結合されるバッファ（５４０６）と；
   前記メッセージインタフェースに結合されるスレッドスケジューリング回路要素（５４０１、５４０４）と、
   前記データメモリ、前記バッファ、前記命令メモリ、前記スレッドスケジューリング回路要素、及び前記システムインタフェースに結合されるプロセッサ（５４０２）と、
   を有する、
   装置
2. 請求項１に記載の装置であって、前記ロード／ストアユニットが、前記プロセッサに結合され、且つ、中断されたスレッドのためのレジスタ状態をストアするように構成される保存／復元メモリ（５４１４）を更に特徴とする装置。
3. 請求項１又は２に記載の装置であって、前記ロード／ストアユニットが、処理回路要素変数のためのアドレスが生成され得るように、処理回路要素（１４０２−１〜１４０２−Ｒ）のためのアドレッシングモードを複製するように構成される前記プロセッサを更に特徴とする装置。
4. 請求項１、２又は３に記載の装置であって、前記ロード／ストアユニットが、前記メッセージインタフェースと前記プロセッサとの間に結合されるスカラ出力バッファ（５４１２）を更に特徴とする装置。
5. 請求項１、２、３、又は４に記載の装置であって、
   前記ロード／ストアユニットが、前記ロード／ストアユニットが前記処理回路要素のためのデータ構造をシステムメモリ（１４１６）からリトリーブするように、構成読み出しスレッドを実装するように構成され、
   前記データ構造が、並列化シリアルプログラムのために、前記処理回路要素の計算及びメモリリソースに少なくとも部分的に基づく、
   装置。
6. システムであって、
   システムメモリ（１４１６）と、
   前記システムメモリに結合される処理クラスタと、
   を特徴とし、
   前記処理クラスタが、
   メッセージバス（１４２０）と、
   データバス（１４２２）と、
   パーティション（１４０２−１〜１４０２−Ｒ）に配される複数の処理ノード（８０８−１〜８０８−Ｎ）であって、各パーティションが前記データバス（１４２２）に結合されるバスインタフェースユニット（４７１０−１〜４７１０−Ｒ）を有し、各処理ノードが前記メッセージバスに結合される、前記複数の処理ノードと、
   前記メッセージバスに結合される制御ノード（１４０６）と、
   ロード／ストアユニット（１４０８）と、
   を含み、
   前記ロード／ストアユニットが、
   システムメモリ（１４１６）と通信するように構成されるシステムインタフェース（５４１６）と、
   前記データバスに結合されるデータインタフェース（５４２０）と、
   前記メッセージバスに結合されるメッセージインタフェース（５４１８）と、
   命令メモリ（５４０５）と、
   データメモリ（５４０３）と、
   前記データインタフェースに結合されるバッファ（５４０６）と、
   前記メッセージインタフェースに結合されるスレッドスケジューリング回路要素（５４０１、５４０４）と、
   前記データメモリ、前記バッファ、前記命令メモリ、前記スレッドスケジューリング回路要素、及び前記システムインタフェースに結合されるプロセッサ（５４０２）と、
   を有する、
   システム。
7. 請求項６に記載のシステムであって、前記ロード／ストアユニットが、前記プロセッサに結合され、且つ、中断されたスレッドのためのレジスタ状態をストアするように構成される保存／復元メモリ（５４１４）を更に特徴とする、システム。
8. 請求項６又は７に記載のシステムであって、前記ロード／ストアユニットが、処理回路要素変数のためのアドレスが生成され得るように、処理回路要素（１４０２−１〜１４０２−Ｒ）のためのアドレッシングモードを複製するように構成される前記プロセッサを更に特徴とするシステム。
9. 請求項６、７又は８に記載のシステムであって、前記ロード／ストアユニットが、前記メッセージインタフェースと前記プロセッサとの間に結合されるスカラ出力バッファ（５４１２）を更に特徴とするシステム。
10. 請求項６、７、８又は９に記載のシステムであって、
    前記ロード／ストアユニットが、前記ロード／ストアユニットがシステムメモリ（１４１６）から前記処理回路要素のためのデータ構造をリトリーブするように、構成読み出しスレッドを実装するように構成され、
    前記データ構造が、少なくとも部分的に並列化シリアルプログラムのための前記処理回路要素の計算及びメモリリソースに基づく、
    システム。
11. 請求項６、７、８、９又は１０に記載のシステムであって、前記システムが、前記データバスと前記データインタフェースとの間に結合されるデータインターコネクト（８１４）を更に特徴とするシステム。
12. 請求項６、７、８、９、１０又は１１に記載のシステムであって、前記システムが、
    前記制御ノード及び前記システムインタフェースに結合されるシステムバス（１３２６、１３２８）と、
    前記システムメモリ及び前記システムバスに結合されるメモリコントローラ（１３０４）と、
    前記システムバスに結合されるホストプロセッサ（１３１６）と、
    を更に特徴とするシステム。