JP6793162B2 - 画像プロセッサのためのラインバッファユニット - Google Patents

Description

発明の分野
本発明は、一般に、画像処理に関し、特に、画像プロセッサのラインバッファ部に関する。

背景
画像処理は、典型的には、アレイに編成されたピクセル値の処理を含む。ここで、空間的に編成された二次元アレイは、画像の二次元的性質を捕捉する（追加の次元は、時間（例えば二次元画像のシーケンス）およびデータタイプ（例えば色）を含み得る。典型的なケースでは、アレイ化されたピクセル値は、静止画像または動きの画像を捕捉するためにフレームのシーケンスを生成したカメラによって提供される。伝統的な画像プロセッサは、典型的には、２つの極端な側面のいずれかに分類される。

第１の極端な側面は、汎用プロセッサまたは汎用状プロセッサ（例えばベクトル命令拡張を備えた汎用プロセッサ）上で実行されるソフトウェアプログラムとして画像処理タスクを実行する。第１の極端な側面は、一般的に非常に汎用性の高いアプリケーションソフトウェア開発プラットフォームを提供するが、関連するオーバーヘッド（例えば、命令フェッチおよびデコード、オンチップおよびオフチップデータの処理、投機的実行）と組み合わされたより精細な粒子のデータ構造の使用は、究極的には、プログラムコードの実行中に、データの単位あたり、より多くのエネルギーが消費される結果となる。

第２の逆の極端な側面は、固定機能のハードワイヤード回路系をはるかに大きなデータブロックに適用する。カスタム設計された回路に直接適用される、（粒度の細かいブロックとは対照的な）より大きなデータブロックの使用は、データ単位あたりの消費電力を大幅に削減する。しかしながら、カスタム設計された固定機能回路系の使用は、一般に、プロセッサが実行することができるタスクのセットが限られる結果となる。このように、（第１の極端な側面に関連する）幅広く汎用性の高いプログラミング環境は第２の極端な側面においては欠けている。

高度に汎用性の高いアプリケーションソフトウェア開発の機会と、データ単位あたりの電力効率の向上とを両立させた技術プラットフォームは、依然として望ましいが、欠けている解決策である。

概要
複数のラインバッファインタフェースユニットからなるラインバッファユニットを含む装置が記載される。各ラインバッファインタフェースユニットは、それぞれの作成側による１つ以上の要求を処理して、それぞれのライングループをメモリに格納し、それぞれの消費側による１つ以上の要求を処理して、メモリからそれぞれのライングループをフェッチおよび提供する。ラインバッファユニットは、異なる画像サイズに対する異なるライングループサイズがメモリに記憶可能となるように情報がライングループサイズを確立するプログラマブルな記憶空間を有する。

図面のリスト
以下の説明および添付の図面は、本発明の実施形態を例示するために使用される。

技術プラットフォームの様々なコンポーネントを示す。 カーネルとともに構築されたアプリケーションソフトウェアの実施形態を示す。 カーネルの構造の実施形態を示す。 カーネルの動作の実施形態を示す。 画像プロセッサハードウェアアーキテクチャの実施形態を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルを伴うシートに対して実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルを伴うシートに対して実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルを伴うシートに対して実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルを伴うシートに対して実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルを伴うシートに対して実行される操作を示す。 ステンシルプロセッサの実施形態を示す。 画像プロセッサの構成およびプログラミングの実施形態を示す。 ライングループからなる画像フレームを示す。 ラインバッファユニットの設計および動作上の実施形態を示す。 ラインバッファユニットの設計および動作上の実施形態を示す。 ラインバッファユニットの設計および動作上の実施形態を示す。 画像プロセッサのプログラマブルなレジスタ空間の実施形態を示す。 画像プロセッサのプログラマブルなレジスタ空間の実施形態を示す。 仮想的に高い動作モードを示す。 仮想的に高い動作モードを示す。 ラインバッファインタフェースユニットの実施形態を示す。 ラインバッファインタフェースユニットの実施形態を示す。 コンピューティングシステムの実施形態を示す。

詳細な記載
ｉ．導入
以下の説明は、広く汎用性のあるアプリケーションソフトウェア開発環境を提供する新たな画像処理技術プラットフォームに関する多数の実施形態を記載するものであり、それは改善された電力効率を提供するために、より大きなデータのブロック（例えば、以下にさらに説明するようなライングループおよびシート）を使用する。

１．０ アプリケーションソフトウェア開発環境
ａ．カーネルの用途および構造
図１は、仮想画像処理環境１０１と、実際の画像処理ハードウェア１０３と、仮想処理環境１０１のために書かれたよりハイレベルのコードを、実際のハードウェア１０３が物理的に実行するオブジェクトコードに変換するためのコンパイラ１０２とを含む、画像プロセッサ技術プラットフォームのハイレベル図である。以下でより詳細に説明するように、仮想処理環境１０１は、アプリケーションの構成プロセスの容易な視覚化のために開発および調整できるアプリケーションの点で、広く汎用性が高い。開発者１０４によるプログラムコード開発努力が完了すると、コンパイラ１０２は、仮想処理環境１０１内で書か
れたコードを、実際のハードウェア１０３に対して対象とされるオブジェクトコードに変換する。

図２ａは、仮想環境内で書かれたアプリケーションソフトウェアが取ることができる構造および形態の例を示す。図２ａにおいて見られるように、プログラムコードは、入力画像データ２０１の１つ以上のフレームを処理して、入力画像データ２０１上で何らかの全体的な変換を行うことが期待される。変換は、開発者によって明示されたオーケストレーションされたシーケンスで入力画像データに対して動作するプログラムコード２０２の１つ以上のカーネルの動作によって実現される。

例えば、図２ａにおいて見られるように、最初に第１のカーネルＫ１で各入力画像を処理することによって全体の変換が行われる。カーネルＫ１によって生成された出力画像は、カーネルＫ２によって操作される。カーネルＫ２によって生成された出力画像の各々は、カーネルＫ３＿１またはＫ３＿２によって操作され、カーネルＫ３＿１／Ｋ３＿２によって生成された出力画像は、カーネルＫ４によって操作される。カーネルＫ３＿１およびＫ３＿２は、Ｋ３ステージで並列処理を課すことによって全体の処理を高速化するように設計された同一のカーネルであってもよいし、異なるカーネルであってもよい（例えば、カーネルＫ３＿１は第１の特定タイプの入力画像で動作し、カーネルＫ３＿２は第２の異なるタイプの入力画像で動作する）。

このように、全体的な画像処理シーケンスが大きくなると、画像処理パイプラインまたは有向非循環グラフ（ＤＡＧ）の形を取り得、開発環境は、開発されているプログラムコードのそのようなものとしての表現を実際に開発者に提示するよう備えられてもよい。カーネルは、開発者によって個々に開発されてもよく、ならびに／または任意の基礎となる技術を供給するエンティティ（実際の信号プロセッサハードウェアおよび／もしくはその設計など）および／もしくは第三者（例えば、開発環境向けに作成されたカーネルソフトウェアのベンダー）によって提供されてもよい。したがって、名目上の開発環境には、開発者がより大きな開発努力の全体的な流れを達成するために様々な方法で自由に「つなぐ」ことができるカーネルの「ライブラリ」が含まれることが期待される。そのようなライブラリの一部であると予想されるいくつかの基本的なカーネルは、以下の基本的な画像処理タスク：畳み込み、ノイズ除去、色空間変換、エッジおよびコーナー検出、シャープニング、ホワイトバランス、γ補正、トーンマッピング、行列乗算、画像レジストレーション、ピラミッド構築、ウェーブレット変換、ブロック状離散コサイン、およびフーリエ変換のうちの１つ以上を提供するようカーネルを含んでもよい。

図２ｂは、開発者が構想することができるカーネル２０３の構造の例示的な図を示す。図２ｂにおいて見られるように、カーネル２０３は、それぞれの下位プロセッサ２０５上で各々動作しているプログラムコード２０４のいくつかの並列スレッド（「スレッド」）として見ることができ、各プロセッサ２０５は、出力アレイ２０６における特定の位置（カーネルが生成している出力画像内の特定のピクセル位置など）に向けられる。簡略化のために、３つのプロセッサおよび対応するスレッドのみが図２ｂに示されている。様々な実施形態では、図示された各出力アレイ位置は、それ自身の専用プロセッサおよび対応するスレッドを有するであろう。すなわち、別個のプロセッサおよびスレッドを出力アレイの各ピクセルに割り当てることができる。

以下でより詳細に説明するように、様々な実施形態では、実際の基礎となるハードウェアにおいて、実行レーンのアレイおよび対応するスレッドが一致して（例えば、単一命令複数データのような態様において）動作して、現在処理中のフレームの「ライングループ」の一部のために出力画像データを生成する。ライングループは、画像フレームの連続したサイズ決め可能な部分である。様々な実施形態では、開発者は、ハードウェアがライン
グループに対して動作することを意識し得、または、開発環境は、例えば、出力フレーム内のすべてのピクセル（例えば、それ自身の専用プロセッサおよびスレッドによって生成された出力フレームにおけるすべてのピクセル）に対して別個のプロセッサおよびスレッドが存在する抽象化を提示し得る。いずれにせよ、様々な実施形態において、開発者は、各出力ピクセルについて個々のスレッドを含むようにカーネルを理解する（出力アレイが視覚化されているかどうかは、出力フレーム全体またはその一部である）。

以下でより詳細に説明するように、一実施形態では、仮想環境内で開発者に提示されるプロセッサ２０５は、標準（例えばＲＩＳＣ）オペコードをサポートするだけでなく、開発者が実行されているピクセル毎の処理を容易に視覚化することを可能にするフォーマットされたデータアクセス命令も含む命令セットアーキテクチャ（ＩＳＡ）を有する。従来の数学的およびプログラム制御オペコードのＩＳＡ全体と組み合わせて任意の入力アレイ位置を容易に定義／視覚化する能力は、理想的には、任意のサイズの画像表面上で実行されるべき任意の所望の機能をアプリケーションプログラム開発者が定義することを本質的に可能にする非常に汎用性の高いプログラミング環境を可能にする。例えば理想的には、任意の数学演算を任意のステンシルサイズに適用するように容易にプログラミングすることができる。

データアクセス命令に関して、一実施形態では、仮想プロセッサのＩＳＡ（「仮想ＩＳＡ」）は、特殊なデータロード命令および特殊なデータストア命令を含む。データロード命令は、画像データの入力アレイ内の任意の位置から読み出しできる。データストア命令は、画像データの出力アレイ内の任意の位置に書き込むことができる。後者の命令は、同じプロセッサの複数のインスタンスを異なる出力ピクセル位置に簡単に割り当てることを可能にする（各プロセッサは出力アレイ内の異なるピクセルに書き込む）。したがって、例えば、ステンシルサイズ自体（例えば、ピクセルの幅およびピクセルの高さとして表現される）を、容易にプログラマブルな特徴にすることができる。処理操作の視覚化は、特殊なロードおよびストア命令の各々が特殊な命令フォーマットを有して、更に単純化され、これにより、ターゲットアレイ位置がＸおよびＹ座標として単純に指定される。

いずれにせよ、出力アレイ内の複数の位置各々に対して別個のプロセッサをインスタンス化することにより、プロセッサはそれぞれのスレッドを並列に実行し、例えば出力アレイ内のすべての位置に対するそれぞれの値が同時に生成される。多くの画像処理ルーチンは、典型的には、同じ出力画像の異なるピクセル上で同じ操作を実行することは注目に値する。このように、開発環境の一実施形態では、各プロセッサは同一であると推定され、同じスレッドプログラムコードを実行する。したがって、仮想化された環境は、ロックステップで同一のコードを各々実行する同一のプロセッサなどの二次元アレイからなる一種の二次元（２Ｄ）ＳＩＭＤプロセッサとして見ることができる。

図３は、出力アレイ内の２つの異なるピクセル位置について同一のコードを処理している２つの仮想プロセッサのための処理環境のより詳細な例を示す。図３は、生成されている出力画像に対応する出力アレイ３０４を示す。ここでは、第１の仮想プロセッサがスレッド３０１のコードを処理して出力アレイ３０４の位置Ｘ１に出力値を生成し、第２の仮想プロセッサがスレッド３０２のコードを処理して出力アレイ３０４の位置Ｘ２に出力値を生成している。再び、様々な実施形態において、開発者は、出力アレイ３０４内の各ピクセル位置について別個のプロセッサおよびスレッドが存在することを理解するであろう（単純にするため、図３はそのうちの２つのみを示す）。しかしながら、様々な実施形態で、開発者は、（マシンのＳＩＭＤのような性質のため、）１つのプロセッサおよびスレッドに対してコードを開発するだけでよい。

当技術分野で知られているように、出力ピクセル値は、しばしば、対応する出力ピクセ
ル位置を含みそれを囲む入力アレイのピクセルを処理することによって決定される。例えば、図３からわかるように、出力アレイ３０４の位置Ｘ１は、入力アレイ３０３の位置Ｅに対応する。したがって、出力値Ｘ１を決定するために処理されるであろう入力アレイ３０３のピクセル値のステンシルは、入力値ＡＢＣＤＥＦＧＨＩに対応するであろう。同様に、出力値Ｘ２を決定するために処理される入力アレイピクセルのステンシルは、入力値ＤＥＦＧＨＩＪＫＬに対応するであろう。

図３は、出力値Ｘ１およびＸ２をそれぞれ計算するために使用され得るスレッド３０１，３０２の対に対する対応する仮想環境プログラムコードの例を示す。図３の例では、両方のコード対が同一であり、９つの入力アレイ値のステンシルを平均して、対応する出力値を決定する。２つのスレッドの唯一の違いは、入力アレイから呼び出される変数および書き込まれる出力アレイの位置である。具体的には、出力位置Ｘ１に書き込むスレッドは、ステンシルＡＢＣＤＥＦＧＨＩで動作し、出力位置Ｘ２に書き込むスレッドはステンシルＤＥＦＧＨＩＪＫＬで動作する。

スレッド３０１，３０２の対からのそれぞれのプログラムコードからわかるように、各仮想プロセッサは、少なくとも内部レジスタＲ１およびＲ２を含み、少なくとも以下の命令をサポートする：１）入力アレイからＲ１へのＬＯＡＤ（ロード）命令；２）入力アレイからＲ２へのＬＯＡＤ命令；３）Ｒ１およびＲ２の内容を加算して結果をＲ２に入れるＡＤＤ（加算）命令；４）Ｒ２内の値を即値オペランド９で除算するＤＩＶ（除算）命令；および５）スレッドの専用の出力アレイ位置にＲ２の内容を格納するＳＴＯＲＥ（格納）命令。ここでもまた、図３には２つの出力アレイ位置ならびに２つのスレッドおよび対応するプロセッサしか描かれていないが、おそらく、出力アレイ内のすべての位置にこれらの機能を実行する仮想プロセッサおよび対応するスレッドを割り当てることができる。様々な実施形態では、処理環境のＳＩＭＤのような性質にしたがって、複数のスレッドが互いに独立して実行される。つまり、仮想プロセッサ間にスレッド間通信は存在しない（１つのＳＩＭＤチャネルが別のＳＩＭＤチャネルと交差しないようにしている）。

ｂ．仮想プロセッサメモリモデル
様々な実施形態において、仮想プロセッサの関連する特徴は、それらのメモリモデルである。当該技術分野で理解されるように、プロセッサは、メモリからデータを読み出し、そのデータを操作し、新たなデータをメモリに書き戻す。メモリモデルは、プロセッサが有する、データがメモリ内に編成される方法のパースペクティブまたはビューである。一実施形態では、仮想プロセッサのメモリモデルは、入力アレイ領域および出力アレイ領域の両方を含む。スレッドの入力ピクセル値は入力アレイ領域に格納され、スレッドによって生成された出力ピクセル値は出力アレイ領域に格納される。

一実施形態では、新規なメモリアドレス指定方式を使用して、仮想プロセッサのメモリモデルの入力アレイ部分からどの特定の入力値が呼び込まれるかを規定する。具体的には、従来の線形メモリアドレスではなく、Ｘ、Ｙ座標で所望の入力データを定義する「位置相対的」アドレス指定方式が使用される。このように、仮想プロセッサのＩＳＡのロード命令は、Ｘ成分とＹ成分とで入力アレイ内の特定のメモリ位置を識別する命令フォーマットを含む。このように、二次元座標系を使用して、入力アレイから読み出される入力値に対してメモリをアドレス指定する。

位置相対的メモリアドレス指定アプローチの使用は、仮想プロセッサが動作している画像の領域が、開発者にとってより容易に識別可能であることを可能にする。上記したように、従来の数学的およびプログラム制御オペコードのＩＳＡ全体と組み合わせて任意の入力アレイ位置を容易に定義／視覚化する能力は、理想的には、任意のサイズの画像表面上で実行されるべき任意の所望の機能をアプリケーションプログラム開発者が容易に定義す
ることを本質的に可能にする非常に汎用性の高いプログラミング環境を可能にする。位置相対的アドレス指定方式を採用する命令のための様々な命令フォーマットの実施形態が、サポートされるＩＳＡの他の特徴の実施形態とならんで、以下により詳細に説明される。

出力アレイには、スレッドが生成を担う出力画像データが含まれる。出力画像データは、全体の画像処理シーケンスに従うディスプレイ上に提示される実際の画像データなどの最終画像データであってもよいし、全体の画像処理シーケンスの次のカーネルがその入力画像データ情報として使用する中間画像データであってもよい。ここでも、典型的には、仮想プロセッサは、同じサイクル中に出力画像データの異なるピクセル位置に書き込むので、同じ出力データ項目に対して競合しない。

一実施形態では、位置相対的アドレス指定方式は、出力アレイへの書込にも使用される。そのため、各仮想プロセッサに対するＩＳＡは、その命令フォーマットが、従来のランダムアクセスメモリアドレスではなく、二次元のＸ、Ｙ座標としてメモリ内の目標とされる書込位置を規定するストア命令を含む。

２．０ ハードウェアアーキテクチャの実施形態
ａ．画像プロセッサハードウェアアーキテクチャおよび動作
図４は、ハードウェアで実現される画像プロセッサのためのアーキテクチャ４００の実施形態を示す。画像プロセッサは、例えば、シミュレートされた環境内で仮想プロセッサ用に書かれたプログラムコードを、ハードウェアプロセッサによって実際に実行されるプログラムコードに変換するコンパイラによって対象とされてもよい。図４に示すように、アーキテクチャ４００は、複数のラインバッファユニット４０１＿１〜４０１＿Ｍを含み、それらは、複数のステンシルプロセッサユニット４０２＿１〜４０２＿Ｎおよび対応するシート生成部ユニット４０３＿１〜４０３＿Ｎに、ネットワーク４０４（例えば、ネットワークオンチップ（ＮＯＣ）（オンチップスイッチネットワーク、オンチップリングネットワークまたは他の種類のネットワークを含む））を介して相互接続される。一実施形態では、どのラインバッファユニットが、ネットワーク４０４を介してどのシート生成部および対応するステンシルプロセッサに接続してもよい。

一実施形態では、プログラムコードはコンパイルされ、対応するステンシルプロセッサ４０２にロードされて、ソフトウェア開発者によって以前に定義された画像処理動作を実行する（プログラムコードは、例えば、設計および実装に応じて、ステンシルプロセッサの関連のシート生成部４０３にもロードされてもよい）。少なくともいくつかの例では、画像処理パイプラインを、第１のパイプラインステージ用の第１のカーネルプログラムを第１のステンシルプロセッサ４０２＿１にロードし、第２のパイプラインステージ用の第２のカーネルプログラムを第２のステンシルプロセッサ４０２＿２にロードするなどして、実現することができ、第１のカーネルはパイプラインの第１ステージの機能を実行し、第２のカーネルはパイプラインの第２ステージの機能を実行し、追加の制御フロー方法がインストールされて、出力画像データをパイプラインの１つのステージからの次のステージに渡す。

他の構成では、画像プロセッサは、同じカーネルプログラムコードを動作させる２つ以上のステンシルプロセッサ４０２＿１，４０２＿２を有する並列マシンとして実現することができる。例えば、画像データの高密度かつ高データレートのストリームが、各々が同じ機能を実行する複数のステンシルプロセッサにわたってフレームを広げることによって処理されてもよい。

さらに他の構成では、カーネルの本質的に任意のＤＡＧのハードウェアプロセッサへのロードを、それぞれのステンシルプロセッサをそれら自身のプログラムコードのカーネル
とともに構成し、適切な制御フローフックをハードウェアに構成して、出力画像をＤＡＧ設計における１つのカーネルから次のカーネルの入力に向けることによって、行なってもよい。

一般的なフローとして、画像データのフレームは、マクロＩ／Ｏユニット４０５で受信され、フレーム単位でラインバッファユニット４０１の１つ以上に渡される。特定のラインバッファユニットは、それの画像データのフレームを、「ライングループ」と呼ばれる画像データのより小さな領域に解析し、次いでライングループをネットワーク４０４を介して特定のシート生成部に渡す。ある完全な（ｆｕｌｌ）単数のライングループを、例えば、フレームの複数の連続した完全な行または列のデータで構成することができる（簡単にするために、本明細書では主に連続した行と称する）。シート生成部は、画像データのライングループを「シート」と呼ばれる画像データのより小さな領域にさらに解析し、そのシートを対応するステンシルプロセッサに提示する。

単一入力の画像処理パイプラインやＤＡＧフローの場合、一般に、入力フレームは、同じラインバッファユニット４０１＿１に向けられ、それは、画像データをライングループに解析し、ライングループを対応するシート生成部４０３＿１（対応するステンシルプロセッサ４０２＿１はパイプライン／ＤＡＧにおいて第１のカーネルのコードを実行している）に向ける。ステンシルプロセッサ４０２＿１による、それが処理するライングループでの動作が終了した後、シート生成部４０３＿１は、出力ライングループを「下流」のラインバッファユニット４０１＿２に送信する（ある使用例では、出力ライングループは、先に入力ライングループを送信したのと同じラインバッファ装置４０１＿１に送り返すことができる）。

自身のそれぞれの他のシート生成部およびステンシルプロセッサ（例えば、シート生成部４０３＿２およびステンシルプロセッサ４０２＿２）上で実行されるパイプライン／ＤＡＧにおける次のステージ／動作を表す１つ以上の「消費側」カーネルは、下流ラインバッファユニット４０１＿２から、第１のステンシルプロセッサ４０２＿１によって生成された画像データを受信する。このようにして、第１のステンシルプロセッサ上で動作する「作成側」カーネルは、その出力データが、第２のステンシルプロセッサ上で動作する「消費側」カーネルに転送され、消費側カーネルは、パイプラインまたはＤＡＧ全体の設計と整合する作成側カーネルの後に次のタスクのセットを実行する。

ステンシルプロセッサ４０２は、画像データの複数の重なり合うステンシル上で同時に動作するように設計されている。複数の重なり合うステンシルおよびステンシルプロセッサの内部ハードウェア処理能力は、シートのサイズを効果的に決定する。ここでは、ステンシルプロセッサ４０２内で、実行レーンのアレイが一致して動作して、複数の重なり合うステンシルによってカバーされる画像データ表面領域を同時に処理する。

以下でより詳細に説明するように、様々な実施形態において、画像データのシートは、ステンシルプロセッサ４０２内において二次元レジスタアレイ構造にロードされる。シートおよび二次元レジスタアレイ構造の使用は、大量のデータを、大量のレジスタ空間に、例えば、処理タスクが実行レーンアレイによってその直後に直接データ上で実行される単一のロード動作として移動することによって、電力消費の改善を効果的に提供すると考えられている。さらに、実行レーンアレイおよび対応するレジスタアレイの使用は、容易にプログラマブル／設定可能な異なるステンシルサイズを提供する。

図５ａ〜図５ｅは、ラインバッファユニット４０１の解析アクティビティ、およびシート生成部ユニット４０３のより微細な粒子の解析アクティビティ、ならびにシート生成部４０３に結合されるステンシルプロセッサ４０２のステンシル処理アクティビティの両方
のハイレベルの実施形態を示す。

図５ａは、画像データ５０１の入力フレームの一実施形態を示す。図５ａはまた、ステンシルプロセッサが動作するように設計された３つの重なり合うステンシル５０２（各々３ピクセル×３ピクセルの寸法を有する）の概要を示す。各ステンシルがそれぞれ出力画像データを生成する出力ピクセルは、ベタ黒で強調表示される。簡略化のために、３つの重なり合うステンシル５０２は、垂直方向にのみ重なるように示されている。実際には、ステンシルプロセッサは、垂直方向および水平方向の両方に重なるステンシルを有するように設計されてもよいことを認識することが適切である。

図５ａに見られるように、ステンシルプロセッサ内の垂直に重なり合うステンシル５０２のために、フレーム内に単一のステンシルプロセッサが動作することができる画像データの広い帯域が存在する。以下でより詳細に説明するように、一実施形態では、ステンシルプロセッサは、データを、それらの重なり合うステンシル内で、左から右への態様で、画像データにわたって処理する（そして、次のラインのセットに対して、上から下の順序で繰り返す）。このように、ステンシルプロセッサがそれらの動作を前方に進めるにつれて、ベタ黒出力ピクセルブロックの数は、水平方向に右に成長する。上述したように、ラインバッファユニット４０１は、ステンシルプロセッサが今後の拡張された数のサイクルにわたって動作するのに十分な入来フレームからの入力画像データのライングループを解析することを担う。ライングループの例示的な図示は、陰影領域５０３として示されている。一実施形態では、以下でさらに説明するように、ラインバッファユニット４０１は、ライングループをシート生成部との間で送受信するための異なるダイナミクスを理解することができる。例えば、「完全なグループ」と呼ばれる１つのモードによれば、画像データの完全な全幅のラインが、ラインバッファユニットとシート生成部との間で渡される。「仮想的に高い」と呼ばれる第２のモードによれば、ライングループは最初に全幅行のサブセットと共に渡される。その後、残りの行は、より小さい（全幅未満の）片で順番に渡される。

入力画像データのライングループ５０３がラインバッファユニットによって画定され、シート生成部ユニットに渡されると、シート生成部ユニットはさらに、ライングループを、ステンシルプロセッサのハードウェア制限に、より正確に適合する、より微細なシートに、解析する。より具体的には、以下でさらに詳細に説明するように、一実施形態では、各ステンシルプロセッサは、二次元シフトレジスタアレイからなる。二次元シフトレジスタアレイは、本質的に、画像データを実行レーンのアレイの「真下」にシフトし、シフトのパターンは、各実行レーンをそれ自身のステンシル内においてデータに対して動作させる（すなわち、各実行レーンは、それ自身の情報のステンシル上で処理して、そのステンシルの出力を生成する）。一実施形態では、シートは、二次元シフトレジスタアレイを「満たす」か、さもなければ二次元シフトレジスタアレイにロードされる入力画像データの表面領域である。

したがって、図５ｂに見られるように、シート生成部は、ライングループ５０３から最初のシート５０４を解析し、それをステンシルプロセッサに供給する（ここで、データのシートは、参照番号５０４によって全体的に識別される陰影領域に対応する）。図５ｃおよび図５ｄに示すように、ステンシルプロセッサは、重なるステンシル５０２をシート上で左から右へ効果的に移動させることによって、入力画像データのシートに対して動作する。図５ｄのように、シート内のデータから出力値を計算することができるピクセル数が使い果たされる（他のピクセル位置は、シート内の情報から決定される出力値を有することができない）。簡単にするために、画像の境界領域は無視されている。

図５ｅにおいて見られるように、シート生成部は次いで、ステンシルプロセッサが動作
を継続する次のシート５０５を提供する。ステンシルが次のシートに対して動作を開始するときのステンシルの初期位置は、（先に図５ｄに示されている）最初のシート上の消耗点から右への次の進行であることに留意されたい。新たなシート５０５で、ステンシルプロセッサが最初のシートの処理と同じ態様で新たなシートに対して動作するにつれ、ステンシルは単に右に移動し続ける。

出力ピクセル位置を取り囲むステンシルの境界領域のために、第１のシート５０４のデータと第２のシート５０５のデータとの間にいくらかの重なりがあることに留意されたい。重なりは、シート生成部が重なり合うデータを２回再送信することによって簡単に処理することができる。別の実現例では、次のシートをステンシルプロセッサに供給するために、シート生成部は、ステンシルプロセッサに新たなデータを送るだけに進んでもよく、ステンシルプロセッサは、前のシートからの重なり合うデータを再利用する。

ｂ．ステンシルプロセッサ設計および動作
図６は、ステンシルプロセッサ６００の実施形態を示す。図６において見られるように、ステンシルプロセッサは、データ計算ユニット６０１、スカラープロセッサ６０２および関連するメモリ６０３およびＩ／Ｏユニット６０４を含む。データ計算ユニット６０１は、実行レーンのアレイ６０５、二次元シフトアレイ構造６０６、およびアレイの特定の行または列に関連する別個のランダムアクセスメモリ６０７を含む。

Ｉ／Ｏユニット６０４は、シート生成部から受け取ったデータの「入力」シートをデータ計算ユニット６０１にロードし、ステンシルプロセッサからのデータの「出力」シートをシート生成部に格納する役割を果たす。一実施形態では、データ計算ユニット６０１へのシートデータのロードは、受け取ったシートを画像データの行／列に解析し、画像データの行／列を二次元シフトレジスタ構造６０６または実行レーンアレイの行／列のそれぞれのランダムアクセスメモリ６０７にロードすることを必要とする（以下でより詳細に説明する）。シートが最初にメモリ６０７にロードされる場合、実行レーンアレイ６０５内の個々の実行レーンは、適宜、ランダムアクセスメモリ６０７からシートデータを二次元シフトレジスタ構造６０６にロードすることができる（例えば、シートのデータ上での動作のすぐ前のロード命令として）。データのシートのレジスタ構造６０６へのロード（シート生成部からの直接的であろうとまたはメモリ６０７からであろうと）が完了すると、実行レーンアレイ６０５の実行レーンはデータに対して動作し、最終的に、完成したデータをシートとしてシート生成部に、またはランダムアクセスメモリ６０７に「書き戻す」。後者の場合、Ｉ／Ｏユニット６０４はランダムアクセスメモリ６０７からデータをフェッチして出力シートを形成し、出力シートはシート生成部に転送される。

スカラープロセッサ６０２は、スカラーメモリ６０３からステンシルプロセッサのプログラムコードの命令を読み出し、実行レーンアレイ６０５の実行レーンに命令を発行するプログラムコントローラ６０９を含む。一実施形態では、データ計算ユニット６０１からＳＩＭＤのような動作を実行するために、単一の同じ命令がアレイ６０５内のすべての実行レーンにブロードキャストされる。一実施形態では、スカラーメモリ６０３から読み出され、実行レーンアレイ６０５の実行レーンに発行される命令の命令フォーマットは、命令当たり２つ以上のオペコードを含む非常に長い命令語（ＶＬＩＷ）タイプのフォーマットを含む。さらなる実施形態では、ＶＬＩＷフォーマットは、（以下に説明するように、一実施形態では２つ以上の従来のＡＬＵ動作を指定することができる）各実行レーンのＡＬＵによって実行される数学的機能を指示するＡＬＵオペコードと、（特定の実行レーンまたは実行レーンのセットに対してメモリ操作を指示する）メモリオペコードとの両方を含む。

「実行レーン」という用語は、命令を実行することができる１つ以上の実行ユニットの
セット（例えば、命令を実行することができる論理回路系）を指す。実行レーンは、しかしながら、様々な実施形態では、単なる実行ユニットを超えた、よりプロセッサに似た機能を含むことができる。例えば、１つ以上の実行ユニットに加えて、実行レーンは、受信された命令をデコードする論理回路系、または、よりＭＩＭＤのような設計の場合、命令をフェッチおよびデコードする論理回路系を含むことができる。ＭＩＭＤのようなアプローチに関しては、ここでは集中プログラム制御アプローチが主に記載されているが、より分散型のアプローチが様々な代替実施形態（例えば、アレイ６０５の各実行レーン内のプログラムコードおよびプログラムコントローラを含む）において実施されてもよい。

実行レーンアレイ６０５、プログラムコントローラ６０９および二次元シフトレジスタ構造６０６の組み合わせは、広範囲のプログラマブルな機能のための幅広く適応可能／設定可能なハードウェアプラットフォームを提供する。例えば、アプリケーションソフトウェア開発者は、個々の実行レーンが多種多様な機能を実行することができ、任意の出力アレイ位置に近接した入力画像データに容易にアクセスすることができれば、寸法（例えばステンシルサイズ）だけでなく幅広い異なる機能能力を有するカーネルをプログラミングすることができる。

実行レーンアレイ６０５によって操作される画像データのためのデータ記憶装置として機能することとは別に、ランダムアクセスメモリ６０７は、１つ以上のルックアップテーブルを保持することもできる。様々な実施形態では、１つ以上のスカラールックアップテーブルをスカラーメモリ６０３内でインスタンス化することもできる。

スカラールックアップは、同じルックアップテーブルからの同じインデックスからの同じデータ値を実行レーンアレイ６０５内の各実行レーンに渡すことを含む。様々な実施形態では、上述のＶＬＩＷ命令フォーマットは、スカラープロセッサによって実行されるルックアップ動作をスカラールックアップテーブルに向けるスカラーオペコードを含むようにも拡張される。オペコードとともに使用するために指定されたインデックスは、即値オペランドでもよいし、他のデータ記憶位置からフェッチされてもよい。いずれにせよ、一実施形態では、スカラーメモリ内のスカラールックアップテーブルからのルックアップは、基本的に同じクロックサイクル中に実行レーンアレイ６０５内のすべての実行レーンに同じデータ値をブロードキャストすることを含む。

３．０ ラインバッファユニットの実施形態
ａ．ラインバッファユニット概観
上記におけるセクション１．０での議論から、様々な実施形態において、ハードウェアプラットフォーム用に書かれたプログラムコードは、その命令フォーマットが入力および出力アレイ位置、例えば、Ｘ、Ｙ座標を特定するロードおよびストア命令を有する命令セットを含む一意的な仮想コードで書かれる。様々な実施態様において、Ｘ、Ｙ座標情報は実際にはハードウェアプラットフォームにプログラミングされ、そのコンポーネントの様々なものによって認識／理解される。これは、例えば、Ｘ、Ｙ座標を（例えばコンパイラ内で）異なる情報に変換することとは別である。例えば、ステンシルプロセッサ内の二次元シフトレジスタ構造の場合、Ｘ、Ｙ座標情報はレジスタシフト移動に変換される。対照的に、ハードウェアプラットフォームの他の部分は、元はより高い仮想コードレベルで表現されるＸ、Ｙ座標情報を具体的に受け取り、理解してもよい。

図７で見られるように、セクション１．０で説明したように、プログラムコード開発者は、データ位置を、Ｘ、Ｙ座標として、特殊な命令フォーマットが仮想コードレベルにある状態で、表現する（７１０）。コンパイル段階の間に、仮想コードは、ハードウェアによって実際に処理されるプログラムコード（オブジェクトコード）と、ハードウェアの構成（例えばレジスタ）空間にロードされる対応する構成情報とに変換される。図７に示す
ように、一実施形態では、特定のカーネルのためのオブジェクトコードが、ステンシルプロセッサのスカラープロセッサ７０５のプログラム空間にロードされる。

構成プロセスの一部として、スカラープロセッサ７０５上で実行される構成ソフトウェアは、適切な構成情報７１１，７１２を、ステンシルプロセッサ７０２に結合されるシート生成部ユニット７０３と、ステンシルプロセッサ７０２のために新たなシートを生成して、ステンシルプロセッサ７０２によって生成された処理済みシートに対して動作するかまたはそれを受取るラインバッファユニット７０１との両方にロードする。ここで、一般的に、シートを依然として全体画像のＸ、Ｙ座標に関して企図することができる。すなわち、一旦画像またはフレームが（例えば、行当たりのピクセル数、行数、列当たりのピクセル数および列数に関して）規定されても、画像のどの部分または位置も、依然としてＸ、Ｙ座標で言及され得る。

このように、様々な実施形態では、シート生成部ユニット７０３およびラインバッファユニット７０１のいずれかまたは両方は、情報７１１，７１２が、画像またはフレームの特定の位置および／または領域（例えば、ライングループ、シート）がＸ、Ｙ座標で識別される情報プラットフォームを確立するそれらのそれぞれの構成空間７０６，７０７内にある状態で、構成されている。様々な実現例／用途において、Ｘ、Ｙ座標は、仮想コードレベルで表現される同じＸ、Ｙ座標であってもよい。

このような情報の例は、例えば、ラインバッファユニット内のアクティブなライングループの数、各ライングループについての画像サイズ（例えば、４つのＸ、Ｙ座標のセット（各角に１つ）またはＸ、Ｙ座標の対（１つは下側のより近くの角に、もう１つは上側のより遠い角に））絶対画像幅および画像高さ、ステンシルサイズ（単一のステンシルのサイズおよび／またはステンシルプロセッサの重なり合うステンシルの領域を定義するＸ、Ｙ値として表される）、シートおよび／またはライングループサイズ（例えば、画像サイズと同じ点で指定されるが、より小さい寸法を有する）などを含む。さらに、ラインバッファユニット７０１は、少なくともラインバッファユニット７０１によって管理されるライングループを書き込む作成側カーネルの数および読み取る消費側カーネルの数などの追加の構成情報でプログラミングされてもよい。画像データに関連するチャネルの数および／または寸法も、典型的には、構成情報として含まれる。

図８は、画像内でライングループを一例として定義するＸ、Ｙ座標の使用を示す。ここで、Ｎ個のライングループ８０１＿１，８０１＿２，…８０１＿Ｎが画像８０１内で見ることができる。図８から分かるように、各ライングループは、例えばライングループの角の点の１つ以上を規定する画像内のＸ、Ｙ座標を参照することによって容易に規定することができる。したがって、様々な実施形態では、特定のライングループを規定するために使用されるライングループの名称または他のデータ構造は、そのライングループを特に識別するためにそれに関連付けられたＸ、Ｙ座標位置を含むことができる。

図７を簡単に参照すると、図７は、ランタイム中、シート生成部７０３は、例えば、所望のデータ領域を規定するＸ、Ｙ座標情報を含むことによって、ラインバッファユニット７０１から「次の」ライングループ（またはライングループの一部）を要求することができることを示す。図８は、画像データの完全な行のみからなる名目上「全幅」のライングループを示す。以下でさらに詳細に説明する「仮想的に高い」と呼ばれる代替構成では、ラインバッファユニット７０１は、最初に画像データの全幅の行としてライングループの第１の上側部分のみを通過させる。ライングループの後続の下側の行が、次いで、全幅の行よりも小さい連続した塊でシート生成部によって具体的に要求され、別個に要求される。したがって、完全なライングループを得るために、シート生成部によって複数の要求が行われる。ここで、各そのような要求は、次の下側部分に起因するＸ、Ｙ座標によって次
の下側部分を規定してもよい。

図９ａ〜図９ｃは、ラインバッファユニットの実施形態９００の様々な特徴を示す。図９ａに示すように、ラインバッファユニットは、ライングループ９０３＿１〜９０３＿Ｎが格納されるメモリ９０２（例えば、スタティックまたはダイナミックランダムアクセスメモリ（ＳＲＡＭまたはＤＲＡＭ））を含む。図９ａは、メモリ９０２内において特定の画像／フレームについてライングループ９０３＿１〜９０３＿Ｎを作成および消費する様々なカーネル間のアクティビティを示す。

図９ａで見られるように、作成側カーネルＫ１は、別々の時間インスタンスＰ１、Ｐ２〜ＰＮにわたって、新たなライングループをメモリ９０２に送信する。作成側カーネルＫ１は、新たなデータシートを生成するステンシルプロセッサ上で実行される。ステンシルプロセッサに結合されるシート生成部はシートを集積してライングループを形成し、ライングループをメモリ９０２に転送する。

また、図９ａに示すように、作成側カーネルＫ１によって生成されたライングループ９０３＿１〜９０３＿Ｎに対して動作する２つの消費側カーネルＫ２、Ｋ３が存在する。ここで、消費側カーネルＫ２およびＫ３は、それぞれ時間Ｃ２１およびＣ３１で第１のライングループ９０３＿１を受け取る。明らかに、時間Ｃ２１およびＣ３１は時間Ｐ１の後に生じる。他の制約は存在しなくてもよい。例えば、時間Ｃ２１および／または時間Ｃ３１は、時間Ｐ２からＰＮのいずれかの前または後に生じてもよい。ここで、カーネルＫ２およびＫ３のためのそれぞれのシート生成部は、それらのそれぞれのカーネルに適した時間に次のライングループを要求する。カーネルＫ２、Ｋ３のいずれかが時間Ｐ１の前にライングループ９０３＿１を要求すると、ライングループ９０３＿１が実際にメモリ９０２に書き込まれるまで、要求はアイドル状態にされる。多くの実現例では、作成側カーネルは、消費側カーネルとは異なるステンシルプロセッサ上で動作する。

おそらく、全てのライングループ９０３＿１〜９０３＿Ｎに対するカーネルＫ２およびＫ３の一方または両方からの要求は、時間Ｐ１の前に到着し得る。したがって、ライングループは、いつでも消費側カーネルによって要求され得る。しかしながら、消費側カーネルがライングループを要求すると、ライングループは、作成側カーネルＫ１がそれらを生成することができるレートを条件として、消費側カーネルに転送される。様々な実施形態では、消費側カーネルは順番にライングループを要求し、同様にそれらを順番に受け取る（カーネルＫ２は、ライングループ９０２＿２〜９０２＿Ｎを時間Ｃ２２〜Ｃ２Ｎでシーケンスで受け取る）。簡略化のために、特定のライングループに対して１つの作成側カーネルしか示されていない。異なる作成側が同じライングループに書き込むことができるように様々な実施形態を設計することが考えられる（例えば、すべての作成側がライングループに書き込んでしまうまで消費側にサービスを提供することが許可されていない場合など）。

（消費側カーネルがプロセッサのＤＡＧ処理フローにおける最初のカーネルであるため）作成側カーネルが存在しない場合、画像データのフレームは、メモリ９０２に（例えば、ダイレクトメモリアクセス（ＤＭＡ）を介して、またはカメラから）転送され、ライングループに解析されてもよい。（作成側カーネルがプロセッサの全体的なプログラムフローの最後のカーネルであるため）消費側カーネルが存在しない場合、結果のライングループを組み合わせて出力フレームを形成してもよい。

図９ｂは、ラインバッファユニット９００全体のより詳細な実施形態を示す。議論のため、図９ａのアクティビティは、図９ｂのラインバッファユニット９００に重ね合わされる。図９ｂに見られるように、ラインバッファユニット９００は、ラインバッファユニッ
ト回路系９０１に結合されるメモリ９０２を含む。ラインバッファユニット回路系９０１は、例えば、専用の論理回路系で構成することができる。ラインバッファユニット回路系９０１内では、メモリ９０２内のライングループ９０３＿１〜９０３＿Ｎ毎にラインバッファインタフェースユニット９０４＿１〜９０４＿Ｎが確保されている。様々な実施形態では、ラインバッファユニットが任意の時点で管理できるライングループの数の上限を設定する固定数のラインバッファインタフェースユニット９０４＿１〜９０４＿Ｎが存在する（Ｎ個より少ないライングループがアクティブである場合、対応するより少ない数のラインバッファユニットインタフェースが起動され、いつでも使用される）。

図９ｂに示すように、総数Ｎ個のラインバッファインタフェースユニット９０４がラインバッファユニット回路系９０１内にある状態で、ラインバッファユニット９００は最大数のライングループを処理している。さらに、（ライングループサイズが設定可能なパラメータである）最大許容ライングループサイズで、メモリ９０２についてのおおよそのサイズを決定することができる（もちろん、ハードウェアの効率を考慮するために、より小さいメモリフットプリントを、Ｎ個の最大サイズのライングループを同時に許可しないことを犠牲にしてインスタンス化してもよい）。

各ラインバッファインタフェースユニット９０４＿１〜９０４＿Ｎは、それが処理するように割り当てられた特定のライングループに対する作成側および消費側の要求を処理する役割を担う。例えば、ラインバッファインタフェースユニット９０４＿１は、時間Ｐ１における作成側Ｋ１からのライングループ９０３＿１を格納するようにとの要求を処理するとともに、ライングループ９０３＿１に対する消費側カーネルＫ２およびＫ３からの要求を処理する。前者に応答して、ラインバッファインタフェースユニット９０４＿１はライングループ９０３＿１をメモリ９０２に書き込む。後者に応答して、ラインバッファインタフェースユニット９０４＿１は、メモリ９０２からのライングループ９０３＿１のそれぞれの読出を実行し、ライングループ９０３＿１を消費側Ｋ２およびＫ３に時刻Ｃ２１およびＣ３１でそれぞれ転送する。

ライングループのすべての消費側がそれらのライングループのコピーを転送された後、ラインバッファインタフェースユニットは別のライングループに割り当てられるよう「フリー」になる。例えば、ライングループ９０３＿１がフレームのシーケンスの第１の画像フレーム内で第１のライングループを表す場合、ライングループ９０３＿１が時間Ｃ２１およびＣ３１で消費側Ｋ２およびＫ３に転送された後、ラインバッファインタフェースユニット９０４＿１が、次に、フレームのシーケンスの、次の第２の画像フレーム内で第１のライングループを処理するように割り当てられてもよい。このようにして、ラインバッファユニット回路系９０１はラインバッファインタフェースユニット９０４の「プール」を有すると見ることができ、直前のライングループが最後の消費側に供給された後に管理すべき新たなライングループが各インタフェースユニットに割り当てられる。したがって、最後の消費側にサービスを提供し、そして次のライングループを待つラインバッファインタフェースユニットの「フリープール」にインタフェースユニット繰り返し入り、およびそれから取除かれるときに、インタフェースユニットのローテーションがある。

図９ｃは、ローテーションの実施形態をより詳細に示す。図９ｃに示すように、利用可能なラインバッファインタフェースユニットは、ラインバッファユニット回路系内においてラインバッファインタフェースユニットのフリープールから選択される（９１０）。次いで、ラインバッファインタフェースユニットは、次いで、適切な構成情報（例えば、新たなライングループのＸ、Ｙ位置情報または線形メモリアドレス等価物）を用いて構成される（９１１）。ここで、図９ｂにおいて、各ラインバッファインタフェースユニットは、そのような構成情報が保持される構成レジスタ空間９０５を含むことができることに留意されたい。

次いで、ラインバッファインタフェースユニットは、その新たに割り当てられたライングループについて作成側および消費側の要求を処理することに進む（９１２）。最後の作成側がライングループに書き込んだ後（様々な実施形態では、ライングループごとにただ１つの作成側が存在する）、最後の消費側にその作成側によって書き込まれたライングループのバージョンが提供された後、ラインバッファインタフェースユニットはフリープールに戻され、プロセスは次のライングループのために９１０を繰り返す。図９ｃの制御フローを監督するラインバッファユニット回路９０１内の制御論理回路系は、例示の便宜のために図９ｂには示されていない。

ｂ．プログラマブルなレジスタ空間の実施形態
次のライングループの割り当ての一部としてラインバッファインタフェースユニットに提供される更新された構成情報９１１に関して、公称の場合、ラインバッファユニット９００それ自体は、例えば、１つ以上の消費側からなる固定されたセットに供給しているわずか１つの固定された作成側の静的な構成を処理している。この場合、主要な構成情報（例えば、ライングループサイズ、消費側の数など）も静的でありがちであり、ライングループからライングループに変化しない。むしろ、ラインバッファインタフェースユニットに提供される新たな構成情報は、主に新たなライングループ（例えば、メモリ内のライングループの位置など）を識別する。しかしながら、より複雑な潜在的な構成／設計も可能である。これらのうちのいくつかは、この後より詳細に説明される。

図９ｄは、ラインバッファインタフェースユニットのレジスタ空間の内容（例えば、図９ｂのレジスタ空間９０５＿１の内容）の実施形態を示す。いくつかのレジスタフィールドの説明がすぐ後に続く。

ＬＢ＿Ｅｎａｂｌｅフィールド９２１は、本質的にラインバッファインタフェースユニットをイネーブルにし、ラインバッファインタフェースユニットをフリープールから取得するプロセスの一部として「設定」される。Ｎｕｍ＿Ｃｈａｎｎｅｌｓフィールド９２２は、ライングループの画像データ内のチャネル数を定義する。一実施形態では、Ｎｕｍ＿Ｃｈａｎｎｅｌｓフィールド９２２を使用して、ライングループごとのデータの総量を決定することができる。例えば、ビデオストリームは、しばしば、赤（Ｒ）ピクセルのフレームシーケンス、青（Ｂ）ピクセルのフレームシーケンス、および緑（Ｇ）ピクセルのフレームシーケンスを含む。したがって、どのライングループでも、実際には３つのライングループ分の情報（Ｒ、Ｇ、Ｂ）がある。

Ｎｕｍ＿Ｃｏｎｓｕｍｅｒｓフィールド９２３は、ライングループを要求する消費側の数を記述する。一実施形態では、ライングループインスタンスが、Ｎｕｍ＿Ｃｏｎｓｕｍｅｒｓフィールド９２３の値に等しい回数だけ送られた後、ラインバッファインタフェースユニットはフリープールに入れられる。

Ｒｏｗ＿Ｗｉｄｔｈフィールド９２４は、ある完全なライングループの幅を（例えばピクセル数で）定義する。Ｒｏｗ＿Ｗｉｄｔｈ９２４の値は、コンパイラによって提供されるＸ座標値として表すことができることに留意されたい。ＦＢ＿Ｒｏｗｓフィールド９２６は、ある完全なライングループの高さを（例えばピクセル数で）定義する。ＦＢ＿Ｒｏｗｓフィールド９２４は、コンパイラによって提供されるＹ座標値として表すことができることに留意されたい。

ＦＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓフィールド９３０は、ラインバッファユニットメモリにおいてライングループの位置を定義する。「完全」ライングループモードと呼ばれる第１の動作モードでは、ある完全なサイズのライングループがメモリ内でアクセスされる（
ライングループは作成側から受け取られ、消費側にそれらのそれぞれのデータの全量を含むとして送られる）。完全ライングループモードでは、Ｎｕｍ＿Ｃｈａｎｎｅｌｓフィールド９２２、Ｒｏｗ＿Ｗｉｄｔｈフィールド９２４およびＦＢ＿Ｒｏｗｓフィールド９２６をＦＢ＿Ａｄｄｒｅｓｓフィールド９３０とともに使用して、ある完全なライングループに完全にアクセスするためにメモリに適用されるアドレスの範囲を決定することができる。さらに、これらの同じパラメータを使用して、Ｘ、Ｙ座標でライングループを要求したシート生成部からの要求を線形メモリアドレスに「変換」することができる。

ＶＢ＿Ｅｎａｂｌｅ、ＶＢ＿Ｒｏｗｓ、ＶＢ＿Ｃｏｌｓ、Ｎｕｍ＿Ｒｅｕｓｅ＿ＲｏｗｓおよびＶＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓフィールド９２５，９２７，９２８，９３１は、「仮想的に高い」ライングループモードと呼ばれる別の動作モードで使用され、これについては後で詳しく説明する。

図９ｄは単一のラインバッファインタフェースユニットに対する構成レジスタ空間９０５を表示したが、図９ｅは全体としてラインバッファユニット回路系９０１のためのグローバル構成レジスタ空間９０７の内容の実施形態を示す。図９ｄのラインバッファインタフェースユニットレジスタ空間は、特定のライングループに焦点を当てているのに対して、図９ｅのグローバルレジスタ空間９０７は、同じ画像からの異なるライングループの解析、および画像の処理に関連する作成側／消費側の組み合わせに固有の他の情報の理解に焦点を当てている。

図９ｅにおいて見られるように、グローバルレジスタ空間の実施形態は、特定の画像に対するチャネルの数９３２および消費側の数９３３を含む。簡単にするために、図９ｅのレジスタ空間は、１組の作成側および消費側（例えば、ＤＡＧにおける単一のビデオストリームおよび単一の点のみ）を伴う１つの画像のみを考えている。おそらく、図９ｅのレジスタ空間の複数のインスタンスを割り当てて、ラインバッファユニット回路系が効果的にマルチタスクを行えるようにすることが考えられる。

マルチタスク化の第１の形態は、画像プロセッサに実装されるＤＡＧまたはソフトウェアパイプライン内にある。ここでは、同じラインバッファユニットを、ＤＡＧ内の２つの異なるノードについての、またはパイプラインの２つの異なるステージについてのライングループ化を処理するように構成することができる（すなわち、１つのラインバッファユニットが複数のステンシルプロセッサをサポートすることができる）。異なるノード／ステージは、異なる数の消費側を容易に有し得るが、多くの場合、同じ画像およびステンシルサイズ特性を有する可能性が高い。マルチタスク化の第２の形態は、同一の画像プロセッサハードウェア上に実装される複数の異なるＤＡＧおよび／または複数の異なるパイプラインにわたる。例えば、４つのステンシルプロセッサを有する画像プロセッサは、完全に異なるステンシル寸法を伴う完全に異なる画像サイズをそれぞれ処理する２つの完全に異なる２ステージパイプラインを同時に実行し得る。

図９ｅの特定の実施形態に戻ると、ＤＡＧ内またはパイプラインステージ間の任意の特定のノードは、画像内のチャネル数、画像サイズ、適用可能なステンシルの寸法およびライングループの消費側の数によって、ハイレベルに特徴付けることができることに留意されたい（図９ｅは再びライングループ当たり１つの作成側を仮定するが、おそらくは２つ以上の作成側が１つのライングループに書き込むことができ、その場合には図９ｅのグローバルレジスタ空間は作成側の数に対するフィールドも含むであろう）。Ｎｕｍ＿ＣｈａｎｎｅｌｓおよびＮｕｍ＿Ｃｏｎｓｕｍｅｒｓフィールド９３２，９３３は、図９ｃの対応するフィールド９２２，９２３と本質的に同じである。

Ｉｍａｇｅ＿ＳｉｚｅおよびＳｔｅｎｃｉｌ＿Ｄｉｍｅｎｓｉｏｎフィールド９３４，
９３５は、本質的に、処理される画像の寸法と、画像からそれぞれ分割されるべきライングループに対して動作するステンシルの寸法を記述する。両方のフィールド９３４，９３５は、Ｘ、Ｙ座標値によって表現することができ、コンパイラから提供することができることに留意されたい。さらに、一実施形態では、ラインバッファ回路系ユニット（図９ｂには図示せず）内の制御論理回路は、Ｉｍａｇｅ＿ＳｉｚｅおよびＳｔｅｎｃｉｌ＿Ｄｉｍｅｎｓｉｏｎフィールド９３４，９３５を使用して、ラインバッファインタフェースユニットが、グローバル情報が関係する作成側／消費側の組からのライングループを処理するように割り当てられているときに、バッファインタフェースユニットのレジスタ空間にロードされるラインにロードされるＲｏｗ＿Ｗｉｄｔｈ９２４、ＦＢ＿Ｒｏｗｓ９２６およびＦＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓ値９３０を決定する。代替的またはさらなる実施形態では、画像サイズは２つの別個の値、ｉｍａｇｅ＿ｗｉｄｔｈおよびｉｍａｇｅ＿ｈｅｉｇｈｔとして表され、それらはそれらの別個にアドレス指定可能なレジスタ空間を有してもよい。同様に、ステンシルサイズは、２つの別個の値、ｓｔｅｎｃｉｌ＿ｗｉｄｔｈおよびｓｔｅｎｃｉｌ＿ｈｅｉｇｈｔとして表現されてもよく、それらはそれらの別個にアドレス指定可能なレジスタ空間を有してもよい。

Ｒｏｗ＿Ｗｉｄｔｈ９２４は、Ｉｍａｇｅ＿Ｓｉｚｅ９３４情報から直接取得可能である。例えば、Ｉｍａｇｅ＿Ｓｉｚｅが画像原点から最も遠いピクセル（原点が左下隅にある場合は右上角）のＸ、Ｙ座標の対として表される場合、Ｒｏｗ＿ＷｉｄｔｈはＸ座標値として決定できる。

ＦＢ＿ＲｏｗｓおよびＦＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓフィールド９２６，９３０は、Ｉｍａｇｅ＿ＳｉｚｅおよびＳｔｅｎｃｉｌ＿Ｄｉｍｅｎｓｉｏｎフィールド９３４，９３５から決定することができる。ここで、具体的には、画像の高さ（Ｉｍａｇｅ＿Ｓｉｚｅ９３４のＹ座標値）およびステンシルの高さ（Ｓｔｅｎｃｉｌ＿Ｄｉｍｅｎｓｉｏｎ９３５のＹ座標値）から、各ライングループの高さ（ＦＢ＿Ｒｏｗｓ９２６）を算出することができる。ライングループの高さが分かれば、画像から解析されるライングループの数およびメモリ内における各そのようなライングループに対する開始線形アドレス（ＦＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓ９３０）も決定することができる。

したがって、一実施形態では、グローバルレジスタ空間が図９ｅのレジスタフィールドによって特徴付けられる特定の作成側／消費側の組み合わせに対してライングループを処理するためにラインバッファユニットが割り当てられると、上述の決定はオンザフライで計算され、ＦＢ＿Ｗｉｄｔｈ９２４、ＦＢ＿Ｒｏｗｓ９２６、Ｂａｓｅ＿Ａｄｄｒｅｓｓ９３４の各々は、ラインバッファインタフェースユニットの特定のレジスタ空間に、直接的にコピーするＮｕｍ＿Ｃｈａｎｎｅｌｓ９２２およびＮｕｍ＿Ｃｏｎｓｕｍｅｒｓ９２３と共にロードされる。従って、論理回路系およびデータ経路は、グローバルレジスタ空間とラインバッファインタフェースユニットレジスタ空間の各インスタンスとの間に存在して、これらの決定およびデータ転送を実行してもよい。

代替の実施形態では、コンパイラは、これらの計算の各々を実行し、それにより、グローバルレジスタ空間の全てではないにしても大部分を排除する。ここで、例えば、コンパイラは、各ライングループについてＢａｓｅ＿Ａｄｄｒｅｓｓ値を決定し、それらの値をラインバッファ回路系ユニット内のルックアップテーブルにロードすることができる。値は、それらの対応するライングループが構成されると、ルックアップテーブルから呼び出され、ラインバッファインタフェースユニットのレジスタ空間にロードされる。これら２つの極端なもの（ハードウェアオンザフライ対決定される静的なコンパイラ）の間の異なる組合せも実装することができる。

上記の実施形態は、レジスタ回路系（「レジスタ空間」）における構成情報の保持を強
調したが、他のまたは組み合わせられた実施形態では、構成情報をメモリ（バッファユニットメモリなど）または他のメモリもしくは情報保持回路系に保持することができる。

ｃ．ラインバッファユニットの実施形態および完全ライングループモード対実質的に高いモード
上記の議論は、大部分は、「完全ライングループ」モードに主に向けられ、そこにおいては、ライングループは、完全な全ライングループとして言及され、シート生成部とラインバッファユニットとの間で渡される。「仮想的に高い」と呼ばれる別のモードでは、ライングループは、分離した個別のセグメントで完成される全幅の上側部分および下側部分として言及され、シート生成部間で渡される。

図１０ａおよび図１０ｂは、例示的な仮想的に高いモードシーケンスの図を示す。図１０ａにおいて見られるように、ライングループは、最初は、全幅の行の上側部分１００３および第１のより短い幅のセグメントのみを有する第１の下側部分１００４＿１として形成される。ライングループの最初の形成物は、作成側シート生成部によってラインバッファユニットに提供されてもよく、またはラインバッファユニットによって消費側シート生成部に提供されてもよい。

作成側の場合、ライングループは、ステンシル１００２が下側部分１００４＿１を処理した後に形成される（おおよそのステンシル配置が図１０ｂに見られる）。作成側ステンシルプロセッサが下側部分１００４＿１を処理した後、ステンシルは前方に水平に右に進む。最終的に、それらは次の下側部分１００４＿２を処理する。次の下側部分１００４＿２が完了すると、次の下側部分１００４＿２がシート生成部からラインバッファユニットに送られ、メモリ内において正しい位置、例えば第１の下側部分１００４＿１の「隣」に格納される。ライングループがラインバッファユニットメモリに完全に書き込まれるまで、プロセスは継続される。

消費側の場合、ライングループは、図１０ａに示すように、まずシート生成部に送られる。ステンシルプロセッサは、ライングループの第１の部分１００４＿１に対して動作する。第１の部分１００４＿１の処理の完了に近づくと、シート生成部は、次の下側部分１００４＿２を要求し、それはメモリからフェッチされ、ラインバッファユニットによって送られる。このプロセスは、ライングループが完全に処理されるまで続く。

作成側および消費側の両方にとって、下側部分はシート生成部によって具体的に識別されることに注目されたい。すなわち、作成側の場合および消費側の場合の両方において、下側部分１００４＿２はシート生成部によって具体的に識別され、ラインバッファユニットは具体的にメモリにアクセスして下側部分１００４＿２を格納／フェッチする。実施形態では、シート生成部は、コンパイラによって提供される情報に基づいて企図されるＸ、Ｙ座標値を介して下側部分１００４＿２を識別する（例えば、下側部分１００４＿２の任意の角、下側部分１００４＿２のすべての４つの角、Ｘ座標値だけなど）。

図１１ａは、ラインバッファインタフェースユニット１１０４内の回路系の第１の（より単純な）実施形態を示す。図１１ａにおいて見られるように、ラインバッファインタフェースユニットは、アドレス変換回路系１１０６を含み、１つ以上のＸ、Ｙ座標値によって識別されるライングループまたはその一部（図１０ｂの下側部分１００４＿２など）のアイデンティティをラインバッファユニットメモリにアクセスするための線形アドレスに変換する。つまり、ライングループは、ラインバッファユニットメモリに「マッピング」されるとみなすことができる。変換回路系１１０６は、Ｘ、Ｙ項でこのマッピングを本質的に理解し、それを特定の線形メモリアドレスに変換することができる。

マッピングを理解する能力は、構成レジスタ空間１１０５内の情報に基づいており、その実施形態は上記において図９ｄに示してある。ここで、Ｒｏｗ＿Ｗｉｄｔｈ９２４、ＦＢ＿Ｒｏｗｓ９２６およびＦＢ＿Ｂａｓｅ＿Ａｄｄｒｅｓｓ９３１の知識により、変換ユニットはメモリにおける完全なライングループのサイズおよび位置を「理解」することができる。したがって、例えば、仮想的に高いモードでは、任意のＸ座標値（例えば、下側部分がライングループに対して参照される場合）またはＸ、Ｙ座標位置（例えば、下側部分が画像フレームに対して参照される場合）に基づく下側部分に対する要求は、どの部分がシート生成部によって指されているかを識別するのに十分である。さらに、Ｖｂ＿Ｒｏｗｓ９２７およびＶｂ＿Ｃｏｌｓ９２８は、本質的に下側部分の寸法を定義する。上側部分および下側部分の寸法を知ることにより、バッファメモリとの間でアクセスされるデータ量も容易に決定可能である。これらの同じ概念は、全幅のライングループにも適用され得る。例えば、任意の全幅のライングループは、画像内において、そのＸ、Ｙ位置によって識別することができる。さらに、いくつかの実施形態では、全幅のライングループは、Ｘおよび／またはＹ座標値によって全幅のライングループのより小さい塊を参照する原子要求／応答のシーケンスを介してネットワークを通過させることができる。

また、変換回路系１１０６は、抽象アドレス指定モードで使用することもでき、このモードでは、Ｂａｓｅ＿Ａｄｄｒｅｓｓ＿Ｆｉｅｌｄ９３１は事前設定されておらず、シート生成部はライングループを画像フレーム内においてＸ、Ｙ座標として指す。この場合、変換回路系１００６が、図９ｅのグローバルレジスタ空間の情報の一部（例えばＩｍａｇｅ＿Ｓｉｚｅ、Ｓｔｅｎｃｉｌ＿Ｓｉｚｅ）に結合されているか、または他の方法でそれを通知される場合、変換回路系１１０６は、ライングループに関するすべての関連情報（フレーム内のそれの寸法および位置）を計算し、それを、ラインバッファユニットメモリにアクセスするために使用される線形アドレスに変換し得る。別の実施形態では、変換回路系１１０６は、（グローバルタイプ情報およびライングループを記述する１つ以上のＸ、Ｙ座標に基づいて）Ｂａｓｅ＿Ａｄｄｒｅｓｓ＿Ｆｉｅｌｄ値９３１を完全に決定し、それをそれ自身のレジスタ空間１１０５にロードする。

図１１ａのラインバッファインタフェースユニットの実施形態は、Ｘ、Ｙ座標値がライングループを指すために使用されない（むしろ従来の線形アドレスが使用される）線形アドレス指定モードもサポートする。線形アドレス指定モードの場合、バイパス経路１１４０はアドレス変換回路系１１０６を迂回する。一実施形態では、ラインバッファインタフェースユニット入力においてどのアドレス指定モードが使用されるかにかかわらず、ラインバッファインタフェースユニットは、ラインバッファユニットメモリをアドレス指定するための標準的な線形メモリアドレスを提供する。簡単に図９ｂに戻って参照すると、線形アドレスはアービタに与えられる。メモリインタフェース９０８は、衝突するメモリアクセス要求を解決し、ラインバッファユニットメモリ９０２にアクセスする。

上述したように、シート生成部は、１つ以上のＸ、Ｙ座標値でライングループを指すことができる。別の実施形態では、シート生成部は、完全ライングループモードにおいて次のライングループを、または実質的に高いモードにおいて次の下側部分を識別するのではなく、単に「次」に類似した要求を発行するだけである（例えば、要求は、単に、同じ完全な／仮想的に高いライングループ内の「次の」完全なライングループまたは「次の」下側部分または「次の」画像データが座標なしで指されていることを示す）。

この通信路をサポートするために、ラインバッファユニットおよび／またはラインバッファユニットインタフェースは、次のライングループ／部分が何であるかを理解するよう状態レジスタ空間を含む。図１１ｂは、シート生成部が、単に、ライングループの「次の」下側部分を、仮想的に高いモードで、その位置をＸ、Ｙ座標で指定する必要なく指すことができるようにポインタ状態情報を保持するラインバッファインタフェースユニットの
強化された実施形態を示す。ここでは、書込ポインタ１１４１が、作成側シート生成部によって提供された下側部分を追跡するポインタ制御論理回路系１１４３によって維持される。本質的に、書込ポインタ１１４１は、作成側が送る予定の「次の」部分の位置を記憶する。さらに、ポインタ状態情報はシート生成部がＸ、Ｙ座標を指定することなく（全幅モードで）「次の」全幅のライングループのみを指すことを可能にする（なぜなら、ラインバッファインタフェースユニットは画像についての次の全幅のライングループがどこにあるかを決定することができるからである）。

一実施形態では、ポインタは、１つ以上のＸ、Ｙ座標として明示され、変換回路系は、それを線形アドレスに変換する。次の部分が受け取られると、ポインタ１１４１はポインタ制御論理回路系１１４３によって更新され、受け取られたばかりの部分に続く部分を指し示す。読出ポインタ１１４２は同様に動作するが、別の読出ポインタが各消費側に対して保持される（便宜上、再び１つの作成側のみが仮定される）。

完全ライングループモードの場合、「次の」全幅のライングループの位置は、グローバルレジスタ情報およびグローバルレベルで保持されるポインタの同様の構成から決定可能である。

ｄ．実現例の実施形態
上述した様々な画像プロセッサアーキテクチャの特徴は、必ずしも従来の意味での画像処理に限定されず、したがって、画像プロセッサを再特徴付けしてもよい（またはしなくてもよい）他のアプリケーションに適用することができることを指摘することが適切である。例えば、実際のカメラ画像の処理とは対照的に、アニメーションの作成および／または生成および／またはレンダリングにおいて上述した様々な画像プロセッサアーキテクチャの特徴のいずれかが使用される場合、画像プロセッサはグラフィックス処理ユニットとして徳経づけられてもよい。さらに、上述した画像プロセッサアーキテクチャの特徴は、ビデオ処理、視覚処理、画像認識および／または機械学習などの他の技術的用途にも適用することができる。このように適用されて、画像プロセッサは、より汎用的なプロセッサ（例えば、コンピューティングシステムのＣＰＵの一部であるか、またはその一部である）と（例えばコプロセッサとして）一体化されてもよく、またはコンピューティングシステム内のスタンドアロンプロセッサであってもよい。

上述したハードウェア設計の実施形態は、半導体チップ内において、および／または最終的に半導体製造プロセスに向けての回路設計の記述として実施することができる。後者の場合、そのような回路記述は、より高い／挙動レベルの回路記述（例えばＶＨＤＬ記述）もしくはより低いレベルの回路記述（例えばレジスタ転送レベル（ＲＴＬ）記述、トランジスタレベル記述もしくはマスク記述）またはそれらの様々な組み合わせの形態をとってもよい。回路記述は、典型的には、コンピュータ可読記憶媒体（例えばＣＤ−ＲＯＭまたは他のタイプの記憶技術）上に実施される。

先のセクションから、上記の画像プロセッサは、（例えば、ハンドヘルド装置のカメラからのデータを処理するハンドヘルド装置のシステムオンチップ（ＳＯＣ）の一部として）コンピュータシステム上のハードウェアで実施できることを認識することに関係する。画像プロセッサがハードウェア回路として実施される場合、画像プロセッサによって処理される画像データはカメラから直接受信されてもよいことに留意されたい。ここで、画像プロセッサは、別体のカメラの一部であってもよいし、一体化されたカメラを有するコンピューティングシステムの一部であってもよい。後者の場合、画像データは、カメラから直接、またはコンピューティングシステムのシステムメモリから受信することができる（例えば、カメラは、その画像データを画像プロセッサではなくシステムメモリに送信する）。先のセクションで説明した機能の多くは、（アニメーションをレンダリングする）グ
ラフィックスプロセッサユニットにも適用可能であることにも留意されたい。

図１２は、コンピューティングシステムの例示的な図である。以下に説明するコンピューティングシステムのコンポーネントの多くは、一体化されたカメラおよび関連する画像プロセッサ（例えば、スマートフォンまたはタブレットコンピュータなどのハンドヘルドデバイス）を有するコンピューティングシステムに適用可能である。当業者は、２つの間の範囲を容易に定めることができるであろう。

図１２に見られるように、基本的なコンピューティングシステムは、中央処理ユニット１２０１（例えば、マルチコアプロセッサまたはアプリケーションプロセッサ上に配置された複数の汎用処理コア１２１５＿１〜１２１５＿Ｎおよびメインメモリコントローラ１２１７を含み得る）、システムメモリ１２０２、ディスプレイ１２０３（例えばタッチスクリーン、フラットパネル）、ローカル有線ポイントツーポイントリンク（例えばＵＳＢ）インタフェース１２０４、様々なネットワークＩ／Ｏ機能１２０５（イーサネット（登録商標）インタフェースおよび／またはセルラーモデムサブシステムなど）、無線ローカルエリアネットワーク（例えばＷｉＦｉ）インタフェース１２０６、ワイヤレスポイントツーポイントリンク（例えばブルートゥース（登録商標））インタフェース１２０７およびグローバルポジショニングシステムインタフェース１２０８、様々なセンサ１２０９＿１〜１２０９＿Ｎ、１つ以上のカメラ１２１０、バッテリ１２１１、電力管理制御ユニット１２１２、スピーカおよびマイクロホン１２１３、ならびに音声コーダ／デコーダ１２１４を含んでもよい。

アプリケーションプロセッサまたはマルチコアプロセッサ１２５０は、そのＣＰＵ１２０１内における１つ以上の汎用処理コア１２１５、１つ以上のグラフィカル処理ユニット１２１６、メモリ管理機能１２１７（例えばメモリコントローラ）、Ｉ／Ｏ制御機能１２１８および画像処理ユニット１２１９を含んでもよい。汎用処理コア１２１５は、典型的には、コンピューティングシステムのオペレーティングシステムおよびアプリケーションソフトウェアを実行する。グラフィックス処理ユニット１２１６は、典型的には、ディスプレイ１２０３上に提示されるグラフィックス情報を生成するために、グラフィックス集中型機能を実行する。メモリ制御機能１２１７は、システムメモリ１２０２とインタフェースして、システムメモリ１２０２との間でデータの書込／読出を行う。電力管理制御ユニット１２１２は、システム１２００の電力消費を全体的に制御する。

画像処理ユニット１２１９は、先のセクションで説明した画像処理ユニットの実施形態のいずれかに従って実現することができる。代替的にまたは組み合わせて、ＩＰＵ１２１９は、ＧＰＵ１２１６およびＣＰＵ１２０１のいずれかまたは両方にそのコプロセッサとして結合されてもよい。さらに、様々な実施形態では、ＧＰＵ１２１６は、上で説明した画像プロセッサの特徴のいずれかを用いて実現することができる。

タッチスクリーンディスプレイ１２０３、通信インタフェース１２０４〜１２０７、ＧＰＳインタフェース１２０８、センサ１２０９、カメラ１２１０、およびスピーカ／マイクコーデック１２１３，１２１４の各々はすべて、適切な場合には、一体化された周辺装置（例えば１つ以上のカメラ１２１０）も含むコンピューティングシステム全体に対して様々な形態のＩ／Ｏ（入力および／または出力）として見ることができる。実現例によっては、これらのＩ／Ｏコンポーネントの様々なものは、アプリケーションプロセッサ／マルチコアプロセッサ１２５０上に統合されてもよく、またはアプリケーションプロセッサ／マルチコアプロセッサ１２５０のダイから離れて、またはそのパッケージ外に配置されてもよい。

一実施形態では、１つ以上のカメラ１２１０は、カメラとその視野内の対象との間の深
度を測定することができる深度カメラを含む。アプリケーションプロセッサまたは他のプロセッサの汎用ＣＰＵコア（もしくはプログラムコードを実行するために命令実行パイプラインを有する他の機能ブロック）上で実行されるアプリケーションソフトウェア、オペレーティングシステムソフトウェア、デバイスドライバソフトウェアおよび／またはファームウェアは、上記の機能のいずれかを実行してもよい。

本発明の実施形態は、上述したような様々なプロセスを含むことができる。これらのプロセスは、機械実行可能命令で実施されてもよい。これらの命令は、汎用または特殊目的のプロセッサに特定のプロセスを実行させるために使用できる。代替的に、これらのプロセスは、プロセスを実行するためのハードワイヤード論理を含む特定のハードウェアコンポーネントによって、またはプログラミングされたコンピュータコンポーネントとカスタムハードウェアコンポーネントとの任意の組み合わせによって実行されてもよい。

本発明の要素はまた、機械実行可能命令を記憶するための機械可読媒体として提供されてもよい。機械可読媒体は、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスク、フラッシュメモリ、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、伝搬媒体、または電子命令を記憶するのに適した他のタイプの媒体／機械可読媒体を含むが、それらに限定はされない。例えば、本発明は、搬送波または通信リンク（例えばモデムもしくはネットワーク接続）を介する他の伝搬媒体で実施されたデータ信号によって、遠隔のコンピュータ（例えばサーバ）から要求側コンピュータ（例えばクライアント）に転送され得るコンピュータプログラムとしてダウンロードすることができる。

前述の明細書では、本発明をその特定の例示的な実施形態を参照して説明した。しかしながら、特許請求の範囲に記載される本発明のより広い精神および範囲から逸脱することなく、様々な修正および変更がなされ得ることは明らかであろう。したがって、明細書および図面は、限定的ではなく例示的なものとみなされるべきである。

Claims (16)

1. デバイスであって、
   複数のラインバッファインタフェースユニットと、
   複数のライングループに分割された画像データを格納するよう構成されたメモリユニットとを備え、
   前記デバイスは、前記複数のライングループのそれぞれのライングループに対する読出および書込要求を管理するよう、各ラインバッファインタフェースユニットを割当てるように構成され、
   各ラインバッファインタフェースユニットは、作成側コンポーネントから書込要求を受信し、前記書込要求に対応する前記メモリユニット内の書込位置を特定し、前記書込要求に従って前記メモリユニット内の前記書込位置にデータを格納するように構成され、
   各ラインバッファインタフェースユニットは、１つ以上の消費側コンポーネントから読出要求を受信し、前記読出要求に対応する前記メモリユニット内の読出位置を特定し、前記読出要求に従って前記メモリユニット内の前記読出位置に格納されたデータを提供するよう構成され、
   あるラインバッファインタフェースユニットが、特定のライングループについて１つ以上の消費側コンポーネントからのすべての未処理の読出要求を完了すると、前記デバイスは、異なるライングループに対する読出および書込要求を管理するよう、前記あるラインバッファインタフェースユニットを再割り当てするよう構成され、
   各ラインバッファインタフェースユニットは、前記各ラインバッファインタフェースユニットが割当てられるライングループのプロパティを表すデータを格納するように構成された専用のプログラマブルなユニット構成空間を有し、
   あるラインバッファインタフェースユニットが第１のライングループから第２のライングループに再割り当てされると、前記デバイスは、前記第２のライングループのプロパティを表すよう、前記あるラインバッファインタフェースユニットの前記プログラマブルなユニット構成空間内のデータを更新する、デバイス。
2. 前記プログラマブルなユニット構成空間内の前記データは、前記ラインバッファインタフェースユニットが同時にサービスすることができる最大数の消費側コンポーネント、前記ライングループの行幅、または前記ライングループの前記メモリユニットにおけるベース線形アドレスを表す、請求項１に記載のデバイス。
3. 前記デバイスは、画像データが前記メモリユニットに格納された画像の全体のサイズを表すデータを格納するように構成されたプログラマブルなグローバル構成空間を有する、請求項１または２に記載のデバイス。
4. 前記プログラマブルなグローバル構成空間は、複数のアクティブなラインバッファインタフェースユニットを表すデータを格納するように構成される、請求項３に記載のデバイス。
5. 前記デバイスは、前記プログラマブルなユニット構成空間内の１つ以上のデータ値を、前記デバイスのプログラマブルなグローバル構成空間内の１つ以上のデータ値から動的に計算するように構成される、請求項１に記載のデバイス。
6. 前記デバイスは、前記プログラマブルなグローバル構成空間の画像サイズおよびステンシル寸法要素から前記プログラマブルなユニット構成空間内の複数の完全なライングループの行またはライングループベースアドレスを計算するように構成される、請求項５に記載のデバイス。
7. 各ラインバッファインタフェースユニットは、値の対を前記メモリユニット内の線形アドレスに変換するように構成された変換回路系を有する、請求項１〜６のいずれか１項に記載のデバイス。
8. 各ラインバッファインタフェースユニットは、次の読出要求で提供されるべきライングループの現在または次のセグメントに対してポインタを維持するよう構成される、請求項１〜７のいずれか１項に記載のデバイス。
9. 複数のラインバッファインタフェースユニットと、複数のライングループに分割された画像データを格納するメモリユニットとを有するデバイスが、前記複数のライングループのそれぞれのライングループに対する読出および書込要求を管理するよう、各ラインバッファインタフェースユニットを割当てることと、
   前記複数のラインバッファインタフェースユニットのうちの特定のラインバッファインタフェースユニットが、前記デバイスの作成側コンポーネントから書込要求を受信することと、
   前記特定のラインバッファインタフェースユニットが、前記書込要求に対応する前記メモリユニット内の書込位置を特定することと、
   前記特定のラインバッファインタフェースユニットが、前記書込要求に従って前記メモリユニット内の前記書込位置にデータを格納することと、
   前記特定のラインバッファインタフェースユニットが、前記デバイスの１つ以上の消費側コンポーネントから読出要求を受信することと、
   前記特定のラインバッファインタフェースユニットが、前記読出要求に対応する前記メモリユニット内の読出位置を特定することと、
   前記特定のラインバッファインタフェースユニットが、前記読出要求に従って前記メモリユニット内の前記読出位置に格納されたデータを提供すること、
   あるラインバッファインタフェースユニットが特定のライングループに対する１つ以上の消費側コンポーネントからのすべての未処理の読出要求を完了した、という指示を前記デバイスが受信することと、
   これに応答して、前記デバイスが、異なるライングループに対する読出および書込要求を管理するよう、前記あるラインバッファインタフェースユニットを再割り当てすることとを備え、
   各ラインバッファインタフェースユニットは、前記各ラインバッファインタフェースユニットが割当てられるライングループのプロパティを表すデータを格納するように構成された専用のプログラマブルなユニット構成空間を有し、
   前記ラインバッファインタフェースユニットを再割り当てすることは、前記デバイスが、前記異なるライングループのプロパティを表すよう、前記ラインバッファインタフェースユニットの前記プログラマブルなユニット構成空間内のデータを更新することを含む、方法。
10. 前記プログラマブルなユニット構成空間内の前記データは、前記ラインバッファインタフェースユニットが同時にサービスすることができる最大数の消費側コンポーネント、前記ライングループの行幅、または前記ライングループの前記メモリユニットにおけるベース線形アドレスを表す、請求項９に記載の方法。
11. 前記デバイスは、画像データが前記メモリユニットに格納された画像の全体のサイズを表すデータを格納するように構成されたプログラマブルなグローバル構成空間を有する、請求項９または１０に記載の方法。
12. 前記プログラマブルなグローバル構成空間は、複数のアクティブなラインバッファインタフェースユニットを表すデータを格納するように構成される、請求項１１に記載の方法。
13. 前記デバイスが、前記プログラマブルなユニット構成空間内の１つ以上のデータ値を、前記デバイスのプログラマブルなグローバル構成空間内の１つ以上のデータ値から動的に計算することをさらに備える、請求項９に記載の方法。
14. 前記デバイスが、前記プログラマブルなグローバル構成空間の画像サイズおよびステンシル寸法要素から前記プログラマブルなユニット構成空間内の複数の完全なライングループの行またはライングループベースアドレスを計算することをさらに備える、請求項１３に記載の方法。
15. 各ラインバッファインタフェースユニットは変換回路系を有し、前記特定のラインバッファインタフェースユニットの変換回路系が、値の対を前記メモリユニット内の線形アドレスに変換することをさらに備える、請求項９〜１４のいずれか１項に記載の方法。
16. 前記特定のラインバッファインタフェースユニットが、次の読出要求で提供されるべきライングループの現在または次のセグメントに対してポインタを維持することをさらに備える、請求項９〜１５のいずれか１項に記載の方法。