JP6775088B2 - 画像プロセッサランタイム効率を向上するためのプログラムコード変形 - Google Patents

Description

発明の分野
発明の分野は、一般に、画像処理に関し、特に、画像プロセッサランタイム効率を向上するためのプログラムコード変形に関する。

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

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

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

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

概要
方法が記載されており、この方法は、バッファが作成側カーネルから１つ以上の消費側カーネルに転送される画像データの格納および転送を行う、画像処理ソフトウェアデータフローを構築することを含む。この方法はまた、バッファが画像データの格納および転送を行うために十分なリソースを有していないと認識することを含む。この方法はまた、画像データを作成側カーネルから１つ以上の消費側カーネルに転送中に画像データの格納および転送を行う複数のバッファを含むように、画像処理ソフトウェアデータフローを変更することを含む。

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

画像プロセッサハードウェアアーキテクチャの実施形態を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す。 ステンシルプロセッサの実施形態を示す。 ステンシルプロセッサの命令ワードの実施形態を示す図である。 ステンシルプロセッサ内のデータ計算ユニットの実施形態を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す。 統合された実行レーンアレイおよび二次元シフトアレイのための単位セルの実施形態を示す図である。 第１のプログラムコード変形に関する図である。 第１のプログラムコード変形に関する図である。 第２のプログラムコード変形に関する図である。 第２のプログラムコード変形に関する図である。 第２のプログラムコード変形に関する図である。 第３のプログラムコード変形に関する図である。 第３のプログラムコード変形に関する図である。 第４のプログラムコード変形に関する図である。 第４のプログラムコード変形に関する図である。 第５のプログラムコード変形に関する図である。 第５のプログラムコード変形に関する図である。 第６のプログラムコード変形に関する図である。 第７のプログラムコード変形に関する図である。 第７のプログラムコード変形に関する図である。 第８のプログラムコード変形に関する図である。 プログラムコード変形方法を示す図である。 ソフトウェア開発環境に関する図である。 コンピューティングシステムに関する図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実行レーンアレイ３０５によって操作される画像データのためのデータ記憶装置として機能することとは別に、ランダムアクセスメモリ３０７は、１つ以上のルックアップテーブルを保持することもできる。様々な実施形態では、１つ以上のスカラールックアップテーブルをスカラーメモリ３０３内でインスタンス化することもできる。ルックアップテーブルは、例えば、異なるアレイ場所に関するフィルタまたは変形係数を得るために、複雑な機能（例えば、ガンマカーブ、サイン、コサイン）を実現するために、画像処理タスクによって用いられることが多く、ルックアップテーブルは、入力された指標値などに関する機能出力を提供する。ここでは、ＳＩＭＤ画像処理シーケンスは、同じクロックサイクルの間に同じルックアップテーブルのルックアップを行うことが多いと予想される。同様に、１つ以上の定数テーブルを、スカラーメモリ３０３に記憶することができる。ここでは、例えば、異なる実行レーンは同じクロックサイクルで同じ変数または他の値を必要とすることが予想される（例えば、全画像に適用される特定の乗数）。したがって、定数ルックアップテーブルへのアクセスによって、同じスカラー値は実行レーンの各々に戻る。ルックアップテーブルは、典型的には、指標値でアクセスされる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

２．０ ランタイム効率を向上するためのプログラムコード変形
詳細に説明したように、画像プロセッサに関して開発されているアプリケーションソフトウェアは、本明細書ではカーネルと呼ばれる、より小さくより精細なソフトウェアプログラムを指向性のある非巡回グラフなどのより大きな全体構造にまとめることで定義可能である。この定義は、一般に、異なるカーネルを、多数の「作成側」カーネルがそれらの出力画像データを１つ以上の「消費側」カーネルに供給する特定のデータフローパターンに結合することを含む。少なくとも１つのカーネルは、アプリケーションソフトウェアプログラムが動作を行う全入力画像を受信し、典型的には、カーネルのうち１つが、アプリケーションソフトウェアの全出力画像を生成する。

その後、各カーネルは特定のステンシルプロセッサにマッピングされる。各ステンシルプロセッサは、関連するシート生成部を有し、関連するシート生成部は、その関連するステンシルプロセッサのカーネルが動作を行う画像データを受取る。様々な実施形態では、画像データは、シート生成部によってラインのグループで受信される。例えば、シート生成部は、入力画像フレームの全幅にわたる多数の行として画像データを受信し得る。その後、シート生成部は、ステンシルプロセッサに提供され最終的にステンシルプロセッサの２次元シフトレジスタアレイにロードされる、画像データの２次元「シート」を形成する。

様々な実施形態では、シート生成部は、シート生成部の機能を実現するために、専用ハードウェア論理回路系（例えば、特定用途向け集積回路（ＡＳＩＣ）論理回路系）、プログラマブル論理回路系（例えば、フィールドプログラマブルゲートアレイ論理回路系）、埋込みプロセッサ論理回路系、またはこれらの組み合わせで実現される。専用ハードウェア論理回路系は（もしあれば）、アプリケーションソフトウェアのコンパイルプロセスによって生成された情報でセットされ、このアプリケーションソフトウェアは、シート生成部に、シート生成部が関連するステンシルプロセッサにマッピングされるカーネルの、カーネルに関するシート生成動作を行わせる。プログラマブル論理回路系は（もしあれば）、アプリケーションソフトウェアのコンパイルプロセスによって生成された情報でプログラムされ、このアプリケーションソフトウェアは、プログラマブル論理回路系に、シート生成部の関連するステンシルプロセッサにマッピングされたステンシルプロセッサに対して実行するカーネルに関するシート生成部機能を実現させる。埋込みプロセッサ回路系には（もしあれば）、アプリケーションソフトウェアのコンパイルプロセスによって生成されたプログラムコードが設けられており、このアプリケーションソフトウェアは、埋込みプロセッサによって実行されると、埋込みプロセッサに、シート生成部の関連するステンシルプロセッサにマッピングされたステンシルプロセッサに対して実行するカーネルに関するシート生成部機能を実現させる。また、ステンシルプロセッサのスカラープロセッサは、様々なシート生成動作タスクを行うように、手伝うように、そうでなければこれらと関連するように、プログラム可能である。同じ種類の回路の実現の可能性および関連するコンパイルされたプログラムコードおよび／または情報が、ラインバッファユニットについて存在してもよい。

したがって、アプリケーションソフトウェア開発プロセスは、カーネルを特定のステンシルプロセッサにマッピングすることを含むだけでなく、カーネルのためにシート生成動作を行うために使用される、関連設定情報および／またはプログラムコードの生成も含む。

様々なアプリケーションソフトウェアプログラム開発環境では、アプリケーションソフトウェアプログラムのハイレベル記述の受付け、ならびに、これに応じた、低レベルプログラムコード（たとえば、オブジェクトコード）および画像プロセッサによる実行についての関連設定情報の生成を担うコンパイラが、アプリケーションソフトウェアにおける様々な非効率を認識し、非効率を改善する、そうでなければ非効率を削減するためにコンパイルされているプログラムコードを変更する。変更されているプログラムコードは、プログラムコード、および／または１つ以上のシート生成部に関する設定情報、および／またはそれらによって与えられるカーネル、および／またはラインバッファユニットでもよい。

図７ａは、第１の潜在的な非効率に関する図である。図７ａに見られるように、入力画像７０１が、例えば、ラインバッファユニットによって送られた複数のライングループとして、シート生成部によって受信される。図７ａに見られるように、入力画像は、例えば、シート生成部が結合されるステンシルプロセッサ上で実行されるカーネルＫ１によって処理される前に、シート生成部によってダウンサンプリングされる（７０２）。または、カーネルＫ１は、ダウンサンプリングを行うようにプログラムされてもよい。

様々な実施形態では、当然のことながら、ステンシルプロセッサは、ステンシルプロセッサの実行レーンアレイと同じ寸法を有する出力画像シートを作成する。例えば、実行レーンアレイ寸法が１６ピクセル×１６ピクセルである実施形態では、ステンシルプロセッサのカーネルプログラムコードＫ１の構造は、デフォルトで最初に１６ピクセル×１６ピクセルの出力画像シートの作成になっている。

ステンシルプロセッサは、ダウンサンプリングされた入力画像からその実行レーンアレイと同じ寸法の出力シートを生成するように構成される場合、大量のバッファリング空間が必要である。例えば、図７ａを参照すると、ステンシルプロセッサの２次元シフトレジスタアレイへのロードのために１６ピクセル×１６ピクセルダウンサンプルシート７０３を作成するように、ダウンサンプリング７０２がシート生成部によって行われる場合、シート生成部は、カーネルＫ１による消費に関して１６ピクセル×１６ピクセルのダウンサンプル入力画像７０３を形成するように、３２ピクセル×３２ピクセルの入力画像７０１をキューに入れる必要がある。そのようなキューイングに必要な大量のメモリを割り当てることは、一種の非効率である。

したがって、一実施形態では、コンパイラが図７ｂに示すようなアプリケーションソフトウェアプログラム（例えば、任意の関連する設定情報を含む）を再構築する。具体的には、コンパイラは、カーネルＫ１が完全に使用されているその実行レーンアレイで動作しないように、プログラムコードを構築する。本例を続けると、カーネルＫ１はその代わりに、カーネルＫ１に８ピクセル×８ピクセルの出力シート７０４ｂを生成させる８ピクセル×８ピクセルの入力シート７０３ｂ上で動作するように設計されている。

カーネルＫ１をより小さな８ピクセル×８ピクセルの入力シート７０３ｂ上で動作するように構成することによって、ダウンサンプリング動作７０２ｂは（例えば、シート生成部によって行われるように）、図７ａの入力画像データ７０１ａと比べて半分の量の入力画像データ７０１ｂをキューに入れる必要があるだけである。ここで、図１ａの入力画像データ７０１ａは３２行の画像データに対応するが、これとは対照的に、図７ｂの入力画像データ７０１ｂは、わずか１６行の入力画像データに対応する。わずか１６行の入力画像データ７０１ｂでは、ダウンサンプリング動作７０２ｂは、画像の全幅にまたがる８ピクセル×８ピクセルの入力シート７０３ｂの一続きを生成する２：１ダウンサンプリングを行うことが可能である。

図８ａおよび図８ｂは、アップサンプリングがカーネルＫ１の出力画像データ８０１に対して行われ、その後、Ｋ１の消費側カーネルＫ２によって画像データに対して実行される前に同じ量だけダウンサンプリングが行われる、他の非効率を示す図である。ここで、図８ａに見られるように、作成側カーネルＫ１は、出力シートＡ０〜Ａ３の一続き８０１を生成する。その後、効果的にＫ１の出力のアップサンプリングを行うように、これらの出力シート８０１の画像データはインターリーブされる。すなわち、図８ａに見られるように、例えば、Ｋ１の消費側カーネルＫ２によって消費される前に、一時的にＫ１の出力データをキューに入れるラインバッファ８０２に格納されたアップサンプリングされたＫ１出力８０３の一番上の出力ラインを形成するように、出力シートＡ０〜Ａ３の各々の一番上のラインがインターリーブされる。様々な実施形態では、アップサンプリングは、Ｋ１、Ｋ１が実行するステンシルプロセッサに結合されたシート生成部、またはＫ１がその出力を送るライン８０２バッファのいずれかによって行われてもよい。

図８ｂに見られるように、Ｋ１の出力を消費するカーネルＫ２に関する入力処理は、Ｋ１の出力がアップサンプリングされた同じ係数でその入力のダウンサンプリングを行うように構成される。したがって、Ｋ２に適切なサイズの入力データを与えるプロセスは、Ｋ１の出力に対して行われたアップサンプリングプロセスの反転を必要とする。すなわち、図８ｂを参照すると、ラインバッファ８０２内のインターリーブされた待機データ８０３は、最終的には、Ｋ１によって当初形成された出力画像Ａ０〜Ａ３を改良するために、デインターリーブされる。ダウンサンプリングは、ラインバッファ８０２、Ｋ２が実行するステンシルプロセッサに結合されたシート生成部、またはＫ２それ自体のいずれかによって実行されてもよい。

一実施形態では、コンパイラは、作成側カーネルの出力を消費するカーネル（複数のそのようなカーネルを含むこともある）に関して、作成側カーネルのアップサンプリングされた出力が同じ係数で（例えば、１：２アップサンプリングおよび２：１ダウンサンプリング）ダウンサンプリングされるときを認識するように設計されている。それに応じて、コンパイラはさらに、消費側データパスに対する作成側に沿ったアップサンプリングおよびダウンサンプリングの双方を削除できるように、開発されているプログラムコードを再構成する。この解決策が図８ｃに示されている。ここで、Ｋ１のアップサンプリングされていない出力は、Ｋ１とＫ２との接続の間で結合されたラインバッファ８０２において単にキューに入れられている。その後、アップサンプリングされていないＫ１出力は、ダウンサンプリングを行うことなくＫ２に直接与えられる。したがって、図８ａのアップサンプリング動作と図８ｂのダウンサンプリング動作との双方が避けられる。

図９ａおよび図９ｂは、例えば、多成分出力画像の場合に生じ得る他の非効率に関する図である。従来技術で知られているように、デジタル画像は複数の成分（例えば、ＲＧＢ、ＹＵＶなど）を有し得る。様々なアプリケーションソフトウェアプログラムを、異なるデータのプレーンとして異なる成分を処理するように設計／構成してもよい。ここでは、例えば、完全な出力画像９０１を、作成側カーネルＫ１によって、第１の成分（Ｒ）のみで構成されたデータの１つ以上のシートを生成すること、第２の成分（Ｇ）のみで構成されたデータの１つ以上のシートを生成すること、および第３の成分（Ｂ）のみで構成されたデータの１つ以上のシートを生成することによって、完全に生成可能である。様々な実施形態では、作成側カーネルと消費側カーネルとの間で渡されている画像の全てのデータを、同じラインバッファ９０２においてキューに入れることが自然である、または、標準的なデフォルトである。それゆえ、図９ａは、同じラインバッファユニット９０２においてキューに入れられている３つの成分９０１全ての画像データを示す図である。

しかしながら、例えば大きな出力画像の場合、同じラインバッファユニットの３つの成分全ての画像データを格納することは、大量のラインバッファメモリリソースを極度に使用することがある、そうでなければ、消費することがある。それゆえ一実施形態では、図９ａを参照すると、アプリケーションソフトウェアプログラムのコンパイルを行っているコンパイラが自動的に、多成分画像の異なる成分の格納がラインバッファメモリリソースを極度に使用しているときを認識する。例えば、コンパイルプログラムは、画像の格納および転送を行うために最初に定量のバッファメモリリソースを割り当ててもよい、または、転送されるべきデータのサイズおよび／または量に関連した量のバッファメモリリソースを割当ててもよい、ならびに、割当てを考慮して、自動的に割当てられた量が不十分である、もしくはある最大閾値に達すると判断してもよい。他のアプローチでは、コンパイルプロセスは、アプリケーションソフトウェアプログラムをシミュレートすること、および、ラインバッファユニットがボトルネックであると認識すること（例えば、作成側カーネルによって生成されたライングループを格納するメモリスペースを有していないことがある、または、消費側カーネルからの要求の読取りに応じるための帯域幅を有していない）を含んでもよい。それに応じて、コンパイルプロセスは自動的に、作成側Ｋ１カーネルの出力画像データの異なる成分が異なるラインバッファユニットにおいてキューに入れられるように、アプリケーションソフトウェアプログラムを変更する、および／または、画像プロセッサを再設定する。ここで、図９ｂは、異なるラインバッファユニット９０２＿１，９０２＿２，および９０２＿３においてそれぞれキューに入れられているＲ、Ｇ、およびＢ画像データを示す図である。

図９ｂの解決策は、作成側Ｋ１カーネルが多くの消費者を有する場合にも使用可能である。この場合、図９ａのデフォルトの解決策が採用されると、ただ１つの入力画像の全ての情報を受信するために、多数の消費者がラインバッファから複数回ロード／読出しを行わなければならなくなると、画像データ９０１の全ての成分を格納しているただ１つのラインバッファユニットは、システムボトルネックになることがある。それゆえ、一実施形態では、各ラインバッファが同じ成分タイプについてのデータを保持するたけである、図９ｂのアプローチを採用する。検討中の例では、これによって、一つのラインバッファリソースに対して消費者によって行われた読出し要求が、図９ａのデフォルトアプローチと比較して６６％減少する。すなわち、図９ｂのラインバッファユニット９０２＿１，９０２＿２，９０２＿３の各々は、図９ａのラインバッファユニット９０２の消費側読出し負荷の３３％をサポートするだけでよい。作成側カーネルの、画像データのラインバッファリソースへの書込み動作についても、同様に需要を減少させる効果が生じる。

図９ｂのアプローチが非効率を減少し得る他の状況は、特定の消費者が成分のサブセットを消費するだけであるかどうかである。例えば、極端な場合、一人の消費者がＲ成分を消費し、他の消費者がＧ成分を消費し、他の消費者がＧ成分を消費する。この場合、各々の異なる消費者は、異なるデータパスに沿って（異なるラインバッファユニット接続を通じて）異なる成分に基づくデータフローを合理化する、それ自体の専用ラインバッファソースで構成される。対照的に、図９ａのアプローチが用いられる場合、異なる成分に基づくデータフローは、図９ａのラインバッファ９０２のただ１つの地点において集束する。この場合、他の成分を転送しているラインバッファユニット９０１における多量の書込み／読出し動作によって、１つの成分のデータフローはストールすることがある。

図１０ａおよび図１０ｂは、ただ一人の消費者からのラインバッファリソースダウンストリームの拡散に基づく他の効率の改善を示す図である。ここでは、あまりに多くの消費者が存在すると、ただ１つの作成側カーネルの出力画像データを転送するために、複数のラインバッファユニットの使用が要求されることがある。図１０ａは、４つの異なる消費者Ｋ２〜Ｋ５がただ１つのラインバッファユニット１００２からのただ１つの作成側Ｋ１カーネルの出力を消費している、潜在的な非効率を示す図である。また、ただ１つのラインバッファユニット１００２は、全ての消費者がそれを消費するまでキューに入れられたデータをパージできないため、ボトルネックになることがある。この場合、ラインバッファユニット１００２からの全体のデータフローは、最低でその最も遅い消費者の入力レートまで低下する。さらに、ラインバッファユニット１００２は、ラインバッファユニット１００２のリソースを圧倒し得る多数の消費者をサポートすることを考えて、読出し要求の重負荷を受取る。

したがって、図１０ｂに示すように、消費者Ｋ２，Ｋ３の第１のサブセットが第１のラインバッファユニット１００２＿１に割当てられ、消費者Ｋ４，Ｋ５の第２のサブセットが第２のラインバッファユニット１００２＿２に割当てられる。作成側カーネルＫ１の出力画像ストリームが、ラインバッファユニット１００２＿１，１００２＿２の双方に与えられる。全消費者の負荷を複数のラインバッファユニットリソース１００２＿２，１００２＿２の間で拡散することによって、（図１０ａのアプローチと比較して）任意の特定のラインバッファユニットリソースに対する全需要が低減されやすくなる。また、コンパイラは、より遅い入力レートの消費側カーネルのより遅い消費レートによってより早い消費側カーネルがストールすることがないように、より速い入力ストリームの消費側カーネルに同じラインバッファユニットを与える（および／または、より遅い入力ストリーム消費側カーネルに異なるラインバッファユニットを与える）ことが可能である。

図１１ａは、ＤＡＧとして設計されたアプリケーションソフトウェアプログラム（またはそのコンポーネント）から生じ得る「分割および結合」非効率を示す図である。図１１ａにおいて見られるように、ソースカーネルＫ１の出力は、２つの異なる消費側カーネルＫ２およびＫ３に与えられる。さらに、カーネルＫ３は、カーネルＫ２の出力を消費する。カーネルＫ１の出力からのカーネルＫ３の二重依存は、ランタイム計算非効率およびモデリング／設計非効率を生じることがある。ランタイム非効率に関して、ＬＢ２ラインバッファ１１０２＿２は、大量のＫ１の出力データをキューに入れるために、きわめて大きくされなければならないことがある。通常、カーネルＫ３は、ほぼカーネルＫ３がＬＢ２ １１０２＿２からの次のライングループと一緒に処理するＬＢ３ １００２＿３からの次のライングループが利用可能になるまで、ＬＢ２ １１０２＿２に次のライングループを要求しない。Ｋ２での伝搬遅延が大きい可能性があるため、ＬＢ２ １１０２＿２はきわめて大きくなることがある。ＬＢ２ １１０２＿２内のデータが消費される準備が整ったときと、カーネルＫ２からカーネルＫ３への同胞入力データがＬＢ３ １１０２＿３において利用可能になるときとの間の前述の不一致によって、アプリケーションソフトウェアの設計中のモデリングまたは最適化プロセスがより困難になる場合がある。

図１１ｂは、コンパイラが分割および結合構造にパイプライン構造を強制する解決策を示す図である。ここでは、図１１ａのＫ２カーネルは、本来のＫ２カーネルと、単にＬＢ１ １１０２＿１からのコンテンツを消費しそれをＬＢ４ １１０２＿４に転送する負荷／格納アルゴリズム１１０３とを含む異なるカーネルＫ２’に拡張されている。重要なことに、負荷／格納アルゴリズム１１０３が、Ｋ１からの本来の出力データがＫ３によって消費される準備が整うときと、Ｋ２からの出力データがＬＢ３ １１０２＿３においてＫ３によって消費される準備が整うときとの間の不一致を削除するＫ１からの未処理のストリームに対して、伝播遅延を引き起こす可能性がある。

図３ａの議論から、様々な実施形態において、スカラーメモリ３０３をルックアップテーブルまたは定数テーブルを保持するように構成してもよいことを振り返る。特定の適用例では、カーネルによって処理される入力画像データは、（例えば、様々な入力データに動作を行うソースカーネルによって生成されるような）可変な情報ではなく、固定定数である。例としては、例えば、レンズ表面にわたって異なるかなり大きな粒子サイズを有する領域について、レンズに関する補正値が記録されるシェーディング補正が挙げられる。かなり大きな粒度は、低解像度画像データに対応する（記録されたデータが、各エントリが異なる粒子に対応する異なるエントリとして実現される場合、記録されたデータは多くのエントリを含まない）。

画像プロセッサがレンズを含むカメラからの画像を処理している場合、これらの記録された補正値のうち１つは、実行レーンアレイによって処理されている画像領域に対応する。したがって、記録された値は、入力値として各実行レーンに適用される。この意味で、レンズ補正値は、ルックアップテーブルまたは定数テーブルと同様に実現される。さらに、補正値の実現に必要なデータの全量が制限された状態で、補正値は大量のメモリスペースを消費することはない。したがって、図１２に見られるように、様々な実施形態では、固定された、かつ、スカラーメモリ１２０３内に収まるぐらい小さな入力画像データ１２１０が、（例えば、アプリケーションソフトウェアの初期構成としてスカラーメモリ１２０３にロードされ）、ランタイム中にルックアップテーブルまたは定数テーブルとして（例えば、ソースカーネルによって生成されラインバッファユニットを通じてカーネルに与えられるのではなく）、ステンシルプロセッサの実行レーンアレイ上で実行するカーネルによって参照される。

図１３ａは、ラインバッファユニットおよび／またはシート生成部においてキューに入れられている大量のデータにつながる可能性のある、他のランタイムの問題を示す図である。ここで、図１３ａは、例えばラインバッファユニットから提供された後でシート生成部においてキューに入れられる３つのライングループ１３０１，１３０２，１３０３を示す図である。例の目的で、ライングループ１３０１，１３０２，１３０３の各々が１６行の画像データを含み、シート生成部の対応するステンシルプロセッサの実行レーンアレイの寸法１３０５も１６ピクセル×１６ピクセルであると仮定する。さらに、実行レーンアレイの周囲の４ピクセルの広さの境界を形成するハロー領域をサポートするように、２次元シフトレジスタアレイの寸法１３０６が２４ピクセル×２４ピクセルであると仮定する。少なくともこのような状況では、自然な構成は、１６行の実行レーンアレイ１３０５を１６行の特定のライングループに整列させることである。すなわち、シート生成部は、特定のライングループ上で中央に揃えられたシートを形成する。図１３ａは、実行レーン１３０５が第２のライングループ１３０２の高さにわたって動作するように整列された、このようなアプローチを示す図である。

問題は、図１３ａに示すように、ハロー１３０６の存在によって、２次元シフトレジスタアレイに与えられる完全なシートが、第１のライングループ１３０１の低い領域および第３のライングループ１３０３の高い領域からのデータを必要とすることである（ハロー領域は、これらのライングループも覆う）。したがって、一実施形態では、図１３ｂに見られるように、最小限の数のライングループが実物大のシートを形成するために存在する必要があるように、整列が変更される。この例では、図１３ｂの整列は、２つのライングループ１３０１，１３０２のみが実物大のシートを形成するためにシート生成部内に存在する必要があるように、４つのピクセル値によって、図１３ａの整列に対してシフトアップされている。そうすることによって、 シート生成部で（およびおそらくラインバッファでも）必要とされるメモリスペースは少ないのみならず、シートは、処理を始めるために３つのラインバッファを待つのではなく、処理を始めるために２つのライングループを待つだけでよい。

図１４は、１データレーンにつき複数のピクセルを含む入力画像データ、言い換えると、複数のピクセルを含むシート生成部のカーネルによって処理されるべきデータの基本単位が与えられたカーネルについて、入力プロセスとしてシート生成部によって行われるデインターリーブプロセスに関する図である。一例として、図１４は、例えばＢａｙｅｒパターンフォーマットにおいて異なる着色ピクセルのモザイク１４０１を含むように構成されるような、シート生成部によって受信される入力画像のピクセルを示す図である。ここでは、入力画像は、ラインバッファユニットによって提供されるライングループとしてシート生成部によって受信される。したがって、例えば、シート生成部によって受信される各ライングループの各行は、Ｒ，ＧおよびＢピクセルを含む。ここでは、入力画像のデータの基本単位は、１つのＲピクセル、１つのＢピクセル、および２つのＧピクセルを含む４つのピクセルからなる単位セル１４０２を含む。

シート生成部は、受信された入力画像構造１４０１からのシートを単に直接解析するのではなく（これによって、Ｂａｙｅｒパターンを有するシートが作成される）、４つの異なる種類のシートを含むカーネルに関して、新しい入力構造１４０３を生成するように、入力画像データ構造１４０１に対してデインタリーブプロセスを行う。すなわち、図１４に見られるように、新しい入力構造１４０３は、１）入力画像のＲピクセルからのみ構成される、またはこれからのみ生じるシート、２）単位セル入力画像の単位セルの同じ第１の位置に設けられたＧピクセルからのみ構成される、またはこれからのみ生じるシート、３）単位セル入力画像の単位セルの同じ第２の位置に設けられたＧピクセルからのみ構成される、またはこれからのみ生じるシート、４）入力画像のＢピクセルからのみ構成される、またはこれからのみ生じるシートを含む。これらのシートは、入力画像ピクセルからのみ構成されてもよい、または、例えば、異なる色が存在する入力画像の場所に値を補間することによって、アップサンプリングされてもよい。

その後、新しく構築されたシートは、シート生成部の関連するカーネルに提供される。このカーネルは、新しく構成されたシートを処理し、シート生成部に戻される同じ構造１４０３（１シートにつき１色）の出力シートを生成する。その後、シート生成部は、単色の構造１４０３に対してインターリーブ処理を行って、混色の単位セルを含む本来の構造１４０１を有する消費について、出力画像を生成する。

様々な実施形態では、上述のラインバッファまたはラインバッファユニットは、より一般的には、作成側カーネルと消費側カーネルとの間の画像データの格納および転送を行うバッファとして特徴づけることができる。すなわち、様々な実施形態では、バッファは、必ずしもライングループをキューに入れる必要はない。さらに、画像プロセッサのハードウェアプラットフォームは、関連するメモリリソースを有する複数のラインバッファユニットを含んでもよく、１つ以上のラインバッファは、ただ１つのラインバッファユニットから動作するように構成可能である。すなわち、ハードウェアのただ１つのラインバッファユニットは、異なる作成側／消費側カーネルの対間の異なる画像データフローの格納および転送を行うように構成可能である。

図１５は、上述の方法を示す図である。この方法は、バッファが作成側カーネルから１つ以上の消費側カーネルに転送される画像データの格納および転送を行う、画像処理ソフトウェアデータフローを構築すること（１５０１）を含む。この方法は、バッファが画像データの格納および転送に十分なリソースを有していないと認識すること（１５０２）も含む。この方法は、画像データを作成側カーネルから１つ以上の消費側カーネルに転送中に画像データの格納および転送を行う複数のバッファを含むように、画像処理ソフトウェアデータフローを変更すること（１５０３）も含む。

３．０ 低レベルプログラムコードの構造
図１６は、開発者が非効率を特定する必要がないように、および／または、最初から変形を書く必要がないように、プログラマがハイレベル画像処理機能を設計し、アプリケーション開発環境がセクション２．０の上述の変形のいずれか／全てを提供する、プリランタイム開発環境を示す図である。

ここでは、開発環境は、自動的に上述の非効率のいずれかを認識し、例えば非効率（環境開発が、そこに含まれるように開発されているプログラムコードのスキャンを行う）の記述および（非効率が発見されない場合に強要される）対応する修正を含むライブラリ１６０１を参照することによって、対応する変形上の改善を自動的に強要する。すなわち、開発環境は、自動的により多くの効率的なプロセスを（例えば、コンパイルプロセスの一部として）行うライブラリ１６０１からのプログラムコードのインサートを行う、そうでなければ、プログラムコードを変更して、非効率なコードを非効率に対する修正を含む新しいコードに取り替える。

このように、上述の動作を行うプログラムコードまたはその代替の実施形態は、よりハイレベルのプログラムコードまたはより低レベルのオブジェクトコードで表現可能である。様々な実施形態では、よりハイレベルの仮想命令セットアーキテクチャ（ＩＳＡ）コードが、メモリがｘ、ｙアドレス座標を有すると読出すと、動作が行われるべきデータ値を指定する一方で、オブジェクトコードは、これらのデータアクセスを２次元シフトレジスタ動作として（上述のシフト動作のいずれかまたは同様の実施形態として）認識可能である。

コンパイラは、開発環境のｘ、ｙ読出しを、指定されたオブジェクトコードである２次元シフトレジスタの対応するシフトに変換可能である（例えば、ｘ、ｙ座標（＋２、＋２）を有する開発環境における読出しは、左へ２スペース、および、下へ２スペースのシフトとしてオブジェクトコードにおいて実現可能である）。環境によって、開発者は、これらのレベル（または、例えば、単により高いＩＳＡレベル）の双方への可視性を有してもよい。さらに他の実施形態では、そのようなあらかじめ書込まれたルーチンは、プリランタイムではなくランタイム中に（例えば、ジャストインタイムコンパイラによって）呼び出されてもよい。

４．０ おわりに
先のセクションは、セクション１．０で説明された画像プロセッサが、（例えば、携帯デバイスのカメラからのデータを処理する携帯デバイスのシステムオンチップ（ＳＯＣ）の一部として）コンピュータシステム上のハードウェアで具体化可能であると認識することが適切である。

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの例について以下で説明する。
例１：プログラムコードを含む機械可読記憶媒体であって、プログラムコードは、コンピューティングシステムによって処理されると、コンピューティングシステムに方法を実行させ、方法は、
ａ）バッファが作成側カーネルから１つ以上の消費側カーネルに転送される画像データの格納および転送を行う、画像処理ソフトウェアデータフローを構築することと、
ｂ）バッファが画像データの格納および転送を行うために十分なリソースを有していないと認識することと、
ｃ）画像データを作成側カーネルから１つ以上の消費側カーネルに転送中に画像データの格納および転送を行う複数のバッファを含むように、画像処理ソフトウェアデータフローを修正することとを含む、機械可読記憶媒体。

例２：方法はさらに、画像データの異なる部分が作成側カーネルから複数のバッファのうち異なるバッファに送られるように、画像処理ソフトウェアデータフローを変更することを含む、例１に記載の機械可読記憶媒体。

例３：異なる部分は、画像データの異なる色成分に対応する、例２に記載の機械可読記憶媒体。

例４：方法はさらに、同じ画像データが作成側カーネルから複数のバッファのうち第１および第２のバッファに送られるように、画像処理ソフトウェアデータフローを変更することを含む、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例５：変更することはさらに、１つ以上の消費側カーネルのうち第１の消費側カーネルに与えるように、複数のバッファのうち第１のバッファを構成することと、１つ以上の消費側カーネルのうち第２の消費側カーネルに与えるように、複数のバッファのうち第２のバッファを構成することとを含む、例４に記載の機械可読記憶媒体。

例６：方法はさらに、
画像処理ソフトウェアデータフローは係数で画像のアップサンプリングを行ってアップサンプリングされた画像を形成すると認識することと、
画像処理ソフトウェアデータフローはアップサンプリングされた画像のダウンサンプリングを当該係数で行うと認識することと、
画像のアップサンプリングおよびアップサンプリングされた画像のダウンサンプリングを、画像処理ソフトウェアデータフローから削除することを含む、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例７：方法はさらに、
画像処理ソフトウェアデータフローの分割及び結合パターンを認識することと、
分割および結合パターンを削除するために、画像処理ソフトウェアデータフローを一連のステージとして再構築することとを含む、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例８：複数のステンシルプロセッサユニットおよび／または少なくとも１つの対応するシート生成部ユニットに相互接続された複数のラインバッファユニットを有するアーキテクチャ上で動作するように構成された、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例９：ステンシル、特に重なっているステンシルを処理するように構成された、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例１０：実行レーンアレイよりも広い寸法を有するシフトレジスタ構造を含むデータ計算ユニット上で動作するように構成された、特に、レジスタが実行レーンアレイの外側にある、前述の例の少なくとも１つに記載の機械可読記憶媒体。

例１１：プログラムコードを含む機械可読記憶媒体であって、プログラムコードは、コンピューティングシステムによって処理されると、コンピューティングシステムに方法を実行させ、方法は、
プログラムコードのカーネルによって処理される画像のダウンサンプルが行われると認識することを含み、プログラムコードのカーネルは、画像プロセッサの画像処理コア上で実行され、画像処理コアは２次元実行レーンアレイを含み、方法はさらに、
実行レーンアレイの全ての実行レーンよりも少ない実行レーンで画像を処理して、画像のダウンサンプリングをサポートするために使用されるメモリリソースの消費を低減するように、カーネルの動作を構築することを含む、機械可読記憶媒体。

例１２：画像プロセッサは画像処理コアを含む複数の画像処理コアを含み、複数の画像処理コアのうち１つは、定数情報を格納する関連メモリを有し、方法はさらに、
定数入力画像を格納するように関連メモリを構成することを含み、定数入力画像は、関連メモリを有する複数の画像処理コアのうち当該１つに対して実行されるプログラムコードのそれぞれのカーネルによって処理される、例１１に記載の機械可読記憶媒体。

例１３：画像プロセッサは画像処理コアを含む複数の画像処理コアを含み、複数の画像処理コアのうち１つに関する入力画像データは、画像データのラインのグループとして受信され、方法はさらに、
入力画像領域が最小限の数のラインのグループと重なるように、１つの画像処理コアが動作する入力画像領域を整列させる、例１１または１２に記載の機械可読記憶媒体。

例１４：画像プロセッサは画像処理コアを含む複数の画像処理コアを含み、複数の画像処理コアのうち１つに関する入力画像データは、１つの画像処理コアが動作を行うデータ単位につき複数のピクセルからなるモザイクを含み、方法はさらに、
入力画像を、１つの画像処理コアによって処理される前にデインタリーブされるように構成することと、
１つの画像処理コアによって生成された出力画像データを、データ単位につき複数のピクセルからなるモザイクにインターリーブされるように構成することとを含む、例１１〜１３の少なくとも１つに記載の機械可読媒体。

例１５：複数のステンシルプロセッサユニットおよび／または少なくとも１つの対応するシート生成部ユニットに相互接続された複数のラインバッファユニットを有するアーキテクチャ上で動作するように構成された、例１１から１４の少なくとも１つに記載の機械可読記憶媒体。

例１６：ステンシル、特に重なっているステンシルを処理するように構成された、例１１〜１５の少なくとも１つに記載の機械可読記憶媒体。

例１７：実行レーンアレイよりも広い寸法を有するシフトレジスタ構造を含むデータ計算ユニット上で動作するように構成された、特に、レジスタが実行レーンアレイの外側にある、例１１から１６の少なくとも１つに記載の機械可読記憶媒体。

例１８：コンピューティングシステムであって、
１つ以上の汎用処理コアと、
システムメモリと、
システムメモリと１つ以上の汎用処理コアとの間で結合されたメモリコントローラと、
プログラムコードを含む記憶媒体とを備え、プログラムコードは、コンピューティングシステムによって処理されると、コンピューティングシステムに方法を実行させ、方法は、
ａ）バッファが作成側カーネルから１つ以上の消費側カーネルに転送される画像データの格納および転送を行う、画像処理ソフトウェアデータフローを構築することと、
ｂ）バッファが画像データの格納および転送を行うために十分なリソースを有していないと認識することと、
ｃ）画像データを作成側カーネルから１つ以上の消費側カーネルに転送中に画像データの格納および転送を行う複数のバッファを含むように、画像処理ソフトウェアデータフローを変更することとを含む、コンピューティングシステム。

例１９：方法はさらに、画像データの異なる部分が作成側カーネルから複数のバッファのうち異なるバッファに送られるように、画像処理ソフトウェアデータフローを変更することを含む、例１８に記載のコンピューティングシステム。

例２０：異なる部分は、画像データの異なる色成分に対応する、例１９に記載のコンピューティングシステム。

例２１：方法はさらに、同じ画像データが作成側カーネルから複数のバッファのうち第１および第２のバッファに送られるように、画像処理ソフトウェアデータフローを変更することを含む、例１８〜２０の少なくとも１つに記載のコンピューティングシステム。

例２２：変更することはさらに、１つ以上の消費側カーネルのうち第１のカーネルに与えるように、複数のバッファのうち第１のバッファを構成することと、１つ以上の消費側カーネルのうち第２の消費側カーネルに与えるように、複数のバッファのうち第２のバッファを構成することとを含む、例１８〜２１の少なくとも１つに記載のコンピューティングシステム。

例２３：コンパイリングすることはさらに、
画像処理ソフトウェアデータフローは係数で画像のアップサンプリングを行ってアップサンプリングされた画像を形成すると認識することと、
画像処理ソフトウェアデータフローはアップサンプリングされた画像のダウンサンプリングを当該係数で行うと認識することと、
画像のアップサンプリングおよびアップサンプリングされた画像のダウンサンプリングを、画像処理ソフトウェアデータフローから削除することとを含む、例１８〜２２の少なくとも１つに記載のコンピューティングシステム。

例２４：コンパイリングすることはさらに、
画像処理ソフトウェアデータフローの分割及び結合パターンを認識することと、
分割および結合パターンを削除するために、画像処理ソフトウェアデータフローを一連のステージとして再構築することとを備える、例１８〜２３の少なくとも１つに記載のコンピューティングシステム。

例２５：バッファは、画像データのラインの転送グループを格納する、例１８〜２４の少なくとも１つに記載のコンピューティングシステム。

例２６：バッファは画像プロセッサのラインバッファユニットで実現され、画像プロセッサは、ラインバッファユニットと、プログラムコードの作成側カーネルとプログラムコードの１つ以上の消費側カーネルとをそれぞれ実行する複数の処理コアとの間で結合されたネットワークを含む、例１８〜２５の少なくとも１つに記載のコンピューティングシステム。

例２７：複数のステンシルプロセッサユニットおよび／または少なくとも１つの対応するシート生成部ユニットに相互接続された複数のラインバッファユニットを有するアーキテクチャを有するプロセッサを備える、例１８〜２６の少なくとも１つに記載のコンピューティングシステム。

例２８：ステンシル、特に重なっているステンシルを処理するように構成された、例１８〜２７の少なくとも１つに記載のコンピューティングシステム。

例２９：実行レーンアレイよりも広い寸法を有するシフトレジスタ構造を有するデータ計算ユニットを備え、特に、レジスタが実行レーンアレイの外側にある、例１８〜２８の少なくとも１つに記載のコンピューティングシステム。

Claims (13)

1. コンピュータプログラム命令で符号化された１つ以上の非一時的なコンピュータ記憶媒体であって、前記コンピュータプログラム命令は、１つ以上のコンピュータによって実行されると、前記１つ以上のコンピュータに動作を行わせ、前記動作は、
   画像プロセッサによる実行のために、画像処理ソフトウェアデータフローの定義を受信することを含み、前記画像処理ソフトウェアデータフローは、作成側カーネルと複数の消費側カーネルとのための命令を有し、前記命令は、前記作成側カーネルに、前記画像プロセッサの第１のラインバッファにデータを書込ませる格納命令と、前記複数の消費側カーネルの各々に、前記第１のラインバッファから前記作成側カーネルによって生成されたデータを読出させるロード命令とを含み、前記動作はさらに、
   前記第１のラインバッファのデータレートが、前記複数の消費側カーネルの全てを満たすのに不十分であると判断することと、
   それに応じて、前記画像処理ソフトウェアデータフローを変更することとを含み、前記画像処理ソフトウェアデータフローは、
   前記第１のラインバッファと異なる第２のラインバッファとを含む複数のラインバッファに出力を書込む格納命令を含むように、前記作成側カーネルを変更することと、
   前記第１のラインバッファの代わりに前記異なる第２のラインバッファから前記出力を読み出すロード命令を含むように、前記複数の消費側カーネルのうち１つ以上を変更することとを含む、１つ以上の非一時的なコンピュータ記憶媒体。
2. 前記画像プロセッサは、複数のステンシルプロセッサを含み、前記動作はさらに、前記複数のステンシルプロセッサのそれぞれのステンシルプロセッサによって実行されるべき前記作成側カーネルおよび前記複数の消費側カーネルの各々を割当てることを含む、請求項１に記載の１つ以上の非一時的なコンピュータ記憶媒体。
3. 各ステンシルプロセッサは、関連するシート生成部を有し、各カーネルの前記ロード命令は、それぞれのシート生成部に、対応するラインバッファからデータをロードさせる、請求項２に記載の１つ以上の非一時的なコンピュータ記憶媒体。
4. シート生成部に、対応するラインバッファからデータをロードさせることは、前記複数のステンシルプロセッサのステンシルプロセッサの２次元シフトレジスタアレイにデータをロードすることを含む、請求項３に記載の１つ以上の非一時的なコンピュータ記憶媒体。
5. 前記画像処理ソフトウェアデータフローは、ハイレベルプログラムコードで表現され、前記動作はさらに、変更された前記画像処理ソフトウェアデータフローを実現するローレベルオブジェクトコードを生成することを含む、請求項１に記載の１つ以上の非一時的なコンピュータ記憶媒体。
6. コンピューティングシステムであって、
   １つ以上の汎用処理コアと、
   システムメモリと、
   前記システムメモリと前記１つ以上の汎用処理コアとの間で結合されたメモリコントローラと、
   コンピュータプログラム命令で符号化された１つ以上の非一時的なコンピュータ記憶媒体とを備え、前記コンピュータプログラム命令は、前記１つ以上の汎用コンピュータによって実行されると、前記１つ以上の汎用コンピュータに動作を行わせ、前記動作は、
   画像プロセッサによる実行のために、画像処理ソフトウェアデータフローの定義を受信することを含み、前記画像処理ソフトウェアデータフローは、作成側カーネルと複数の消費側カーネルとのための命令を有し、前記命令は、前記作成側カーネルに、前記画像プロセッサの第１のラインバッファにデータを書込ませる格納命令と、前記複数の消費側カーネルの各々に、前記第１のラインバッファから前記作成側カーネルによって生成されたデータを読出させるロード命令とを含み、前記動作はさらに、
   前記第１のラインバッファのデータレートが、前記複数の消費側カーネルの全てを満たすのに不十分であると判断することと、
   それに応じて、前記画像処理ソフトウェアデータフローを変更することとを含み、前記画像処理ソフトウェアデータフローは、
   前記第１のラインバッファと異なる第２のラインバッファとを含む複数のラインバッファに出力を書込む格納命令を含むように、前記作成側カーネルを変更することと、
   前記第１のラインバッファの代わりに前記異なる第２のラインバッファから前記出力を読出すロード命令を含むように、前記複数の消費側カーネルのうち１つ以上を変更することとを含む、コンピューティングシステム。
7. 前記画像プロセッサは、複数のステンシルプロセッサを含み、前記動作はさらに、前記複数のステンシルプロセッサのそれぞれのステンシルプロセッサによって実行されるべき前記作成側カーネルと前記複数の消費側カーネルの各々を割当てることを含む、請求項６に記載のコンピューティングシステム。
8. 各ステンシルプロセッサは、関連するシート生成部を有し、各カーネルの前記ロード命令は、それぞれのシート生成部に、対応するラインバッファからデータをロードさせる、請求項７に記載のコンピューティングシステム。
9. シート生成部に、対応するラインバッファからデータをロードさせることは、前記複数のステンシルプロセッサのステンシルプロセッサの２次元シフトレジスタアレイにデータをロードすることを含む、請求項８に記載のコンピューティングシステム。
10. 前記画像処理ソフトウェアデータフローは、ハイレベルプログラムコードで表現され、前記動作はさらに、変更された前記画像処理ソフトウェアデータフローを実現するローレベルオブジェクトコードを生成することを含む、請求項６に記載のコンピューティングシステム。
11. 前記バッファは、前記画像データのラインの転送グループを格納する、請求項６に記載のコンピューティングシステム。
12. 前記バッファは前記画像プロセッサのラインバッファユニットで実現され、前記画像プロセッサは、前記ラインバッファユニットと、プログラムコードの前記作成側カーネルと前記プログラムコードの前記１つ以上の消費側カーネルとをそれぞれ実行する複数の処理コアとの間で結合されたネットワークを含む、請求項１１に記載のコンピューティングシステム。
13. １つ以上のコンピュータによって行われる方法であって、
    画像プロセッサによる実行のために、画像処理ソフトウェアデータフローの定義を受信することを含み、前記画像処理ソフトウェアデータフローは、作成側カーネルと複数の消費側カーネルとのための命令を有し、前記命令は、前記作成側カーネルに、前記画像プロセッサの第１のラインバッファにデータを書込ませる格納命令と、前記複数の消費側カーネルの各々に、前記第１のラインバッファから前記作成側カーネルによって生成されたデータを読出させるロード命令とを含み、前記方法はさらに、
    前記第１のラインバッファのデータレートが、前記複数の消費側カーネルの全てを満たすのに不十分であると判断することと、
    それに応じて、前記画像処理ソフトウェアデータフローを変更することとを備え、前記画像処理ソフトウェアデータフローは、
    前記第１のラインバッファと異なる第２のラインバッファとを含む複数のラインバッファに出力を書込む格納命令を含むように、前記作成側カーネルを変更することと、
    前記第１のラインバッファの代わりに前記異なる第２のラインバッファから前記出力を読み出すロード命令を含むように、前記複数の消費側カーネルのうち１つ以上を変更することとを含む、方法。

Images