JP2008525887A - スレッドプロセッサにおける多重クライアントへのバッファの動的割り当て - Google Patents

Abstract

方法は、第１パイプラインの第１セットの関数間にメモリのアドレス範囲を分配することを含む。第１パイプラインの第１セットの関数は、アドレス範囲を使用するデータ上で動作する。メモリ内の異なるアドレス範囲が、第１セットの関数がデータのフラッシュをするのを待つことなく、第２パイプラインの第２セットの関数間に再分配される。
【選択図】図１

Description

（関連出願の相互参照）本願は、「スレッドプロセッサにおける多重クライアントへのバッファの動的割り当て」という名称で２００４年１２月２３日に出願された米国仮出願シリアル番号第６０／６３８，４２７の利益を主張し、そのすべての内容は本明細書に参照として組み込まれる。

請求項に記載の発明の実施例は、一般にメモリの割り当てに関し、詳しくはプロセス間でのメモリの動的割り当てに関する。

データプロセシングにおいては、いくつかのプロセスによる使用のためにメモリが論理的に分割されることがある。例えば４つのプロセスが実行中の場合、メモリは、各プロセスに対応する４つの部分に分割される。プロセスが（例えばパイプラインプロセスの一部として）関連している場合、かかる分割スキームは、各プロセスをメモリの所定最小量に割り当ててデッドロックを防止する。メモリの上記最小限総量の残量はプロセス間で割り当てられ、プロセスによるパフォーマンスがより良好にされる。

いくつかのプロセスがメモリの変更を使用する場合、メモリの割り当てを変更して新たな数のプロセス（上記例の４つのプロセスの代わりに例えば３または５）に対してメモリを最適化することが望ましい。しかし、既存プロセスのいくつかまたはすべては、関連付けられたデータをメモリ内に有し、かかるデータはメモリーの別のプロセスの一部に該当するか、そのプロセスが中断された場合はオーファンとなっている。したがって、典型的には、メモリは、新たな数のプロセス間で再分割される前にフラッシュされ（例えばデータが空にされ）る。いくつかの場合には、インプロセスデータは、メモリから即座に削除／フラッシュされて、新たな分割スキームの下で必要に応じてリロードされる。他の場合には、メモリを再分割する前にプロセスに処理を完了させることによって、インプロセスデータはメモリから暗黙的にフラッシュされる。

しかし、フラッシュのために使用されるスキームにもかかわらず、メモリのフラッシュはプロセスのパフォーマンスに悪影響を与える。分割または割り当ての前にメモリをフラッシュすることは、旧プロセス、新プロセスまたは両者によるデータプロセシングを遅延させる。

本明細書に組み込まれて本明細書の一部をなす添付の図面は、本発明の原理に整合する１つ以上の実施例を示し、記載とともにかかる実施例を説明する。図面は実寸どおりとは限らず、その代わりに本発明の原理を示すことに重点が置かれる。

以下の詳細な説明は添付の図面を参照する。同じまたは類似する要素を特定するために、異なる図面において同じ参照番号が使用される。以下の説明において、請求項に記載の発明の様々な側面の十分な理解を与えるために、具体的な詳細は、特定の構造、アーキテクチャ、インターフェイス、テクニック等のように記載されるが、説明を目的とするものであって限定を目的とするものではない。しかし、本開示の利益を有する当業者にとっては、請求項に記載された本発明の様々な側面が、かかる具体的な詳細から逸脱する他の例で実施できることは明らかであろう。所定の例においては、不必要な詳細で本発明の説明を不明瞭にしないため、周知のデバイス、回路および方法の説明は省略される。

図１は、システム１００の例を示す。システム１００は、メモリ階層１１０、スレッドディスパッチャ１２０、バス１３０およびプロセシングコア１４０−１〜１４０−ｎ（集合的には「プロセシングコア１４０」）を含む。システム１００は、マルチスレッド実行をサポートするマルチプロセシングコア１４０を含む。いくつかの実施例においては、各プロセシングコア１４０は１つまたは多数のスレッドをサポートする。単一プロセッサ（例えばコア１４０−１）に対するマルチスレッディングは、アクティブなスレッドが実行される一方で他のスレッドが非アクティブ状態にあるようにすることによって有効に実行できる。

メモリ階層１１０は、１つ以上のプロセシングコア１４０によって実行中に使用されるべきデータおよび命令を格納する。メモリ階層１１０は、動的ランダムアクセスメモリ（ＤＲＡＭ）、１つ以上のレベルの命令キャッシュ、１つ以上のレベルのデータキャッシュおよび／または１つ以上のレベルの共有命令およびデータキャッシュを含む。

メモリ階層１１０に接続されるスレッドディスパッチャ１２０は、新たなスレッドに関連付けられる命令ポインタおよびデータならびに／またはデータポインタ情報を受け取る。スレッドディスパッチャ１２０は、バス１３０を介してプロセシングコア１４０に接続される。スレッドディスパッチャ１２０は、プロセシングコア１４０のスレッドリソースを管理する。新たなペンディングスレッドを受け取る際、スレッドディスパッチャ１２０は１つのプロセシングコア（例えばコア１４０−３）を選択する。このプロセシングコアは、ペンディングスレッドを実行するべく利用可能なリソースを有しており、選択されたコアへバス１３０を介してスレッドをディスパッチする。プロセシングコアによる既存スレッドの完了の際、スレッドディスパッチャ１２０は通知を受け、そのプロセシングコアへのスレッドリソースを将来のスレッドに開放する。

図２はスレッドディスパッチャ１２０の１つの可能な実施例を示す。スレッドディスパッチャ１２０は、コマンドパーサ２１０、いくつかの関数ブロック２２０−１、２２０−２、・・・、２２０−ｎ（集合的には「関数ブロック２２０」）、高優先バスインターフェイス（ＨＰＢＩ）２３０、低優先バスインターフェイス（ＬＰＢＩ）２４０、統合リターンバッファ（ＵＲＢ）２５０およびディスパッチャ２６０を含む。

コマンドパーサ２１０は、所定のコマンドおよび要求を関数ブロック２２０が処理できるフォーマットに翻訳する。例えば、コマンドパーサ２１０は、いくつかの関数ブロック２２０に関連する単一コマンドを、個々の関数ブロック２２０に送られるいくつかのコマンドおよび／または命令に分解する。

関数ブロック２２０は、異なる関数を恐らくはパイプラインの態様で実行する。いくつかの実施例においては、関数ブロック２２０は、１つ以上の頂点シェーダ、テセレータ、ジオメトリシェーダ、クリッパ、セットアップモジュールおよびウィンドワ（ｗｉｎｄｏｗｅｒ）のような固定グラフィカル関数を実装する。かかる固定関数のいくつか（例えばいくつかの関数ブロック２２０）は、任意の所定時間においてアクティブであり、他の関数（例えば他の関数ブロック２２０）は非アクティブである。アクティブな関数ブロック２２０の各々は、その出力に対する統合リターンバッファ２５０の所定の指定部分（例えばアドレスのグループ）を使用する。

図３は、関数ブロック２２０の１つの可能な実施例を示す。関数ブロック２２０は、アドレスフェンス３１０のセット、スコアボード３２０のセット、アドレス／インデクス計算ユニット３３０および状態マシン３４０を含む。

アドレスフェンス３１０は、アドレスフェンスのピン／ポンセットを含み、各フェンスはトップレジスタおよびボトムレジスタを有する。トップレジスタおよびボトムレジスタは、関数ブロック２２０がアイテムを格納できる場所であるＵＲＢ２５０内にアドレス範囲を画定するアドレスを格納する。本明細書においては、「ポン」は代替セット（例えば「新」セット）を示すのに対して、「ピン」は別のセット（例えば「旧」すなわち以前のセット）を示す。アドレスフェンス３１０のコンテキストにおいては、トップフェンス値およびボトムフェンス値の初期セットはピンフェンスレジスタに格納され、値の置換セットが到着するとポンフェンスレジスタに格納される。トップ値およびボトム値の別の置換セットが到着するとピンフェンスレジスタに格納され、ポンフェンスは最新の値を有し、というようになる。

スコアボード３２０はピンスコアボードおよびポンスコアボードを含み、各スコアボードは、追跡記録されたアドレス当たり１ビットをＵＲＢ２５０に有する。スコアボードは、その関数ブロック２２０に対するＵＲＢ２５０のエントリの最大予測可能割り当てを十分包含できるほど大きい。このため、所定の関数ブロック２２０がＵＲＢ２５０の２０％にのみ割り当てられると、スコアボード３２０はその量のＵＲＢ２５０のエントリ当たり２ビット（ピンおよびポンに対して各１）のサイズになる。

アドレス／インデクス計算ユニット３３０は、インデクスからアドレスを計算するかまたはその逆を計算するためのロジックを含む。本明細書においては、「インデクス」は、アドレスフェンス３１０によって確定されたアドレス範囲内の相対位置を示す数（例えば０に始まりアドレスフェンス３１０のサイズに終わる）を示す。関数ブロック２２０のアドレスフェンス３１０内のアドレスに対しては、そのアドレスに対する対応インデクスは、以下のように計算される：インデクス＝アドレス−トップ、ここでトップはアドレスフェンス３１０の上端を示す。同様に、ユニット３３０は、以下のようにインデクス値からアドレスを計算する：アドレス＝トップ＋インデクス。アドレス／インデクス計算ユニット３３０が使用される例を以下に記載する。

状態マシン３４０は、アドレスフェンス３１０間の変更に際し、スコアボード３２０に再割り当てを行う。かかる再割り当てをさらに詳細に以下に記載する。状態マシン３４０はまた、所定のアドレスを保持すべきか転送すべきかを決定するというような他のアドレスプロセシングも行う。状態マシン３４０はまた、関数ブロック２２０のための他の制御関数および／またはブックキーピング関数も行う。

図２に戻ると、関数ブロック２２０は、２つの双方向バス：ＨＰＢＩ２３０およびＬＰＢＩ２４０によって相互接続される。ＨＰＢＩ２３０およびＬＰＢＩ２４０の各々において、２つのポイント間インターフェイスは各関数ブロック２２０間に及び、一方は「ノース」に向かい、他方は「サウス」に向かう。例えば、アドレスは、ＨＰＢＩ２３０および／またはＬＰＢＩ２４０のサウス方向のインターフェイスにわたりｎ番目の関数ブロック２２０ＦＢ［ｎ］から（ｎ＋ｌ）番目の関数ブロック２２０ＦＢ［ｎ＋ｌ］に送り下げられる。同様に、ＦＢ［ｎ＋ｌ］は、ＨＰＢＩ２３０および／またはＬＰＢＩ２４０のノース方向のインターフェイスにわたり、ＦＢ［ｎ］までアドレスを転送する。関数ブロック２２０間に所有権を伝えるべく発行されるアドレスはＨＰＢＩ２３０で転送される。プロデューサ関数ブロック２２０に返されるペイロードおよび／またはアドレスを生成するべく発行されるアドレスはＬＰＢＩで転送される。

ＨＰＢＩ２３０およびＬＰＢＩ２４０は、いくつかの方法で物理的に実装される。いくつかの実施例においては、２つのインターフェイスは各方向に平行に使用される。いくつかの実施例においては、各方向の１つのインターフェイスはその中に２つの仮想チャネルを備えて使用される。仮想チャネルのメカニズムが実装される場合、例えば、仮想チャネル＃１はＬＰＢＩ２４０に使用される仮想チャネル＃０よりも高い優先順位（例えばＨＰＢＩ２３０）となる。いくつかの実施例においては、ＨＰＢＩ２３０、ＬＰＢＩ２４０またはその両方はフロー制御される。

ＵＲＢ２５０は、プロセシングコア１４０による処理前または処理後に関数ブロック２２０に関連付けられたデータを保持するように構成される。本明細書の記載では、関数ブロック２２０によって、それに関連するアドレスフェンス３１０に基づきＵＲＢ２５０は分割共有される。いくつかの実施例においては、ＵＲＢ２５０は１０２４以下のエントリを有するが、請求項に記載の発明は必ずしもこの点に限定されるわけではない。

ディスパッチャ２６０は、バス１３０を介して関数ブロック２２０からプロセシングコア１４０へ、スレッドをディスパッチする。いくつかの実施例においては、ディスパッチャ２６０は、コア１４０の中のいずれに特定のスレッドを送るべきかを決定する。いくつかの実施例においては、ディスパッチャ２６０は、発信側の関数ブロック２２０によって特定された特定のプロセシングコア２５０へスレッドを送る。

図１に戻ると、バス１３０は、メモリ階層１１０内のいくつかの通信リンク、スレッドディスパッチャ１２０およびプロセシングコア１４０を含む。説明の便宜上、バス１３０は単一のラインとして表されるが、実際にはバス１３０は、１つ以上の制御バス、データバス等を含む。バス１３０は、コア１４０による処理のためにデータをスレッドディスパッチャ１２０から搬送し、処理済みデータもコア１４０からスレッドディスパッチャ１２０および／またはメモリ階層１１０へ搬送する。

システム１００はまた、マルチプロセシングコア１４０も含む。マルチプロセシングコア１４０の各々は、関連付けられた制御回路構成を備える実行回路を含む。プロセシングコア１４０は同一であり、様々な機能性を有する。任意の数のプロセッサコア１４０−１〜１４０−ｎがシステム１００に含まれる。いくつかの実施例においては、プロセッサコア１４０は列状に構成され、各列は関連付けられた列コントローラを有する。

図４は、関数ブロック（ＦＢｓ）２２０間にバッファ２５０内のアドレスを初期的に割り当てるプロセス４００を示すフローチャートである。システム１００のスタートアップに際し、またはリセットおよび／またはフラッシュの後に、すべてのＦＢｓ２２０内のすべてのスコアボード３２０がクリアされてトップ／ボトムフェンスレジスタ３１０は「ｄｏｎ'ｔ ｃａｒｅ」状態になると仮定する。スレッドディスパッチャ１２０内のコマンドストリームから読み取られたデータの第１シーケンスは、ＦＢｓ２２０の各々に対するトップ／ボトムフェンス値のリストを含む。

かかるトップ／ボトムフェンス値をＦＢｓ２２０間に分配することから処理が開始される［アクト４１０］。引き続きいて、かかるトップ／ボトムフェンスレジスタ値はＨＰＢＩ２３０によってＦＢｓ２２０を介してパイプライン化される。いくつかの実施例においては、例えば、ＦＢ２２０−１は、第１トップ／ボトムペアをそのアドレスフェンス３１０に格納し、残りのフェンス値をＦＢ２０１−２に転送する。ＦＢ２２０−２は、残りの値のトップペアをそのアドレスフェンス３１０に格納し、その残りをＨＰＢＩ２３０によってＦＢ２２０−３に転送し、というようになる。最後の関数ブロック２２０−ｎは最後のトップ／ボトムペアを消費する。

ＦＢｓ２２０間に割り当てられるアドレスのリストがコマンドストリーム内に続く［アクト４２０］。アドレスのリストはＨＰＢＩ２３０によって第１ＦＢ２２０−１に入力される。ＦＢ２２０−１は所定のアドレスを見て、それがアドレスフェンス３１０のそのアドレス範囲内にあるか否かを決定する［アクト４３０］。

アドレスがＦＢ２２０−１のアドレスフェンス３１０内にない場合、アドレスは次のＦＢに転送される［アクト４４０］。アドレスがＦＢ２２０−１の範囲内（または転送された場合は２２０−２のような別のＦＢの範囲内）にある場合、ＦＢはアドレスを処理する［アクト４５０］。

かかるアドレスプロセシングにおいては、ＦＢは関連付けられるインデクス、インデクス＝アドレス−ベース、を計算ユニット３３０を介して計算する。この計算されたインデクス値に対し、ビットはその後そのＦＢｓのピンスコアボード３２０にセットされる。アクト４４０およびアクト４５０の戻り矢印に示されるように、かかるアドレスプロセシングは、すべてのアドレスが所定のＦＢ２２０に関連付けられるまで続く。

このシーケンス４００の最後に、すべてのＦＢｓ２２０はそのピンアドレスフェンス３１０が有効となり、そのピンスコアボード３２０は使用を許可されたアドレスに更新される。いくつかの実施例においては、かかるインデクスアドレスはゼロから始まり、シーケンスの最後のアドレスへの増分カウント（０,１,２,...）となるが、請求項に記載の発明はこの点に限定されない。

各スコアボード３２０にビットがセットされると、これは特定のアドレスが「インフライト」（例えば、別の目的地へ移送中）ではないことを示す。したがって、（特定のアドレスフェンス領域内の）スコアボード３２０のゼロ（例えば、セットされていないビット）は、特定のアドレスがインフライトであることを示す。インフライトでないアドレスは再要求（ｒｅｃｌａｉｍ）されて、ＵＲＢ２５０に向かう予定の新たな出力バッファとして再使用される。それとは対照的に、インフライトのアドレスは、新たな出力バッファの一部として使用されるために再要求されることがない。

プロセス４００は、スコアボード３２０をスタートアップにセットするのにそれほど直接的な方法ではないが、かかるスキームによって、アドレスフェンス３１０の再分割がスタートアップシーケンスのスキームに類似する。ＦＢ２２０−１の前にあるアドレスを発行せずにかかるアドレスをパイプラインにまく（ｓｅｅｄ）最適化が可能となる。上記特定のスキーム４００を理解の便宜のため説明するが、その詳細は請求項に記載の発明を必ずしも限定するわけではない。

図５は、関数ブロック（ＦＢｓ）がバッファ２５０内のアドレスを利用するプロセス５００を示すフローチャートである。初期化シーケンス４００の後、ＦＢ２２０−１はそのスコアボードの読み取りポインタをゼロにセットする。ＦＢ２２０−１は、コマンドストリーム（例えば、コマンドパーサ２１０）からタスク（例えば、関数または関数の一部）を受け取る。このタスクに対するバッファリング要件（例えば、ＵＲＢ２５０内に必要な空間の量）に基づいて、ＦＢ２２０−１は、かかる空間をＵＲＢ２５０内に割り当てる［アクト５１０］。

例えばアクト５１０において、ＦＢ２２０−１は、タスクのためのＵＲＢ２５０内の所望数のエントリ（例えば、ワーキングカウント（ＷＣ））とともに、現在のスコアボード読み取りポインタをレジスタ（例えば、ワーキングポインタ（ＷＰ））に格納する。図３には明示的に示されてはいないが、いくつかの実施例においては、ＷＰレジスタおよびＷＣレジスタはスコアボード３２０に含まれる。ＦＢ２２０−１は、スコアボード３２０に、そのスコアボード読み取りポインタで始まる「ワーキングカウント」が隣接したものがセットされているか否かをチェックする。それほど多くの隣接したものがスコアボード３２０にセットされていない場合、ＦＢ２２０−１は、かかる数がセットされるようになるまで待つ。しかし、かかる「ワーキングカウント」空間が利用可能であれば、ＦＢ２２０−１は現在の読み取りポインタのビットをクリアして、スコアボード読み取りポインタを一つ進める。こうしてクリアすることおよび進めることは、タスクのために必要なＵＲＢ２５０内のエントリ数（例えば、ＷＣの数）が割り当てられるまで繰り返され、アクト５１０が完了する。アクト５１０のその他の実施例が可能であり、上記は主に理解の便宜のために提示される。

スコアボード３２０内のエントリに対応するＵＲＢ２５０内のアドレスは、アドレス計算ユニット３３０を介してワーキングポインタから以下のように計算される：ＵＲＢアドレス＝ＷＰ＋トップ、ここでトップはアクティブ（例えば、ピンまたはポン）アドレスフェンス３１０から得られる。プロセシングコア１４０が１つ以上のリターンアドレスを要求する場合は、上記計算は複数のリターンアドレスに対して繰り返される。ＵＲＢ２５０内のかかるリターンアドレスは、タスクのこの部分に対する計算が完了する際に、リターンアドレスとしてプロセシングコア１４０に発行される［アクト５２０］。その他のタスク関連情報もまた、アクト５２０に関連してＦＢ２２０−１によってプロセシングコア１４０にディスパッチされる。

すべてのＦＢｓ２２０は、プロセシングコア１４０へのディスパッチワークの後は、処理後各データがＵＲＢ２５０に戻されたときにＵＲＢ２５０によって信号が送り返される。

こうして信号を送ることは、データがＵＲＢ２５０に書き込まれる際にＵＲＢ２５０によって自動的に行われる。例えば、ＦＢ２２０−１は、ＬＰＢＩ２４０を介してかかる通知を受け取る［アクト５３０］。

アクト５３０においてそのデータがバッファ２５０内にあるという通知を受け取った後、ＦＢ２２０−１は下流の関数ブロック（例えば、ＦＢ２２０−３）がその入力として使用するためのアドレスのリストを生成する［アクト５４０］。一般には、ＦＢ２２０−ｎは、次のＦＢ２２０−（ｎ＋ｘ）が消費するためのＵＲＢ２５０に関連付けられたアドレス＋カウントのリストを生成する。かかるアドレスリストメッセージのフォーマットには、開始ＵＲＢアドレスおよびワードカウントが含まれる。かかるアドレス（およびワードカウント）は、ＬＰＢＩ２４０によってＦＩＦＯ（ファーストイン、ファーストアウト）の形態で近隣の下流関数ブロック（例えばＦＢ２２０−（ｎ＋ｌ））に送られる。ＦＢ２２０−（ｎ＋ｌ）がヌル関数（例えば、所定のタスクのために使用されない）場合は、タスク中の次の関数ブロック２２０、ＦＢ２２０−（ｎ＋ｘ）に到達するまで情報が転送される。

ＦＢ２２０−（ｎ＋ｘ）が完全なワードカウントのためにＵＲＢアドレスによってポイントされたデータを消費した後、送り側のＦＢ２２０−ｎのスコアボード３２０内の対応するエントリは「開放」される。このため、ＦＢ２２０−ｎは、次のＦＢ２２０−（ｎ＋ｘ）によって消費されるべく送られたアドレスのリストに関連付けられたデータを待つ［アクト５５０］。本明細書において、「消費される」という語は、当該アドレスがＵＲＢ２５０から読み取られたということを示す。しかし留意すべきなのは、かかるアドレスが消費されたとみなされても、別の目的地ＦＢ２２０へはまだインフライトの状態であり得る。例えば、アドレスが、その究極の目的地ではないＦＢ２２０によって読み取られた場合、それはその目的地へはまだインフライトでありながら消費されたとみなされる。

アドレスが別のＦＢ２２０によって消費された後、ＦＢ２２０−ｎはアドレスをそのスコアボード３２０の開放リスト（ｆｒｅｅ ｌｉｓｔ）に戻す（例えば、それはアドレスを「開放」する）［アクト５６０］。かかる「開放」エントリは、ＵＲＢ２５０内の新たなリターンバッファを行うオペレーションにおいて再使用すべく利用可能である。アドレスを開放するために、そのスコアボード３２０内のインデクスは、計算ユニット３３０によって以下のように計算される：インデクス＝ＵＲＢアドレス−アクティブトップフェンス。かかるインデクス計算は、この第１アドレスに関連付けられた「カウント」数のすべてに対して行われる。アドレスプラスカウント数のこのような拡張は「微粒化（ａｔｏｍｉｚａｔｉｏｎ）」と呼ばれる。例えば、１０のアドレスと４のカウントとはアドレス１０、１１、１２および１３に微粒化される。次に、インデクスのセットにおける（例えばアドレス＋カウントに対する）スコアボード３２０の特定の値は、以下のようにアドレスが開放されていることを示すようにセットされる：スコアボード［インデクス］＝１。

「開放」ＵＲＢアドレスおよびカウント（例えば、自己生成されるかまたはノース方向またはサウス方向のＬＰＢＩ２４０を介して受け取られるかのいずれか）を受け取る際、ＦＢ２２０−ｎは、アドレスをその現在のアクティブフェンス３１０のトップ／ボトムペアと比較し、情報を保持するかまたは必要に応じてＬＰＢＩ２４０によってそれをノースまたはサウスに転送するかのどちらかを行う［アクト５７０］。アドレスが（ワードカウントを無視して）そのＦＢ２２０のトップ／ボトム範囲内にある場合、それはその関数ブロックによって保持される。アドレスが（ワードカウントを無視して）そのＦＢ２２０のトップ値よりも小さい場合、それはノース方向のＬＰＢＩ２４０を介して送り上げられ；ＦＢ２２０のボトム値よりも大きい場合、それはサウス方向のＬＰＢＩ２４０を介して送り下ろされる。アクト５６０における「開放」ＵＲＢ＋カウント情報の微粒化後アクト５７０においてアドレスを送り上げるか下げるかを比較決定することは意図的であり、これによってＦＢｓ２２０のすべてをフラッシュする必要性なしにフェンス３１０を動的に変更することができる。後に説明するように、これによって、フェンス３１０が以前の隣接したＵＲＢ割り当て間を移動することも可能となる。

主にＦＢ２２０−１に関して説明したが、プロセス５００が、ＦＢ２２０−２、ＦＢ２２０−３等のような他の関数ブロックによって同様に行われる。

いくつかの実施例においては、ＦＢ２２０は、同じＵＲＢ２５０エントリ（およびワードカウント）を下流のＦＢ２２０に向けて複数回発行する。例えば、いくつかのＦＢｓ２２０は、ＵＲＢ２５０のエントリをキャッシュとして使用し、キャッシュヒットは、所定のＵＲＢエントリを別のＦＢによって１回以上読み取られるようにする。したがって、そのＵＲＢエントリは著しく多数に及ぶことがある。スコアボード３２０は、アドレスがインフライトか否かを示し、かかるエントリを、それが複数回消費されるまで「開放」として取り扱うべきではない。

これにより、いくつかの実施例においては、アドレスがスコアボード３３０内に再投入され得るようになる前に、いくつの「開放」インスタンスが必要とされるのかを追跡記録するべく、所定のＦＢｓ２２０は別々のブックキーピングを保持する。こうした振舞いをするかかる関数ブロック２２０は、所定のＵＲＢエントリが発行されるたびにカウントを行うメカニズム、および所定のＵＲＢエントリが「開放」されるたびにカウントを行う補助的なメカニズムを含む。明示的には示されていないが、いくつかの実施例においては、かかるカウントを行うメカニズムは、スコアボード３２０および／または状態マシン３４０に含まれる。このカウントを行うメカニズムは、それが発行するベースＵＲＢアドレスの追跡記録を保持しさえすればよく、カウントフィールドが同じままであれば、ＵＲＢ２５０内の関連付けられたエントリのすべて（例えば、アドレス＋カウント）を保持する必要はない。

プロセス５００がメモリ内のアドレスを利用することを説明してきたが、メモリを関数内に動的に再割り当てすることが以下に説明される。あるポイントでは、ＦＢｓ２２０が「状態を変更」してもよい時点（例えば、１つ以上のＦＢｓ２２０が追加されるとき、または所定の関数チェーンすなわちパイプラインから削除されるとき）である。例えば、ＦＢｓ２２０（すなわち、頂点シェーダ、次いでテセレータ、次いでクリッピング、セットアップおよびウィンドワ）のパイプライン設定が与えられると、この設定においてＵＲＢ２５０の理想的な分割が関数ブロック２２０に存在すると推定される。新たなパイプライン設定（例えば、頂点シェーダ次いでジオメトリシェーダ次いでクリッパ、セットアップおよびウィンドワ、または頂点シェーダ次いでクリッパ、セットアップおよびウィンドワのようなＦＢｓ２２０の別の設定）に対しては、ＦＢｓ２２０の中に異なる理想的なＵＲＢ２５０の分割が存在する。典型的には、かかる状態の変更は、ＦＢｓ２２０の中にＵＲＢ２５０の再分割（例えば、ＦＢｓ２２０内でのアドレスフェンスの変更）を含む。

かかる再分割を達成するための一つの方法は、各連続ＦＢ２２０がアドレスフェンスの変更前のデータをフラッシュされるまで待つことである。しかし、かかるスキームの結果、全パイプラインの状態変更が遅れる一方で連続ＦＢｓ２２０がフラッシュされる「暗示的フラッシュ」となるだろう。再分割のための別の方法は、１つのＦＢ２２０からその新しいアドレスフェンスに応じてアドレスの転送を開始することだろう。しかし、かかるスキームは、１つの「サウス方向」チャネルのみが存在する場合およびそれがフロー制御される場合にはデッドロックとなり得る。

いくつかの実施例によれば、状態の変更と新たな状態内での処理を同時に行う間にデッドロックを避けるべく、第１のＦＢ２２０が下流のＦＢｓ２２０がフラッシュするのを待つことはない。任意のステージのスコアボード３２０にすべて１が投入される（例えばクリアされる）まで待つこともない。状態変更中の遷移においては旧状態からのアドレスが残るが、ＦＢｓ２２０は無分別にアドレスを送り上げおよび送り下げを続けることがない。その代わりに、アドレスはその以前の状態からの通常フローを無分別に完了する一方で、他のアドレスはシステムを介して転送されてそれらを新たな状態にリマップする。後に説明するが、ＨＰＢＩ２３０は、かかる動的状態変更（例えば、メモリの再分割）をデッドロックなしで容易に行う。

図６は、関数ブロックによるアドレスフェンスの動的変更のプロセス６００を示すフローチャートである。チェーンまたはパイプラインの第１関数ブロック（例えばＦＢ２２０−１）に関して説明するが、プロセス６００は、連続するＦＢｓ２２０によって行われてＵＲＢ２５０の動的再割り当てを完了する。

処理は、ＦＢ２２０−１がアドレスフェンス値の新たなセットを受け取ることから開始される［アクト６１０］。かかる新たな値は、アドレスフェンス３１０のピンまたはポン部分のいずれかに、どちらが現在の動作状態に対するフェンスを現在有するかに応じて格納される。すべてのＦＢｓ２２０に対するトップ／ボトムフェンスの新たなリストは、コマンドストリームによって発行され、ＦＢ２２０−１はそのリストから第１トップ／ボトムセットを取得してそれらをその（例えばポン）アドレスフェンス３１０に置く。そして、ＦＢ２２０−１はトップ／ボトムフェンスの残りをＨＰＢＩ２３０を介して次のＦＢ２２０（例えばＦＢ２２０−２）に転送する。

処理が続いて、ＦＢ２２０−１は新たなアドレスフェンスを受け取る前に開始されたプロセシング／ワークを完了する［アクト６２０］。かかるワークは、まだＵＲＢ２５０に戻されていない処理すべきデータを含むが、ＦＢ２２０−１に関連付けられたＵＲＢ２５０内（例えばスコアボード３２０内）のデータを含むわけではない。ＦＢ２２０−１が、その旧状態でまだ動作している間に、その新たなスコアボード（例えばスコアボード３２０の「ポン」部分）にアドレスを「リタイア」することは容認されない。ＦＢ２２０−１がその旧状態でまだ動作している場合は、所有権を求めて転送されているというタグが付けられていないアドレスはいずれも、ＦＢ２２０−１の現在動作中のフェンスに対してフェンスの比較がされ、旧動作状態に基づいて送り上げ、送り下げまたは保持される必要がある。

ＦＢ２２０−１は、その現在のワークを終了した後、旧状態に割り当てられたエントリに対してゼロで開始するその旧スコアボード３２０をスキャンする。スコアボード内のかかるエントリの各々に対し、それは、アドレス＝スコアボードインデクス＋旧トップへのアドレス翻訳を行う。アドレスが新トップ／ボトムフェンス内の場合は、それはインデクス＝アドレス−新トップの翻訳を行い、新スコアボード３２０内のビットをそのインデクスにセットする［アクト６３０］。

アドレスが新アドレスフェンスのボトム値より下またはトップ値より上の場合は、ＦＢ２２０−１は、ＨＰＢＩ２３０を介して下流または上流へ、「所有権転送」インジケータとともにアドレスを転送する［アクト６４０］。なお、トップ値の比較は、トップＦＢ２２０−１よりも下のＦＢｓに対してのみ関連する。かかる所有権転送インジケータは、このアドレスがＦＢ２２０−１に送り返されるべきではないことを他のＦＢｓ２２０（例えばＦＢ２２０−２）に示すが、その代わりに受け側ＦＢの新アドレスフェンスと比較される（および新フェンス内であれば受け側ＦＢの新スコアボード内の対応するエントリをセットする）。アクト６３０において翻訳されたアドレスまたはアクト６４０において転送されたアドレスに対しては、ＦＢ２２０−１は、（例えば、それをゼロにセットすることによって）その旧スコアボード３２０内の対応するエントリをクリアする。図６の破線は、旧スコアボード３２０に見出されるすべてのエントリに対してアクト６２０およびアクト６４０が繰り返されることを示す。

旧スコアボード３２０が所定のインデクスにおいてゼロを有する（例えば、アドレスがないことを示す）場合、そのインデクスについてアクト６３０およびアクト６４０におけるオペレーションは行われない。インデクスは増分を受けて、ゼロを転送する。アドレス計算が行われてエントリが新スコアボード３２０内にマップされると、ＦＢ２２０は、それを単に転送する代わりに、その新スコアボードエントリに対してゼロを書き込む。なお、旧スコアボード３２０がスキャンされるとすぐに、ＦＢ２２０−１は、新スコアボードに対してスコアボード読み取りポインタをゼロにリセットし、ＵＲＢ２５０内のエントリを要求する新たなペイロードを生成するべく隣接する１を探し始める。

アクト６３０およびアクト６４０と同時に、アドレスはノース方向ＬＰＢＩ２４０を介してＦＢ２２０−１に到達する。かかる到達アドレスは、新フェンス３１０およびスコアボード３２０に関するＦＢ２２０−１によって扱われる［アクト６５０］。例えば、入ってくるアドレスは新トップ／ボトムフェンス３１０内にマップされて新スコアボードインデクスに対して参照され、新スコアボードエントリは１にセットされる。アドレスが新フェンス３１０の範囲外の場合（第１ＦＢ２２０−１の場合はそれがボトム値よりも大きい場合のみがあり得る）、アドレスはＨＰＢＩ２３０上のＦＢ２２０−２（またはパイプライン内の次のＦＢ２２０のいずれでも）へ「所有権転送」インジケータとともに下へ送り返される。

ＦＢ２２０−１が新たな状態のための第１ワークロードを次のＦＢ２２０（例えばＦＢ２２０−２）に送る準備ができている場合、それはサウス方向のＬＰＢＩ２４０上で「フリップ状態」メッセージを送る［アクト６６０］。かかるフリップ状態メッセージはパイプライン内の次のＦＢにプロセス６００を開始するように指示する。アクト６５０の後に示されているが、いくつかの実施例においてはアクト６６０はアクト６２０の直後に行われる。ＦＢ２２０−２がこのメッセージを見て以前の状態のワークで済む場合（例えば、アクト６２０の完了後）、それは、そのサウス方向ＬＰＢＩ２４０上での順番で別の「フリップ状態」メッセージを発行する。

誤ったタイミングの状態変更を防ぐためには、ＦＢ２２０−１が、エンジン／パイプラインの残りの準備ができる前に新状態に応じてデータを発行させることを防ぐメカニズムが望ましい。したがって、ＦＢ２２０−１は、最下流のユニット（例えばＦＢ２２０−ｎ、ここでｎはパイプライン内の最後のユニットを示す）から、その新状態になったことを示すなんらかの信号を受け取るまで待つ［アクト６７０］。いくつかの実施例においては、最下流のＦＢ２２０−ｎは、ＬＰＢＩ２４０を介して受け取った「フリップ状態」で動作する場合、ノース方向のＨＰＢＩ２３０を介してＦＢ２２０−１に確認応答信号を送り返す。

パイプライン内の他のＦＢｓ２２０はすべて、このメッセージを無視する。かかる実施例において、ＦＢ２２０−１は、確認応答パケットが受け取られるまで新状態パケットを発行しない。しかし、他の確認応答および／または遅延のメカニズムも可能かつ考慮される。

そして、ＦＢ２２０−１は新状態のワークの発行を開始する［アクト６８０］。

ここで、ＦＢ２２０−２のような下流ユニットに対するプロセス６００を説明する。ＦＢ２２０−１は、ＦＢ２２０−２がまだ旧状態にある間に状態を変更している。ＦＢ２２０−２が「開放」してその旧フェンス内に該当する任意のアドレスは、必然的にその旧スコアボードに該当する。ＦＢ２２０−２が「開放」してその旧フェンス外に該当する任意のアドレスは、ノース方向ＬＰＢＩ２４０を使用して上流へ転送される。このことはまた、ＦＢ２２０−２がそのノース方向ＬＰＢＩ２４０を介して下流ユニット（例えばＦＢ２２０−３）から受け取る任意のアドレスについても当てはまる。ＦＢ２２０−２は、そのワークを旧状態からディスパッチすることを済ませた場合、アクト６３０およびアクト６４０を行う。ＦＢ２２０−２は、その旧スコアボード３２０をスキャンし、ノース方向またはサウス方向のＨＰＢＩ２３０を使用して「所有権転送」セマンティクスとともに必要に応じてアドレスを転送する。プロセス６００は、残りのユニット２２０によって繰り返されて、それらの中にＵＲＢ２５０を動的に再割り当てする。

図７は、ＨＰＢＩ２３０およびＬＰＢＩ２４０上の例示的なメッセージフォーマットを示す。メッセージ７１０は、ＨＰＢＩ２３０上の（例えば、連続ＦＢ２２０への）サウス方向へのメッセージのフォーマットを示す。メッセージ７２０は、ＨＰＢＩ２３０上の（例えば、以前のＦＢ２２０への）ノース方向へのメッセージのフォーマットを示す。同様に、メッセージ７３０およびメッセージ７４０は、各々ＬＰＢＩ２４０上のサウス方向およびノース方向のメッセージのフォーマットを示す。

なお、メッセージ７１０−７４０のＵＲＢアドレスのすべては１０ビットフィールドとして示されている。このデータ長は、ＵＲＢ２５０が１０２４以下のエントリを有していることを仮定しており、アドレスされたメモリのサイズに基づくと異なるかもしれない。これは、再分割されるべきＵＲＢ２５０または他のメモリが多少のアドレス空間を必要とする場合には、所望に応じて調整される。

本明細書に記載のように、アドレスフェンスメカニズム３１０は、各関数ブロック２２０に組み込まれる。各関数ブロック２２０は、そのＵＲＢ２５０内への出力に対しては、それ自体のフェンス範囲内のアドレスのいずれかを使用する。これらのアドレスは、その後の読み取りおよびさらなる処理を目的として下流の関数２２０に転送される。その後の読み取りが行われた後、アドレスは、（例えば、アドレスがその関数ブロックのアドレス範囲内にある場合）その関数ブロック２２０によって保持されるか、（例えば、アドレスがその関数ブロックのアドレス範囲よりも大きい場合）送り下げられるか、または（例えば、アドレスがその関数ブロックのアドレス範囲よりも小さい場合）送り上げられるか、のいずれかとなる。関数ブロック２２０の状態変更が生じると、アドレスフェンス３１０は、デッドロックなしにまたは関連付けられたデータの関数ブロック２２０を完全にフラッシュする必要なしに、動的に再設定される。

１つ以上の実施例の上記記載は例示および説明を与えるが、本発明の範囲を網羅することも、開示の正確な形態に限定することも意図しない。修正例および変形例は上記教示に鑑みて可能であり、本発明の様々な実施例を行うことから得られる。

例えば、本明細書においてメモリの再割り当てスキームは、リターンバッファ２５０および関数ブロック２２０に関して記載されてきたが、一般的には計算関数および／またはスレッドによる／に対するメモリ内の動的再割り当てに適用することができる。また、本明細書で説明されたアドレスフェンス３１０およびスコアボード３２０によって行われるアドレスソーティング関数およびブックキーピング関数のための他のスキームも可能かつ考慮される。さらに、アドレスフェンス３１０は、関数ブロック２２０に対して連続アドレスを仮定するが、所望に応じて、バッファ中の不連続アドレスは、フェンスとは異なる関連付けロジックを備える所定の関数ブロック２２０に関連付けられてもよい。

さらに、図４から図６に記載のアクトは、図示の順序で行われる必要はないし、必ずしもアクトのすべてが行われる必要もない。また、他のアクトに依存しないアクトは、他のアクトと並列して行われてもよい。さらに、この図のアクトの少なくともいくつかは、命令または命令のグループとして行われてもよく、機械読み取り可能媒体において行われてもよい。

本願の記載に使用された要素、アクトまたは命令はいずれも、明示的に記載されていない限りは本発明に対して決定的または必須のものとして解釈するべきではない。また、本明細書において使用されている冠詞「ａ」は、１つ以上のアイテムを含むことを意図する。請求項に記載の発明の上記実施に対しては、本発明の要旨および原理から実質的に逸脱することなく変形例および修正例が可能である。本明細書においては、かかるすべての修正例および変形例は、本開示の範囲内に含まれ、以下の請求項によって保護されることを意図する。

システムの例を示す。 図１のシステムの例におけるスレッドディスパッチャを示す。 図２のスレッドディスパッチャにおける関数ブロックを示す。 関数ブロック中のバッファにアドレスを初期的に割り当てるプロセスを示すフローチャートである。 関数ブロックによるバッファ内のアドレス利用プロセスを示すフローチャートである。 関数ブロックによるアドレスフェンスの動的変更プロセスを示すフローチャートである。 メッセージフォーマットの例を示す。

Claims (23)

1. メモリと、
   前記メモリの割り当て部分である複数の設定可能な関数ブロックと
   を含み、
   前記関数ブロックの各々は、
   前記関数ブロックによって現在使用されるメモリ内の範囲を画定する値を格納するアドレスフェンスユニットと、
   前記現在使用される範囲の利用を追跡記録するスコアボードユニットと
   を含むシステム。
2. 前記アドレスフェンスユニットは、前記現在使用される範囲に加えて、前記メモリ内の少なくとも１つの範囲のための格納部を含む、請求項１に記載のシステム。
3. 前記スコアボードユニットは、前記現在使用される範囲に加えて、前記メモリ内の前記少なくとも１つの範囲の利用を追跡記録する格納部を含む、請求項２に記載のシステム。
4. 前記関数ブロックの各々は、前記アドレスフェンスユニット内の値に基づいて、前記メモリ内のアドレス値と前記スコアボードユニット内のインデクスとの間の翻訳を行う計算ユニットをさらに含む、請求項１に記載のシステム。
5. 前記関数ブロックの各々は、前記計算ユニットからのインデクスに基づいて、前記スコアボードユニット内の値をセットまたはクリアするロジックをさらに含む、請求項４に記載のシステム。
6. 前記関数ブロックまたは前記メモリからデータを受け取り、前記データを処理し、および処理済みデータを前記メモリに書き込むべく、１つ以上のプロセッサをさらに含む、請求項１に記載のシステム。
7. 前記複数の設定可能な関数ブロックに接続する高優先双方向バスと、前記複数の設定可能な関数ブロックに接続する低優先双方向バスとをさらに含む、請求項１に記載のシステム。
8. 第１パイプラインの第１セットの関数間にメモリ内のアドレス範囲を分配することと、
   前記第１パイプラインの第１セットの関数が、前記アドレス範囲を使用するデータ上で動作することと、
   前記メモリ内の異なるアドレス範囲を、前記第１セットの関数がデータをフラッシュされるのを待つことなしに第２パイプラインの第２セットの関数間に再分配することと
   を含む方法。
9. 前記分配は、前記第１セットの関数間にアドレスフェンスのセットを分配することを含む、請求項８に記載の方法。
10. 前記分配は、
    アドレスがアドレスフェンス内にあるか否かを決定することと、
    前記アドレスが前記アドレスフェンス内に該当する場合は前記アドレスを処理することと、
    前記アドレスが前記アドレスフェンス外に該当する場合は前記アドレスを別の関数に転送することと
    を含む、請求項９に記載の方法。
11. 前記動作は、
    プロセシングタスクに対してメモリ内の空間を割り当てることと、
    前記タスクをプロセッサにディスパッチすることと、
    前記タスクに対応する前記メモリ内のアドレスのリストを次の関数のために生成することと
    を含む、請求項８に記載の方法。
12. 前記動作は、
    前記アドレスのリストに関連付けられたデータが消費されるまで待つことと、
    前記アドレスのリストをスコアボードに開放すること
    を含む、請求項１１に記載の方法。
13. 前記再分配は、
    前記第２セットの関数間に新セットのアドレスフェンスを分配することと、
    前記アドレスが新アドレスフェンス内に該当する場合はアドレスを旧スコアボードから新スコアボードに翻訳することと、
    前記アドレスが新アドレスフェンス外に該当する場合は前記旧スコアボード内の前記アドレスの所有権を転送することと
    を含む、請求項８に記載の方法。
14. 前記再分配は、次の関数にメッセージを送り、その新アドレスフェンスに関するその旧スコアボードおよび新スコアボードに対して前記翻訳および前記転送を始めることをさらに含む、請求項１３に記載の方法。
15. 前記再分配が行われた後に前記異なるアドレス範囲を使用して、前記第２パイプライン内の前記第２セットの関数が動作することをさらに含む、請求項８に記載の方法。
16. アドレスフェンスを使用するいくつかのプロセス間にメモリを分割することと、
    前記いくつかのプロセスが前記メモリを使用し続けている間に、前記いくつかのプロセスの１つから前記いくつかのプロセスの別の１つにメモリ空間を動的に再割り当てすることと
    を含む方法。
17. 前記動的な再割り当ては、
    新セットのアドレスフェンスを受け取ることと、
    前記アドレスが前記新セットのアドレスフェンス内に該当する場合はアドレスの所有権を維持することと、
    前記アドレスが前記新セットのアドレスフェンス外に該当する場合は前記アドレスの所有権を転送することと
    を含む、請求項１６に記載の方法。
18. 前記所有権を転送することは、前記アドレスを高優先バスによって別のプロセスに送ることを含む、請求項１７に記載の方法。
19. 前記再分配は、次のプロセスにメッセージを送り、その新セットのアドレスフェンスに対応するアドレスに対して前記維持および前記転送を行うことをさらに含む、請求項１７に記載の方法。
20. グラフィカル処理デバイスに以前に割り当てられた量とは異なる量の物理的メモリを、セットの固定関数間に、前記セットの固定関数に関連付けられたデータの完全なフラッシュを行うことなしに割り当てることを含む方法。
21. 前記セットの固定関数は、前記割り当て中に前記物理的メモリを使用かつアクセスし続ける、請求項２０に記載の方法。
22. 前記割り当ては、前記セットの固定関数において旧セットのアドレスフェンスと新セットのアドレスフェンスとの間で前記メモリ内のアドレスを伝えることを含む、請求項２０に記載の方法。
23. 前記割り当ては、前記新セットのアドレスフェンスに応じて高優先バス上の固定関数間で前記メモリ内のアドレスの所有権を転送する、請求項２２に記載の方法。

Images