【誤訳訂正書】
【提出日】平成22年12月7日(2010.12.7)
【誤訳訂正１】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
第１パイプラインの第１セットの機能間にメモリ内のアドレス範囲を分配することと、
前記第１パイプラインの第１セットの機能が、前記アドレス範囲を使用するデータ上で動作することと、
前記メモリ内の異なるアドレス範囲を、前記第１セットの機能がデータをフラッシュされるのを待つことなしに第２パイプラインの第２セットの機能間に再分配することと
を含む方法。
【請求項２】
前記分配は、前記第１セットの機能間にアドレスフェンスのセットを分配することを含む、請求項１に記載の方法。
【請求項３】
前記分配は、
アドレスがアドレスフェンス内にあるか否かを決定することと、
前記アドレスが前記アドレスフェンス内に該当する場合は前記アドレスを処理することと、
前記アドレスが前記アドレスフェンス外に該当する場合は前記アドレスを別の機能に転送することと
を含む、請求項２に記載の方法。
【請求項４】
前記動作は、
プロセシングタスクに対してメモリ内の空間を割り当てることと、
前記タスクをプロセッサにディスパッチすることと、
前記タスクに対応する前記メモリ内のアドレスのリストを次の機能のために生成することと
を含む、請求項１から３のいずれかに記載の方法。
【請求項５】
前記動作は、
前記アドレスのリストに関連付けられたデータが消費されるまで待つことと、
スコアボード内の前記アドレスのリストを開放すること
を含む、請求項４に記載の方法。
【請求項６】
前記再分配は、
前記第２セットの機能間に新しいアドレスフェンスのセットを分配することと、
前記アドレスが新アドレスフェンス内に該当する場合はアドレスを旧スコアボードから新スコアボードに変換することと、
前記アドレスが新アドレスフェンス外に該当する場合は前記旧スコアボード内の前記アドレスの所有権を転送することと
を含む、請求項１から５のいずれかに記載の方法。
【請求項７】
前記再分配は、次の機能にメッセージを送り、その新アドレスフェンスに関するその旧スコアボードおよび新スコアボードに対して前記変換および前記転送を始めることをさらに含む、請求項６に記載の方法。
【請求項８】
前記再分配が行われた後に前記異なるアドレス範囲を使用して、前記第２パイプライン内の前記第２セットの機能が動作することをさらに含む、請求項１から７のいずれかに記載の方法。
【請求項９】
固定機能のセットのうちのグラフィカル処理デバイスに以前に割り当てられた量とは異なる量の物理的メモリを、前記固定機能のセットに関連付けられたデータの完全なフラッシュを行うことなしに割り当てることを含む、請求項１から８のいずれかに記載の方法。
【請求項１０】
前記固定機能のセットは、前記割り当て中に前記物理的メモリを使用かつアクセスし続ける、請求項９に記載の方法。
【請求項１１】
前記割り当ては、前記固定機能のセットにおいて旧セットのアドレスフェンスと新セットのアドレスフェンスとの間で前記メモリ内のアドレスを伝えることを含む、請求項９または１０に記載の方法。
【請求項１２】
前記割り当ては、前記新セットのアドレスフェンスに応じて高優先バス上の固定機能間で前記メモリ内のアドレスの所有権を転送する、請求項１１に記載の方法。
【請求項１３】
メモリと、
前記メモリの一部が割り当てられる複数の設定可能な機能ブロックと
を備え、
前記複数の機能ブロックのうち第１パイプラインの第１セットの機能ブロックは、第１セットの機能ブロック間にメモリ内のアドレス範囲を分配し、
前記第１パイプラインの第１セットの機能ブロックが、前記アドレス範囲を使用するデータ上で動作し、
前記複数の機能ブロックのうち第２パイプラインの第２セットの機能ブロックは、前記第１セットの機能ブロックがデータをフラッシュされるのを待つことなしに、前記メモリ内の異なるアドレス範囲を、第２パイプラインの第２セットの機能間に再分配する
システム。
【請求項１４】
前記第１セットの機能ブロックは、前記第１セットの機能ブロック間にアドレスフェンスのセットを分配することを含む、請求項１３に記載のシステム。
【請求項１５】
前記第１セットの機能ブロックのそれぞれは、前記分配において、
アドレスがアドレスフェンス内にあるか否かを決定し、
前記アドレスが前記アドレスフェンス内に該当する場合は前記アドレスを処理し、
前記アドレスが前記アドレスフェンス外に該当する場合は前記アドレスを別の機能ブロックに転送する
請求項１４に記載のシステム。
【請求項１６】
前記第１セットの機能ブロックは、前記動作において、
プロセシングタスクに対してメモリ内の空間を割り当て、
前記タスクをプロセッサにディスパッチし、
前記タスクに対応する前記メモリ内のアドレスのリストを次の機能ブロックのために生成する
請求項１３から１５のいずれかに記載のシステム。
【請求項１７】
前記第１セットの機能ブロックは、前記動作において、
前記アドレスのリストに関連付けられたデータが消費されるまで待ち、
スコアボード内の前記アドレスのリストを開放する
請求項１６に記載のシステム。
【請求項１８】
前記第２セットの機能ブロックは、前記再分配において、
前記第２セットの機能ブロック間に新しいアドレスフェンスのセットを分配し、
前記アドレスが新アドレスフェンス内に該当する場合はアドレスを旧スコアボードから新スコアボードに変換し、
前記アドレスが新アドレスフェンス外に該当する場合は前記旧スコアボード内の前記アドレスの所有権を転送する
請求項１３から１７のいずれかに記載のシステム。
【請求項１９】
前記第２セットの機能ブロックは、前記再分配において、次の機能ブロックにメッセージを送り、その新アドレスフェンスに関するその旧スコアボードおよび新スコアボードに対して前記変換および前記転送を始める請求項１８に記載のシステム。
【請求項２０】
前記第２パイプライン内の前記第２セットの機能ブロックは、前記再分配が行われた後に前記異なるアドレス範囲を使用して動作する請求項１３から１９のいずれかに記載のシステム。
【請求項２１】
前記機能ブロックの各々は、
前記機能ブロックによって現在使用されるメモリ内の範囲を画定する値を格納するアドレスフェンスユニットと、
前記現在使用される範囲の利用を追跡記録するスコアボードユニットと
を有する請求項１３から２０のいずれかに記載のシステム。
【請求項２２】
前記機能ブロックの各々は、前記アドレスフェンスユニット内の値に基づいて、前記メモリ内のアドレス値と前記スコアボードユニット内のインデクスとの間の変換を行う計算ユニットをさらに含む、請求項２１に記載のシステム。
【請求項２３】
前記機能ブロックの各々は、前記計算ユニットからのインデクスに基づいて、前記スコアボードユニット内の値をセットまたはクリアするロジックをさらに含む、請求項２２に記載のシステム。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】スレッドプロセッサにおける多重クライアントへのバッファの動的割り当て
【技術分野】
【０００１】
（関連出願の相互参照）本願は、「スレッドプロセッサにおける多重クライアントへのバッファの動的割り当て」という名称で２００４年１２月２３日に出願された米国仮出願シリアル番号第６０／６３８，４２７の利益を主張し、そのすべての内容は本明細書に参照として組み込まれる。
【０００２】
請求項に記載の発明の実施例は、一般にメモリの割り当てに関し、詳しくはプロセス間でのメモリの動的割り当てに関する。
【背景技術】
【０００３】
データプロセシングにおいては、いくつかのプロセスによる使用のためにメモリが論理的に分割されることがある。例えば４つのプロセスが実行中の場合、メモリは、各プロセスに対応する４つの部分に分割される。プロセスが（例えばパイプラインプロセスの一部として）関連している場合、かかる分割スキームは、各プロセスをメモリの所定最小量に割り当ててデッドロックを防止する。メモリの上記最小限総量の残量はプロセス間で割り当てられ、プロセスによるパフォーマンスがより良好にされる。
【０００４】
いくつかのプロセスがメモリの変更を使用する場合、メモリの割り当てを変更して新たな数のプロセス（上記例の４つのプロセスの代わりに例えば３または５）に対してメモリを最適化することが望ましい。しかし、既存プロセスのいくつかまたはすべては、関連付けられたデータをメモリ内に有し、かかるデータはメモリーの別のプロセスの一部に該当するか、そのプロセスが中断された場合はオーファンとなっている。したがって、典型的には、メモリは、新たな数のプロセス間で再分割される前にフラッシュされ（例えばデータが空にされ）る。いくつかの場合には、インプロセスデータは、メモリから即座に削除／フラッシュされて、新たな分割スキームの下で必要に応じてリロードされる。他の場合には、メモリを再分割する前にプロセスに処理を完了させることによって、インプロセスデータはメモリから暗黙的にフラッシュされる。
【０００５】
しかし、フラッシュのために使用されるスキームにもかかわらず、メモリのフラッシュはプロセスのパフォーマンスに悪影響を与える。分割または割り当ての前にメモリをフラッシュすることは、旧プロセス、新プロセスまたは両者によるデータプロセシングを遅延させる。
【発明の開示】
【０００６】
本明細書に組み込まれて本明細書の一部をなす添付の図面は、本発明の原理に整合する１つ以上の実施例を示し、記載とともにかかる実施例を説明する。図面は実寸どおりとは限らず、その代わりに本発明の原理を示すことに重点が置かれる。
【発明を実施するための最良の形態】
【０００７】
以下の詳細な説明は添付の図面を参照する。同じまたは類似する要素を特定するために、異なる図面において同じ参照番号が使用される。以下の説明において、請求項に記載の発明の様々な側面の十分な理解を与えるために、具体的な詳細は、特定の構造、アーキテクチャ、インターフェイス、テクニック等のように記載されるが、説明を目的とするものであって限定を目的とするものではない。しかし、本開示の利益を有する当業者にとっては、請求項に記載された本発明の様々な側面が、かかる具体的な詳細から逸脱する他の例で実施できることは明らかであろう。所定の例においては、不必要な詳細で本発明の説明を不明瞭にしないため、周知のデバイス、回路および方法の説明は省略される。
【０００８】
図１は、システム１００の例を示す。システム１００は、メモリ階層１１０、スレッドディスパッチャ１２０、バス１３０およびプロセシングコア１４０−１〜１４０−ｎ（集合的には「プロセシングコア１４０」）を含む。システム１００は、マルチスレッド実行をサポートするマルチプロセシングコア１４０を含む。いくつかの実施例においては、各プロセシングコア１４０は１つまたは多数のスレッドをサポートする。単一プロセッサ（例えばコア１４０−１）に対するマルチスレッディングは、アクティブなスレッドが実行される一方で他のスレッドが非アクティブ状態にあるようにすることによって有効に実行できる。
【０００９】
メモリ階層１１０は、１つ以上のプロセシングコア１４０によって実行中に使用されるべきデータおよび命令を格納する。メモリ階層１１０は、動的ランダムアクセスメモリ（ＤＲＡＭ）、１つ以上のレベルの命令キャッシュ、１つ以上のレベルのデータキャッシュおよび／または１つ以上のレベルの共有命令およびデータキャッシュを含む。
【００１０】
メモリ階層１１０に接続されるスレッドディスパッチャ１２０は、新たなスレッドに関連付けられる命令ポインタおよびデータならびに／またはデータポインタ情報を受け取る。スレッドディスパッチャ１２０は、バス１３０を介してプロセシングコア１４０に接続される。スレッドディスパッチャ１２０は、プロセシングコア１４０のスレッドリソースを管理する。新たなペンディングスレッドを受け取る際、スレッドディスパッチャ１２０は１つのプロセシングコア（例えばコア１４０−３）を選択する。このプロセシングコアは、ペンディングスレッドを実行するべく利用可能なリソースを有しており、選択されたコアへバス１３０を介してスレッドをディスパッチする。プロセシングコアによる既存スレッドの完了の際、スレッドディスパッチャ１２０は通知を受け、そのプロセシングコアへのスレッドリソースを将来のスレッドに開放する。
【００１１】
図２はスレッドディスパッチャ１２０の１つの可能な実施例を示す。スレッドディスパッチャ１２０は、コマンドパーサ２１０、いくつかの機能ブロック２２０−１、２２０−２、・・・、２２０−ｎ（集合的には「機能ブロック２２０」）、高優先バスインターフェイス（ＨＰＢＩ）２３０、低優先バスインターフェイス（ＬＰＢＩ）２４０、統合リターンバッファ（ＵＲＢ）２５０およびディスパッチャ２６０を含む。
【００１２】
コマンドパーサ２１０は、所定のコマンドおよび要求を機能ブロック２２０が処理できるフォーマットに変換する。例えば、コマンドパーサ２１０は、いくつかの機能ブロック２２０に関連する単一コマンドを、個々の機能ブロック２２０に送られるいくつかのコマンドおよび／または命令に分解する。
【００１３】
機能ブロック２２０は、異なる機能を恐らくはパイプラインの態様で実行する。いくつかの実施例においては、機能ブロック２２０は、１つ以上の頂点シェーダ、テセレータ、ジオメトリシェーダ、クリッパ、セットアップモジュールおよびウィンドワ（ｗｉｎｄｏｗｅｒ）のような固定グラフィカル機能を実装する。かかる固定機能のいくつか（例えばいくつかの機能ブロック２２０）は、任意の所定時間においてアクティブであり、他の機能（例えば他の機能ブロック２２０）は非アクティブである。アクティブな機能ブロック２２０の各々は、その出力に対する統合リターンバッファ２５０の所定の指定部分（例えばアドレスのグループ）を使用する。
【００１４】
図３は、機能ブロック２２０の１つの可能な実施例を示す。機能ブロック２２０は、アドレスフェンス３１０のセット、スコアボード３２０のセット、アドレス／インデクス計算ユニット３３０および状態マシン３４０を含む。
【００１５】
アドレスフェンス３１０は、アドレスフェンスのピン／ポンセットを含み、各フェンスはトップレジスタおよびボトムレジスタを有する。トップレジスタおよびボトムレジスタは、機能ブロック２２０がアイテムを格納できる場所であるＵＲＢ２５０内にアドレス範囲を画定するアドレスを格納する。本明細書においては、「ポン」は代替セット（例えば「新」セット）を示すのに対して、「ピン」は別のセット（例えば「旧」すなわち以前のセット）を示す。アドレスフェンス３１０のコンテキストにおいては、トップフェンス値およびボトムフェンス値の初期セットはピンフェンスレジスタに格納され、値の置換セットが到着するとポンフェンスレジスタに格納される。トップ値およびボトム値の別の置換セットが到着するとピンフェンスレジスタに格納され、ポンフェンスは最新の値を有し、というようになる。
【００１６】
スコアボード３２０はピンスコアボードおよびポンスコアボードを含み、各スコアボードは、ＵＲＢ２５０内の追跡記録されたアドレス当たり１ビットを有する。スコアボードは、その機能ブロック２２０に対するＵＲＢ２５０のエントリの最大予測可能割り当てを十分包含できるほど大きい。このため、所定の機能ブロック２２０がＵＲＢ２５０の２０％にのみ割り当てられると、スコアボード３２０はその量のＵＲＢ２５０のエントリ当たり２ビット（ピンおよびポンに対して各１）のサイズになる。
【００１７】
アドレス／インデクス計算ユニット３３０は、インデクスからアドレスを計算するかまたはその逆を計算するためのロジックを含む。本明細書においては、「インデクス」は、アドレスフェンス３１０によって確定されたアドレス範囲内の相対位置を示す数（例えば０に始まりアドレスフェンス３１０のサイズに終わる）を示す。機能ブロック２２０のアドレスフェンス３１０内のアドレスに対しては、そのアドレスに対する対応インデクスは、以下のように計算される：インデクス＝アドレス−トップ、ここでトップはアドレスフェンス３１０の上端を示す。同様に、ユニット３３０は、以下のようにインデクス値からアドレスを計算する：アドレス＝トップ＋インデクス。アドレス／インデクス計算ユニット３３０が使用される例を以下に記載する。
【００１８】
状態マシン３４０は、アドレスフェンス３１０間の変更に際し、スコアボード３２０に再割り当てを行う。かかる再割り当てをさらに詳細に以下に記載する。状態マシン３４０はまた、所定のアドレスを保持すべきか転送すべきかを決定するというような他のアドレスプロセシングも行う。状態マシン３４０はまた、機能ブロック２２０のための他の制御機能および／またはブックキーピング機能も行う。
【００１９】
図２に戻ると、機能ブロック２２０は、２つの双方向バス：ＨＰＢＩ２３０およびＬＰＢＩ２４０によって相互接続される。ＨＰＢＩ２３０およびＬＰＢＩ２４０の各々において、２つのポイント間インターフェイスは各機能ブロック２２０間に及び、一方は「ノース」に向かい、他方は「サウス」に向かう。例えば、アドレスは、ＨＰＢＩ２３０および／またはＬＰＢＩ２４０のサウス方向のインターフェイスにわたりｎ番目の機能ブロック２２０ＦＢ［ｎ］から（ｎ＋ｌ）番目の機能ブロック２２０ＦＢ［ｎ＋ｌ］に送り下げられる。同様に、ＦＢ［ｎ＋ｌ］は、ＨＰＢＩ２３０および／またはＬＰＢＩ２４０のノース方向のインターフェイスにわたり、ＦＢ［ｎ］までアドレスを転送する。機能ブロック２２０間に所有権を伝えるべく発行されるアドレスはＨＰＢＩ２３０で転送される。プロデューサ機能ブロック２２０に返されるペイロードおよび／またはアドレスを生成するべく発行されるアドレスはＬＰＢＩで転送される。
【００２０】
ＨＰＢＩ２３０およびＬＰＢＩ２４０は、いくつかの方法で物理的に実装される。いくつかの実施例においては、２つのインターフェイスは各方向に並列に使用される。いくつかの実施例においては、各方向の１つのインターフェイスはその中に２つの仮想チャネルを備えて使用される。仮想チャネルのメカニズムが実装される場合、例えば、仮想チャネル＃１はＬＰＢＩ２４０に使用される仮想チャネル＃０よりも高い優先順位（例えばＨＰＢＩ２３０）となる。いくつかの実施例においては、ＨＰＢＩ２３０、ＬＰＢＩ２４０またはその両方はフロー制御される。
【００２１】
ＵＲＢ２５０は、プロセシングコア１４０による処理前または処理後に機能ブロック２２０に関連付けられたデータを保持するように構成される。本明細書の記載では、機能ブロック２２０によって、それに関連するアドレスフェンス３１０に基づきＵＲＢ２５０は分割共有される。いくつかの実施例においては、ＵＲＢ２５０は１０２４以下のエントリを有するが、請求項に記載の発明は必ずしもこの点に限定されるわけではない。
【００２２】
ディスパッチャ２６０は、バス１３０を介して機能ブロック２２０からプロセシングコア１４０へ、スレッドをディスパッチする。いくつかの実施例においては、ディスパッチャ２６０は、コア１４０の中のいずれに特定のスレッドを送るべきかを決定する。いくつかの実施例においては、ディスパッチャ２６０は、発信側の機能ブロック２２０によって特定された特定のプロセシングコア２５０へスレッドを送る。
【００２３】
図１に戻ると、バス１３０は、メモリ階層１１０内のいくつかの通信リンク、スレッドディスパッチャ１２０およびプロセシングコア１４０を含む。説明の便宜上、バス１３０は単一のラインとして表されるが、実際にはバス１３０は、１つ以上の制御バス、データバス等を含む。バス１３０は、コア１４０による処理のためにデータをスレッドディスパッチャ１２０から搬送し、処理済みデータもコア１４０からスレッドディスパッチャ１２０および／またはメモリ階層１１０へ搬送する。
【００２４】
システム１００はまた、マルチプロセシングコア１４０も含む。マルチプロセシングコア１４０の各々は、関連付けられた制御回路構成を備える実行回路を含む。プロセシングコア１４０は同一であり、様々な機能性を有する。任意の数のプロセッサコア１４０−１〜１４０−ｎがシステム１００に含まれる。いくつかの実施例においては、プロセッサコア１４０は列状に構成され、各列は関連付けられた列コントローラを有する。
【００２５】
図４は、機能ブロック（ＦＢｓ）２２０間にバッファ２５０内のアドレスを初期的に割り当てるプロセス４００を示すフローチャートである。システム１００のスタートアップに際し、またはリセットおよび／またはフラッシュの後に、すべてのＦＢｓ２２０内のすべてのスコアボード３２０がクリアされてトップ／ボトムフェンスレジスタ３１０は「ｄｏｎ'ｔ  ｃａｒｅ」状態になると仮定する。スレッドディスパッチャ１２０内のコマンドストリームから読み取られたデータの第１シーケンスは、ＦＢｓ２２０の各々に対するトップ／ボトムフェンス値のリストを含む。
【００２６】
かかるトップ／ボトムフェンス値をＦＢｓ２２０間に分配することから処理が開始される［アクト４１０］。引き続いて、かかるトップ／ボトムフェンスレジスタ値はＨＰＢＩ２３０によってＦＢｓ２２０を介してパイプライン化される。いくつかの実施例においては、例えば、ＦＢ２２０−１は、第１トップ／ボトムペアをそのアドレスフェンス３１０に格納し、残りのフェンス値をＦＢ２０１−２に転送する。ＦＢ２２０−２は、残りの値のトップペアをそのアドレスフェンス３１０に格納し、その残りをＨＰＢＩ２３０によってＦＢ２２０−３に転送し、というようになる。最後の機能ブロック２２０−ｎは最後のトップ／ボトムペアを消費する。
【００２７】
ＦＢｓ２２０間に割り当てられるアドレスのリストがコマンドストリーム内に続く［アクト４２０］。アドレスのリストはＨＰＢＩ２３０によって第１ＦＢ２２０−１に入力される。ＦＢ２２０−１は所定のアドレスを見て、それがアドレスフェンス３１０のそのアドレス範囲内にあるか否かを決定する［アクト４３０］。
【００２８】
アドレスがＦＢ２２０−１のアドレスフェンス３１０内にない場合、アドレスは次のＦＢに転送される［アクト４４０］。アドレスがＦＢ２２０−１の範囲内（または転送された場合は２２０−２のような別のＦＢの範囲内）にある場合、ＦＢはアドレスを処理する［アクト４５０］。
【００２９】
かかるアドレスプロセシングにおいては、ＦＢは関連付けられるインデクス、インデクス＝アドレス−ベース、を計算ユニット３３０を介して計算する。この計算されたインデクス値に対し、ビットはその後そのＦＢｓのピンスコアボード３２０にセットされる。アクト４４０およびアクト４５０の戻り矢印に示されるように、かかるアドレスプロセシングは、すべてのアドレスが所定のＦＢ２２０に関連付けられるまで続く。
【００３０】
このシーケンス４００の最後に、すべてのＦＢｓ２２０はそのピンアドレスフェンス３１０が有効となり、そのピンスコアボード３２０は使用を許可されたアドレスに更新される。いくつかの実施例においては、かかるインデクスアドレスはゼロから始まり、シーケンスの最後のアドレスへの増分カウント（０,１,２,...）となるが、請求項に記載の発明はこの点に限定されない。
【００３１】
各スコアボード３２０にビットがセットされると、これは特定のアドレスが「インフライト」（例えば、別の目的地へ移送中）ではないことを示す。したがって、（特定のアドレスフェンス領域内の）スコアボード３２０のゼロ（例えば、セットされていないビット）は、特定のアドレスがインフライトであることを示す。インフライトでないアドレスは再要求（ｒｅｃｌａｉｍ）されて、ＵＲＢ２５０に向かう予定の新たな出力バッファとして再使用される。それとは対照的に、インフライトのアドレスは、新たな出力バッファの一部として使用されるために再要求されることがない。
【００３２】
プロセス４００は、スタートアップにおいてスコアボード３２０をセットするのにそれほど直接的な方法ではないが、かかるスキームによって、アドレスフェンス３１０の再分割がスタートアップシーケンスのスキームに類似する。ＦＢ２２０−１の前にあるアドレスを発行せずにかかるアドレスをパイプラインにまく（ｓｅｅｄ）最適化が可能となる。上記特定のスキーム４００を理解の便宜のため説明するが、その詳細は請求項に記載の発明を必ずしも限定するわけではない。
【００３３】
図５は、機能ブロック（ＦＢｓ）がバッファ２５０内のアドレスを利用するプロセス５００を示すフローチャートである。初期化シーケンス４００の後、ＦＢ２２０−１はそのスコアボードの読み取りポインタをゼロにセットする。ＦＢ２２０−１は、コマンドストリーム（例えば、コマンドパーサ２１０）からタスク（例えば、機能または機能の一部）を受け取る。このタスクに対するバッファリング要件（例えば、ＵＲＢ２５０内に必要な空間の量）に基づいて、ＦＢ２２０−１は、かかる空間をＵＲＢ２５０内に割り当てる［アクト５１０］。
【００３４】
例えばアクト５１０において、ＦＢ２２０−１は、タスクのためのＵＲＢ２５０内の所望数のエントリ（例えば、ワーキングカウント（ＷＣ））とともに、現在のスコアボード読み取りポインタをレジスタ（例えば、ワーキングポインタ（ＷＰ））に格納する。図３には明示的に示されてはいないが、いくつかの実施例においては、ＷＰレジスタおよびＷＣレジスタはスコアボード３２０に含まれる。ＦＢ２２０−１は、スコアボード３２０に、そのスコアボード読み取りポインタで始まる「ワーキングカウント」分の連続した１がセットされているか否かをチェックする。それほど多くの連続した１がスコアボード３２０にセットされていない場合、ＦＢ２２０−１は、かかる数がセットされるようになるまで待つ。しかし、かかる「ワーキングカウント」空間が利用可能であれば、ＦＢ２２０−１は現在の読み取りポインタのビットをクリアして、スコアボード読み取りポインタを一つ進める。こうしてクリアすることおよび進めることは、タスクのために必要なＵＲＢ２５０内のエントリ数（例えば、ＷＣの数）が割り当てられるまで繰り返され、アクト５１０が完了する。アクト５１０のその他の実施例が可能であり、上記は主に理解の便宜のために提示される。
【００３５】
スコアボード３２０内のエントリに対応するＵＲＢ２５０内のアドレスは、アドレス計算ユニット３３０を介してワーキングポインタから以下のように計算される：ＵＲＢアドレス＝ＷＰ＋トップ、ここでトップはアクティブ（例えば、ピンまたはポン）アドレスフェンス３１０から得られる。プロセシングコア１４０が１つ以上のリターンアドレスを要求する場合は、上記計算は複数のリターンアドレスに対して繰り返される。ＵＲＢ２５０内のかかるリターンアドレスは、タスクのこの部分に対する計算が完了する際に、リターンアドレスとしてプロセシングコア１４０に発行される［アクト５２０］。その他のタスク関連情報もまた、アクト５２０に関連してＦＢ２２０−１によってプロセシングコア１４０にディスパッチされる。
【００３６】
すべてのＦＢｓ２２０は、プロセシングコア１４０へと作業をディスパッチした後は、処理後各データがＵＲＢ２５０に戻されたときにＵＲＢ２５０によって信号が送り返される。
【００３７】
こうして信号を送ることは、データがＵＲＢ２５０に書き込まれる際にＵＲＢ２５０によって自動的に行われる。例えば、ＦＢ２２０−１は、ＬＰＢＩ２４０を介してかかる通知を受け取る［アクト５３０］。
【００３８】
アクト５３０においてそのデータがバッファ２５０内にあるという通知を受け取った後、ＦＢ２２０−１は下流の機能ブロック（例えば、ＦＢ２２０−３）がその入力として使用するためのアドレスのリストを生成する［アクト５４０］。一般には、ＦＢ２２０−ｎは、次のＦＢ２２０−（ｎ＋ｘ）が消費するためのＵＲＢ２５０に関連付けられたアドレス＋カウントのリストを生成する。かかるアドレスリストメッセージのフォーマットには、開始ＵＲＢアドレスおよびワードカウントが含まれる。かかるアドレス（およびワードカウント）は、ＬＰＢＩ２４０によってＦＩＦＯ（ファーストイン、ファーストアウト）の形態で近隣の下流機能ブロック（例えばＦＢ２２０−（ｎ＋ｌ））に送られる。ＦＢ２２０−（ｎ＋ｌ）がヌル機能（例えば、所定のタスクのために使用されない）場合は、タスク中の次の機能ブロック２２０、ＦＢ２２０−（ｎ＋ｘ）に到達するまで情報が転送される。
【００３９】
ＦＢ２２０−（ｎ＋ｘ）が完全なワードカウントのためにＵＲＢアドレスによってポイントされたデータを消費した後、送り側のＦＢ２２０−ｎのスコアボード３２０内の対応するエントリは「開放」される。このため、ＦＢ２２０−ｎは、次のＦＢ２２０−（ｎ＋ｘ）によって消費されるべく送られたアドレスのリストに関連付けられたデータを待つ［アクト５５０］。本明細書において、「消費される」という語は、当該アドレスがＵＲＢ２５０から読み取られたということを示す。しかし留意すべきなのは、かかるアドレスが消費されたとみなされても、別の目的地ＦＢ２２０へはまだインフライトの状態であり得る。例えば、アドレスが、その究極の目的地ではないＦＢ２２０によって読み取られた場合、それはその目的地へはまだインフライトでありながら消費されたとみなされる。
【００４０】
アドレスが別のＦＢ２２０によって消費された後、ＦＢ２２０−ｎはアドレスをそのスコアボード３２０の開放リスト（ｆｒｅｅ  ｌｉｓｔ）に戻す（例えば、それはアドレスを「開放」する）［アクト５６０］。かかる「開放」エントリは、ＵＲＢ２５０内の新たなリターンバッファを行うオペレーションにおいて再使用すべく利用可能である。アドレスを開放するために、そのスコアボード３２０内のインデクスは、計算ユニット３３０によって以下のように計算される：インデクス＝ＵＲＢアドレス−アクティブトップフェンス。かかるインデクス計算は、この第１アドレスに関連付けられた「カウント」数のすべてに対して行われる。アドレスプラスカウント数のこのような拡張は「微粒化（ａｔｏｍｉｚａｔｉｏｎ）」と呼ばれる。例えば、１０のアドレスと４のカウントとはアドレス１０、１１、１２および１３に微粒化される。次に、インデクスのセットにおける（例えばアドレス＋カウントに対する）スコアボード３２０の特定の値は、以下のようにアドレスが開放されていることを示すようにセットされる：スコアボード［インデクス］＝１。
【００４１】
「開放」ＵＲＢアドレスおよびカウント（例えば、自己生成されるかまたはノース方向またはサウス方向のＬＰＢＩ２４０を介して受け取られるかのいずれか）を受け取る際、ＦＢ２２０−ｎは、アドレスをその現在のアクティブフェンス３１０のトップ／ボトムペアと比較し、情報を保持するかまたは必要に応じてＬＰＢＩ２４０によってそれをノースまたはサウスに転送するかのどちらかを行う［アクト５７０］。アドレスが（ワードカウントを無視して）そのＦＢ２２０のトップ／ボトム範囲内にある場合、それはその機能ブロックによって保持される。アドレスが（ワードカウントを無視して）そのＦＢ２２０のトップ値よりも小さい場合、それはノース方向のＬＰＢＩ２４０を介して送り上げられ；ＦＢ２２０のボトム値よりも大きい場合、それはサウス方向のＬＰＢＩ２４０を介して送り下ろされる。アクト５６０における「開放」ＵＲＢ＋カウント情報の微粒化後アクト５７０においてアドレスを送り上げるか下げるかを比較決定することは意図的であり、これによってＦＢｓ２２０のすべてをフラッシュする必要性なしにフェンス３１０を動的に変更することができる。後に説明するように、これによって、フェンス３１０が以前の隣接したＵＲＢ割り当て間を移動することも可能となる。
【００４２】
主にＦＢ２２０−１に関して説明したが、プロセス５００が、ＦＢ２２０−２、ＦＢ２２０−３等のような他の機能ブロックによって同様に行われる。
【００４３】
いくつかの実施例においては、ＦＢ２２０は、同じＵＲＢ２５０エントリ（およびワードカウント）を下流のＦＢ２２０に向けて複数回発行する。例えば、いくつかのＦＢｓ２２０は、ＵＲＢ２５０のエントリをキャッシュとして使用し、キャッシュヒットは、所定のＵＲＢエントリを別のＦＢによって１回以上読み取られるようにする。したがって、そのＵＲＢエントリは著しく多数に及ぶことがある。アドレスがインフライトか否かを示すスコアボード３２０は、かかるエントリを、それが複数回消費されるまで「開放」として取り扱うべきではない。
【００４４】
これにより、いくつかの実施例においては、アドレスがスコアボード３３０内に再投入され得るようになる前に、いくつの「開放」インスタンスが必要とされるのかを追跡記録するべく、所定のＦＢｓ２２０は別々のブックキーピングを保持する。こうした振舞いをするかかる機能ブロック２２０は、所定のＵＲＢエントリが発行されるたびにカウントを行うメカニズム、および所定のＵＲＢエントリが「開放」されるたびにカウントを行う補助的なメカニズムを含む。明示的には示されていないが、いくつかの実施例においては、かかるカウントを行うメカニズムは、スコアボード３２０および／または状態マシン３４０に含まれる。このカウントを行うメカニズムは、それが発行するベースＵＲＢアドレスの追跡記録を保持しさえすればよく、カウントフィールドが同じままであれば、ＵＲＢ２５０内の関連付けられたエントリのすべて（例えば、アドレス＋カウント）を保持する必要はない。
【００４５】
プロセス５００がメモリ内のアドレスを利用することを説明してきたが、メモリを機能内に動的に再割り当てすることが以下に説明される。あるポイントでは、ＦＢｓ２２０が「状態を変更」してもよい時点（例えば、１つ以上のＦＢｓ２２０が追加されるとき、または所定の機能チェーンすなわちパイプラインから削除されるとき）である。例えば、ＦＢｓ２２０（すなわち、頂点シェーダ、次いでテセレータ、次いでクリッピング、セットアップおよびウィンドワ）のパイプライン設定が与えられると、この設定においてＵＲＢ２５０の理想的な分割が機能ブロック２２０に存在すると推定される。新たなパイプライン設定（例えば、頂点シェーダ次いでジオメトリシェーダ次いでクリッパ、セットアップおよびウィンドワ、または頂点シェーダ次いでクリッパ、セットアップおよびウィンドワのようなＦＢｓ２２０の別の設定）に対しては、ＦＢｓ２２０の中に異なる理想的なＵＲＢ２５０の分割が存在する。典型的には、かかる状態の変更は、ＦＢｓ２２０の中にＵＲＢ２５０の再分割（例えば、ＦＢｓ２２０内でのアドレスフェンスの変更）を含む。
【００４６】
かかる再分割を達成するための一つの方法は、各連続ＦＢ２２０がアドレスフェンスの変更前のデータをフラッシュされるまで待つことである。しかし、かかるスキームの結果、全パイプラインの状態変更が遅れる一方で連続ＦＢｓ２２０がフラッシュされる「暗示的フラッシュ」となるだろう。再分割のための別の方法は、１つのＦＢ２２０からその新しいアドレスフェンスに応じてアドレスの転送を開始することだろう。しかし、かかるスキームは、１つの「サウス方向」チャネルのみが存在する場合およびそれがフロー制御される場合にはデッドロックとなり得る。
【００４７】
いくつかの実施例によれば、状態の変更と新たな状態内での処理を同時に行う間にデッドロックを避けるべく、第１のＦＢ２２０が下流のＦＢｓ２２０がフラッシュするのを待つことはない。任意のステージのスコアボード３２０にすべて１が投入される（例えばクリアされる）まで待つこともない。状態変更中の遷移においては旧状態からのアドレスが残るが、ＦＢｓ２２０は無分別にアドレスを送り上げおよび送り下げを続けることがない。その代わりに、アドレスはその以前の状態からの通常フローを無分別に完了する一方で、他のアドレスはシステムを介して転送されてそれらを新たな状態にリマップする。後に説明するが、ＨＰＢＩ２３０は、かかる動的状態変更（例えば、メモリの再分割）をデッドロックなしで容易に行う。
【００４８】
図６は、機能ブロックによるアドレスフェンスの動的変更のプロセス６００を示すフローチャートである。チェーンまたはパイプラインの第１機能ブロック（例えばＦＢ２２０−１）に関して説明するが、プロセス６００は、連続するＦＢｓ２２０によって行われてＵＲＢ２５０の動的再割り当てを完了する。
【００４９】
処理は、ＦＢ２２０−１がアドレスフェンス値の新たなセットを受け取ることから開始される［アクト６１０］。かかる新たな値は、アドレスフェンス３１０のピンまたはポン部分のいずれかに、どちらが現在の動作状態に対するフェンスを現在有するかに応じて格納される。すべてのＦＢｓ２２０に対するトップ／ボトムフェンスの新たなリストは、コマンドストリームによって発行され、ＦＢ２２０−１はそのリストから第１トップ／ボトムセットを取得してそれらをその（例えばポン）アドレスフェンス３１０に置く。そして、ＦＢ２２０−１はトップ／ボトムフェンスの残りをＨＰＢＩ２３０を介して次のＦＢ２２０（例えばＦＢ２２０−２）に転送する。
【００５０】
処理が続いて、ＦＢ２２０−１は新たなアドレスフェンスを受け取る前に開始されたプロセシング／ワークを完了する［アクト６２０］。かかるワークは、まだＵＲＢ２５０に戻されていない処理すべきデータを含むが、ＦＢ２２０−１に関連付けられたＵＲＢ２５０内（例えばスコアボード３２０内）のデータを含むわけではない。ＦＢ２２０−１が、その旧状態でまだ動作している間に、その新たなスコアボード（例えばスコアボード３２０の「ポン」部分）にアドレスを「リタイア」することは容認されない。ＦＢ２２０−１がその旧状態でまだ動作している場合は、所有権を求めて転送されているというタグが付けられていないアドレスはいずれも、ＦＢ２２０−１の現在動作中のフェンスに対してフェンスの比較がされ、旧動作状態に基づいて送り上げ、送り下げまたは保持される必要がある。
【００５１】
ＦＢ２２０−１は、その現在のワークを終了した後、旧状態に割り当てられたエントリに対してゼロで開始するその旧スコアボード３２０をスキャンする。スコアボード内のかかるエントリの各々に対し、それは、アドレス＝スコアボードインデクス＋旧トップへのアドレス変換を行う。アドレスが新トップ／ボトムフェンス内の場合は、それはインデクス＝アドレス−新トップの変換を行い、新スコアボード３２０内のそのインデクスのビットをセットする［アクト６３０］。
【００５２】
アドレスが新アドレスフェンスのボトム値より下またはトップ値より上の場合は、ＦＢ２２０−１は、ＨＰＢＩ２３０を介して下流または上流へ、「所有権転送」インジケータとともにアドレスを転送する［アクト６４０］。なお、トップ値の比較は、トップＦＢ２２０−１よりも下のＦＢｓに対してのみ関連する。かかる所有権転送インジケータは、このアドレスがＦＢ２２０−１に送り返されるべきではないことを他のＦＢｓ２２０（例えばＦＢ２２０−２）に示すが、その代わりに受け側ＦＢの新アドレスフェンスと比較される（および新フェンス内であれば受け側ＦＢの新スコアボード内の対応するエントリをセットする）。アクト６３０において変換されたアドレスまたはアクト６４０において転送されたアドレスに対しては、ＦＢ２２０−１は、（例えば、それをゼロにセットすることによって）その旧スコアボード３２０内の対応するエントリをクリアする。図６の破線は、旧スコアボード３２０に見出されるすべてのエントリに対してアクト６２０およびアクト６４０が繰り返されることを示す。
【００５３】
旧スコアボード３２０が所定のインデクスにおいてゼロを有する（例えば、アドレスがないことを示す）場合、そのインデクスについてアクト６３０およびアクト６４０におけるオペレーションは行われない。インデクスはゼロをパスして増やされる。アドレス計算が行われてエントリが新スコアボード３２０内にマップされると、ＦＢ２２０は、それを単にパスする代わりに、その新スコアボードエントリに対してゼロを書き込む。なお、旧スコアボード３２０がスキャンされるとすぐに、ＦＢ２２０−１は、新スコアボードに対してスコアボード読み取りポインタをゼロにリセットし、ＵＲＢ２５０内のエントリを要求する新たなペイロードを生成するべく隣接する１を探し始める。
【００５４】
アクト６３０およびアクト６４０と同時に、アドレスはノース方向ＬＰＢＩ２４０を介してＦＢ２２０−１に到達する。かかる到達アドレスは、新フェンス３１０およびスコアボード３２０に関するＦＢ２２０−１によって扱われる［アクト６５０］。例えば、入ってくるアドレスは新トップ／ボトムフェンス３１０内にマップされて新スコアボードインデクスに対して参照され、新スコアボードエントリは１にセットされる。アドレスが新フェンス３１０の範囲外の場合（第１ＦＢ２２０−１の場合はそれがボトム値よりも大きい場合のみがあり得る）、アドレスはＨＰＢＩ２３０上のＦＢ２２０−２（またはパイプライン内の次のＦＢ２２０のいずれでも）へ「所有権転送」インジケータとともに下へ送り返される。
【００５５】
ＦＢ２２０−１が新たな状態のための第１ワークロードを次のＦＢ２２０（例えばＦＢ２２０−２）に送る準備ができている場合、それはサウス方向のＬＰＢＩ２４０上で「フリップ状態」メッセージを送る［アクト６６０］。かかるフリップ状態メッセージはパイプライン内の次のＦＢにプロセス６００を開始するように指示する。アクト６５０の後に示されているが、いくつかの実施例においてはアクト６６０はアクト６２０の直後に行われる。ＦＢ２２０−２がこのメッセージを見て、かつ以前の状態の作業を終えている場合（例えば、アクト６２０の完了後）、それは、そのサウス方向ＬＰＢＩ２４０上での順番で別の「フリップ状態」メッセージを発行する。
【００５６】
誤ったタイミングの状態変更を防ぐためには、ＦＢ２２０−１が、エンジン／パイプラインの残りの準備ができる前に新状態に応じてデータを発行させることを防ぐメカニズムが望ましい。したがって、ＦＢ２２０−１は、最下流のユニット（例えばＦＢ２２０−ｎ、ここでｎはパイプライン内の最後のユニットを示す）から、その新状態になったことを示すなんらかの信号を受け取るまで待つ［アクト６７０］。いくつかの実施例においては、最下流のＦＢ２２０−ｎは、ＬＰＢＩ２４０を介して受け取った「フリップ状態」で動作する場合、ノース方向のＨＰＢＩ２３０を介してＦＢ２２０−１に確認応答信号を送り返す。
【００５７】
パイプライン内の他のＦＢｓ２２０はすべて、このメッセージを無視する。かかる実施例において、ＦＢ２２０−１は、確認応答パケットが受け取られるまで新状態パケットを発行しない。しかし、他の確認応答および／または遅延のメカニズムも可能かつ考慮される。
【００５８】
そして、ＦＢ２２０−１は新状態のワークの発行を開始する［アクト６８０］。
【００５９】
ここで、ＦＢ２２０−２のような下流ユニットに対するプロセス６００を説明する。ＦＢ２２０−１は、ＦＢ２２０−２がまだ旧状態にある間に状態を変更している。ＦＢ２２０−２が「開放」してその旧フェンス内に該当する任意のアドレスは、必然的にその旧スコアボードに該当する。ＦＢ２２０−２が「開放」してその旧フェンス外に該当する任意のアドレスは、ノース方向ＬＰＢＩ２４０を使用して上流へ転送される。このことはまた、ＦＢ２２０−２がそのノース方向ＬＰＢＩ２４０を介して下流ユニット（例えばＦＢ２２０−３）から受け取る任意のアドレスについても当てはまる。ＦＢ２２０−２は、そのワークを旧状態からディスパッチすることを済ませた場合、アクト６３０およびアクト６４０を行う。ＦＢ２２０−２は、その旧スコアボード３２０をスキャンし、ノース方向またはサウス方向のＨＰＢＩ２３０を使用して「所有権転送」セマンティクスとともに必要に応じてアドレスを転送する。プロセス６００は、残りのユニット２２０によって繰り返されて、それらの中にＵＲＢ２５０を動的に再割り当てする。
【００６０】
図７は、ＨＰＢＩ２３０およびＬＰＢＩ２４０上の例示的なメッセージフォーマットを示す。メッセージ７１０は、ＨＰＢＩ２３０上の（例えば、連続ＦＢ２２０への）サウス方向へのメッセージのフォーマットを示す。メッセージ７２０は、ＨＰＢＩ２３０上の（例えば、以前のＦＢ２２０への）ノース方向へのメッセージのフォーマットを示す。同様に、メッセージ７３０およびメッセージ７４０は、各々ＬＰＢＩ２４０上のサウス方向およびノース方向のメッセージのフォーマットを示す。
【００６１】
なお、メッセージ７１０−７４０のＵＲＢアドレスのすべては１０ビットフィールドとして示されている。このデータ長は、ＵＲＢ２５０が１０２４以下のエントリを有していることを仮定しており、アドレスされたメモリのサイズに基づくと異なるかもしれない。これは、再分割されるべきＵＲＢ２５０または他のメモリが多少のアドレス空間を必要とする場合には、所望に応じて調整される。
【００６２】
本明細書に記載のように、アドレスフェンスメカニズム３１０は、各機能ブロック２２０に組み込まれる。各機能ブロック２２０は、そのＵＲＢ２５０内への出力に対しては、それ自体のフェンス範囲内のアドレスのいずれかを使用する。これらのアドレスは、その後の読み取りおよびさらなる処理を目的として下流の機能２２０に転送される。その後の読み取りが行われた後、アドレスは、（例えば、アドレスがその機能ブロックのアドレス範囲内にある場合）その機能ブロック２２０によって保持されるか、（例えば、アドレスがその機能ブロックのアドレス範囲よりも大きい場合）送り下げられるか、または（例えば、アドレスがその機能ブロックのアドレス範囲よりも小さい場合）送り上げられるか、のいずれかとなる。機能ブロック２２０の状態変更が生じると、アドレスフェンス３１０は、デッドロックなしにまたは関連付けられたデータの機能ブロック２２０を完全にフラッシュする必要なしに、動的に再設定される。
【００６３】
１つ以上の実施例の上記記載は例示および説明を与えるが、本発明の範囲を網羅することも、開示の正確な形態に限定することも意図しない。修正例および変形例は上記教示に鑑みて可能であり、本発明の様々な実施例を行うことから得られる。
【００６４】
例えば、本明細書においてメモリの再割り当てスキームは、リターンバッファ２５０および機能ブロック２２０に関して記載されてきたが、一般的には計算機能および／またはスレッドによる／に対するメモリ内の動的再割り当てに適用することができる。また、本明細書で説明されたアドレスフェンス３１０およびスコアボード３２０によって行われるアドレスソーティング機能およびブックキーピング機能のための他のスキームも可能かつ考慮される。さらに、アドレスフェンス３１０は、機能ブロック２２０に対して連続アドレスを仮定するが、所望に応じて、バッファ中の不連続アドレスは、フェンスとは異なる関連付けロジックを備える所定の機能ブロック２２０に関連付けられてもよい。
【００６５】
さらに、図４から図６に記載のアクトは、図示の順序で行われる必要はないし、必ずしもアクトのすべてが行われる必要もない。また、他のアクトに依存しないアクトは、他のアクトと並列して行われてもよい。さらに、この図のアクトの少なくともいくつかは、命令または命令のグループとして行われてもよく、機械読み取り可能媒体において行われてもよい。
【００６６】
本願の記載に使用された要素、アクトまたは命令はいずれも、明示的に記載されていない限りは本発明に対して決定的または必須のものとして解釈するべきではない。また、本明細書において使用されている冠詞「ａ」は、１つ以上のアイテムを含むことを意図する。請求項に記載の発明の上記実施に対しては、本発明の要旨および原理から実質的に逸脱することなく変形例および修正例が可能である。本明細書においては、かかるすべての修正例および変形例は、本開示の範囲内に含まれ、以下の請求項によって保護されることを意図する。
【図面の簡単な説明】
【００６７】
【図１】システムの例を示す。
【図２】図１のシステムの例におけるスレッドディスパッチャを示す。
【図３】図２のスレッドディスパッチャにおける機能ブロックを示す。
【図４】機能ブロック中のバッファにアドレスを初期的に割り当てるプロセスを示すフローチャートである。
【図５】機能ブロックによるバッファ内のアドレス利用プロセスを示すフローチャートである。
【図６】機能ブロックによるアドレスフェンスの動的変更プロセスを示すフローチャートである。
【図７】メッセージフォーマットの例を示す。
【誤訳訂正３】
【訂正対象書類名】図面
【訂正対象項目名】図２
【訂正方法】変更
【訂正の内容】
【図２】
2008525887.tif 000001
【誤訳訂正４】
【訂正対象書類名】図面
【訂正対象項目名】図５
【訂正方法】変更
【訂正の内容】
【図５】
2008525887.tif 000002
【誤訳訂正５】
【訂正対象書類名】図面
【訂正対象項目名】図６
【訂正方法】変更
【訂正の内容】
【図６】
2008525887.tif 000003