JP5668014B2 - プロセッサにおけるタスクおよびデータ管理 - Google Patents

Description

［関連出願との相互参照］
本出願は、２００５年９月２７日に提出された、本出願と譲受人が共通する特許文献１に関連し、その開示内容全体をここに援用する。
本出願は、２００５年９月２７日に提出された、本出願と譲受人が共通する特許文献２に関連し、その開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に提出された、本出願と譲受人が共通する特許文献３に関連し、その開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に提出された、本出願と譲受人が共通する特許文献４に関連し、その開示内容全体をここに援用する。
US patent application 11/238,077 entitled "CELL PROCESSOR METHODS AND APPARATUS" to John P. Bates, Payton R. White and Attila Vass US patent application 11/238,087 entitled "SPU TASK MANAGER FOR CELL PROCESSOR" to John P. Bates, Payton R. White, Richard Stenson, Howard Berkey, Attila Vass and Mark Cerny US patent application 11/238,086 entitled "OPERATING CELL PROCESSORS OVER A NETWORK" to Tatsuya Iwamoto US patent application 11/238,085 entitled "METHOD AND SYSTEM FOR PERFORMING MEMORY COPY FUNCTION ON A CELL PROCESSOR" to Antoine Labour John P. Bates and Richard B. Stenson

［発明の属する技術分野］
本発明の実施形態は、並列処理を対象とし、特に、ｃｅｌｌプロセッサにおけるタスク処理およびデータ処理の管理に関する。

ｃｅｌｌプロセッサは、並行処理を用いるマイクロプロセッサの一種である。ｃｅｌｌプロセッサの基本的な構成は、「パワープロセッサエレメント」（「ＰＰＥ」）（「プロセッシングエレメント」または「ＰＥ」ともいう）と、複数の「共有（Synergistic）プロセッシングエレメント」（「ＳＰＥ」）とを含む。ＰＰＥと、ＳＰＥは、「エレメント接続バス」（「ＥＩＢ」）と呼ばれる内部高速バスで接続される。ｃｅｌｌプロセッサは、携帯用デバイスからメインフレームコンピュータまでの広範にわたる用途に適用できるように、スケーラブルに設計されている。

典型的なｃｅｌｌプロセッサは、１個のＰＰＥと、８個以下のＳＰＥを有する。各ＳＰＵは、典型的には単チップ、または、メインプロセッサとコプロセッサとを含む単チップの一部である。全てのＳＰＵと、ＰＰＵが、例えば、メモリフローコントローラ（ＭＦＣ）を介して、メインメモリにアクセスすることができる。ＳＰＵは、メインプロセッサ上で動作しているプログラムに連動して、オペレーションの並行処理を実行することができる。ＳＰＵは、ソフトウェアコードによって管理されるべき小さなローカルメモリ（典型的には２５６キロバイト程度）を有し、データは、非自動的にローカルＳＰＵメモリへと、またはローカルＳＰＵメモリから、転送されなければならない。高いパフォーマンスを達成するために、このコードとデータは、ＳＰＵソフトウェアによって管理される必要がある（ＰＰＵソフトウェアの関与は、最小限にする必要がある）。ＳＰＵからコードとデータを管理するための、様々な手法が存在する。多くの場合、ＳＰＵからコードとデータを管理するための異なる手法を、ｃｅｌｌプロセッサ上で同時に実行する必要がある。ＳＰＵによって駆動されるタスク管理のためのプログラミングモデルは、多数存在する。残念ながら、全ての用途において適切であるような、単一のタスクシステムは存在しない。

ｃｅｌｌプロセッサは、グラフィックスのための頂点処理のような用途に用いられる。処理された頂点データは、続いて、ピクセル処理のためにグラフィックスカードへと受け渡されてもよい。頂点処理においては、ｃｅｌｌプロセッサが、多数のポリゴンを描画するために呼び出されてもよい。各ポリゴンは、三以上の頂点により、定義される。多数の頂点が処理されなければならない状況においては、このような頂点データの取り扱いが問題となる可能性がある。例えば、一万個のポリゴンを描画するためにｃｅｌｌプロセッサが呼び出されるかもしれない。各ポリゴンが、３個の頂点を必要とする場合、ｃｅｌｌプロセッサは、３００００個の頂点を処理しなけれぱならない。各頂点が、３２バイトのデータを必要とするならば、一万個のポリゴンでは、９６０キロバイトのデータが必要となるであろう。残念ながら、これは典型的なＳＰＵのローカルストレージ（典型的には２５６キロバイト程度）よりも大きい。

すなわち、このような問題に対処するやり方で、ｃｅｌｌプロセッサのタスクを分配し、ｃｅｌｌプロセッサのデータを管理するための方法およびシステムが必要とされている。

課題を解決する手段

上述の不利な点を克服するために、本発明の実施形態は向けられる。

本発明の教示するところは、添付される図面とともに下記の詳細な説明を考慮することで、容易に理解される。
本発明の実施形態における、セルのタスクおよびデータ管理を実現するセルブロードバンドエンジンアーキテクチャを示す模式図である。 本発明の実施形態におけるｃｅｌｌプロセッサに基づくシステムの模式図である。 本発明の実施形態における、大きなレンダイベントの分割を説明するブロック図である。 本発明の実施形態における、大きなレンダイベントおよび小さなレンダイベントの分割を説明するブロック図である。 本発明の実施形態におけるイベントの処理を説明するシークエンスブロック図である。 本発明の実施形態における、セグメントとグループのバッファリングを説明するブロック図である。 本発明の実施形態における、セルに基づくプロセッサシステム内のイベント処理を説明する一連のブロック図である。

以下の詳細な説明は、多数の、説明のための具体的な細かい内容を含むが、以下の詳細な記述の様々な変形や変更が、本発明の範囲内に含まれることは、当業者に理解される所である。従って、以下に記述される本発明の実施例は、請求項に記載された発明の一般性を失うことなく、また、請求項に記載された発明に制限を課すことなく、説明されている。本発明の実施例は、ｃｅｌｌプロセッサのタスクおよびデータ管理（ＣＴＤＭ）を対象とする。本発明の実施形態においては、イベントと呼ばれる大きなタスクは、ｃｅｌｌプロセッサの共有プロセッシングエレメント（ＳＰＥ）のローカルストアに収まることができるように、セグメントに分割されることにより、管理される。各セグメントは、一度に一のＳＰＵによって、タスク処理される。出力プロセッサのメモリの制約のため、二以上のセグメントが関連づけされて、一以上のグループとされてもよい。ここで出力プロセッサとは例えば、ＳＰＵから結果として生じた出力を処理するグラフィックスカードなどである。従って、各グループを、ＳＰＵによる一以上のセグメントの処理の結果生じた出力とみなしてもよい。

本発明の実施形態において、セルのデータ管理は、ＳＰＵが自ら、ローカルストレージからのまたはローカルストレージへのデータについて、ダイレクトメモリアクセス（ＤＭＡ）転送を操作できる、という事実に依拠する。ＣＴＤＭは、タスクコマンドをメインメモリに設定できる。ＰＵが新たなコマンド書き込む間、およびＳＰＵがデータにアクセスする間に、データをロックするために、セマフォが使われてもよい。ＳＰＵは、他のＳＰＵやＰＵと競合する状況を避けるために、同じセマフォインタフェースを介して、コマンドリストから、コマンドを引き出すことができる。それらが完了したとき、ＳＰＵが新たなコマンドを引き出すことを可能とすることにより、ＳＰＵは常にアクティブな状態に保たれるだろう。これにより、データ構造が変化したときでさえも、一貫性のあるピーク効率を確保できるだろう。出力プロセッサへのコマンドについても同様に、コマンドリストに設定することができる。ｃｅｌｌプロセッサＳＰＵは、これらのコマンドを順番にに引き出し、出力プロセッサに受け渡すことができる。

図１は、Ｃｅｌｌブロードバンドエンジン・アーキテクチャ（ＣＢＥＡ:Cell Broadband engine architecture）として知られるアーキテクチャ準拠プロセッサであることを特徴とする、あるタイプのｃｅｌｌプロセッサ１００を示す図である。なお、図１は例示であり、制限を課すものではない。この例に示されるように、ｃｅｌｌプロセッサは、ＰＰＥの複数のグループ（ＰＰＥグループ）とＳＰＥの複数のグループ（ＳＰＥグループ）を含みうる。あるいは、ｃｅｌｌプロセッサは、単一のＳＰＥと、単一のＰＰＥによる、単一のＳＰＥグループと、単一のＰＰＥグループのみを有してもよい。ハードウェア資源は、グループ内のユニット間で共有されうる。一方、ソフトウェアからは、ＳＰＥおよびＰＰＥが独立のエレメントであるように見えなければならない。

図１に示される例では、ｃｅｌｌプロセッサ１００は、ＳＧ＿０、．．．、ＳＧ＿ｎといった複数のＳＰＥグループと、ＰＧ＿０、．．．、ＰＧ＿ｐといった複数のＰＰＥグループと、を含む。各ＳＰＥグループは、ＳＰＥ０、．．．、ＳＰＥｇといった複数のＳＰＥを含む。ｃｅｌｌプロセッサ１００はまた、メインメモリＭＥＭと、入出力機能Ｉ／Ｏも含む。

各ＰＰＥグループは、ＰＰＥ＿０、．．．、ＰＰＥ＿ｇといった複数のＰＰＥを含む。この例においては、一のグループのＳＰＥは、単一のキャッシュＳＬ１を共有する。キャッシュＳＬ１は、ローカルストレージとメインストレージの間のダイレクトメモリアクセス（ＤＭＡ）転送のための第一レベルキャッシュである。グループ内の各ＰＰＥは、それぞれの第一レベル（内部）キャッシュＬ１を有する。これに加えて、グループ内のＰＰＥは、単一の第二レベル（外部）キャッシュＬ２を共有する。図１では、ＳＰＥとＰＰＥのためのキャッシュが示されているが、一般的にｃｅｌｌプロセッサ、特にＣＢＥＡ準拠プロセッサにとって、これらは必須の構成ではない。

エレメント接続バス（ＥＩＢ）は、上に列挙された様々なコンポーネントを接続する。各ＳＰＥグループのＳＰＥ、そして、各ＰＰＥグループのＰＰＥが、バス・インタフェース・ユニットＢＩＵを介して、ＥＩＢにアクセスすることができる。ｃｅｌｌプロセッサ１００はまた、通常のプロセッサに見出される典型的な二つのコントローラを含む。すなわち、ＥＩＢとメインメモリＭＥＭの間のデータの流れを制御するメモリ・インタフェース・コントローラＭＩＣと、Ｉ／ＯとＥＩＢの間のデータの流れを制御するバス・インタフェース・コントローラＢＩＣを含む。種々の実装において、ＭＩＣ、ＢＩＣ、ＢＩＵおよびＥＩＢに必要とされる事項は様々であるが、これらの機能、およびこれらを実現するための回路は、当業者によく知られているであろう。

各ＳＰＥは、ＳＰＵ（ＳＰＵ０、．．．、ＳＰＵｇ）を含んで構成される。ＳＰＥグループ内の各ＳＰＵはそれぞれ、専用のローカルストレージ・エリアＬＳと、専用のメモリフローコントローラＭＦＣを有する。ＭＦＣは、対応づけられたメモリ管理ユニット（ＭＭＵ）を含む。ＭＭＵは、メモリ保護やアクセス許可についての情報を保持し、また処理することができる。

ＰＰＥは、例えば、対応するキャッシュ付きの６４ビットパワーＰＣプロセッサ・ユニット（ＰＰＵ）である。ＣＢＥＡ準拠システムは、ＰＰＥ内に、ベクトル・マルチメディア拡張ユニット（vector multimedia extension unit）を含む。ＰＰＥは、汎用処理ユニットであり、（例えば、メモリ保護テーブルのような）システム管理資源にアクセスすることができる。ＣＢＥＡに定義されるハードウェア資源は、ＰＰＥから見えるように、実アドレス空間に明示的にマップされる。従って、いずれのＰＰＥも、適切かつ有効なアドレス値を用いて、これらの資源の任意のものに直接アドレスできる。ＰＰＥの主要な機能は、システム内におけるＳＰＥタスクの割り当てと管理である。

ＳＰＥは、ＰＰＥと比べると、システム管理機能を実行しない点において、計算ユニットとして複雑ではない。一般的にＳＰＵは、単一命令複数データ処理（ＳＩＭＤ:single instruction multiple data）能力を有し、主としてデータを処理し、割り当てられたタスクを実行するために必要なデータ転送を（ＰＰＥによりセットアップされたアクセス特性に従って）開始する。ＳＰＵの目的は、計算ユニットのいっそうの高密度集積を要求し、供給された命令セットを効果的に用いるアプリケーションを可能とすることである。ＰＰＥに管理される、システム内の多数のＳＰＵにより、幅広い用途に渡ってコスト効率のよい処理が可能となる。ＳＰＵは、新たな命令セットアーキテクチャを実現する。

ＭＦＣコンポーネントは、基本的には、データ転送エンジンである。ＭＦＣは、データ転送、保護、そしてｃｅｌｌプロセッサのメインストレージとＳＰＥのローカルストレージとの間の同期のための主要な方法を提供する。ＭＦＣコマンドは、実行すべき転送を記述する。ＭＦＣの主要な設計目的は、これらのデータ転送動作を、適正な方法で可能な限り早く実行し、それによってｃｅｌｌプロセッサ全体のスループットを最大化することである。データ転送のためのコマンドは、ＭＦＣ・ＤＭＡコマンドと呼ばれる。これらのコマンドが変換されて、ローカルストレージ・ドメインとメインストレージ・ドメインとの間のＤＭＡ転送となる。

各ＭＦＣは、典型的には、複数のＤＭＡ転送を同時にサポートすることができ、複数のＭＦＣコマンドを保持し、処理することができる。これを実現するために、ＭＦＣは、ＭＦＣコマンドの待ち行列（queue）を保持し、処理する。ＭＦＣは、複数の転送要求を待ち行列に投入したり、同時に複数の転送要求を発行したりすることができる。各ＭＦＣは、対応するＳＰＵのための一の待ち行列（ＭＦＣ・ＳＰＵコマンド待ち行列）と、他のプロセッサおよびデバイスのための一の待ち行列（ＭＦＣプロキシ・コマンド待ち行列）とを備える。論理的には、ＭＦＣ待ち行列の集合は常に、ｃｅｌｌプロセッサ中の各ＳＰＵと関連づけられている。しかし一部のアーキテクチャの実装においては、ＳＰＵグループのように複数のＳＰＵ間で、単一の物理ＭＦＣを共有してもよい。そのような場合、ソフトウェアから、すべてのＭＦＣファシリティ（facility）が各ＳＰＵに関して独立であるように見えなければならない。各ＭＦＣ・ＤＭＡデータ転送コマンド要求は、ローカルストレージ・アドレス（ＬＳＡ）と有効アドレス（ＥＡ：effective address）との双方を伴う。ローカルストレージ・アドレスは、関連づけられたＳＰＵのローカルストレージ・エリアのみ、直接アドレスできる。有効アドレスは、より一般的な用途を有する。すなわち、ローカルストレージ・エリアが実アドレス空間にエイリアス（aliase）されている場合には（つまり、ＭＦＣ＿ＳＲ１［Ｄ］が「１」に設定されているならば）、全てのＳＰＵのローカルストレージ・エリアを含めて、メインストレージを参照できる。

ＭＦＣは２種類のインタフェースを提示する。１種類はＳＰＵ用であり、他の１種類は処理グループ内の他のプロセッサやデバイスすべてのためである。ＳＰＵは、ＭＦＣを制御するために、チャネルインタフェース（channel interface）を用いる。この場合、あるＳＰＵで動作しているコードは、そのＳＰＵ用のＭＦＣ・ＳＰＵコマンド待ち行列にのみ、アクセスできる。他のプロセッサとデバイスは、メモリマップされたレジスタを用いることにより、そのＭＦＣを制御する。システム内のいずれのプロセッサやデバイスも、ＳＰＵに代わってＭＦＣを制御し、ＭＦＣプロキシ・コマンド要求を発行することが可能である。ＭＦＣはまた、帯域予約やデータ同期特性もサポートする。ＳＰＵ間の、および／またはＳＰＵとＰＰＵ間の通信を容易にするために、ＳＰＥおよびＰＰＥは、シグナルイベントに対応づけられるシグナル通知レジスタを含んでもよい。典型的には、ＰＰＥとＳＰＥは、ＰＰＥがＳＰＥにメッセージを転送するルータとして動作するスター型トポロジで結合されてもよい。そのようなトポロジにおいては、ＳＰＥ間の直接通信は提供されない。その代わり、各ＳＰＥと各ＰＰＥは、メールボックスと呼ばれる一方向シグナル通知レジスタを有する。メールボックスは、ＳＰＥとホストＯＳとの同期をとるために用いることができる。

ＩＩＣコンポーネントは、ＰＰＥに提示された割り込みの、優先順位を制御する。ＩＩＣの主要な目的は、プロセッサ中の他のコンポーネントからの割り込みを、メインシステムの割り込みコントローラを用いずに、処理可能とすることである。ＩＩＣは、実際には、第二レベルのコントローラである。ＩＩＣは、ＣＢＥＡ準拠プロセッサの内部割り込み、あるいは、ＣＢＥＡ準拠プロセッサのマルチプロセッサシステム内部割り込みの全てのを扱うことを意図している。システム割り込みコントローラは、典型的には、ｃｅｌｌプロセッサ外部の全ての割り込みに対処する。

ｃｅｌｌプロセッサシステムにおいては、ソフトウェアは多くの場合、まずＩＩＣを確認して、割り込みが外部システム割り込みコントローラから発生したものであるか判定する必要がある。ＩＩＣは、全てのＩ／Ｏデバイスからの割り込みを処理するためのメインシステム割り込みコントローラを代替することを意図するものではない。

ｃｅｌｌプロセッサ内部には、２種類のストレージ・ドメイン（storage domain）がある。すなわち、ローカルストレージ・ドメインと、メインストレージ・ドメインである。ＳＰＥのローカルストレージは、ローカルストレージ・ドメインに存在する。他の全てのファシリティやメモリは、メインストレージ・ドメインにある。ローカルストレージは、それぞれが特定のＳＰＵと関連づけされた、メモリ・ストレージの一以上の分離したエリアで構成される。各ＳＰＵは、それ自身と関連づけられたローカルストレージ・ドメイン内部からの指示（データロードまたはデータストア操作を含む）のみを実行できる。従って、ローカルストレージのエイリアスが可能とされているのでないかぎり、システム内のいずれかのストレージへの、もしくはいずれかのストレージからのデータ転送要求は常に、（個々のＳＰＵの）ローカルストレージ・ドメインとメインストレージ・ドメインとの間でデータを転送するためのＭＦＣ・ＤＭＡコマンドを発行することにより、実行されなければならない。

ＳＰＵプログラムは、ローカルアドレスを用いて、そのローカルストレージ・ドメインを参照する。一方、特権ソフトウェアにおいては、ＭＦＣ＿ＳＲ１のＤｂｉｔを「１」に設定することにより、ＳＰＵのローカルストレージ・エリアを、メインストレージ・ドメインにエイリアス指定することが可能である。各ローカルストレージ・エリアは、メインストレージ・ドメイン内の実アドレスを割り当てられる（実アドレスは、システムメモリ内のバイト単位のアドレス、またはＩ／Ｏデバイスのバイト単位のアドレスである。）これにより、特権ソフトウェアは、ローカルストレージ・エリアを、アプリケーションの有効アドレス空間にマップすることができ、一のＳＰＵのローカルストレージと、他の一ののＳＰＵのローカルストレージ間でのＤＭＡ転送が可能となる。

ローカルストレージ・エリアをメインストレージドメインにエイリアス指定することで、メインストレージ・ドメインにアクセスする他のプログラムまたはデバイスは、ローカルストレージエリアに直接アクセスすることができる。このローカルストレージ・エリアは、ある変換方法によりメインストレージ・ドメインに示される実アドレス空間空間にマッピングされた、有効アドレスまたはＩ／Ｏバスアドレスを用いて、メインストレージドメインにエイリアス指定される。

メインストレージドメインにエイリアス指定されたローカルストレージエリアを用いるデータ転送は、キャッシュ禁止として行う必要がある。なぜならば、これらのアクセスは、ローカルストレージドメインにおいて、ＳＰＵローカルストレージアクセス（すなわち、ＳＰＵロード、ストア、命令フェッチ）と、整合性がないからである。ローカルストレージエリアを、メインストレージドメインの実アドレス空間空間にエイリアス指定することにより、メインストレージエリアにアクセスできる他のどのプログラムやデバイスも、ローカルストレージに直接アクセスすることができる。しかし、エイリアス指定されたローカルストレージは、キャッシュ不可として扱わねばならないため、ＰＰＥロードおよびストア命令を用いた大量のデータ転送においては、低いパフォーマンスしか得られないかもしれない。ローカルストレージ・ドメインと、メインストレージ・ドメインの間のデータ転送は、ストール(stall)を避けるために、ＭＦＣ・ＤＭＡコマンドを用いなければならない。

ＣＢＥＡにおける、メインストレージへのアドレス指定は、パワーＰＣアーキテクチャで定義されたアドレス指定と互換性がある。ＣＰＥＡは、パワーＰＣアーキテクチャのコンセプトを基礎に構築され、さらに、それらをＭＦＣによるメインストレージのアドレス指定に拡張している。

ＳＰＵあるいは他の任意のプロセッサやデバイスの中で実行されるアプリケーションプログラムは、メインメモリにアクセスするために、有効アドレスを用いる。有効アドレスは、ＰＰＥが、ロード、ストア、分岐、キャッシュ命令を実行するときや、また次の順次命令をフェッチするときに計算される。ＳＰＵプログラムは、ＭＦＣコマンドの中のパラメータとして、有効アドレスを与えなければならない。有効アドレスは、非特許文献１に記述される手順に従って、実アドレスに変換される。実アドレスは、変換された有効アドレスによって参照される、メインストレージ内の位置である。メインストレージは、システム内の全てのＰＰＥ、ＭＦＣ、およびＩ／Ｏデバイスによって共有される。このレベルのストレージに保持される情報は、システム内の全てのプロセッサ、そして全てのデバイスからみることができる。このストレージエリアは、構造上一様でもよく、また、階層的なキャッシュ構造の一部でもよい。プログラムは、有効アドレスを用いて、このレベルのストレージを参照する。
Overview of addres translation in "power PC architechture Book III"

システムのメインメモリは、典型的には、システム・コンフィギュレーションや、データ転送同期、メモリマップドＩ／Ｏ、Ｉ／Ｏサブシステムなどの機能に用いられる特定目的のためのハードウェアレジスタまたはアレイに加えて、汎用および不揮発性のストレージの両方を含む。メインメモリについては、様々なコンフィギュレーションが可能である。表１は、セルブロードバンドエンジンアーキテクチャ（ＣＢＥＡ）として知られる特定の実装のｃｅｌｌプロセッサについて、メインメモリ中のアドレス空間の大きさを記載する。なお、表１は例示であり、制限を課すものではない。

ｃｅｌｌプロセッサ１００は、プロセッサとシステム内のクリティカルな資源（critical resources）を管理するために、任意のファシリティを含んでもよい。ｃｅｌｌプロセッサの管理対象となる資源は、変換ルックアサイド・バッファ（ＴＬＢ: translation lookaside buffer）と、データおよび命令キャッシュである。これらの資源の管理は、実装に依存するテーブルにより、制御される。

ＴＬＢとキャッシュを管理するテーブルは、置換管理テーブルＲＭＴと呼ばれ、各ＭＭＵと関連づけられてもよい。これらのテーブルはオプションではあるが、多くの場合、システムにおいてボトルネックになりうるクリティカルな資源それぞれについて、テーブルを備えることが有用である。ＳＰＥグループはまた、オプションでキャッシュ階層であるＳＬ１キャッシュを含んでもよい。ＳＬ１キャッシュは、ＤＭＡ転送のための第１レベルのキャッシュに相当する。ＳＬ１キャッシュはまた、オプションでＲＭＴを含んでもよい。

ｃｅｌｌプロセッサデータおよびタスク管理（ＣＴＤＭ）プログラム１０２は、メインメモリＭＥＭに格納され、かつ／またはＰＰＥグループのうちの一のＰＰＵにおいて、実行されうる。ＣＴＤＭプログラム１０２は、所与のＳＰＥにおいて使用可能なメモリ空間よりも多くのメモリ空間を必要とする大きいタスク（処理イベント１０４という）を、より小さいサイズの塊(chunk)であるセグメント１０６に分割する。次に、ＣＴＤＭプログラム１０２は、セグメント１０６の処理に関連する命令を含むコマンドリスト１０８を構築する。各セグメント１０６は、ＳＰＥのＬＳの使用可能なサイズ以下であることを特徴とする。ＳＰＥは、コマンドリスト１０８に従って、そのセグメントを処理し、対応する出力を生成する。この出力は、各グループが、関連するセグメント１０６を処理することにより生成された出力を有する、一以上のグループ１１０の形であってもよい。

上述の説明は、ｃｅｌｌプロセッサの実装において用いられる用語の紹介と解説の提供を意図している。上述の議論はまた、本発明の実施形態におけるデータ構築と方法のためのコンテキストを説明することを意図している。かかる実施形態は、上述のアーキテクチャを有するｃｅｌｌプロセッサ上での、またはｃｅｌｌプロセッサを用いるものに限られない。、ただし、以下に述べる実施形態の一部または全部は、ＣＴＤＭが用いられる環境として、そのようなＣｅｌｌアーキテクチャを用いて実装されうる。

図２は、本発明の実施形態におけるＣＴＤＭを実装すべく構成された、ｃｅｌｌプロセッサに基づくシステム２００の例を示す図である。説明のために、このシステムは、ｃｅｌｌプロセッサ２０１と出力プロセッサ２１４を含むものとする。ｃｅｌｌプロセッサ２０１は、メインメモリ２０２、単一のＰＰＥ２０４、そして８個のＳＰＥ２０６を含む。ただし、ｃｅｌｌプロセッサ２０１は、任意の数のＳＰＥで構成されてもよい。図２について、メモリ、ＰＰＥ、そしてＳＰＥは、リング型エレメント接続バス２１０越しに互いに通信することができ、またＩ／Ｏデバイス２０８と通信することができる。

ＣＴＤＭプログラム２０５は、ＰＰＥ２０４が、新たなコマンドを書き込み、ＳＰＵがデータにアクセスする間、データをロックするために、セマフォを用いてもよい。ＳＰＵは、他のＳＰＵやＰＰＥ２０４との競合状態を避けるために、同じセマフォ・インタフェイスにより、メインメモリ２０２内のコマンドリスト２１１からコマンドを引き出す。それらが完了したとき、ＳＰＵが新たなコマンドを引き出すことを可能とすることにより、ＳＰＵは常にアクティブな状態に保たれる。これにより、コンフィギュレーションにおいてデータが変動したときでさえも、ピーク効率が定常的であることが保証されるだろう。コマンドリスト２１１はまた、出力プロセッサ２１４のためのコマンドを含んでもよい。ｃｅｌｌプロセッサ２０１のＳＰＵは、これらのコマンドを順序通りに引き出し、出力プロセッサ２１４に受け渡すことができる。

出力プロセッサ２１４は、ｃｅｌｌプロセッサ２０１からの、グループを処理する。そのグループのサイズは、一般的に、出力プロセッサのためのターゲット入力サイズによって決定される。例えば、各出力セグメントが、わずか３６キロバイトであるのに対して、出力プロセッサは、５１２キロバイトのデータを扱うことのできるＩ／Ｏバッファを有するかもしれない。それゆえ、各出力グループは、十六の出力セグメントを含むだろう。

一例として、適応性があり、効率的かつ取り扱いが簡単なグラフィックスＡＰＩにおいて、システム２００が用いられてよい。このような場合、出力プロセッサ２１４は、カリフォルニア州サンタクララのＮｖｉｄｉａコーポレーションで入手可能なモデルＮＶ４０、ＮＶ４５、ＮＶ４７のようなグラフィックスカードであってもよい。

ＰＰＥ２０４は、以下で議論するようにＳＰＵのタスクおよびデータを管理するＣＴＤＭプログラム２０５を実行する。ＣＴＤＭプログラム２０５は、小さいイベントおよび大きいイベントを取り扱うことができるよう、充分な適応性があることが好ましい。ＣＴＤＭプログラム２０５はまた、ＳＰＵおよび出力プロセッサにおけるそれらのイベントの管理にあたって、充分効率的であることが望ましい。ＣＴＤＭプログラム２０５においてはまた、ストリーミングでの遅延処理をサポートするために、システム２００を拡張することにより、効率性を保証することが望ましい。

このような、適応性および効率性が重要であることを説明するため、以下の例について参照する。この例においてイベントは、頂点データ３０３のための、大きいレンダイベント３０１である。頂点データ３０３は、さらなる処理のためにグラフィックスカードへ送られる前に、ｃｅｌｌプロセッサにおいて処理される。さらなる処理とは、例えばシェーディングのようなピクセル処理などである。このようなシェーディングは、例えばＣＧのような既知のシェーディングソフトウェアによって、達成されてよい。図３Ａは、ＣＴＤＭに基づくレンダイベントの処理をドローコール（Draw Call）３０２の形式で説明する図である。そのようなレンダイベントは、頂点の組で表される、ビデオゲームのキャラクタのビューの平行移動や、回転、変化などを伴ってもよい。図３Ａに示された例においては、ドローコール３０２は、大量の頂点データを処理するための命令である。大量のデータとは例えば、一のＳＰＵが一度に処理可能である量よりも多いデータである。

符号３０４において、ＣＴＤＭプログラムは、大きなレンダイベント３０１を複数のセグメントに細分し、そしてこれらのセグメントのサブセットを関連付けして、グループとする。具体的には、セグメント１から４は関連づけられてグループ１とされ、セグメント５から８は関連付けられてグループ２とされる。ＣＴＤＭプログラム２０５は、これらのセグメントを、ｃｅｌｌプロセッサ２０１の利用可能なＳＰＵ間で分配する。セグメントのＳＰＵへの分配は、そのＳＰＵの利用可能性に依存する。イベント３０１の頂点データ３０３を論理的に、一のＳＰＵタスクについて一のセグメントとなるように、セグメントに分離し、セグメントを結合させてレンダグループとする。レンダグループは、一のＳＰＵ並行ジョブのためのデータを表す。このようにタスクを分離することにより、並行タスキング（tasking）が可能となり、単一のＳＰＵの限られた使用可能なメモリのアコモデーション(accommodation)が可能となる。

ＰＰＥ２０４に負荷をかけることなく、セグメントを利用可能なＳＰＵに効率的に分配するために、ＣＴＤＭプログラムは、コマンドリスト３０５を作成する。コマンドリストは、各セグメントについての必要なデータのアドレスに加えてさらに、ＳＰＵが必要な頂点データのレンダリングを実行するためのコード用のアドレスをも提供する。その結果、ＳＰＵは、利用可能になると、コードとデータにアクセスできる。ＳＰＵは、各セグメントの頂点データを並行に処理し、結果の出力データを出力プロセッサ（グラフィックスカード）２１４に、出力する。グラフィックスカード２１４のためのコマンドもまた、コマンドリスト３０５にセットされる。ｃｅｌｌプロセッサ２０１のＳＰＵは、それらを単に、順次引き出し、グラフィックスカード２１４に受け渡すことができる。例えば、一旦グループ内の最後のセグメントがグラフィックスカードに渡されると、そのデータを渡したＳＰＵは、グラフィックスカードに、そのグループの処理を開始するよう指示する「キック」コマンドを引き出すだろう。

図３Ｂは、ＣＴＤＭに基づく、小さなレンダイベント３１１と大きなレンダイベント３２１の処理を説明する。ここで、小さいイベント３１１については、1個のＳＰＵタスクに足りるだけのデータであるため、1個のＳＰＵのみが用いられる。この場合、出力グループは、ただ１個のセグメントの処理からの出力を含む。大きいイベント３２１は、それぞれ４個のセグメントを有する２個のグループに分割される。そのデータの一部は、1個のＳＰＵが小さいイベント３１１を処理する間に、４個のＳＰＵで並行に実行されるように設定可能である。このようにして、比較的データ量の少ない、小さいイベントがシステム２００をストールさせることなく、それぞれのＳＰＵが、ＤＭＡ転送ごとに取り扱い可能な最大のデータのタスクを処理できる。もしも小さいイベントがＳＰＵ間で分割されたならば、このようにはいかないであろう。

一般的に、ＳＰＵ間でのセグメントの分配は、利用可能なＳＰＵの数がセグメントの数と等しい場合に、最も効率がよい。この条件を常に充たすことは不可能であるため、ＣＴＤＭプログラム２０５により、利用可能なＳＰＵの数よりも多いセグメントを有する大きなイベントを、利用可能なＳＰＵが並行に処理することを可能とする。図４Ａから４Ｃは、そのような、並行処理の一例を説明する図である。この場合もやはり例を示す意図で、グラフィックスＡＰＩのための頂点描画呼び出しドローコールが説明されている。具体的には、図４Ａで示されるように、ドローコール４０２に応じて、ＣＴＤＭプログラム２０５は、大きなレンダイベント４０１を８個のレンダセグメントに分割し、コマンドリスト４０５を生成する。コマンドリスト４０５は、ＳＰＵに、そのセグメントを処理するためのコードとデータをどこで見出すことができるかを示す。グラフィックスカード４０６の制約のために、セグメントは２つのグループに分割される。

この例においては、レンダイベント４０１を処理するために、３個のＳＰＵのみが、使用可能であると仮定している。ＳＰＵ１がコマンドリスト４０５から、最初のコマンドを取り出す。それは、グループ１のためのセットアップコマンドである。セットアップコマンドは、この特定のグループに関連する特別なデータのリストを含む。そのデータのリストは、そのグループについての詳細を把握する必要がある、全ての他のプロセッサに渡す必要がある。グラフィックスの例の場合は、そのような特別なデータは、テクスチャや、ライティングや変換などのレンダ状態を含んでもよい。これらは、必ずしも処理されるＳＰＵセグメントのために必要とされるのではなく、そのグループのＳＰＵセグメントデータの出力を待つグラフィックスカードまたは他のプロセッサのために必要とされる。そして、ＳＰＵ１、ＳＰＵ２およびＳＰＵ３は、セグメント１、２および３のためのタスクを取り出す。これらのタスクコマンドは、ＳＰＵに、それを処理するためのデータとコードをどこで見出すことができるかを示す。ＳＰＵがすでに、そのローカルストアに必要なコードをロードしている場合には、コードをロードするステップを省略することができる。セグメント１、２、および３を処理した後、そのＳＰＵは、結果の出力をグラフィックスカード４０６に転送する。しかしながら、グループ１のすべては処理されていないので、グラフィックスカード４０６は、それらの処理を開始しない。ただし、ＳＰＵ１、ＳＰＵ２およびＳＰＵ３は、セグメント１、２および３の処理を終了しているため、他のタスクのために利用可能である。

図４Ｂに示すように、ＳＰＵ１は、タスクセグメント４を処理する。その後、キックコマンドをグループ１のために引き出し、グラフィックスカード４０６に渡す。グラフィックスカード４０６は、グループ１の処理を開始する。その間、ＳＰＵ２とＳＰＵ３は、タスクセグメント５と６をそれぞれ引き出しており、それらの処理を開始する。一旦、タスクセグメント５、６が完了すると、結果の出力はグラフィックスカード４０６のバッファに受け渡され、グループ２の準備ができたときにプロセス開始されるべく、待機する。

図４Ｃに示されるように、ＳＰＵ１は、タスクセグメント７を引き出し、ＳＰＵ２は、タスクセグメント８を引き出す。これらのタスクセグメントの処理が完了したとき、これらのセグメントの対応する出力は、グラフィックスカード４０６のバッファに転送される。ＳＰＵ２は、グループ２内の最後のセグメントであるタスクセグメント８を引き出したため、ＳＰＵ２はその次に、グループ２のキックコマンドを引き出す。それは、セグメント８についてのＤＭＡが完了した後、グラフィックスカード４０６に受け渡される。

この例においては、タスクセグメントは、順次処理されていることに留意されたい。これは、厳密に必須という訳ではない。また一方、効率的な動作を保証するためには、どのタスクが完了され、どのタスクが完了していないのか、ＳＰＵが把握することが望ましい。そのようにして、あるグループ内の最後の未処理タスクセグメントを処理したＳＰＵは、それ自身がキックコマンドをグラフィックスカードに送るべきであることを判定できる。この目的を達成するためには、ｃｅｌｌプロセッサ２０１がメモリ２０２内に「通知板」を含むことが望ましい。通知板に対して、定期的に問い合わせと更新を行うことにより、ＳＰＵは、追加のセグメントが処理を要求しているか、および／あるいは、特定のグループが完了したか、判定することができる。通知板は、例えば、下の表２に示されるように、編成されうる。

表２は、図４Ｂに示される処理のスナップショットを表す。具体的には、タスク１、２、３および４は完了されており、グループ１が現在、完了されている。セグメント８はまだ、処理を待っている。ＳＰＵ１の「グループの状態」欄内の「完了」は、ＳＰＵ１が、「キックグループ１」コマンドをグラフィックスカード４０６に送るべきであることを、ＳＰＵ１に示す。タスク１、２および３の「主体」欄の値「なし」は、これらのタスクについて、動作しているＳＰＵがないことを示す。これらのタスクは完了しているためである。同様に、タスク７および８の「主体」欄の値「なし」は、これらのタスクについて動作しているＳＰＵがないことを示す。なぜならば、「状態」欄の値「待機中」によって示されるように、これらのタスクは、まだ処理されていないからである。

ｃｅｌｌプロセッサにおいて、各ＳＰＵは、ローカルストレージへの、またはローカルストレージからの他のデータを転送しながら同時に、データを処理できる。ＳＰＵが、タスクセグメントの処理を効率的に推進するためには、タスクセグメント内のデータをバッファリングすることにより、この能力を活かすことが望ましい。図５は、想定される例のうち、そのようなバッファリングがどのようにして実行されるのかについて説明する例の一を示す。この例においては、大きなレンダイベント５０１が、ｃｅｌｌプロセッサ上で処理されるために、８個のセグメントの頂点データに分割される。ｃｅｌｌプロセッサのＳＰＵ５０２は、インタリーブされたＳＰＵタスクのタスキングのため、およびＤＭＡ転送のために、セグメントをバッファリングしてもよい。なお、これは例示であり、制限を課すものではない。その結果としてＳＰＵ５０２から出力された頂点データは、グラフィックスカードメモリ５０４に１以上のグループとして、ダブルバッファリングされる。これに代えて、グラフィックスカードメモリ５０４において、リングバッファメモリが用いられてもよい。

レンダセグメントのバッファリングは、以下の順序で進められてよい。符号１で示されるように、レンダセグメント１は、ＳＰＵローカルストレージのバッファＡ１の中にロードされる。このタスクデータは処理され、その結果の出力は、符号２に示されるように、ＳＰＵローカルストレージのバッファＡ２に格納される。レンダセグメント１がＳＰＵ５０２によって処理される間に、例えばダイレクトメモリアクセス（ＤＭＡ）によって、符号３で示されるように、レンダセグメント２をバッファＢ１にロードすることができる。ＳＰＵ５０２がレンダセグメント１の処理を終えたとき、対応する出力は、符号４に示されるように、グラフィックスカードメモリ５０４のバッファＡ２に転送される。セグメント１からの出力が転送されている間、ＳＰＵ５０２は、レンダセグメント２を処理し、符号５で示されるように、その結果の出力をバッファＢ２に格納することができる。ＳＰＵ５０２がレンダセグメント２を処理する間、ＤＭＡによって、符号６で示されるように、レンダセグメント３をバッファＡ１に転送することができる。ＳＰＵ５０２がレンダセグメント２の処理を終えた場合、レンダセグメント３がバッファＡ１にロードされている間に、ＳＰＵ５０２は結果の出力をグラフィックスカードメモリ５０４のバッファＢ２に転送してもよい。グラフィックスカードメモリ５０４が完全なグループを収容した時点で、その頂点データのグループを、例えばシェーディングのようなピクセル処理のために、グラフィックスプロセッサ５０６に受け渡すことができる。

図５は、セグメントが単一のＳＰＵへ、または単一のＳＰＵからバッファリングされる様子を示す。ｃｅｌｌプロセッサならではの計算の効率性を十分に活用するためには、セグメント群を複数のＳＰＵにおいて、並行に処理することが望ましい。そのような並行処理は、本発明の実施形態の範囲に含まれる。例えば、図６Ａから６Ｂに示される図は、レンダイベントデータを並行処理できる３個のＳＰＵが、４個の並行ジョブのための４個のレンダグループ用に組織化される様子を示す。レンダグループは、ｃｅｌｌプロセッサ６００のメインメモリ６０２内で編成される。メインメモリ６０２は、さらに、そのレンダイベントを実行するために必要な種々のコマンドを示すコマンドリスト６０４を含んでもよい。これらのコマンドは、レンダイベントセットアップコマンド、各セグメント用のレンダコマンド、および各グループのキックレンダコマンドを含む。これらは、上述のように実装されてよい。メモリ６０２は、前述のタイプの通知板６０６をさらに含んでもよい。

初めに、図６Ａに示すように、レンダグループ１のセグメント１、２および３は、ＳＰＵ１、ＳＰＵ２およびＳＰＵ３により、破線の矢印で示されるように、それぞれのＳＰＵのバッファＡ１にＤＭＡ転送される。ＳＰＵ１、ＳＰＵ２およびＳＰＵ３は、頂点処理セグメント１、２および３を、符号６０３の実線の矢印で示されるように、バッファＡ１からバッファＡ２へと転送する。これにより、バッファＡ１に格納されたセグメントデータが処理され、その結果の出力はバッファＡ２内に格納される。頂点タスキング６０３が進められる間、レンダグループ２のセグメント４、５および６は、符号６０５において点線の矢印で示されるように、ＤＭＡによってＢ１・ＳＰＵバッファに転送される。この時点で、通知板６０６は、テーブル３に示すように表されてもよい。

この例においては、ＳＰＵにロードされたタスクセグメント全てについて、そのタスクがそのＳＰＵによって処理されているか否かにかかわらず、「実行中」の状態が適用されている。

一旦ＳＰＵ１、ＳＰＵ２およびＳＰＵ３において、バッファＡ１、Ａ２のタスクキングが終了すると、図６Ｂにおいて符号６０７の実線の矢印で示されるように、結果の出力データを、ＤＭＡにより、グラフィックスカードに送ることができる。グラフィックスカードの、現在使用中のバッファが、全部揃ったグループを含むときには、グラフィックスカードは、その全部揃ったグループを、処理することができる。この処理においては、例えば、ピクセルタスキングを実行したり、そのグループの頂点データをレンダリングしたりする。例えば、グループ１の最後のセグメントについて処理を終了したＳＰＵは、コマンドリストから、「キックレンダグループ１」コマンドを渡す。ＳＰＵは、さらにレンダグループを処理しつづけることができ、データをグラフィックスプロセッサ６１０のバッファＢにＤＭＡ転送することができる。例えば、セグメント４、５および６をＢ１からＢ２バッファへとタスキングしている間、符号６０９の破線の矢印で示されるように、ＳＰＵ１、ＳＰＵ２およびＳＰＵ３はそれぞれ、セグメント７、８および９をＳＰＵのＡ１バッファに転送してよい。セグメント４、５および６についての処理が終了したとき、その結果の出力は、グラフィックスカードのバッファＢに転送されてよい。そして、セグメント７、８および９を処理する。ＳＰＵ１、ＳＰＵ２およびＳＰＵ３は、これらのセグメントを処理する間、セグメント１０、１１、１２を、符号６１１の破線矢印で示されるように、ＳＰＵのＢ１バッファに転送してよい。この時点で、通知板６０６は、テーブル４に示すように表されてもよい。

この例において、通知板の「主体」欄は、セグメントを処理したＳＰＵのＩＤを、処理が完了した後、保持していることに注意されたい。

また、この例においては簡単のため、一のＳＰＵタスクパスによって、グラフィックスカードバッファを満たすＳＰＵを示していることにも注意されたい。実際の実装においては、一レンダイベントを完了するためには、いくつかのレンダグループが必要であるかもしれない。

上記の議論においては、大きなイベントがセグメントに分割されるものとした。これらのセグメントの大きさは、いくぶんかは、イベントサイズと、ＳＰＵ内の使用可能なストレージとに依存する。大きなイベントをセグメントに分割する処理の一部は、これらのセグメントのサイズと数の決定を伴う。これがどのように実行されるかを説明するためには、数値的な例が有用である。ｃｅｌｌプロセッサとデータ管理部に受け渡されて処理される大量のデータである「処理イベント」が、以下の属性を有すると仮定する。なお、これは例示であり、制限を課すものではない。

1.ＳＰＵ・ＣＴＤＭローダプログラムは１６キロバイト（16*1024バイト）を占める。
2.頂点プロセスは、それぞれ２０キロバイトを占める二個のＳＰＵ処理プログラムを必要とする。
3.イベントのデータ量の総計は、１メガバイト（1*1024*1024バイト）である。
4.個々の入力データはそれぞれ３２バイトである（これは、頂点、単なるｘｙｚベクトルの集合、またはその他、を取り混ぜたものであるかもしれない）。
5.個々の出力データはそれぞれ４８バイトである（これは、出力された頂点、単なる処理されたベクトルの集合、さらに、何か他のものなどである）。
6.ＳＰＵローカルストアの大きさは２５６キロバイト（256*1024バイト）である。

一般的に処理イベントは、他の情報を含むだろう。他の情報とは、例えば、元のデータの記憶場所、そのデータの転送先の記憶場所、そして、その出力と関連づけておく必要がある、処理イベントに特有の他のデータのようなデータである。そのような情報は、イベントに特有なデータのブラックボックスと見なされうる。しかし、これらは、簡単のため、この例には含まれていない。

ＣＴＤＭプログラムは、これらの任意パラメータのＳＰＵ内における制約に基づいて、処理イベントを評価する。この例においては、ＳＰＵがクワッドバッファリングを用いると仮定する。しかしながら、ＣＴＤＭ・ＳＰＵメモリ構成は、適応性があり、ここで述べるクワッドバッファリング構造と同様、トリプルバッファまたはリングバッファ構造をサポートすることもできる。

初めに、ＣＴＤＭは、プログラムが占める空間を判定する。この空間は、ＣＴＤＭＳＰＵローダのための１６Ｋ＋プロセスプログラム１のための２０Ｋ＋プロセスプログラム２のための２０Ｋ＝（ローダを含むプログラムのための５６）を含む。この５６Ｋをローカルストアの容量２５６Ｋから引くと、バッファ用に利用可能な２００Ｋが残る。４個のバッファがあるとすると、これにより、２００Ｋ／４個のバッファ＝バッファあたり５０Ｋが残る。

ＣＴＤＭプログラムは、セグメントの入力と出力が５０Ｋのバッファに収まることを保証しなければならない。一般的に、出力のサイズが入力のサイズよりも大きいときには、入力と出力の双方に、十分なスペースを提供することが望ましい。この場合、すでに所定の場所に存在する入力データの上に、出力データを直接上書きすることはできない。さらにまた、データ内で相互依存関係があるとき、すべての計算を完成させるために、データの一部が必要となるかもしれない。このような相互依存関係の例としては、全ての頂点が一つ一つの出力に影響を持ちうるような、スプラインに基づく曲線生成や、ポリゴンに基づく細分化曲面の計算などのおいてみられる。そのような場合、計算を実行する間、入力データを上書きすることはできない。もしも、相互依存関係がなく、かつ、入力データのサイズが出力データのサイズ以上であるときには、ただ一個のバッファが必要とされる。そのバッファは、入力および出力の両方のバッファとして機能する。この場合についてもまた、ＣＴＤＭが処理することが可能である。

例として、ＣＴＤＭは、以下の計算に基づいてデータのセグメントを生成してもよい。
SPUIOBufferSize = 51200 バイト;(50 * 1024バイト)( ＳＰＵ入力+出力バッファサイズ)
InputElementSize = 32 バイト;(上記の項目４;)
OutputElementSize = 48 バイト;( 上記の項目５)
//初めに、一のバッファ入力+出力に、幾つの完全なエレメントが収まるか見出す必要がある。

NbrOfElementsPerSegment = SPUIOBufferSize / ( InputElementSize + OutputElementSize )
NbrOfElementsPerSegment = 640;
ActualSegmentSize = NbrOfElementsPerSegment * (InputElementSize + OutputElementSize)
//この場合、実際のサイズはバッファと同じであるが、殆どの場合はこれに当てはまらない。

ActualSegmentSize = 50k (すなわち 51200バイト) ;
NbrOfSegments = TotalDataSize / ActualSegmentSize;
NbrOfSegments = 1*1024バイト*1024バイト/ 51200バイト;
NbrOfSegments = 20; //これは、整数の変数である。余りは切り捨てられる。
//もしも余りがあるならば、その余りを処理するために、さらに一のセグメントを加えなければならない。以下のコードは、余りがあるか否か判定し、その余っているデータに、さらに一のセグメントを加える。

if ( TotalDataSize % ActualSegmentSize )
//%は、モジュラスと呼ばれ、整数の割り算の余りを返す。
NbrOfSegments = NbrOfSegments + 1;
NbrOfSegments = 21;

ＣＴＤＭがＳＰＵ上で１メガバイトのデータを動的に処理するためには、上記のＳＰＵの構成と、入力および出力のデータサイズを所与として、２１（実際には２０．４８）個のデータセグメントが必要である。とはいえ、上の計算においては、セグメントのグルーピングについては考慮していないことに注意されたい。なぜなら、基本的に、ＳＰＵセグメント生成において、グルーピングは適切でないからである。出力ターゲットの出力を所与として、グルーピングは第二の計算として生じる。例えば、ＳＰＵからくるデータを入れるために、２５６ｋのバッファしかないかもしれない。この演算は、非常に似ている計算を含むが、異なるパラメータについても考慮している。

TargetDataSize = 256k; ( 256 * 1024バイト )
//幾つのセグメントがそのグループの入るべきか判定するために要するのは、出力サイズのみである。なぜならば、それが、例えばグラフィックスカードメモリバッファのターゲット出力に影響を与える全てであるからである。

NbrGroups = TargetDataSize / (NbrOfElementsPerSegment * OutputElementSize) ; (上記の項目5 によるエレメントサイズ)
NbrGroups = 262144バイト / (640 * 48 バイト);
NbrGroups = 8:
//余りが切り捨てられる。
//セグメント数の計算と同様に、CTDMは余りを確認し、必要であれば他のグループを加える。

if (TargetDataSize % (NbrOfElementsPerSegment*OutputElementSize))
NbrGroups = NbrGroups + 1;

上記の計算から分かるように、上記のＳＰＵメモリ制約と入力および出力データサイズを所与として、ＣＴＤＭがＳＰＵ上で、１メガバイトのデータを動的に処理するためには、９グループのデータセグメントが必要である。ここで、上記の処理は、ＣＴＤＭの「データ委託（Data Delegation）」ポーション（portion）と呼ぶ。

当業者には認識されるように、ここで説明された実施形態については、様々な変形例が可能である。例えば、異なる数のＳＰＵが用いられてもよく、また、セルアーキテクチャによっては複数のグループのＳＰＵとＰＰＥが用いられてもよい。さらに、上の議論においては、グラフィックスカードでのピクセル処理とともに、関連するｃｅｌｌプロセッサ上での頂点処理について述べたが、本発明の実施形態は、決して、そのような用途に制限されるものではない。当業者は、ここでの教示と一貫性のあるｃｅｌｌのタスクおよびデータ管理について、多くの異なる用途を考案することができるだろう。

ＣＴＤＭの実施形態は、かならずしも、ＰＰＵ上に常駐しなくてもよい。これに代えて、ＣＴＤＭは、特別な役割を有するＳＰＥ（データ管理ＳＰＥと呼ばれる）上で動作してもよい。このような構成は、場合によっては、より効率的である可能性がある。このような構成によれば、所定の「データ管理ＳＰＥ」に全般的に処理イベントをタスキングする場合をのぞいて、ＰＰＵがほぼ完全に中断されないからである。ＰＰＵは、セグメントおよびグループにした処理の各ＳＰＥへの移管を扱う必要はないであろう。全てのセグメントとグループを含む全般的な処理イベントが完了したとき、データ管理ＳＰＵは、ＰＰＵに信号を送ることが可能である。データ管理ＳＰＥはまた、その全般的なイベントのための完了キーを更新することが可能である。ＰＰＵは、そのアイドル時間に完了キーを確認する。これらの二つの可能性により、大小両方のデータに関連づけられた、両方の処理イベントのための効率的な通知が可能となるだろう。

以上は、本発明の好ましい実施形態の完全な記述であるが、他の様々な変形、変更、等価物への置換が可能である。それゆえ、本発明の範囲は、上記の記述によって決定されるのではなく、以下の請求項によって決定されるべきであり、その完全な等価物もその範囲に含まれる。ここで記述された特徴は、好ましいものであるか否かに関わらず、ここで述べたいずれの特徴と組み合わされてもよい。以下の請求項においては、特に明示的に断らない限りは、各要素の数量は一以上である。ここに、添付される請求項は、所与の請求項において、「〜ための手段」との語句を用いて明示的に示される場合の他は、ミーンズ・プラス・ファンクションの制限を含むと解されてはならない。

Claims (42)

1. １以上のコプロセッサエレメントを備えるプロセッサが、該プロセッサのコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも、大きいメモリ空間を必要とするプロセッサイベントを、前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである２以上のセグメントに分割するステップと、
   前記２以上のセグメントを、前記プロセッサが、該プロセッサの１以上のコプロセッサエレメントにおいて処理し、対応する２以上の出力を生成するステップと、
   を備え、
   前記２以上のセグメントを処理するステップは、前記１以上のコプロセッサエレメントが、前記２以上のセグメントの全てのセグメントの処理が完了したか判定するために、前記２以上のセグメントのうちの１以上のセグメントの処理の状態に関する情報を格納する通知板を確認するステップを含むプロセッサのタスクおよびデータ管理方法。
2. 前記２以上のセグメントを処理するステップは、プロセッサが、１以上のコマンドをコマンドリストから引き出すステップを含み、
   前記コマンドは、１以上のセグメントを処理する命令を含む請求項１に記載の方法。
3. 前記２以上のセグメントを処理するステップは、プロセッサが、前記セグメントと対応する出力とをクワッドバッファリングするステップを含む請求項１または２に記載の方法。
4. 前記セグメントサイズは、ローカルストレージ用バッファのサイズ以下である請求項１から３のいずれかに記載の方法。
5. 前記プロセッサイベントを２以上のセグメントに分割するステップは、プロセッサが、ローカルストレージ用バッファのサイズと、プロセッサイベントのサイズと、個々の入力データである入力エレメントのサイズと、個々の出力データである出力エレメントのサイズとに基づいて、前記セグメントサイズを決定するステップを含む請求項１から４のいずれかに記載の方法。
6. 前記プロセッサイベントを２以上のセグメントに分割するステップは、プロセッサが、前記プロセッサイベントのサイズおよび前記セグメントサイズに基づいて、前記プロセッサイベントを分割してなるセグメントの数を決定するステップを含む請求項５に記載の方法。
7. プロセッサが、前記２以上の出力を関連づけて１以上のグループとするステップをさらに含む請求項１に記載の方法。
8. 前記プロセッサは、各グループが、該プロセッサによって生成された出力に次の処理を施す出力プロセッサが処理可能なターゲットデータサイズ以下のメモリ容量を必要とするように前記２以上の出力を関連づけて１以上のグループとする請求項７に記載の方法。
9. 前記２以上の出力を関連づけて１以上のグループとするステップは、
   個々の出力データである出力エレメントのサイズ、セグメント当たりの出力エレメントの数、および前記プロセッサによって生成された出力に次の処理を施す出力プロセッサが処理可能なターゲットデータサイズに基づいて、プロセッサが、グループの数を計算するステップを含む請求項７または８に記載の方法。
10. 前記出力プロセッサが、前記対応する２以上の出力を、該出力プロセッサへの入力として用いるステップをさらに備える請求項８または９に記載の方法。
11. 前記出力プロセッサは、グラフィックスカードである請求項１０に記載の方法。
12. 前記プロセッサイベントは、頂点レンダリングイベントである請求項１から１１のいずれかに記載の方法。
13. 前記２以上の出力を関連づけて、１以上のグループとするステップをさらに含み、
    各グループのサイズは、前記プロセッサによって生成された出力に次の処理を施す出力プロセッサが処理可能なターゲットデータサイズ以下である請求項１に記載の方法。
14. 前記次の処理は、プロセッサが、他のグループを第２のバッファにロードしながら、第１のバッファに格納された１以上のセグメントからなるグループについての処理を実行するステップを含む請求項１３に記載の方法。
15. 前記プロセッサイベントは頂点レンダリングイベントであり、前記次の処理はピクセルレンダリングイベントである請求項１３または１４に記載の方法。
16. 前記ピクセルレンダリングイベントは、ピクセルシェーディングプロセスを含む請求項１５に記載の方法。
17. 前記２以上のセグメントを１以上のコプロセッサエレメントにおいて処理するステップは、
    プロセッサが、第１のコプロセッサエレメントで第１のセグメントを処理するステップと、
    プロセッサが、第２のコプロセッサエレメントで第２のセグメントを処理するステップとを含む請求項１から１６のいずれかに記載の方法。
18. プロセッサが、前記２以上の出力を関連づけて１以上のグループとするステップをさらに含み、
    各グループのサイズは、前記プロセッサによって生成された出力に次の処理を施す出力プロセッサが処理可能なターゲットデータサイズ以下であり、
    前記２以上のセグメントを１以上のコプロセッサエレメントにおいて処理するステップは、プロセッサが、前記関連づけられた２以上のセグメントのグループの各セグメントを異なるコプロセッサエレメントにおいて処理するステップを含む請求項１に記載の方法。
19. 前記２以上のセグメントを１以上のコプロセッサエレメントにおいて処理するステップは、プロセッサが、一のセグメントをバッファにロードし、他のセグメントを他の１以上のバッファへと転送しながら、かつ／または、他の１以上のバッファから転送しながら、前記一のセグメントを処理するステップを含む請求項１から１８のいずれかに記載の方法。
20. メインプロセッサと、１以上のコプロセッサエレメントと、前記メインプロセッサおよびコプロセッサエレメントと接続されたメインメモリとを有するプロセッサであって、
    各コプロセッサエレメントはコプロセッサユニットとローカルストレージを含み、
    前記メインメモリ内部にはコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも、大きいメモリ空間を必要とするプロセッサイベントを示すデータ、および／またはコードが組み込まれ、また、前記プロセッサによる１以上のコプロセッサエレメントにおける２以上のセグメントの処理の状態に関する情報を格納する通知板が組み込まれ、
    前記プロセッサは、タスクおよびデータ管理方法を実現するための、プロセッサ可読な命令を実行すべく構成され、
    前記方法は、
    前記プロセッサイベントを、前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである前記２以上のセグメントに分割するステップと、
    前記２以上のセグメントを、前記プロセッサの１以上のコプロセッサエレメントにおいて処理し、対応する２以上の出力を生成するステップとを備え、
    前記前記２以上のセグメントを処理するステップは、前記１以上のコプロセッサエレメントが、前記２以上のセグメントの全てのセグメントの処理が完了したか判定するために、前記通知板を確認するステップを含むプロセッサ。
21. 前記プロセッサイベントを２以上のセグメントに分割するステップは、
    ローカルストレージ用のバッファのサイズと、プロセッサイベントのサイズと、個々の入力データである入力エレメントのサイズと、個々の出力データである出力エレメントのサイズとに基づいて、前記セグメントサイズを計算するステップを含む請求項２０に記載のプロセッサ。
22. プロセッサイベントを２以上のセグメントに分割するステップは、前記プロセッサイベントのサイズおよび前記セグメントサイズに基づいて、前記プロセッサイベントを分割してなるセグメントの数を決定するステップを含む請求項２１に記載のプロセッサ。
23. メインメモリに組み込まれたコマンドリストをさらに備え、
    前記コマンドリストは、前記セグメントそれぞれの処理に付随する１以上のコマンドを含む請求項２０から２２のいずれかに記載のプロセッサ。
24. 前記１以上のコマンドはキックコマンドを含み、
    前記キックコマンドは、他のプロセッサに、前記２以上の対応する出力を含むグループの処理を開始するよう命令する請求項２３に記載のプロセッサ。
25. 前記他のプロセッサは、グラフィックスカードである請求項２４に記載のプロセッサ。
26. １以上のコプロセッサエレメントは、一のセグメントをバッファにロードし、他のセグメントを１以上の他のバッファへと、かつ／または、１以上の他のバッファから転送しながら、前記一のセグメントを処理するよう構成された請求項２０から２５のいずれかに記載のプロセッサ。
27. 前記２以上のセグメントのグループのサイズは、前記プロセッサによって生成された出力に次の処理を施す出力プロセッサが処理可能なターゲットデータサイズ以下であり、
    前記２以上のセグメントを、１以上のコプロセッサエレメントにおいて処理するステップは、前記グループ内の各セグメントを異なるコプロセッサエレメントにおいて処理するステップを含む請求項２０から２６のいずれかに記載のプロセッサ。
28. 前記プロセッサイベントは、頂点レンダリングイベントである請求項２０から２７のいずれかに記載のプロセッサ。
29. 前記コプロセッサエレメントのうち選択された一のコプロセッサエレメントのローカルストレージに、タスクおよびデータ管理方法をプロセッサに実現させるための、プロセッサ可読な命令が組み込まれ、
    前記選択されたコプロセッサエレメントは、データ管理コプロセッサエレメントとして動作する請求項２０から２８のいずれかに記載のプロセッサ。
30. メインプロセッサと、コプロセッサユニットおよびローカルストレージを含む１以上のコプロセッサエレメントと、前記メインプロセッサおよびコプロセッサエレメントと接続されたメインメモリとを有するプロセッサと、
    前記プロセッサによって生成された出力を処理できるよう該プロセッサと接続された出力プロセッサと、
    前記メインメモリおよび／または一以上のコプロセッサエレメントのローカルストレージ内に、タスクおよびデータ管理方法を前記プロセッサに実現させるよう構成されたプロセッサ可読な命令の集合とを備え、
    前記メインメモリには、２以上のセグメントの処理の状態に関する情報を格納する通知板が組み込まれ、
    前記方法は、
    プロセッサイベントを、前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである前記２以上のセグメントに分割するステップと、
    前記２以上のセグメントを、前記プロセッサの１以上のコプロセッサエレメントにおいて処理し、対応する２以上の出力を生成するステップと、
    前記対応する２以上の出力を前記出力プロセッサに転送するステップと、
    前記出力プロセッサを用いて、前記対応する２以上の出力を処理するステップとを備え、
    前記前記２以上のセグメントを処理するステップは、前記１以上のコプロセッサエレメントが、前記２以上のセグメントの全てのセグメントの処理が完了したか判定するために、前記通知板を確認するステップを含むプロセッサに基づくシステム。
31. 前記プロセッサイベントを２以上のセグメントに分割するステップは、
    ローカルストレージ用バッファのサイズと、プロセッサイベントのサイズと、個々の入力データである入力エレメントのサイズと、個々の出力データである出力エレメントのサイズとに基づいて、前記セグメントサイズを計算するステップを含む請求項３０に記載のシステム。
32. 前記プロセッサイベントを２以上のセグメントに分割するステップは、前記プロセッサイベントのサイズおよび前記セグメントサイズに基づいて、前記プロセッサイベントを分割してなるセグメントの数を決定するステップを含む請求項３１に記載のシステム。
33. 前記プロセッサイベントは、頂点処理イベントである請求項３０から３２のいずれかに記載のシステム。
34. 前記出力プロセッサは、グラフィックスカードである請求項３０から３３のいずれかに記載のシステム。
35. 前記メインメモリに組み込まれたコマンドリストをさらに備え、
    前記コマンドリストは、前記セグメントそれぞれの処理に付随する１以上のコマンドを含む請求項３０から３４のいずれかに記載のシステム。
36. 前記１以上のコマンドはキックコマンドを含み、
    前記キックコマンドは、前記出力プロセッサに、前記２以上の対応する出力を含むグループの処理を開始するよう命令する請求項３５に記載のシステム。
37. 前記２以上の出力が関連づけられて、前記出力プロセッサが処理可能なターゲットデータのサイズ以下のメモリ容量を要するグループとされる請求項３０から３６のいずれかに記載のシステム。
38. 前記プロセッサイベントは、頂点処理イベントであり、
    前記２以上のセグメントを処理するステップは、頂点データについての頂点変換
    を実行するステップを含み、
    前記出力プロセッサにおいて対応する２以上の出力を処理するステップは、前記対応する２以上の出力についてピクセル処理を実行するステップを含む請求項３０から３７のいずれかに記載のシステム。
39. 前記ピクセル処理は、シェーディング処理である請求項３８に記載のシステム。
40. 前記２以上のセグメントを、１以上のコプロセッサエレメントにおいて処理するステップは、前記２以上のセグメントの各セグメントを異なるコプロセッサエレメントにおいて処理するステップを含む請求項３０に記載のシステム。
41. １以上のコプロセッサエレメントを備えるプロセッサにプロセッサのタスクおよびデータ管理方法を実現させるためのプロセッサ可読命令の集合が組み込まれたプロセッサ可読媒体であって、
    前記方法は、
    プロセッサのコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも、大きいメモリ空間を必要とするプロセッサイベントを、プロセッサが、前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである２以上のセグメントに分割するステップと、
    プロセッサが、前記２以上のセグメントを、前記プロセッサの１以上のコプロセッサエレメントにおいて処理し、対応する２以上の出力を生成するステップと、
    を備え、
    前記プロセッサは、２以上のセグメントの処理の状態に関する情報を格納する通知板が内部に組み込まれたメインメモリを備え、
    前記前記２以上のセグメントを処理するステップは、前記１以上のコプロセッサエレメントが、前記２以上のセグメントの全てのセグメントの処理が完了したか判定するために、前記通知板を確認するステップを含むプロセッサ可読媒体。
42. １以上のコプロセッサエレメントを備えるプロセッサ用のタスクおよびデータ管理装置であって、
    プロセッサのコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも、大きいメモリ空間を必要とするプロセッサイベントを、前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである２以上のセグメントに分割する手段と、
    前記２以上のセグメントを、前記プロセッサの１以上のコプロセッサエレメントにおいて処理し、対応する２以上の出力を生成する手段と、
    とを備え、
    前記前記２以上のセグメントを処理する手段は、前記１以上のコプロセッサエレメントが、前記２以上のセグメントの全てのセグメントの処理が完了したか判定するために、通知板を確認する手段を含み、
    前記プロセッサイベントを分割する手段は、前記２以上のセグメントのうち１以上のセグメントの処理の状態に関する情報を格納する通知板が内部に組み込まれたメインメモリを備えるプロセッサタスクおよびデータ管理装置。

Images