JP6858239B2 - プログラムコードを、高性能で電力効率の良いプログラマブルな画像処理ハードウェアプラットフォームにマッピングするためのコンパイラ技法 - Google Patents

Description

関連事例
この出願は、２０１６年２月２６日に出願された米国仮出願第６２／３００，６８４号「プログラムコードを、高性能で電力効率の良いプログラマブルな画像処理ハードウェアプラットフォームにマッピングするためのコンパイラ技法 （“Compiler Techniques For
Mapping Program Code To A High Performance, Power Efficient, Programmable Image
Processing Hardware Platform”）」の利益を主張し、その全体をここに引用により援
用する。

発明の分野
本発明の分野は、一般に画像処理に関し、より詳細には、高性能で電力効率のよいプログラマブルな画像処理ハードウェアプラットフォームのようなプログラマブルな画像処理ハードウェアプラットフォームにプログラムコードをマッピングするためのコンパイラ技術に関する。

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

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

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

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

概要
ある方法が記載される。この方法は、それぞれの二次元実行レーンおよびシフトレジスタ回路構造からなるプログラマブルなステンシルプロセッサを有する画像プロセッサの対象とされるプログラムコードをコンパイルすることを備える。プログラムコードは、有向非循環グラフを実現し、ステンシルプロセッサのそれぞれで実行される複数のカーネルからなり、コンパイルすることは、画像プロセッサ内のステンシルプロセッサとは異なる数のカーネルがプログラムコード内に存在することを認識すること、カーネルのうちの少なくとも１つが、カーネルのうちの別のカーネルよりも演算負荷が高いことを認識すること、およびプログラムコードが画像プロセッサのメモリ容量を超えるリソース要件を有することを認識すること、のいずれかを含む。コンパイルすることは、さらに、上記認識することのいずれかに応答して、カーネルの水平融合、カーネルの垂直融合、カーネルの１つの、複数のカーネルへの分裂、カーネルの、複数の空間的に区分されたカーネルへの空間的区分、有向非循環グラフの、より小さなグラフへの分割、のいずれかを実行することを含む。

装置が記載される。この装置は、それぞれの二次元実行レーンおよびシフトレジスタ回路構造からなるプログラマブルなステンシルプロセッサを有する画像プロセッサの対象とされるプログラムコードをコンパイルするための手段を備える。プログラムコードは、有向非循環グラフを実現し、ステンシルプロセッサのそれぞれで実行される複数のカーネルからなり、コンパイルするための手段は、画像プロセッサ内のステンシルプロセッサとは異なる数のカーネルがプログラムコード内に存在することを認識すること、カーネルのうちの少なくとも１つが、カーネルのうちの別のカーネルよりも演算負荷が高いことを認識すること、およびプログラムコードが画像プロセッサのメモリ容量を超えるリソース要件を有することを認識すること、のいずれかのための手段を含む。コンパイルするための手段は、さらに、上記認識することのいずれかに応答して、カーネルの水平融合、カーネルの垂直融合、カーネルの１つの、複数のカーネルへの分裂、カーネルの、複数の空間的に区分されたカーネルへの空間的区分、有向非循環グラフの、より小さなグラフへの分割、のいずれかを実行するための手段を含む。

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

画像プロセッサハードウェアアーキテクチャの実施形態を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 ステンシルプロセッサの実施形態を示す。 ステンシルプロセッサの命令ワードの実施形態を示す図である。 ステンシルプロセッサ内のデータ計算ユニットの一実施形態を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 統合された実行レーンアレイおよび二次元シフトアレイのための単位セルの実施形態を示す図である。 画像処理プログラムコードを開発して実行する手順を示す図である。 画像プロセッサを構成するための手順に関する。 ラインバッファユニットの動作に関する。 ラインバッファユニットの動作に関する。 ＤＡＧプログラムフローに関する。 ＤＡＧプログラムフローに関する。 パイプラインプログラムフローに関する。 パイプラインプログラムフローに関する。 パイプラインプログラムフローに関する。 水平カーネル融合プロセスに関する。 水平カーネル融合プロセスに関する。 垂直カーネル融合プロセスに関する。 垂直カーネル融合プロセスに関する。 垂直カーネル融合プロセスに関する。 カーネル分裂プロセスに関する。 グラフィカル区分プロセスに関する。 ＤＡＧ／パイプライン分割プロセスに関する。 コンパイル方法を示す。 プログラムコード開発環境を示す。 例示的なコンピューティングシステムを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

以下でより詳細に説明するように、様々な実施形態では、実際には、任意のサイクルでシフト可能な二次元レジスタデータの複数の層が存在する。便宜上、本記載の多くは、「二次元シフトレジスタ」などの用語を、シフト可能な二次元レジスタデータの１つ以上のそのような層を有する構造を指すために単純に使用する。

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

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

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

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

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

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

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

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

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

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

図３ｂは、上述のＶＬＩＷ命令ワードの実施形態を要約したものである。図３ｂにおいて見られるように、ＶＬＩＷ命令ワードフォーマットは、３つの別個の命令、すなわち、１）スカラープロセッサによって実行されるスカラー命令３５１、２）実行レーンアレイ内でそれぞれのＡＬＵによってＳＩＭＤ方式でブロードキャストされ実行されるＡＬＵ命令３５２、および３）部分的ＳＩＭＤ方式でブロードキャストされ実行されるメモリ命令３５３に対するフィールドを含む（例えば、実行レーンアレイ内において同じ行に沿った実行レーンが同じランダムアクセスメモリを共有する場合、異なる行の各々からの１つの実行レーンが実際に命令を実行する（メモリ命令３５３のフォーマットは、各行からのどの実行レーンが命令を実行するかを識別するオペランドを含むことができる）。

１つ以上の即時オペランドに対するフィールド３５４も含まれる。命令３５１，３５２，３５３のどれが、どの即時オペランド情報を用いるかは命令フォーマットで識別されてもよい。命令３５１，３５２，３５３の各々は、また、それら自身のそれぞれの入力オペランドおよび結果情報（例えば、ＡＬＵ演算用のローカルレジスタならびにメモリアクセス命令用のローカルレジスタおよびメモリアドレス）を含む。一実施形態では、スカラー命令３５１は、実行レーンアレイ内の実行レーンが他の２つの命令３５２，３５３のいずれかを実行する前にスカラープロセッサによって実行される。すなわち、ＶＬＩＷワードの実行は、スカラー命令３５１が実行される第１のサイクルと、続いて他の命令３５２，３５３が実行されてもよい第２のサイクルとを含む。（様々な実施形態では、命令３５２，３５３は並列して実行されてもよい）。

一実施形態では、スカラープロセッサによって実行されるスカラー命令は、シートをデータ計算ユニットのメモリもしくは２Ｄシフトレジスタからロードまたはそれに格納するようシート生成部に発行されるコマンドを含む。ここで、シート生成部の動作は、ラインバッファユニットの動作またはスカラープロセッサによって発行されたコマンドをシート生成部が完了するのに要するサイクル数のプレランタイムの理解を妨げる他の変数に依存し得る。したがって、一実施形態では、スカラー命令３５１がシート生成部に発行されるべきコマンドに対応するか、さもなければコマンドをシート生成部に発行させるＶＬＩＷワードは、他の２つの命令フィールド３５２，３５３に無操作（ＮＯＯＰ）命令を含む。次に、プログラムコードは、シート生成部がデータ計算ユニットに対するそのロードまたはデータ計算ユニットからのその格納を完了するまで、命令フィールド３５２，３５３についてＮＯＯＰ命令のループに入る。ここで、シート生成部にコマンドを発行すると、スカラープロセッサは、シート生成部がコマンドの完了時にリセットするインターロックレジスタのビットをセットしてもよい。ＮＯＯＰループの間、スカラープロセッサはインタ
ーロックビットのビットを監視する。スカラープロセッサが、シート生成部がそのコマンドを完了したことを検出すると、通常の実行が再び開始される。

図４は、データ計算コンポーネント４０１の一実施形態を示す。図４において見られるように、データ計算コンポーネント４０１は、二次元シフトレジスタアレイ構造４０６「の上に」論理的に位置決めされる実行レーンのアレイ４０５を含む。上述したように、様々な実施形態では、シート生成部によって提供される画像データのシートが二次元シフトレジスタ４０６にロードされる。実行レーンは、レジスタ構造４０６からのシートデータに対して動作する。

実行レーンアレイ４０５およびシフトレジスタ構造４０６は、互いに対して適所に固定される。しかし、シフトレジスタアレイ４０６内のデータは、戦略的かつ調整された態様でシフトして、実行レーンアレイ内の各実行レーンがデータ内で異なるステンシルを処理するようにする。したがって、各実行レーンは、生成されている出力シートにおいて異なるピクセルに対する出力画像値を決定する。図４のアーキテクチャから、実行レーンアレイ４０５が垂直に近接する実行レーンおよび水平に近接する実行レーンを含むので、重なり合うステンシルが垂直に配置されるだけでなく水平にも配置されることは明らかである。

データ計算ユニット４０１のいくつかの注目すべきアーキテクチャ上の特徴には、実行レーンアレイ４０５よりも広い寸法を有するシフトレジスタ構造４０６が含まれる。すなわち、実行レーンアレイ４０５の外側にレジスタ４０９の「ハロー」が存在する。ハロー４０９は、実行レーンアレイの２つの側に存在するように示されているが、実現例に応じて、実行レーンアレイ４０５の２つ未満（１つ）またはそれ以上（３つまたは４つ）の側に存在してもよい。ハロー４０５は、データが実行レーン４０５の「下で」シフトしているときに、実行レーンアレイ４０５の境界の外側にこぼれ出るデータのための「スピルオーバ」空間を提供する働きをする。単純なケースとして、実行レーンアレイ４０５の右端を中心とする５×５のステンシルは、ステンシルの最も左側のピクセルが処理されるとき、さらに右側に４つのハローレジスタ位置を必要とすることになる。図面を簡単にするために、図４は、名目上の実施例において、どちらの側（右、底）のレジスタでも水平方向接続および垂直方向接続の両方を有するであろうとき、ハローの右側のレジスタを、水平方向シフト接続を有するだけとして、およびハローの底側のレジスタを、垂直方向シフト接続を有するだけとして示す。様々な実施形態では、ハロー領域は、画像処理命令を実行するための対応する実行レーン論理を含まない（例えば、ＡＬＵは存在しない）。しかしながら、個々のメモリアクセスユニット（Ｍ）が各ハロー領域位置に存在し、個々のハローレジスタ位置はメモリからデータを個別にロードし、データをメモリに格納できる。

アレイの各行および／もしくは各列またはその一部分に結合されるランダムアクセスメモリ４０７によって追加のスピルオーバールームが提供される（例えば、ランダムアクセスメモリは、４つの実行レーン行状と２つの実行レーン列状にまたがる実行レーンアレイの「領域」に割り当てられてもよい。簡略化のために、アプリケーションの残りの部分は、主に、行および／または列に基づく割り当てスキームを指す）。ここで、実行レーンのカーネル動作が、それが（一部の画像処理ルーチンが必要とする場合がある）二次元シフトレジスタアレイ４０６の外にあるピクセル値を処理することを必要とする場合、画像データの面は、ハロー領域４０９からランダムアクセスメモリ４０７にさらにこぼれ出ることができる。例えば、ハードウェアが実行レーンアレイの右端の実行レーンの右側にわずか４つの記憶素子のハロー領域を含む場合の６Ｘ６ステンシルを考える。この場合、ステンシルを完全に処理するために、データをハロー４０９の右端からさらに右側にシフトする必要があるであろう。ハロー領域４０９の外側にシフトされたデータは、ランダムアクセスメモリ４０７にこぼれ出る。ランダムアクセスメモリ４０７および図３のステンシル
プロセッサの他の適用例を以下でさらに説明する。

図５ａないし図５ｋは、上述のように実行レーンアレイ「の下で」二次元シフトレジスタアレイ内で画像データがシフトされる態様の実施例を示す。図５ａにおいて見られるように、二次元シフトアレイのデータ内容は第１のアレイ５０７に示され、実行レーンアレイはフレーム５０５によって示される。また、実行レーンアレイ内の２つの近隣の実行レーン５１０が簡略化して示されている。この簡単な図示５１０では、各実行レーンは、シフトレジスタからデータを受け付け、ＡＬＵ出力からデータを受け付け（例えば、サイクルにわたってアキュムレータとして動作する）、または出力データを出力先に書き込むことができるレジスタＲ１を含む。

各実行レーンはまた、ローカルレジスタＲ２において、二次元シフトアレイにおけるそれ「の下の」内容が利用可能である。したがって、Ｒ１は実行レーンの物理レジスタであり、Ｒ２は二次元シフトレジスタアレイの物理レジスタである。実行レーンは、Ｒ１および／またはＲ２によって提供されるオペランドに対して動作可能なＡＬＵを含む。さらに詳細に後述するように、一実施形態では、シフトレジスタは、実際にはアレイ位置ごとに複数の（ある「深さ」の）記憶／レジスタ素子で実現されるが、シフト動作は記憶素子の１つの面に限られる（例えば、記憶素子の１つの面のみがサイクルごとにシフトすることができる）。図５ａないし図５ｋは、それぞれの実行レーンから結果のＸを格納するために使用されるとしてこれらのより深いレジスタ位置の１つを示している。例示を容易にするために、より深い結果のレジスタは、その対応するレジスタＲ２の下ではなく、その横に図示されている。

図５ａ〜図５ｋは、実行レーンアレイ内に示された実行レーン位置５１１の対に中心位置が整列された２つのステンシルの計算に焦点を当てている。例示を容易にするために、実行レーン５１０の対は、実際には、以下の例によれば、それらが垂直方向の近隣実行レーンである場合に、水平方向の近隣実行レーンとして図示されている。

図５ａで最初に見られるように、実行レーンはそれらの中央のステンシル位置上に中心を配される。図５ｂは、両方の実行レーンによって実行されるオブジェクトコードを示す。図５ｂにおいて見られるように、両方の実行レーンのプログラムコードは、シフトレジスタアレイ内のデータを、１つの位置だけ下にシフトさせ、１つの位置だけ右にシフトさせる。これにより、両方の実行レーンがそれらのそれぞれのステンシルの左上隅に整列される。次に、プログラムコードは、（Ｒ２において）それらのそれぞれの位置にあるデータをＲ１にロードさせる。

図５ｃに示すように、次にプログラムコードは、実行レーンの対に、シフトレジスタアレイ内のデータを１単位だけ左にシフトさせ、各実行レーンのそれぞれの位置の右の値を各実行レーンの位置にシフトさせる。Ｒ１の値（以前の値）は、次いで、（Ｒ２における）実行レーンの位置にシフトした新しい値とともに加算される。結果はＲ１に書き込まれる。図５ｄで見られるように、図５ｃについて上述したのと同じプロセスが繰り返され、結果のＲ１に対して、今度は上側実行レーンにおける値Ａ＋Ｂ＋Ｃ、および下側実行レーンにおけるＦ＋Ｇ＋Ｈ値を含ませるようにする。この時点で、両方の実行レーンはそれらのそれぞれのステンシルの上側の行を処理している。（左側に存在する場合には）実行レーンアレイの左側でハロー領域に、またはハロー領域が存在しない場合にはランダムアクセスメモリにこぼれ出ることは、実行レーンアレイの左側には存在しないことに注目されたい。

図５ｅに示すように、次に、プログラムコードは、シフトレジスタアレイ内のデータを１単位だけ上にシフトさせ、両方の実行レーンをそれらのそれぞれのステンシルの中間行
の右端に整列される。両方の実行レーンのレジスタＲ１は、現在、ステンシルの最上行および中間行の一番右の値の合計を含む。図５ｆおよび図５ｇは、両方の実行レーンのステンシルの中間行にわたって左方向に移動する継続的な進行を示す。累積加算は、図５ｇの処理の終了時に、両方の実行レーンがそれらのそれぞれのステンシルの最上行の値と中間行の値との合計を含むように、継続する。

図５ｈは、各実行レーンをそれの対応するステンシルの最下行に整列させる別のシフトを示す。図５ｉおよび図５ｊは、両方の実行レーンのステンシルの過程にわたって処理を完了するための継続的なシフトを示す。図５ｋは、各実行レーンをデータアレイにおいてそれの正しい位置に整列させ、その結果をそこに書き込むための追加のシフトを示す。

図５ａ〜図５ｋの例では、シフト動作のためのオブジェクトコードは、（Ｘ、Ｙ）座標で表されるシフトの方向および大きさを識別する命令フォーマットを含むことができることに留意されたい。例えば、１つの位置分の上方向シフトのためのオブジェクトコードは、オブジェクトコードでＳＨＩＦＴ０，＋１として表現されてもよい。別の例として、１つの位置分の右方向へのシフトは、オブジェクトコードでＳＨＩＦＴ＋１，０として表現されてもよい。様々な実施形態では、より大きい大きさのシフトも、オブジェクトコードで指定することができる（例えば、シフト０，＋２）。ここで、２Ｄシフトレジスタハードウェアが１サイクルにつき１つの位置だけしかシフトをサポートしない場合、命令は機械によって複数のサイクル実行を要求するように解釈されてもよく、または２Ｄシフトレジスタハードウェアは、１サイクルにつき２つ以上の位置分シフトをサポートするように設計されてもよい。後者の実施形態はより詳細にさらに下に記載される。

図６は、アレイ実行レーンおよびシフトレジスタ構造の単位セルの別のより詳細な図を示す（ハロー領域のレジスタは、対応する実行レーンを含まない）。実行レーンおよび実行レーンアレイの各位置に関連するレジスタ空間は、一実施形態では、実行レーンアレイの各ノードで、図６に示す回路系をインスタンス化することによって実施される。図６に示すように、単位セルは、４つのレジスタＲ２〜Ｒ５からなるレジスタファイル６０２に結合される実行レーン６０１を含む。任意のサイクルの間、実行レーン６０１は、レジスタＲ１〜Ｒ５のいずれかから読み書きすることができる。２つの入力オペランドを必要とする命令の場合、実行レーンはＲ１〜Ｒ５のいずれかからオペランドの両方を取り出すことができる。

一実施形態では、二次元シフトレジスタ構造は、近隣のレジスタファイル間のシフトが同じ方向にあるように（例えば、すべての実行レーンは左にシフトする、すべての実行レーンは右にシフトするなど）、それの近隣のレジスタファイルが入力マルチプレクサ６０４を介する場合に、単一のサイクルの間に、レジスタＲ２〜Ｒ４のいずれか（ただ）１つの内容が、出力マルチプレクサ６０３を介してその近隣のレジスタファイルの１つにシフト「アウト」され、対応するものからシフト「イン」される内容でレジスタＲ２〜Ｒ４のいずれか（ただ）１つの内容が置き換えられることによって、実現される。同じレジスタがその内容がシフトアウトされて同じサイクルでシフトインされる内容で置き換えられるのが一般的であるかもしれないが、マルチプレクサ構成６０３，６０４は、同じサイクル中に同じレジスタファイル内で異なるシフトソースおよびシフトターゲットレジスタを可能にする。

図６に示すように、シフトシーケンスの間、実行レーンは、内容をそのレジスタファイル６０２からその左、右、上および下の近隣のレジスタファイルにシフトアウトする。同じシフトシーケンスと関連して、実行レーンは、さらに、内容をその左、右、上および下の近隣のレジスタファイルの特定のものからそれのレジスタファイルにシフトする。再び、シフトアウトターゲットおよびシフトインソースは、すべての実行レーンについて同じ
シフト方向と整合しなければならない（例えば、シフトアウトが右隣に対する場合、シフトインは左隣からでなければならない）。

一実施形態では、１サイクルにつき１つの実行レーンにつき１つのレジスタの内容だけをシフトすることが許されるが、他の実施形態では、２つ以上のレジスタの内容をシフトイン／アウトすることが許されてもよい。例えば、図６に示されたマルチプレクサ回路系６０３，６０４の第２の例が図６の設計に組み込まれる場合、同じサイクルの間に２つのレジスタの内容がシフトアウト／インされてもよい。もちろん、１つのレジスタの内容だけがサイクルごとにシフトされることが許される実施形態では、数学的演算間のシフトのためにより多くのクロックサイクルを消費することによって、複数のレジスタからのシフトが数学的演算間に起こってもよい（例えば、２つのレジスタの内容が、数学的演算間で２つのシフト演算を消費することによって数学的演算間でシフトされてもよい）。

実行レーンのレジスタファイルのすべての内容未満がシフトシーケンス中にシフトアウトされる場合、各実行レーンのシフトアウトされないレジスタの内容は適所に残る（シフトしない）ことに留意されたい。したがって、シフトインされる内容と置き換えられないシフトされない内容は、シフトサイクルにわたって実行レーンにローカルに維持される。各実行レーンで見られるメモリユニット（「Ｍ」）は、データを、実行レーンアレイ内の実行レーンの行および／または列に関連付けられるランダムアクセスメモリ空間からロードまたはそれに格納するために使用される。ここで、Ｍユニットは、実行レーンの自身のレジスタ空間からロードまたはそれに格納できないデータをロード／格納するためによく使用されるという点で、標準的なＭユニットとして機能する。様々な実施形態では、Ｍユニットの主な動作は、ローカルレジスタからメモリにデータを書き込み、メモリからデータを読み出してそれをローカルレジスタに書き込むことである。

ハードウェア実行レーン６０１のＡＬＵユニットによってサポートされるＩＳＡオペコードに関して、様々な実施形態において、ハードウェアＡＬＵによってサポートされる数学的オペコードは、仮想実行レーンによってサポートされる数学的オペコード（例えば、ＡＤＤ、ＳＵＢ、ＭＯＶ、ＭＵＬ、ＭＡＤ、ＡＢＳ、ＤＩＶ、ＳＨＬ、ＳＨＲ、ＭＩＮ／ＭＡＸ、ＳＥＬ、ＡＮＤ、ＯＲ、ＸＯＲ、ＮＯＴ）と一体的に結び付けられる（例えば実質的に同じである）。上述のように、メモリアクセス命令は、実行レーン６０１によって実行され、データをそれらの関連付けられるランダムアクセスメモリからフェッチまたはそれに格納することができる。さらに、ハードウェア実行レーン６０１は、シフト演算命令（右、左、上、下）をサポートし、二次元シフトレジスタ構造内でデータをシフトする。上述したように、プログラム制御命令は主にステンシルプロセッサのスカラープロセッサによって実行される。

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

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

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

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

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

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

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

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

図９ｂに示すように、ラインバッファユニットは、ライングループ９０２＿１〜９０２＿Ｎが格納されるメモリ９０１（例えば、スタティックまたはダイナミックランダムアクセスメモリ（ＳＲＡＭまたはＤＲＡＭ））を含む。メモリ９０１は、ラインバッファユニット（ならびに例えばシート生成部およびステンシルプロセッサ）を実現する同じ回路系と共にオンチップで、またはオフチップで実現されてもよい。図９ｂは、メモリ９０１内において特定の画像／フレームについてライングループ９０２＿１〜９０２＿Ｎを作成および消費する様々なカーネル間のアクティビティを示す。

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

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

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

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

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

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

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

上述したように、様々な実施形態において、各カーネルはそれ自体のステンシルプロセッサ上で動作する。例えば、図１０ａを参照すると、カーネルＫ１は第１のステンシルプロセッサ上で動作し、カーネルＫ２は第２のステンシルプロセッサ上で動作する。さらに、上述したように、作成側カーネルおよび消費側カーネルはラインバッファユニットを介してインタフェースする。

図１０ｂは、図１０ａのＤＡＧフローを実現すべくどのように画像プロセッサを構成することができるかを示している。図１０ｂに示すように、ラインバッファユニット１００１＿１（ＬＢＵ＿１）は、入力画像ストリームを受信し、受信したフレームをライングループに解析する。スイッチングネットワークは、ライングループを、ＬＢＵ＿１から、カーネルＫ１が実行される第１のステンシルプロセッサ１００２＿１にルーティングするように構成される。カーネルＫ１からの出力画像はライングループにフォーマットされ、第２のラインバッファユニット１００１＿２（ＬＢＵ＿２）に転送される。これらのライングループは、次いで、カーネルＫ２が実行される第２のステンシルプロセッサに転送される。

図１０ａから、画像情報は、カーネルＫ２からカーネルＫ３＿１またはＫ３＿２のいずれかに「分割」され得る。ここで、例えば、カーネルＫ３＿１およびＫ３＿２は、処理されている全体画像に関連付けられる異なるチャネルを処理してもよい。例えば、カーネルＫ３＿１は赤（Ｒ）画像を処理し、カーネルＫ３＿２は緑（Ｇ）および青（Ｂ）画像を処理することができる。代替的に、Ｋ３＿１は視覚画像を処理することができ、カーネルＫ３＿２は（例えば、視覚画像と共に飛行時間深度撮像カメラから取得される）深度画像を処理することができる。いずれにせよ、画像のすべてのチャネルはカーネルＫ１およびＫ２によって処理されるが、画像の異なるチャネルは異なるカーネルＫ３＿１およびＫ３＿２で処理される。さらに、カーネルＫ３＿１およびＫ３＿２は、同じ（例えば、非常に数値的に集中的な）プログラムコードの別個のインスタンスであってもよく、２つのステンシルプロセッサを用いて、Ｋ３機能の処理を、それを並列に実行することによって高速化する。

いずれにせよ、前述の「分割」により、カーネルＫ２からの一部のライングループ画像情報が第３のラインバッファユニット１００１＿３（ＬＢＵ＿３）にバッファリングされ、カーネルＫ２からの他のライングループ画像情報が第４のラインバッファユニット１００１＿４（ＬＢＵ＿４）にバッファリングされる。ＬＢＵ＿３ラインバッファユニットにバッファリングされるライングループは、カーネルＫ３＿１が実行される第３のステンシルプロセッサ１００２＿３に転送される。ＬＢＵ＿４ラインバッファユニットにバッファリングされるライングループは、カーネルＫ３＿２が実行される第４のステンシルプロセッサ１００２＿４に転送される。カーネルＫ３＿１およびＫ３＿２からの出力ライングループは、第５および第６のラインバッファユニット１００１＿４（ＬＢＵ＿５）、１００１＿５（ＬＢＵ＿６）にそれぞれバッファリングされる。次に、ＬＢＵ＿５およびＬＢＵ＿６ラインバッファユニットからのライングループは、カーネルＫ４を実行する第５のステンシルプロセッサ１００２＿５に渡される。分割されたライングループは、第５のステンシルプロセッサ１００２＿５で再びマージされることに留意されたい。

図１１ａおよび図１１ｂは、各ステンシルプロセッサが直前のステージからライングループを受け取り、直後のステージのために提供する、より直接的なパイプライン手法に関する。具体的には、ラインバッファユニット１１０１＿１（ＬＢＵ＿１）、１１０１＿２（ＬＢＵ＿２）、１１０１＿３（ＬＢＵ＿３）、１１０１＿４（ＬＢＵ＿４）は、それぞれカーネルＫ１、Ｋ２、Ｋ３、Ｋ４を実行するステンシルプロセッサ１１０２＿１，１１０２＿２，１１０２＿３，１１０２＿４にそれぞれ供給を行なう。ステンシルプロセッサ１１０２＿１，１１０２＿２，１１０２＿３，１１０２＿４も、それぞれラインバッファユニット１１０１＿２（ＬＢＵ＿２）、１１０１＿３（ＬＢＵ＿３）、１１０１＿４（ＬＢＵ＿４）、１１０１＿５（ＬＢＵ＿５）に供給を行なう。

図１１ｃは、本質的に２つのパイプラインを並列（Ｋ１−Ｋ３−…）および（Ｋ２−Ｋ４−…）で実行する別のパイプライン手法を示す。この構成を用いてパイプラインを並列
実行で高速化できる（例えば、カーネルＫ１およびＫ２は同じであり、カーネルＫ３およびＫ４は同じである）か、または画像データコンテキストに応じて２つの異なるパイプラインが使用される（例えば、１つのパイプラインは１種類のチャネルを処理し、他のパイプラインは他の種類のチャネルを処理する）。

図１１ａ、図１１ｂ、図１１ｃの各図において、ステンシルプロセッサをソースライングループおよびシンクライングループに適切な態様で接続するために接続ネットワーク１００４／１１０４に行われる必要がある異なる構成に注目されたい。

様々な実施形態では、画像プロセッサは適切な構成空間を含み（例えば、構成レジスタおよび／またはランダムアクセスメモリ（スカラープロセッサのスカラーメモリなど）で実現される）、無数の様々な構成（例えば、ＤＡＧ、画像処理パイプライン）のいずれかを実現するための構成情報をそこに保持する。いくつかの例示的な構成パラメータには、以下が含まれる：１）ソース画像の数（例えば、カメラまたはより大きなコンピュータシステムのメインメモリからシステムに流入するソース画像フレームの数）；２）ライングループの数（システムにおいてラインバッファユニット内で構成されるライングループの総数）。３）アクティブなステンシルプロセッサの数（システムにおいてアクティブなステンシルプロセッサの総数）；４）ステンシルプロセッサごとの入力ライングループの数（１つのステンシルプロセッサは２つ以上の入力画像フレームを処理でき、Ｎｕｍ＿Ｉｎｐｕｔ＿ＬＧｓ＿ｐｅｒＳｔｅｎｃｉｌは本質的にステンシルプロセッサが処理する異なる入力画像フレームの数を示す）；５）ステンシルプロセッサごとの出力ライングループの数（１つのステンシルプロセッサは２つ以上の出力画像フレームを処理でき、Ｎｕｍ＿Ｏｕｔｐｕｔ＿ＬＧｓ＿ｐｅｒＳｔｅｎｃｉｌは本質的にステンシルプロセッサが処理する異なる出力画像フレームの数を示す）；６）ライングループごとの消費側数（各ラインバッファユニットにおいて構成される各ライングループについて、Ｎｕｍ＿Ｃｏｎｓ＿ｐｅｒ＿ＬＧはライングループの消費側数を示す）。他のタイプの構成情報が、上述のシステムの任意の特徴、構造、または動作に基づいてシステムによって受け入れられてもよい。

ｅ．自動化されたＤＡＧ／コードライン再構成プロセス
前述の画像プロセッサの構成および動作の基本原理を前節で説明したが、本節では、カーネルのＤＡＧのより効率的な全体的な実装を行うために、コンパイラがＤＡＧに対して実行できる、ある再構成プロセスについて説明する。上記で示唆したように、パイプラインはＤＡＧの一形態であると理解される。

ここで、コンパイラは、ある非効率的なＤＡＧ構造または問題のあるＤＡＧ構造を認識し、自動的にＤＡＧを再構成して、非効率性を低減し、および／または問題を排除するようにプログラムすることができる。様々な実施形態では、ソフトウェアプログラム開発ツールによって、プログラム開発者は、コンパイラが非効率性に対処するために以下にさらに記載されるプログラムコードへの１つ以上の変換を実行するために使用することができるヒントを提供することができる。

コンパイラによって検出され応答され得るＤＡＧにおける非効率性または問題の例としては、（１）ＤＡＧにおける他のカーネルと比較して特に計算上複雑なカーネル、（２）画像プロセッサ内のステンシルプロセッサよりも多いまたは少ないカーネルを含むＤＡＧ、（３）限定されたラインバッファユニットメモリ空間および／または限定された命令メモリ空間、が含まれるが、それらに限定はされない。図１２／ａ／ｂ／ｃから図１６は、コンパイラがこれらの非効率性／問題に対応して実施するように設計されてもよい再構成のいくつかを説明している。

図１２ａおよび図１２ｂは、「水平融合」コード再構成を対象としている。水平融合の場合、図１２ａに示されるように、例えば同じカーネルから各々流れるＤＡＧの複数のカーネルが単一のカーネルにマージされる。ここで、図１２ａは、元のコードシーケンス１２０１が別々のＫ２およびＫ３カーネルを有するのを示す。コンパイラによる再構成の後、カーネルＫ２およびＫ３が単一のカーネルＫ２／Ｋ３に結合される新しいコードシーケンス１２０２が作成される。

水平融合は、例えば、他のカーネルと比較して、ＤＡＧ／パイプラインにおける、より小さいカーネルの存在に応答して、コンパイラによって実行されてもよい。ここで、カーネルの融合は、他のカーネルと比べてサイズ／演算負荷がより匹敵する、より大きなカーネルを生成する。代替的に、または組み合わせて、コンパイラは、ステンシルプロセッサよりも元のＤＡＧ内により多くのカーネルが存在することに応答して、水平方向の融合を実行することができる。ここで、融合は、ＤＡＧ内のカーネルの総数を低減することになる（理想的には、画像プロセッサ内のステンシルプロセッサの数をもはや超えないようにする）。

様々な実施形態では、水平融合は、互いに独立した複数のカーネルのプログラムコードをマージする（例えば、マージされる２つのカーネルのうち、第１のカーネルは第２のカーネルによって生成された情報を入力として受け入れない）。さらに、水平に融合されたカーネルは、同じカーネルからの入力情報を受け入れ、および／または同じカーネルによって消費される出力情報を提供することができる。前者は図１２ａに示されており、融合されたカーネルＫ２およびＫ３は共にカーネルＫ１からの入力情報を受け入れる。

図１２ｂは、水平融合の実現例の実施形態を示す。ここで、新しく構築されたＫ２／Ｋ３カーネルは、融合されているカーネルの連結として設計される。すなわち、図１２ｂの実施形態では、新たなカーネルＫ２／Ｋ３は、カーネルＫ２に対するプログラムコードが１２０３を実行した直後に実行を開始するカーネルＫ３に対するプログラムコードから構成される。特に、新たなカーネルＫ２／Ｋ３は、カーネルＫ２とＫ３との組み合わせと同じ入力情報を受け入れ、カーネルＫ２とＫ３との組み合わせと同じ出力情報を提供する。再び、入力は、同じまたは異なるラインバッファユニットから受信されてもよく、出力は、それらのそれぞれの出力を同じまたは異なるラインバッファユニットに提供してもよい。

ここで、図１２ａを参照すると、カーネルＫ１が２つの異なるラインバッファユニット（Ｋ２に供給する第１のラインバッファユニットおよびＫ３に供給する第２のラインバッファユニット）に対してラインバッファデータを生成する場合、プログラムフローの変更は必要ない（カーネルＫ２／Ｋ３のＫ２部分は、Ｋ２のために生成するラインバッファユニットから読み出し、カーネルＫ２／Ｋ３のＫ３部分は、Ｋ３のために生成するラインバッファから読み出す）。両方のカーネルＫ２およびＫ３がカーネルＫ１からの同じデータの消費側である場合（すなわち、カーネルＫ１が１つのラインバッファユニットにのみ書き込みを行い、そのラインバッファユニットからＫ２およびＫ３の両方が読み出す場合）も、プログラムのデータフローを変更する必要はない。この場合、カーネルＫ２／Ｋ３のＫ２部分およびＫ３部分は、同じラインバッファユニットから消費する。カーネルＫ２／Ｋ３の出力ラインバッファユニットにも同様のアナロジーが適用される。

様々な実施形態において、コンパイラは、融合されたカーネルが従って動作する空間率（カーネル呼び出しごとに処理されるピクセル）を意識すべきである。ここで、融合されているカーネルは、必ずしも最初に書き込まれたのと同じ率で動作しなくてもよい。例えば、画像解像度の違いにより、それらはそれらのそれぞれのアルゴリズムを実行する際に同じサイクル数を消費しなくてもよい。例えば、ダウンサンプリングカーネルは、ダウン
サンプリングしない他のカーネルよりも多くの二次元シフトレジスタシフト動作を必要とする、より広い画像領域にわたって動作しなければならなくてもよい。

結果として、ダウンサンプリングカーネルは、それが完了する前に、ダウンサンプリングしないカーネルよりも多くの呼び出しを消費する。例えば、ダウンサンプリングカーネルは、それが完了する前に１６サイクルを消費してもよく、非ダウンサンプリングカーネルは、それが完了する前に４サイクルしか消費しなくてもよい。完了率の違いは、１つの完了あたりのサイクルがカーネル全体のランレングスにわたって一定であることを期待するラインバッファユニットとタイミング問題を引き起こす可能性がある。したがって、コンパイラは、カーネルが、それらのそれぞれのアルゴリズムを完全に実行するのにほぼ同数のサイクルを消費するように、カーネルのコードを修正する。このようにすることで、ラインバッファは、中間カーネル実行中に劇的に異なるカーネルアルゴリズム完了率に調整する必要がなくなる。

したがって、一実施形態では、コンパイラは、１つの完了につき、より少ないサイクルを消費するカーネルに１つ以上のループを追加して、たとえば、そのカーネルが、１つの完了につき、より多くのサイクルを消費するカーネルと同じ数のサイクルを消費するようにする。例えば、上記の例では、非ダウンサンプリングカーネルは、それが完了する前にそれのアルゴリズムの４つのループを通して実行されるように修正されることになる。１回の実行ランに対するそれの元のバージョンに比べて、４回、データが、修正されたカーネルによって作成されるが、修正されたカーネルはそれが完了する前に１６サイクルを消費することになり、それはダウンサンプリングカーネルと同じである。おそらく、コンパイラは、複数のカーネルの率を変更して、すべてのカーネルが率を一致させることができる、サイクルを共通に支配するものに到達すると考えられる。

図１３ａ〜図１３ｃは垂直融合に関する。垂直融合の場合、図１３ａで見られるように、融合されているカーネル間に作成側／消費側関係が存在する。例えば、図１３ａで見られるように、カーネルＫ１はカーネルＫ２に対する作成側である（カーネルＫ２はカーネルＫ１の消費側である）。カーネルによる再構成の後、融合されたカーネルＫ１およびＫ２の機能を実行する新たなカーネルＫ１／Ｋ２が生成される。

図１３ｂは新たなカーネルの構成を示す。ここで、消費カーネルＫ２は、カーネルＫ１の後に連結され、正しい作成側／消費側関係をもたらす。新たなカーネルＫ１／Ｋ２に対する入力はカーネルＫ１に対する入力に対応し、新たなカーネルＫ１／Ｋ２の出力はカーネルＫ２の出力に対応する。コンパイラは、例えば、融合されるカーネルがＤＡＧにおける他のカーネルよりも計算上複雑でないこと、および／または画像プロセッサ内のステンシルプロセッサよりもＤＡＧにおいてより多くのカーネルあることに応答して、垂直融合を課すことを決定することができる。

垂直融合の場合において、垂直に融合されたカーネルの消費カーネル部分がそのタスクを実行するためにハロー領域を必要とする場合、問題が生じる可能性がある。様々な実施形態において、ステンシルプロセッサ内の二次元シフトレジスタの寸法は、出力ピクセル値が格納される領域の外側に延びるハロー領域４０９に対応し得ることを、上記の図４の議論から想起されたい。

ここで、垂直に融合されたカーネルの消費カーネル部分がハロー領域内のコンテンツを必要とする場合、それは、作成カーネル部分の出力に対して直ちに動作することはできない。つまり、作成側によって生成された出力データは実行レーンの「下」に保持され、ハロー領域に拡張しないことになる。消費カーネル部分がハロー領域内の画像データを必要とする場合、消費カーネル部分が、作成側からの結果の出力での動作を、それが生成され
た直後に開始する場合、ハローデータは利用できないことになる。

解決策は、消費カーネル部分の開始を遅延させて、消費カーネルが動作を開始するまでに、ハロー領域データが作成側カーネル部分によって確実に生成されるようにすることである。図１３ｃは、解決策の例示的な図を示す。ここで、縁取りされた領域１３０１は作成側カーネル部分の実行レーン領域に対応し、縁取りされた領域１３０２は作成側カーネル部分の実行レーン領域１３０１の外部に存在するハロー領域に対応する。

対照的に、縁取りされた領域１３０３は、作成側カーネル部分が領域１３０１内の出力を生成した後に消費カーネル部分が動作している実行レーン領域に対応する。縁取りされた領域１３０４は、消費側カーネル部分の実行レーン領域１３０３の周りに存在するハロー領域に対応する。図１３ｃは、ステンシル処理が同じ行のシートに沿って左から右への態様でシートに対して動作し、そのシートの行に対する処理が完了すると、次のシートの行に対して処理が開始される、と仮定する。

領域１３０１と１３０３との間に存在するオフセットまたは位相差は、消費カーネル部分に利用可能であり、図１３ｃに見られる相対的な位置決めオフセットを有する出力が作成カーネル部分によって生成されるまで、消費カーネル部分の開始を遅らせることによって、慎重に課される。注目すべきは、このオフセットで、作成側カーネルによって生成され、消費カーネル部分に利用可能な画像データ出力は、消費カーネル部分の実行レーン領域１３０３だけでなく、それのハロー領域１３０４も「充填」する。このように、消費カーネル部分は、領域１３０３についての出力値を適切に計算するためにそれが必要なデータを有し、Ｋ１にＫ２が続く連結演算の後にＫ１の次の実行が試みられることが許容される。

公称の実施形態では、作成側カーネルはその出力データをラインバッファユニットに書き込み、消費カーネルはその同じラインバッファユニットからデータを読み出す。しかしながら、作成カーネル部分をおよび消費カーネル部分が今融合され同じステンシルプロセッサ上で実行される結果として、作成カーネル部分によって生成された出力データは、ラインバッファユニットに書き戻されるのではなく、ステンシルプロセッサにローカルに（例えばステンシルプロセッサＲＡＭ４０７および/またはシート生成部メモリ内に）留ま
り得る。したがって、ラインバッファユニットからデータを読み出すのではなく、消費カーネル部分は、代わりに、ステンシルプロセッサにローカルなメモリから出力データを読み出す。

したがって、ステンシルプロセッサとラインバッファユニットとの間の書き込み／読み出しシーケンス全体を回避することができる。作成カーネル部分の出力を消費するが、その作成カーネル部分とは融合されなかった他の消費側が存在する実施形態では、作成カーネル部分の出力はラインバッファユニットに外部的に書き込まれ、外部の消費カーネルは作成側のデータを受け取ることができる。

図１３ｃは、同様の理由により、ステンシルプロセッサによって実際に処理される画像データの寸法が、処理されている画像の寸法を超えていることも示している。具体的には、追加の空間領域１３０５，１３０６が作成側カーネル部分によって処理され、作成側カーネル部分は消費側カーネル部分によって必要とされるハローデータを生成することができる。

図１４は、「カーネル分裂分割」と呼ぶことができる別の制限を示す。カーネル分裂分割の場合、より大きなカーネルは複数のより小さなカーネルに分解される。例えば、図１４に示すように、サブグラフＡ〜Ｆを有する大きな初期カーネルＫは、２つのカーネルＫ
１およびＫ２に分解され、新たなカーネルＫ１はサブグラフＡ〜Ｄを含み、新たなカーネルＫ２はサブグラフＥおよびＦを含む。カーネル分裂分割がコンパイラによって課され得るのは、たとえば、分割されるカーネルＫがＤＡＧ内の他のカーネルよりも演算負荷が大きい場合、および／またはその命令フットプリントが大きすぎてステンシルプロセッサ命令メモリに収まらない場合である。

再構成の一環として、「store_sheet（シート格納）」コマンド／命令および「load_sheet（シートロード）」コマンド／命令が、より大きいカーネルコードが分割された分割
部で、コード全体に新たに挿入されることに注意されたい。具体的には、図１４の例から、より大きなカーネルＫが分割部１４０１で分割されていることを観察すると、サブグラフＤの出力は情報のシートを格納するように修正され、サブグラフＥの入力は、情報のシートをロードするように修正されることに注目されたい。

前述のように、ステンシルプロセッサ内に二次元シフトレジスタアレイが存在するため、画像データのシートはカーネルのための基本的な入力データ構造および出力データ構造である。したがって、カーネルがデータのシート上で動作するには、まず、データのシートをステンシルプロセッサの二次元レジスタ空間にロードしなければならない。同様に、カーネルがそれのコアアルゴリズムの１つの実行を終えると、カーネルはそれのデータの出力シートを二次元シフトレジスタからステンシルプロセッサＲＡＭおよび／またはシート生成部ＲＡＭに書き込む。

これらの基本的なデータ構造要件と一致して、カーネル分裂分割を課すことの一部は、新たに生成されたカーネル出力（図１４のサブグラフＤの出力）および新たに生成されたカーネル入力（図１４のサブグラフＥの入力）である。前者は二次元シフトレジスタアレイから出力データのシートを書き込むためにシート格納コマンドを必要とし、前者は入力データのシートを二次元シフトレジスタアレイに読み込むためにシートロードコマンドを必要とする。Store_SheetコマンドおよびLoad_Sheetコマンドは、カーネルとラインバッ
ファユニットとの間の通信にも対応する（ラインバッファは複数のシートで構成されている）。したがって、カーネル分裂前はサブグラフＤはラインバッファユニットに直接供給しなかったが、分裂後にはそうする。同様に、カーネル分裂前はサブグラフＥはラインバッファユニットからは直接受け取らなかったが、融合後にはそうすることになる。

一実施形態では、コンパイラは、新たに生成された別個のカーネルＫ１、Ｋ２がサイズ／演算負荷においておおよそ等しくなるように、ある領域またはより大きなカーネルＫに分割部１４０１を課すように設計される。場合によっては、これにより、コンパイラは、反復ループを介して分割部１４０１を課し得る。例えば、サブグラフＤおよびＥは、プログラムフローがサブグラフＥからサブグラフＤに流れて戻るループを、ループが完了するまで実施してもよい。

分割部１４０１がループを切断する場合、コンパイラは、ループ自体が分割されるようにプログラムコードをさらに修正する。ここで、図１４で観測されたカーネル分裂分割１４０１は、本質的に、作成側／消費側関係を有する新たなカーネルを生成することに留意されたい。すなわち、新しく作成されたカーネルＫ２は、カーネルＫ１がそれを出力ラインバッファを書き込むラインバッファユニットからカーネルＫ１によって作成されたラインバッファを読み出す。したがって、ループの先行の反復はＫ１によって実行され、ループの後続の反復はＫ２によって実行される。

別の実施形態では、コンパイラは、前の反復と次の反復との間にデータ依存性を有するループを分割しようとせず、ループの全体を同じカーネル内に保持する。したがって、ループが存在すると、コンパイラが分割部１４０１を（ループを通る代わりにそれらの周り
に）課すべく選択する場所に影響を与える可能性がある。

図１５は、「空間的区分」と呼ばれる別のコンパイラ再構成プロセスを示す。図１５で見られるように、空間的区分は、もとは、より大きい画像上で動作するように設計されたカーネルを、その画像の一部分のみで動作するように設計された、同じコアアルゴリズムの複数のカーネルに複製することを伴う。

ここで、図１５の例示的な図示では、元のカーネルＫ１は、画像１５０１全体で動作するように設計されている。コンパイラは、ＤＡＧがＫ１のコードの２つのインスタンスであるＫ１＿１およびＫ１＿２を含むように、本質的にカーネルＫ１を複製する。コンパイラはさらに、新しく生成されたカーネルのベースＫ１コードを、それらが処理することになっている画像の部分のみを参照するように修正する。図１５の例では、カーネルＫ１＿１は画像１５０１の左半分１５０１＿１でのみ動作し、カーネルＫ１＿２は画像１５０１の右半分１５０１＿２でのみ動作する。

したがって、コンパイラは、画像１５０１の左半分１５０１＿１内に存在するラインバッファデータのみを要求するように、カーネルＫ１＿１のカーネルコードを再構築し、画像１５０１の右半分１５０１＿２内に存在するラインバッファデータのみを要求するように、カーネルＫ１＿２のカーネルコードを再構築する。カーネルソフトウェアがラインバッファをそのＸ、Ｙ座標によって参照することによって要求できることを想起すると、様々な実施形態では、コンパイラのカーネルＫ１およびＫ２の再構築は、カーネルが処理するはずの画像の部分に対応する座標を指定するためにラインバッファ要求を再フォーマットすることを伴う。

例えば、カーネルＫ１＿１は、画像の左半分１５０１＿１を処理するのに十分な入力ラインバッファデータが受信されると、画像全体の幅を横切って亘る座標を要求するのを避け、代わりに画像データの次の下位行を要求する。同様に、処理するラインバッファデータの次の下位行を開始するとき、カーネルＫ１＿２は、画像の半分に対応するＸ軸オフセットを有することになる（例えば、座標０，Ｙで次の下位のラインバッファを要求する代わりに、カーネルは、座標Ｗ／２，Ｙで次の下位のラインバッファを要求し、ここで、ＷはＸ軸に沿った画像１５０１全体の幅である）。

要求されたラインバッファデータの座標値を微調整する前述の原理に従って、他の画像区分構成が可能である。

典型的な実施形態では、元のカーネルＫ１は、単一のラインバッファユニットから画像全体を読み出し、その出力データを別の単一のラインバッファユニットに書き込むように設計された。空間的区分の後、カーネルＫ１＿１およびＫ１＿２の両方は、画像データが存在する単一のソースラインバッファユニットを参照し得る（または、カーネルＫ１＿１、Ｋ２＿２に対する入力画像の作成側カーネルは、カーネルＫｌ＿１およびＫｌ＿２が別々に読み出す２つの別々のラインバッファユニットに画像の２つのコピーを書き込むように再構成される）。しかしながら、図１５で見られるように、一実施形態では、カーネルＫ１＿１およびＫ１＿２の各々は、それらの出力データを２つの別々のラインバッファユニットＬＢ＿１およびＬＢ＿２に書き込む。

一実施形態では、この制限が課されるのは、図９ａおよび９ｂに関して上述したように、ラインバッファユニットは複数の消費側に仕えることができるが、１つの作成側しか扱うことができないからである。したがって、単一のラインバッファユニットはカーネルＫ１＿１およびＫ２＿２の両方からの出力を処理することはできない（各カーネルはそれ自身のラインバッファユニットに書き込まなければならない）。したがって、図１５で見ら
れるように、消費カーネルＫ２も、２つの異なるラインバッファユニットからそれが画像の２つの異なる半分について所望する画像データを読み取るために、空間的区分再構成の一部として再構成される（ＬＢ＿１は左側の画像データを保持し、ＬＢ＿２は右側の画像データを保持する）。すなわちカーネルＫ２は、左側の画像を望む場合にはＬＢ＿１に要求を出し、右側の画像データを望む場合にはＬＢ＿２に要求を出すように再構成される。例えば、Ｋ２のアルゴリズムが画像全体上で動作する場合には、Ｋ２を再構成して、画像半分を単一の画像に併合することもできる。

図１６は、「グラフ分割」と呼ばれる別のコード再構成プロセスに関する。グラフ分割の場合、ＤＡＧによって処理されるデータの量は、画像プロセッサの内部メモリ要件を超える。したがって、ＤＡＧは複数のＤＡＧに分割されなければならず、各ＤＡＧは画像プロセッサの内部記憶空間の限界内にある量のデータを処理する。ここで、様々な実施形態において、ラインバッファユニット、シート生成部およびステンシルプロセッサは、各々、関連付けられるメモリを有する。単一のＤＡＧの記憶要件がこれらのメモリの１つ以上の容量を超えると、複数のＤＡＧが作成される。

非常に大きな入力画像１６０１をはるかにより小さな、より低密度の出力画像１６０７にまで繰り返しダウンサンプリングすることを目的とするＤＡＧ１６０８が作成される例を図１６に示す。ＤＡＧ／パイプライン１６０８は、６つのカーネルＫ１〜Ｋ６から構成され、各カーネルはより大きな入力画像をより小さい出力画像にダウンサンプリングする（例えば、カーネルＫ１はより大きな入力画像１６０１をより小さい画像１６０２に、カーネルＫ２は画像１６０２をより小さい画像１６０３に、カーネルＫ３は画像１６０３をより小さい画像１６０４ダウンサンプリングする等）。

例えば、初期入力画像１６０１が非常に大きい実現例では、画像プロセッサの内部メモリ空間にすべてのデータ／命令／コンテキストを適合させることができない場合がある。したがって、それに応じて、コンパイラは、カーネルＫ１〜Ｋ６のメモリリソース要求を分析し、初期のより大きなＤＡＧ／パイプライン１６０８を、シーケンスで動作し、各々、画像プロセッサ内で利用可能なものより多くの内部メモリリソースを必要としない、より小さいＤＡＧ／パイプライン１６０９，１６１０，１６１１のグループに解析する。

図１の議論から、ＤＡＧは外部メモリからラインバッファユニットへの入力データのロードで始まり、ラインバッファユニットから外部メモリへの出力データの書き込みで閉じることを想起されたい。したがって、図１６の最初のＤＡＧ／パイプライン１６０８は、外部メモリからの入力データをカーネルＫ１への入力でラインバッファユニットに転送するためのコマンド／命令を含み、ラインバッファユニットからの出力データをカーネルＫ６の出力で外部メモリに転送するコマンド／命令も含んだ。

コンパイラは、元の、より大きいＤＡＧ／パイプライン１６０８を、より小さいＤＡＧ／パイプライン１６０９，１６１０，１６１１に解析した後、外部メモリからの入力データをカーネルＫ２およびＫ４の入力において（すなわち、新たな、より小さいＤＡＧ／パイプライン１６１０および１６１１の入力において）ラインバッファユニットにロードするコマンド／命令を追加的に挿入することになる。コンパイラはまた、カーネルＫ１およびＫ３の出力（すなわち、より小さい新たなＤＡＧ／パイプライン１６０９および１６１０の出力）でラインバッファユニットからの出力データを外部メモリにロードするコマンド／命令を挿入することになる。これらの新たなコマンド／命令の挿入がある場合、元のＤＡＧ／パイプライン１６０８は外部メモリではなくラインバッファユニットへの／からのデータの書き込み／読み出しを指定した（なぜならば、同じＤＡＧ／パイプライン内のカーネルはラインバッファユニットを介して互いを供給先/供給元とするからである）こ
とに注目されたい。したがって、これらの元のコマンド／命令はコンパイラによって削除
されることになる。

説明された再構成の様々なものは、上記の非効率性のいずれかに応答して最終的に実行され得ることに留意されたい。例えば、一連の融合の後、コンパイラは最終的にグラフ分割を実行することができる。

前述の議論では、カーネルそれら自体は、最終的にオブジェクトコードにコンパイルされるとき、コードの多くの分岐および関連付けられる基本ブロックで構成される大きな複雑なソフトウェアルーチンであり得ることに注目されたい。したがって、カーネル内のサブグラフも、それら自体、最終的にオブジェクトコードにコンパイルされるとき、オブジェクトコードの複数の分岐および基本ブロックから構成され得る。

図１７ａは、上述したように、例えばコンパイラによって実行される方法を示す。図１７ａで見られるように、この方法は、それぞれの二次元実行レーンおよびシフトレジスタ回路構造からなるプログラマブルステンシルプロセッサを有する画像プロセッサの対象とされるプログラムコードをコンパイルすること１７０１を含み、このプログラムコードは、有向非循環グラフを実現し、前記ステンシルプロセッサのそれぞれで実行される複数のカーネルからなり、前記コンパイルすることは、画像プロセッサ内のステンシルプロセッサとは異なる数のカーネルがプログラムコード内に存在することを認識すること、カーネルのうちの少なくとも１つが、カーネルのうちの別のカーネルよりも演算負荷が高いことを認識すること、およびプログラムコードが画像プロセッサのメモリ容量を超えるリソース要件を有することを認識すること、のいずれかを含む。この方法はまた、上記認識のいずれかに応答して、カーネルの水平融合、カーネルの垂直融合、カーネルの１つの、複数のカーネルへの分裂、カーネルの、複数の空間的に区分されたカーネルへの空間的区分、有向非循環グラフの、より小さなグラフへの分割、のいずれかを実行すること１７０２を含む。

図１７ｂは、上述のハードウェア機能のいずれかを有する画像プロセッサなどの画像プロセッサ上で実行するためのプログラムコードをコンパイルするときに、前述のコンパイラプロセスのいずれかと共に使用することができるアプリケーションソフトウェア開発およびシミュレーション環境１７２１を示す。ここで、開発者は、全体的な意図された画像変換と整合する戦略的シーケンスでカーネルを配置することによって、包括的な画像処理機能（例：各ステージが専用の画像処理タスクを実行する画像処理パイプライン、他のＤＡＧ規定のルーチンセットなど）を開発することができる。カーネルはライブラリ１７２２から呼び出されてもよく、および／または開発者が１つ以上のカスタムカーネルを開発してもよい。

ライブラリ１７２２内のカーネルは、カーネルの第三者ベンダおよび／または任意の基礎をなす技術のプロバイダによって提供されてもよい（例えば、対象とされるハードウェア画像プロセッサを含むハードウェアプラットフォームのベンダまたは対象とされるハードウェア画像プロセッサのベンダ（例えば、その設計として、または実際のハードウェアとして提供される））。

カスタム開発されたカーネルの場合、多くの状況において、開発者は、単一のスレッド１７２３についてプログラムコードを書くだけでよい。つまり、開発者は、単一の出力ピクセル値を、（例えば、前述の位置相対メモリアクセス命令フォーマットで）出力ピクセル位置に対する入力ピクセル値を参照することによって決定するプログラムコードを書くだけでよい。単一スレッド１７２３の動作を満足すると、開発環境は、スレッドコードの複数のインスタンスをそれぞれの仮想プロセッサ上で自動的にインスタンス化して、画像表面領域上で動作するプロセッサのアレイ上でカーネルを実行することができる。画像表
面領域は、画像フレームのセクション（ライングループなど）であってもよい。

様々な実施形態では、カスタムスレッドプログラムコードは、仮想プロセッサＩＳＡのオブジェクトコード（または仮想プロセッサＩＳＡオブジェクトコードにコンパイルされる高級言語）で書かれる。カスタムカーネルのプログラムコードの実行のシミュレーションは、メモリモデルに従って編成されたメモリにアクセスする仮想プロセッサを含むシミュレートされた実行時環境において実行されてもよい。ここで、仮想プロセッサのソフトウェアモデル（オブジェクト指向型またはその他）１７２４およびそのモデルを組み込んだメモリ１７２５がインスタンス化される。

仮想プロセッサモデル１７２４は、次いで、スレッドコード１７２３の実行をシミュレートする。スレッド、それのより大きなカーネル、およびそのカーネルが属する任意のより大きな機能の実行を満足すると、その全体が、基礎となるハードウェアの実際のオブジェクトコードにコンパイルされる。シミュレーション環境１７２１の全体は、コンピュータシステム（例えば、ワークステーション）１７２６上で実行されるソフトウェアとして実現されてもよい。

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

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

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

図１８は、コンピューティングシステムの例示的な図である。以下に説明するコンピューティングシステムのコンポーネントの多くは、一体化されたカメラおよび関連する画像プロセッサ（例えば、スマートフォンまたはタブレットコンピュータなどのハンドヘルドデバイス）を有するコンピューティングシステムに適用可能である。当業者は、２つの間の範囲を容易に定めることができるであろう。さらに、図１８のコンピューティングシステムは、図１７ｃに関して上述した開発環境を実現するために使用されるワークステーションのような高性能コンピューティングシステムの多くの特徴も含む。

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

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

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

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

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

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

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

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

Claims (17)

1. １つ以上のコンピュータによって実行される方法であって、
   複数のプロセッサを有するデバイスによって実行されるべき元の処理パイプラインを定義する命令を受け取ることを備え、前記元の処理パイプラインは特定の順序で実行されるべき複数のカーネルを含み、前記方法はさらに、
   前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することと、
   応答して、複数の処理パイプラインを生成することとを備え、前記複数の処理パイプラインを生成することは、
   第１の修正された処理パイプラインを生成することを含み、前記第１の修正された処理パイプラインを生成することは、前記デバイスの内部の内部ラインバッファを参照する前記元の処理パイプラインにおける第１のカーネルの１つ以上のストア命令を、前記デバイスの外部のメモリを参照する１つ以上のそれぞれのストア命令となるよう修正することを含み、前記複数の処理パイプラインを生成することはさらに、
   第２の修正された処理パイプラインを生成することを含み、前記第２の修正された処理パイプラインを生成することは、前記内部ラインバッファを参照する前記元の処理パイプラインにおける第２のカーネルの１つ以上のロード命令を、前記デバイスの外部の前記メモリを参照するロード命令となるよう修正することを含む、方法。
2. 前記１つ以上のロード命令を修正することは、前記１つ以上のロード命令を、前記第１のカーネルが実行された後に前記デバイスによって実行される命令となるように修正することを含む、請求項１に記載の方法。
3. 前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することは、前記元の処理パイプラインによって生成されるデータの量が前記デバイスの内部メモリサイズを超えていると判断することを含む、請求項１または２に記載の方法。
4. 前記元の処理パイプラインによって生成されるデータの量が前記内部メモリサイズを超えていると判断することは、前記生成されるデータの量が、前記デバイスのラインバッファのメモリサイズ、前記デバイスのシート生成部のメモリサイズ、または前記デバイスの前記複数のプロセッサのうちの１つの内部メモリサイズを超えていると判断することを含む、請求項３に記載の方法。
5. 前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することは、前記複数のカーネルのうちのあるカーネルが計算複雑度の所定の尺度を超えると判断することを含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記第１の修正された処理パイプラインに属する第１のカーネルを実行し、その後前記第２の修正された処理パイプラインに属する第２のカーネルを実行するように、前記デバイスの同じプロセッサを割り当てることをさらに備える、請求項１〜５のいずれか１項に記載の方法。
7. 前記複数のプロセッサの各々はラインバッファユニットに相互接続され、
   前記１つ以上のロード命令を修正することは、前記１つ以上のロード命令を、前記デバイスの外部のメモリから前記ラインバッファユニットにデータをロードするかまたは前記ラインバッファユニットからのデータを前記デバイスの外部の前記メモリにロードするための命令となるよう修正することを含む、請求項１〜６のいずれか１項に記載の方法。
8. 前記複数のプロセッサの各々はラインバッファユニットに相互接続され、
   前記１つ以上のストア命令を修正することは、前記１つ以上のストア命令を、前記第１のカーネルからの出力を表すデータを前記ラインバッファユニットにストアする命令となるよう修正することを含む、請求項１〜７のいずれか１項に記載の方法。
9. システムであって、
   １つ以上のコンピュータと１つ以上のストレージデバイスとを含み、前記１つ以上のストレージデバイスには、前記１つ以上のコンピュータによって実行されると前記１つ以上のコンピュータに動作を実行させるよう動作可能である命令が格納され、前記動作は、
   複数のプロセッサを有するデバイスによって実行されるべき元の処理パイプラインを定義する命令を受け取ることを含み、前記元の処理パイプラインは特定の順序で実行されるべき複数のカーネルを含み、前記動作はさらに、
   前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することと、
   応答して、複数の処理パイプラインを生成することとを含み、前記複数の処理パイプラインを生成することは、
   第１の修正された処理パイプラインを生成することを含み、前記第１の修正された処理パイプラインを生成することは、前記デバイスの内部の内部ラインバッファを参照する前記元の処理パイプラインにおける第１のカーネルの１つ以上のストア命令を、前記デバイスの外部のメモリを参照する１つ以上のそれぞれのストア命令となるよう修正することを含み、前記複数の処理パイプラインを生成することはさらに、
   第２の修正された処理パイプラインを生成することを含み、前記第２の修正された処理パイプラインを生成することは、前記内部ラインバッファを参照する前記元の処理パイプラインにおける第２のカーネルの１つ以上のロード命令を、前記デバイスの外部の前記メモリを参照するロード命令となるよう修正することを含む、システム。
10. 前記１つ以上のロード命令を修正することは、前記１つ以上のロード命令を、前記第１のカーネルが実行された後に前記デバイスによって実行される命令となるように修正することを含む、請求項９に記載のシステム。
11. 前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することは、前記元の処理パイプラインによって生成されるデータの量が前記デバイスの内部メモリサイズを超えていると判断することを含む、請求項９または１０に記載のシステム。
12. 前記元の処理パイプラインによって生成されるデータの量が前記内部メモリサイズを超えていると判断することは、前記生成されるデータの量が、前記デバイスのラインバッファのメモリサイズ、前記デバイスのシート生成部のメモリサイズ、または前記デバイスの前記複数のプロセッサのうちの１つの内部メモリサイズを超えていると判断することを含む、請求項１１に記載のシステム。
13. 前記元の処理パイプラインが１つ以上のグラフ分割基準を満たすと判断することは、前記複数のカーネルのうちのあるカーネルが計算複雑度の所定の尺度を超えると判断することを含む、請求項９〜１２のいずれか１項に記載のシステム。
14. 前記動作は、前記第１の修正された処理パイプラインに属する第１のカーネルを実行し、その後前記第２の修正された処理パイプラインに属する第２のカーネルを実行するように、前記デバイスの同じプロセッサを割り当てることをさらに含む、請求項９〜１３のいずれか１項に記載のシステム。
15. 前記複数のプロセッサの各々はラインバッファユニットに相互接続され、
    前記１つ以上のロード命令を修正することは、前記１つ以上のロード命令を、前記デバイスの外部のメモリから前記ラインバッファユニットにデータをロードするかまたは前記ラインバッファユニットからのデータを前記デバイスの外部の前記メモリにロードするための命令となるよう修正することを含む、請求項９〜１４のいずれか１項に記載のシステム。
16. 前記複数のプロセッサの各々はラインバッファユニットに相互接続され、
    前記１つ以上のストア命令を修正することは、前記１つ以上のストア命令を、前記第１のカーネルからの出力を表すデータを前記ラインバッファユニットにストアする命令となるよう修正することを含む、請求項９〜１５のいずれか１項に記載のシステム。
17. 請求項１〜８のいずれか１項に記載の方法を１つ以上のコンピュータに実行させるためのコンピュータ可読プログラム。

Images