JP6820428B2 - マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成 - Google Patents

マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成 Download PDF

Info

Publication number
JP6820428B2
JP6820428B2 JP2019539225A JP2019539225A JP6820428B2 JP 6820428 B2 JP6820428 B2 JP 6820428B2 JP 2019539225 A JP2019539225 A JP 2019539225A JP 2019539225 A JP2019539225 A JP 2019539225A JP 6820428 B2 JP6820428 B2 JP 6820428B2
Authority
JP
Japan
Prior art keywords
kernel
stencil
image processing
processor
line buffer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019539225A
Other languages
English (en)
Other versions
JP2020519977A (ja
Inventor
パーク,ヒュンチュル
メイクスナー,アルバート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of JP2020519977A publication Critical patent/JP2020519977A/ja
Application granted granted Critical
Publication of JP6820428B2 publication Critical patent/JP6820428B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00General purpose image data processing
    • G06T1/20Processor architectures; Processor configuration, e.g. pipelining
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Description

発明の分野
本発明の分野は、概してコンピューティング・サイエンスに関し、より具体的には、マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成に関する。
背景
画像処理は、典型的には、アレイに編成されたピクセル値の処理を含む。ここで、空間的に編成された二次元アレイは、画像の二次元的性質を捕捉する(追加の次元は、時間(たとえば二次元画像のシーケンス)およびデータタイプ(たとえば色)を含み得る)。典型的なケースでは、アレイ化されたピクセル値は、静止画像または動きの画像を捕捉するためにフレームのシーケンスを生成したカメラによって提供される。伝統的な画像プロセッサは、典型的には、2つの極端な側面のいずれかに分類される。
第1の極端な側面は、汎用プロセッサまたは汎用状プロセッサ(たとえばベクトル命令拡張を備えた汎用プロセッサ)上で実行されるソフトウェアプログラムとして画像処理タスクを実行する。第1の極端な側面は、一般的に非常に汎用性の高いアプリケーションソフトウェア開発プラットフォームを提供するが、関連するオーバヘッド(たとえば、命令フェッチおよびデコード、オンチップおよびオフチップデータの処理、投機的実行)と組み合わされたより精細な粒子のデータ構造の使用は、究極的には、プログラムコードの実行中に、データの単位あたり、より多くのエネルギーが消費される結果となる。
第2の逆の極端な側面は、固定機能のハードワイヤード回路系をはるかに大きなデータブロックに適用する。カスタム設計された回路に直接適用される、(粒度の細かいブロックとは対照的な)より大きなデータブロックの使用は、データ単位あたりの消費電力を大幅に削減する。しかしながら、カスタム設計された固定機能回路系の使用は、一般に、プロセッサが実行することができるタスクのセットが限られる結果となる。このように、(第1の極端な側面に関連する)幅広く汎用性の高いプログラミング環境は第2の極端な側面においては欠けている。
高度に汎用性の高いアプリケーションソフトウェア開発の機会と、データ単位あたりの電力効率の向上とを両立させた技術プラットフォームは、依然として望ましいが欠けている解決策である。
概要
ある方法について説明する。この方法は、画像プロセッサ上で実行する複数のカーネルを有するプログラムのカーネル間接続のデータ転送メトリックを計算するステップを含む。画像プロセッサは、複数の処理コアと、複数の処理コアを接続するネットワークとを備える。カーネル間接続は各々、複数の処理コアのうちの1つの処理コア上で実行する作成カーネル(producing kernel)と、複数の処理コアのうちの別の処理コア上で実行する消費カーネル(consuming kernel)とを含む。消費カーネルは、作成カーネルが生成したデータに対して動作する。この方法はまた、計算したデータ転送メトリックに基づいて、複数のカーネルのうちのカーネルを、複数の処理コアのうちの対応する処理コアに割り当てるステップを含む。
したがって、汎用性がより高いアプリケーション処理を、計算およびエネルギー効率が改善された状態で使用することができる。
カーネル間接続は、カーネル間でデータを送るルートであってもよく、データ転送メトリックはたとえば、カーネル間の速度、周波数、インターフェイス(たとえばホップ)の数、および/またはカーネル間で転送されるデータのタイプを説明するものであってもよい。
任意で、画像プロセッサは複数のバッファユニットをさらに備え、バッファユニットは、カーネル間接続のデータを格納および転送する。
任意で、バッファユニットはさらに、カーネル間接続の画像のラインのグループを格納および転送するラインバッファユニットを含む。
任意で、データ転送メトリックを計算するステップはさらに、作成カーネルと消費カーネルとの間の、ネットワーク内のノーダルホップの数に基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、データ転送メトリックを計算するステップはさらに、ネットワークを介して作成カーネルと消費カーネルとの間で転送される画像のサイズに基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、カーネルを複数の処理コアのうちの対応する処理コアに割り当てるステップはさらに、プログラムの各種構成の重みを計算するステップを含み、プログラムの各構成は、複数の処理コアに対するカーネル割り当ての異なるセットを含み、特定の構成の重みの計算は、特定の構成の特定のカーネル間接続について計算したデータ転送メトリックのサブセットに基づいており、割り当てるステップはさらに、上記構成の中から、最適な重みを有する構成を選択するステップを含む。
他の局面に従い、コンピューティングシステムによって処理されるとこのコンピューティングシステムに方法を実行させるプログラムコードを含む非一時的なマシン読取可能記憶媒体が提供され、この方法は、画像プロセッサ上で実行する複数のカーネルを含むプログラムのカーネル間接続のデータ転送メトリックを計算するステップを含み、画像プロセッサは、複数の処理コアと、複数の処理コアを接続するネットワークとを備え、カーネル間接続は各々、複数の処理コアのうちの1つの処理コア上で実行する作成カーネルと、複数の処理コアのうちの別の処理コア上で実行する消費カーネルとを含み、消費カーネルは、作成カーネルが生成したデータに対して動作し、この方法はさらに、計算したデータ転送メトリックに基づいて、複数のカーネルのうちのカーネルを、複数の処理コアのうちの対応する処理コアに割り当てるステップを含む。
任意で、画像プロセッサは複数のバッファユニットを備え、バッファユニットは、カーネル間接続のデータを格納および転送する。
任意で、バッファユニットはさらに、カーネル間接続の画像のラインのグループを格納および転送するラインバッファユニットを含む。
任意で、データ転送メトリックを計算するステップはさらに、作成カーネルと消費カーネルとの間の、ネットワーク内のノーダルホップの数に基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、データ転送メトリックを計算するステップはさらに、ネットワークを介して作成カーネルと消費カーネルとの間で転送される画像のサイズに基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、カーネルを複数の処理コアのうちの対応する処理コアに割り当てるステップはさらに、プログラムの各種構成の重みを計算するステップを含み、プログラムの各構成は、複数の処理コアに対するカーネル割り当ての異なるセットを含み、特定の構成の重みの計算は、特定の構成の特定のカーネル間接続について計算したデータ転送メトリックのサブセットに基づいており、割り当てるステップはさらに、構成の中から、最適な重みを有する構成を選択するステップを含む。
任意で、処理コアは、実行レーンアレイと、二次元シフトレジスタアレイとを含む。
さらに他の局面に従い、コンピューティングシステムが提供され、コンピューティングシステムは、複数の汎用処理コアと、システムメモリと、システムメモリと複数の汎用処理コアとの間のメモリコントローラと、コンピューティングシステムによって処理されるとコンピューティングシステムに方法を実行させるプログラムコードを含む非一時的なマシン読取可能記憶媒体とを備え、この方法は、画像プロセッサ上で実行する複数のカーネルを含むプログラムのカーネル間接続のデータ転送メトリックを計算するステップを含み、画像プロセッサは、複数の処理コアと、複数の処理コアを接続するネットワークとを備え、カーネル間接続は各々、複数の処理コアのうちの1つの処理コア上で実行する作成カーネルと、複数の処理コアのうちの別の処理コア上で実行する消費カーネルとを含み、消費カーネルは、作成カーネルが生成したデータに対して動作し、この方法はさらに、計算したデータ転送メトリックに基づいて、複数のカーネルのうちのカーネルを、複数の処理コアのうちの対応する処理コアに割り当てるステップを含む。
任意で、画像プロセッサは複数のバッファユニットを備え、バッファユニットは、カーネル間接続のデータを格納および転送する。
任意で、バッファユニットはさらに、カーネル間接続の画像のラインのグループを格納および転送するラインバッファユニットを含む。
任意で、データ転送メトリックを計算するステップはさらに、作成カーネルと消費カーネルとの間の、ネットワーク内のノーダルホップの数に基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、データ転送メトリックを計算するステップはさらに、ネットワークを介して作成カーネルと消費カーネルとの間で転送される画像のサイズに基づいて、重みをカーネル間接続に割り当てるステップを含む。
任意で、カーネルを複数の処理コアのうちの対応する処理コアに割り当てるステップはさらに、プログラムの各種構成の重みを計算するステップを含み、プログラムの各構成は、複数の処理コアに対するカーネル割り当ての異なるセットを含み、特定の構成の重みの計算は、特定の構成の特定のカーネル間接続について計算したデータ転送メトリックのサブセットに基づいており、割り当てるステップはさらに、構成の中から、最適な重みを有する構成を選択するステップを含む。
任意で、処理コアは、実行レーンアレイと、二次元シフトレジスタアレイとを含む。
なお、上記特徴のうちのいずれかの特徴を、本発明のいずれかの特定の局面または実施形態のために使用してもよい。
図面
以下の説明および添付の図面を用いて本発明の実施形態を明らかにする。
ステンシルプロセッサアーキテクチャのハイレベル図を示す。 画像プロセッサアーキテクチャのより詳細な図を示す。 画像プロセッサアーキテクチャのさらに詳細な図を示す。 画像プロセッサが実行可能なアプリケーションソフトウェアプログラムを示す図である。 図4のアプリケーションソフトウェアプログラムを画像プロセッサ上で実行するための構成を決定する実施形態を示す図である。 図4のアプリケーションソフトウェアプログラムを画像プロセッサ上で実行するための構成を決定する実施形態を示す図である。 アプリケーションソフトウェアプログラムを画像プロセッサ上で実行するための構成を決定する方法を示す図である。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す図である。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す図である。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す図である。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す図である。 画像データのライングループへの解析、ライングループのシートへの解析、および重なり合うステンシルでシート上で実行される操作を示す図である。 ステンシルプロセッサの実施形態を示す図である。 ステンシルプロセッサの命令ワードの実施形態を示す図である。 ステンシルプロセッサ内のデータ計算ユニットの一実施形態を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 二次元シフトアレイおよび実行レーンアレイを使用して、重なり合うステンシルで近隣の出力ピクセル値の対を決定する例を示す図である。 統合された実行レーンアレイおよび二次元シフトアレイのための単位セルの実施形態を示す図である。 典型的なコンピューティングシステムを示す図である。
詳細な説明
1.0 固有画像プロセッサアーキテクチャ
当該技術において知られているように、プログラムコードを実行するための基本回路構造は、実行段とレジスタ空間とを含む。実行段は命令を実行するための実行ユニットを含む。命令を実行するための入力オペランドが、レジスタ空間から実行段に与えられる。実行段が命令を実行したことによって生成された結果は、レジスタ空間に書き戻される。
従来のプロセッサ上でソフトウェアスレッドを実行するには、実行段を通して一連の命令を順次実行する必要がある。演算は、1つの入力オペランドセットから1つの結果が生成されるという意味において「スカラー」である、というのが最も一般的である。しかしながら、「ベクトル」プロセッサの場合は、実行段が命令を実行すると、入力オペランドのベクトルから、結果のベクトルが生成される。
図1は、二次元シフトレジスタアレイ102に結合された実行レーンのアレイ101を含む固有画像プロセッサアーキテクチャ100のハイレベル図を示す。ここで、実行レーンアレイにおける各レーンは、プロセッサ100がサポートする命令セットを実行するのに必要な実行ユニットを含む離散実行段とみなすことができる。各種実施形態において、各実行レーンは、同一のマシンサイクルにおいて、実行すべき同一の命令を受け、プロセッサは、二次元のシングルインストラクションマルチプルデータ(SIMD)プロセッサとして動作する。
各実行レーンは、二次元シフトレジスタアレイ102内の対応する位置において、自身の専用レジスタ空間を有する。たとえば、コーナーの実行レーン103は、コーナーシフトレジスタ位置104において自身の専用レジスタ空間を有し、コーナーの実行レーン105は、コーナーシフトレジスタ位置106において自身の専用レジスタ空間を有し、他も同様である。
加えて、シフトレジスタアレイ102は、その内容をシフトすることにより、各実行レーンが、自身のレジスタ空間から、前のマシンサイクル中において別の実行レーンのレジスタ空間内にあった値に対して直接動作できるようにすることが可能である。たとえば、水平方向に+1シフトすると、各実行レーンのレジスタ空間は、その左端に隣接するレジスタ空間から値を受ける。水平方向軸に沿って値を左右両方向にシフトすることが可能でありかつ鉛直方向軸に沿って値を上下両方向にシフトすることが可能であることで、プロセッサは画像データのステンシルを効率良く処理することができる。
ここで、当該技術において知られているように、ステンシルは、基本データ単位として使用される、画像表面領域のスライスである。たとえば、出力画像内の特定の画素位置の新たな値は、この特定の画素位置が中心にある入力画像領域内の画素値の平均として計算することができる。たとえば、ステンシルの寸法が3画素×3画素である場合、この特定の画素位置は3×3画素アレイの中央画素に対応していればよく、平均はこの3×3画素アレイ内の9画素すべてについて計算すればよい。
図1のプロセッサ100の各種動作の実施形態に従うと、実行レーンアレイ101の各実行レーンは、出力画像内の特定の位置の画素値を計算する役割を果たす。したがって、上記3×3ステンシルの平均の例を続けると、入力画素データが最初にロードされ、シフトレジスタ内における8つのシフト動作からなる連系シフトシーケンスの後に、実行レーンアレイ内の各実行レーンは、そのローカルレジスタ空間内に、対応する画素位置に対応する平均を計算するのに必要な9画素値すべてを収容していることになる。すなわち、プロセッサは、たとえばそれぞれが隣り合う出力画像画素位置を中心とする、重なり合う複数のステンシルを、同時に処理することができる。図1のプロセッサアーキテクチャは、特に画像ステンシルの処理に長けているので、ステンシルプロセッサと呼ぶこともできる。
図2は、複数のステンシルプロセッサ202_1〜202_Nを有する画像プロセッサのアーキテクチャ200のある実施形態を示す。図2からわかるように、アーキテクチャ200は、複数のステンシルプロセッサユニット202_1〜202_Nおよび対応するシート生成ユニット203_1〜203_Nに、ネットワーク204(たとえば、ネットワークオンチップ(NOC)(オンチップスイッチネットワーク、オンチップリングネットワークまたはその他の種類のネットワークを含む))を介して相互接続された、複数のラインバッファユニット201_1〜201_Mを含む。ある実施形態において、いずれのラインバッファユニット201_1〜201_Mも、ネットワーク204を介していずれかのシート生成部203_1〜203_Nおよび対応するステンシルプロセッサ202_1〜202_Nに接続し得る。
プログラムコードがコンパイルされ対応するステンシルプロセッサ202にロードされて、ソフトウェア開発者によって以前に定義された画像処理動作を実行する(プログラムコードは、たとえば、設計および実装に応じて、このステンシルプロセッサに関連するシート生成部203にロードされてもよい)。したがって、各ステンシルプロセッサ202_1〜202_Nは、より一般的に、処理コア、プロセッサコア、コア等として特徴付けることができ、画像プロセッサ全体は、マルチコア画像プロセッサとして特徴付けることができる。少なくともいくつかの例では、画像処理パイプラインを、第1のパイプラインステージ用の第1のカーネルプログラムを第1のステンシルプロセッサ202_1にロードし、第2のパイプラインステージ用の第2のカーネルプログラムを第2のステンシルプロセッサ202_2にロードするなどして、実現することができ、たとえば第1のカーネルはパイプラインの第1ステージの機能を実行し第2のカーネルはパイプラインの第2ステージの機能を実行し、追加の制御フロー方法がインストールされて、出力画像データをパイプラインの1つのステージから次のステージに渡す。
他の構成では、画像プロセッサは、同じカーネルプログラムコードを実行する2つ以上のステンシルプロセッサ202_1,202_2を有する並列マシンとして実現することができる。たとえば、画像データの高密度かつ高データレートのストリームが、各々が同じ機能を実行する複数のステンシルプロセッサにフレームを分散させることによって処理されてもよい。
さらに他の構成では、カーネルの本質的に任意の有向非巡回グラフ(DAG)の画像プロセッサへのロードを、それぞれのステンシルプロセッサをそれら自身のプログラムコードのカーネルで構成し、適切な制御フローフックをハードウェアに構成して、出力画像をDAG設計における1つのカーネルから次のカーネルの入力に向けることによって、行ってもよい。
一般的なフローとして、画像データのフレームは、マクロI/Oユニット205で受信され、フレーム単位でラインバッファユニット201のうちの1つ以上に渡される。特定のラインバッファユニットは、その画像データのフレームを、「ライングループ」と呼ばれる画像データのより小さな領域に解析し、次いでライングループをネットワーク204を介して特定のシート生成部に渡す。ある完全な(full)単数のライングループを、たとえば、フレームの複数の連続した完全な行または列のデータで構成することができる(簡潔にするために、本明細書では主に連続した行を意味する)。シート生成部は、画像データのライングループを、「シート」と呼ばれる画像データのより小さな領域にさらに解析し、そのシートを対応するステンシルプロセッサに提示する。
単一入力の画像処理パイプラインやDAGフローの場合、一般に、入力フレームは、同じラインバッファユニット201_1に向けられ、それは、画像データをライングループに解析し、ライングループをシート生成部203_1(対応するステンシルプロセッサ202_1はパイプライン/DAGにおいて第1のカーネルのコードを実行している)に向ける。ステンシルプロセッサ202_1による、それが処理するライングループでの動作が終了した後、シート生成部203_1は、出力ライングループを「下流」ラインバッファユニット201_2に送信する(ある使用例では、出力ライングループは、先に入力ライングループを送信したのと同じラインバッファユニット201_1に送り返すことができる)。
自身のそれぞれの他のシート生成部およびステンシルプロセッサ(たとえば、シート生成部203_2およびステンシルプロセッサ202_2)上で実行されるパイプライン/DAGにおける次のステージ/動作を表す1つ以上の「消費側(consumer)」カーネルは、下流ラインバッファユニット201_2から、第1のステンシルプロセッサ202_1によって生成された画像データを受信する。このようにして、第1のステンシルプロセッサ上で実行される「作成側(producer)」カーネルは、その出力データが、第2のステンシルプロセッサ上で実行される「消費側」カーネルに転送され、消費側カーネルは、パイプラインまたはDAG全体の設計と整合する作成側カーネルの後に次のタスクのセットを実行する。
先に図1に関して示唆したように、各ステンシルプロセッサ201_1〜202_Nは、画像データの複数の重なり合うステンシルを同時に扱うように設計されている。複数の重なり合うステンシルおよびステンシルプロセッサの内部ハードウェア処理能力は、シートのサイズを効果的に決定する。ここでも、先に述べたように、ステンシルプロセッサ202_1〜202_Nのうちのいずれかのステンシルプロセッサ内で、実行レーンのアレイが一斉に動作して、複数の重なり合うステンシルによってカバーされている画像データ表面領域を同時に処理する。
加えて、各種実施形態において、画像データのシートが、ステンシルプロセッサ202の二次元シフトレジスタアレイに、このステンシルプロセッサに対応する(たとえばローカル)シート生成部203によってロードされる。シートおよび二次元シフトレジスタアレイ構造の使用は、大量のデータを、大量のレジスタ空間に、たとえば、処理タスクが実行レーンアレイによってその直後に直接データ上で実行される単一のロード動作として移動することによって、電力消費の改善を効果的に提供すると考えられている。さらに、実行レーンアレイおよび対応するレジスタアレイの使用は、容易にプログラマブル/設定可能な異なるステンシルサイズを提供する。ラインバッファユニット、シート生成部、およびステンシルプロセッサに関するその他の詳細をさらに以下のセクション3.0において示す。
図3は、図2の画像プロセッサの具体的なハードウェア実装例のより詳細な実施形態を示す。図3からわかるように、図2のネットワーク204はリングトポロジー304で実現されており、ラインバッファユニット301とシート生成部/ステンシルプロセッサコア302との間の各交差部に4×4ネットワークノード314がある。簡潔にするために、図3は、ラインバッファユニット301_4とシート生成部/ステンシルプロセッサコア302_4との間にあるネットワークノードのみに符号314を付している。
ここで、シート生成部/ステンシルプロセッサコア302_1〜302_8は各々、ステンシルプロセッサおよびそれに対応するシート生成部双方を含むものと理解される。簡潔にするために、シート生成部/ステンシルプロセッサコア302_1〜302_8各々を、以下簡単にステンシルプロセッサコアまたはコアと呼ぶ。8つのラインバッファユニット301_1〜301_8および8つのコア302_1〜302_8が図3の特定の実施形態に示されているが、ラインバッファユニットおよび/またはコアの数が異なる各種アーキテクチャも可能であることが理解されるはずである。リングトポロジー以外のネットワークトポロジーも可能である。
図3の画像プロセッサに関して、リングネットワーク304は、1)I/Oユニット305が入力データを任意のラインバッファユニット301_1〜301_8(または任意のコア302_1〜302_8)に送ることを可能にし、2)任意のラインバッファユニット301_1〜301_8がライングループを任意のコア302_1〜302_8に転送することを可能にし、3)任意のコア302_1〜302_8がその出力データを任意のラインバッファユニット301_1〜301_8に送ることを可能にし、かつ、4)任意のラインバッファユニット301_1〜301_8が画像プロセッサの出力データをI/Oユニット305に送ることを可能にする。このため、豊富な各種ソフトウェアカーネルロードオプションおよび内部ネットワーク構成が可能である。すなわち、理論上は、複数のカーネルからなる任意のソフトウェアアプリケーションをプロセッサの各種コア302上で実行するために、任意のカーネルを任意のコアにロードすることができ、任意のラインバッファユニットを、入力/出力データを任意のコアにソースする/からシンクするように構成することができる。
2.0 画像プロセッサ上のアプリケーションソフトウェアの構成
図4は、図3の画像プロセッサにロードすることができる典型的なアプリケーションソフトウェアプログラムまたはその一部を示す。図4からわかるように、プログラムコードは、入力画像データ401の1つ以上のフレームを処理することにより、入力画像データ401に対して何らかの全変換を実現すると予想することができる。この変換は、アプリケーションソフトウェア開発者によって表現された調整されたシーケンスで入力画像データに対して動作するプログラムコード402の1つ以上のカーネルの動作によって実現される。
図4の例において、全変換は、まず各入力画像を第1のカーネルK1で処理することによって実現される。次に、カーネルK1が生成した出力画像がカーネルK2によって処理される。次に、カーネルK2が生成した出力画像がそれぞれカーネルK3_1〜K3_2によって処理される。次に、カーネルK3_1/K3_2が生成した出力画像がカーネルK4によって処理される。図3の特定の例において、カーネルK3_1およびK3_2は、たとえば、異なる画像処理動作を実行する異なるカーネルであってもよい(たとえば、カーネルK3_1は第1の特定タイプの入力画像に対して動作し、カーネルK3_2は異なる第2のタイプの入力画像に対して動作する)。
簡潔にするために、4つのカーネルK1〜K4のみを示している。図3の画像プロセッサハードウェアアーキテクチャの実施形態に関して、各カーネルが異なるステンシルプロセッサ上で動作する基本構成においては、おそらく、プロセッサのすべてのコア402があるカーネルを実行する前に、4以上のカーネルがカーネルK4から流れる可能性があることに注意する(図4の4カーネルフローは、図3のプロセッサのコアの2分の1しか利用していない)。
また、図4は、異なる画像サイズがさまざまなカーネル入力/出力に対応付けられる場合があることを示す。ここで、先に述べたように、画像プロセッサは一連の入力フレーム401を受ける。入力フレーム各々のサイズ(たとえば、いずれか1つのフレーム内の画素の総数)は、正規化された単位元のサイズ(1.0)として示されている。カーネルK1は、入力フレーム401を処理することにより、各々が入力フレームの4倍のサイズを有する出力フレーム411を生成する(カーネルK1の出力フレームサイズはサイズ4.0として示されている)。画像サイズの増大は、たとえば、カーネルK1が入力画像フレーム401に対してアップサンプリングを実行にすることによって実現できる。
カーネルK2は、カーネルK1が生成した(より大きな)出力画像フレーム411を処理し、各々が単位元サイズ(1.0)を有するより小さな出力画像フレーム412_1および412_2を生成する。サイズの減少は、たとえば、カーネルK2がカーネルK1の出力画像411に対してダウンサンプリングを実行することによって実現できる。カーネルK3−1は、フレーム412_1を処理することにより、正規化サイズ4.0を有するより大きな出力フレームを生成し、カーネルK3_2は、フレーム412_2を処理することにより、正規化サイズ5.0を有するさらに大きな出力フレームを生成する。カーネルK4は、カーネルK3_1およびK3_2の出力画像413_1および413_2を処理することにより、単位元サイズ1.0の出力フレームを生成する。
図4の例からわかるように、たとえば、消費カーネルによって処理されるフレームであって、作成カーネルによって生成されたフレームのサイズに応じて、量が異なるデータをカーネル間で送ることができる。ここで、再び図3の典型的なハードウェア実装例を参照すると、これは、大量のデータを互いに送る作成カーネルおよび消費カーネルを、隣り合うまたは少なくとも互いに近接するステンシルプロセッサ上に置いて、全体的なプロセッサ効率を改善することで、大量のデータをリング304に沿って長距離にわたって送ることを回避する。
したがって、先に図3について述べたように、プロセッサの実装例300は、カーネルとコアのさまざまな配置およびこれがサポートできるカーネル間の相互接続という点において、極めて汎用性が高いことから、プロセッサ300上で実行されるように構成されるアプリケーションソフトウェアプログラムのデータフローを解析して、そのカーネルを特定のコア上に配置しそのラインバッファを特定のカーネル/コアをソース/シンクするように構成して、より大きなサイズのデータフローがネットワーク304に沿って経由するホップを少なくすることができ、たとえば、サイズがより小さいデータフローはネットワーク304に沿ってより多くのホップを経由することができるようにすることが、適切である。
図5および図6は、アフィニティマッパー(affinity mapper)ソフトウェアプログラムの計算の一部を図示する。これは、アプリケーションソフトウェアプログラムを解析し、その特定のカーネルを特定のコアにマッピングして、プロセッサ内で効率的なデータフローが実現されるようにする。説明し易くするために、図5および図6は、図4のアプリケーションソフトウェアフローの代表的な計算を示す。以下の説明からより明らかになるように、アフィニティマッパーは、アプリケーションソフトウェアプログラムの各カーネルを特定の処理コアにマッピングする、より最適な全体構成を特定するために、可能な各種のカーネル−コア配置の組み合わせを経由する。
これらの計算の一部として、マッパーは、特定の接続が実装された場合にそれが如何に非効率または高負担であるかを示す、各種接続のメトリックを判断する。各種実施形態において、このマッパーは、解析されている各種接続に重みを割り当てる。ネットワークリングに沿って経由するノーダルホップ(nodal hop)がより多いおよび/またはより長い距離にわたる、より大きなデータ転送にはより大きな重みを割り当て、ネットワークリングに沿って経由するノーダルホップがより少ないおよび/またはより短い距離にわたる、より小さなデータ転送には、より小さな重みを割り当てる。その他可能なファクタは、例として、たとえばより遅いまたはより速い転送速度による、接続に沿うより大きなまたはより小さな伝搬遅延を含み得る。
したがって、より一般的には、重みがより大きいことは、内部プロセッサデータ転送効率がより低いことおよび/またはデータ移送の負担がより大きいことに相当する。各種実施形態において、全体の重みが最も小さくなる構成が、最終的にプロセッサの正しい構成として選択される。これに代わる実施形態は、負担がより小さいデータ転送に対してより大きな重みを割り当てて合計の重みが最も大きくなる構成を見出そうとすることを選択できる。説明し易くするために、本明細書の残りの部分では、効率がより低いまたは負担がより大きい接続に対してより大きな重みを割り当てる手法を主に説明する。それとは関係なく、各種実施形態において、完全な構成は、1)どのカーネルがどのコア上で動作するか、2)どのラインバッファがどのカーネルにソース(フィード)するか、および3)どのラインバッファがどのカーネルからシンクする(どのカーネルからの出力データを受ける)かを特定することに相当する。
簡潔にするために、図5および図6の典型的なアフィニティマッピングプロセスは、I/Oユニット305と、入力フレームを第1のカーネルK1にフィードするラインバッファユニットとの間の接続には対処していない。図5は、図4のK1からK2へのカーネル接続に関する典型的な一組の計算の概要を示す。ここで、先に述べたように、第1の「作成」カーネル(K1)は、第1のコア上で動作し、その出力データをラインバッファユニットに転送する。そうすると、ラインバッファユニットは、第1のカーネル(K1)から受けたこのデータを、第2の「消費」カーネル(K2)に転送する。
ある実施形態において、含まれる探索空間のサイズを保つとともに、ラインバッファユニットのメモリリソースの割り当てを単純化するために、カーネル間接続を、介在するラインバッファユニットを考慮せずに、マッピングアルゴリズムによってモデル化する。すなわち、実際には作成カーネルから消費カーネルへのデータ転送は本来、介在するラインバッファユニットによって待ち行列に入れられるが、ラインバッファユニットの存在は、まずマッピングアルゴリズムによって無視される。
図5は、カーネルK1がその出力データをその消費カーネルK2に送る各種構成の重み割り当てを示す。この特定の接続を図5では「K1−>K2」で示す。第1のテーブル501(「K1−>K2」で示される)は、カーネルK1と消費カーネルK2との間の、利用できる/可能な接続のセットを示す。ここで、図3のプロセッサ実装形態をターゲットアーキテクチャとして使用すると、すべての接続が可能である。すなわち、第1の作成カーネルK1が、処理コア302_1〜302_8のうちの特定の1つにマッピングされると仮定すると、その対応する消費カーネルK2は、残り7つの処理コアのうちのいずか1つに配置することができる。
テーブル501に記載されている、「Path_1」および「Path_2」でそれぞれ示された第1および第2の接続は、カーネルK1がその出力データをその隣接コアのうちのいずれか1つに送ることに相当する(消費カーネルK2が動作する場合)。たとえば、図3を参照して、カーネルK1がコア302_2上で動作している場合、Path_1は、カーネルK2がコア302_1上で動作していることに相当し、Path_2は、カーネルK2がコア302_3上で動作していることに相当する。2つ以上の経路、Path_3およびPath_4は、カーネルK1の出力データが、K1のコアに隣接するコアの反対側にある処理コアのうちの1つに送られていることに相当する。たとえば、カーネルK1がコア302_2上で動作していると再び仮定すると、Path_3はカーネルK2がコア302_4上で動作していることに相当し、Path_4はカーネルK2がコア302_8上で動作していることに相当する。
ここで、Path_1およびPath_2各々にノーダルホップ距離1.0が割り当てられていることに注目する。ノーダルホップ距離の1単位は、ネットワークリング304に沿う1論理単位長に相当する。すなわち、あるコアから、このコアの真隣のコアのうちのいずれかまでの距離に、ノーダルホップ距離1.0が割り当てられる。Path_1およびPath_2はいずれも、K1の出力データをその隣接コアのうちの一方に送るので、これらの経路はいずれも、ノーダルホップ距離1.0が割り当てられる。これに対し、Path_3およびPath_4は各々、テーブル501のノーダルホップ距離2.0を有する。なぜなら、先に述べたように、Path_3およびPath_4は、カーネルK1のデータが、カーネルK1が動作するコアから、リングに沿って2つのコア位置分転送されることに相当するからである。
引き続きこの手法の場合、Path_5およびPath_6は、K1の出力データを、K1のコアから3ノーダルホップ分離れたコアのうちのいずれかに転送することに相当する(これらの経路のノーダルホップ距離は3.0)。最後に、Path_7は、ノーダルホップ距離が4.0であり、ネットワークリング上においてK1のコアと反対側に位置する(1つの)経路に相当する。たとえば、カーネルK1がコア302_2上で動作している例を再び使用すると、Path_8は、カーネルK1の出力データがコア302_6に転送されることに相当する。
テーブル501に記載されている経路は各々、ノーダルホップ距離の倍数に相当する、対応付けられた重みと、この接続に沿って転送されている画像データのサイズとを有する。K1からK2への接続の場合、図4のアプリケーションソフトウェアプログラムの記述から、画像データのサイズは4.0である。したがって、図4に記載されている特定の経路の各ノーダルホップ距離を4.0で乗算することにより、この経路の総重みを求める。よって、K1−>K2テーブル501は、カーネルK1から、K1がそのデータを送ることができる、プロセッサ内の他の各種コアまでの、可能なすべての経路の総重みを示す。
次に、引き続きK1−>K2接続の可能な各種経路を示すK1−>K2テーブル501を用いると、図5は、これらの経路のうちの1つについてアフィニティマッパーが実行する次のレベルの解析をさらに示す。ここで、K2−>K3_1テーブル502は、K1−>K2テーブル501のPath_1について、K2−>K3_1接続(K2の出力データをK3_1カーネルに送る)に使用できる、残りの利用可能な接続を示す。Path_1は、K1がその出力データをカーネルK1を実行しているコアに隣接するコアに転送する構成に相当する、と先に述べたことからわかるように、K2−>K3_1テーブル502は、この特定の構成が機能している場合の、残りの経路の選択肢を示す。
ここで、K2−>K3_1テーブル502において、経路Path_11が、ノーダルホップが1である唯一の経路であることに注目する。これは、ノーダルホップ1に相当するコアのうちの一方が、既にカーネルK1の実行のために消費されているので、カーネルK2からのデータを受けるために利用できないことが原因である(この例は、異なるカーネルを異なるコア上で実行することを想定している)。言い換えると、図5のこの特定のK2−>K3_1テーブル502の目的は、カーネルK1を実行しているコアを利用できないことを認識した上で、カーネルK3_1を、利用できるコア上に有効配置することである。
ここで、Path_11は、カーネルK2を実行しているコアの真隣の、利用できる残り1つのコア上に、カーネルK3_1が配置されることに相当する。再びPath_1の例、すなわち、カーネルK1が図3のコア302_2上で実行されカーネルK1がその出力データを、コア301_2上で動作するカーネルK2に転送する例において、Path_11は、カーネルK2がその出力データを、K3_1が動作するコア301_3に送ることに相当する。同様に、Path_12およびPath_13は、K3_1が、コアK2が動作するコアから2ホップ分離れたコアのうちの一方で動作することに相当する。再び、図5のPath_1が、たとえば、カーネルK1がコア302_1上で動作しカーネルK2がコア302_2上で動作することに相当すると認識すると、Path_12は、カーネルK3_1がコア302_4上で動作することに相当し得るものであり、Path_13は、カーネルK3_1がコア302_8上で動作することに相当し得るものである。残りの経路Path_14〜Path_16は、カーネルK3_1が動作するコアが、ネットワークリング上においてカーネルK2が動作するコアからより遠くに移動するときの、対応するノーダルホップを示す。なお、図4において、K2からK3_1への接続は画像サイズ1.0を維持しており、そのため、テーブル501の各経路の総重みは、ノーダルホップ距離に等しい(ノーダルホップ距離を単位元によって因数分解することにより経路の総重量を求める)。
ここで、各固有経路名は、プロセッサを通る固有経路に対応する。K2−>K3_1テーブル502に記載されているすべての経路は、K1−>K2テーブル501のPath_1から始まっているので、K2−>K3_1テーブル502に記載されている各経路は、必然的に、カーネルK1がその出力データを、K2が動作する隣接コアのうちの1つに転送することを含んでいる。したがって、Path_11は、この接続だけでなく、K2が動作するコアの真隣の、残っている唯一の利用できるコアへの接続も含み得る。同様に、Path_12は、K1からK2への1ホップ接続と、K2のコアから2ホップ分離れたコアのうちの1つへの接続を含むものとして定義することができる(また、Path_12はこのようなコアのうちの他方への経路として定義される)。なお、どの特定のコアでK1が動作するかを明確に定義する必要はない。なぜなら、この構成は、(最後にどのコアで終わることになるとしても)リング上におけるK1のコアの位置からのオフセットとして定義できるからである。
図5に示されるK2−>K3_1テーブル502は、テーブル501のPath_1が有効であるときに利用できる接続のみを示す。各種実施形態において、アフィニティマッパーは、K1−>K2テーブル501に示される経路各々について同様の次の解析を実行する。すなわち、K1−>K2テーブル501が7つの異なる経路を示すことに注目し、アフィニティマッパーは、K2−>K3_1テーブル502と同様の、7つのテーブルを有効に計算するであろう。しかしながら、これらのテーブルは、比較的多様なノーダルホップおよび重みの値を含むことで、テーブル501に反映されている、対応する異なる基本経路をそれぞれ反映するであろう。たとえば、K2−>K3_1テーブル502は、1.0ノーダルホップを1つだけ含んでいるが、その理由は、K2が動作しているコアに隣接するあるコアは(K1がそこで動作しているので)、K2のデータの消費に利用できないからである。しかしながら、K1−>K2テーブル501の、Path_1以外の経路のいずれかの経路から生成された、任意の次のテーブルでは、2つの1.0ノーダルホップを利用できるであろう。
図6は、図5のPath_11が有効であるときに適用される、アフィニティマッパーが実行するより深い次のレベルの計算の一例を示す。ここで、上述のように、Path_11は、K1がその出力データを真隣のコアのうちの1つ(K2が動作するコア)に転送しK2がその出力データを残りの利用できる唯一の隣接コア(K3_1が動作するコア)に転送する構成に、対応する。たとえば、K1が図3のコア302_2上で動作しK2がコア302_3上で動作する場合、Path_11は必然的に、コア302_4上で動作するK3_1を含む。図6のK2−>K3_2テーブル601として示される、計算の次のレベルは、Path_11が有効である場合、K2がそのデータをK3_2による消費のためにどのコアに転送するかを決定する。テーブル601を参照して、ノーダルホップが1.0である経路は利用できないことに注目する。ここで、Path_11の構成において、K2のコアに隣接するコアはどちらも利用されている(一方はK1の実行のため、他方はK3_1の実行のため)。このため、最も近いコアは、2.0ノーダルホップ分離れている。テーブル601の総重みも、単位元によって因数分解される。なぜなら、図4によると、カーネルK2からカーネルK3_2に送られる画像フレームのサイズも1.0であるからである。
K3_1−>K4テーブル602は、テーブル601のK2−>K3_2経路のPath_112が有効である場合に可能な経路および対応する総重みを示す。ここで、Path_112は、K1およびK3_1が、K2のコアの真隣のコア上で動作しK3_2がK1の真隣のコアまたはK3_1のコアの真隣のコア上で動作する構成に、対応する。Path_112が、K3_2がK1のコアの次のコア上で動作する構成に対応すると想定すると、K4が動作するコアは、4つ残っていることになる。これら4つのコアは、K3_1のコアから1ホップ分離れているコア、K3_1のコアから2ホップ分離れているコア、K3_1のコアから3ホップ分離れているコア、および、K3_1のコアから4ホップ分離れているコアである。たとえば、K1がコア302_2上で動作し、K2がコア302_3上で動作し、K3_1がコア302_4上で動作し、K3_2がコア302_1上で動作する場合、K4は、K3_1のコア(302_4)からそれぞれ1.0、2.0、3.0、および4.0ノーダルホップ分離れている、コア302_5、302_6、302_7、および302_8のうちのいずれかに置くことができる。テーブル604は、これらのオプションを適切な重みで反映する。K4を置くことで、図4のアプリケーション構造におけるカーネルからコアへのマッピングは終了する。
なお、図5から図6までの各レベルの計算を経ることで、利用できる経路の数は連続的に減少し、連続的に深くなる計算のスレッドによって表される特定の構成に対するコアの現在のコミットメントを反映する。再び、各種実施形態において、アフィニティマッパーは、可能なすべての接続からすべてのレベルを調査/計算する。各種レベルを経由する固有の計算の各スレッドは、特定のコア上の特定のカーネルの異なる構成に対応する。各スレッドは、総重みを、選択された経路からなる特定のセットに沿って蓄積し、結果として、完全なスレッド/構成の最終的な重みが得られる。総重みが最も小さいスレッドを、プロセッサのアプリケーションソフトウェアプログラムの構成として選択する。
各種実施形態において、カーネルからコアへのマッピングが定められた後に、バッファ(待ち行列)がラインバッファユニットに割り当てられる。図2および図3に関して先に述べたように、ラインバッファユニットは、たとえば、作成カーネルから送られた画像データのライングループを受け、これらのライングループを、消費カーネルに転送する前に待ち行列に入れる。ここで、1つの作成側/消費側接続のために待ち行列に入れること(queuing)を、「バッファ」と呼ぶ場合がある。バッファは、対応する待ち行列を実現するために消費する、対応するラインバッファユニットメモリ空間量を有する。ここで、1つのラインバッファユニットを、複数のバッファを実現するように構成することができる。ある実施形態において、ラインバッファユニットは各々、メモリ空間量が限られているので、特定のラインバッファユニットに割り当てられるすべてのバッファの合計サイズは、ラインバッファユニットのメモリリソースの内部に適合するものでなければならない。
ある実施形態において、アプリケーションソフトウェアプログラムにおける各バッファ、およびその対応するメモリ消費フットプリントを定める。次に、バッファごとに、マッピングアルゴリズムは、バッファの作成コアまでの距離を基準として分類されたラインバッファユニットのリストを作成する(ここでは、バッファの作成カーネルのコアに最も近いラインバッファユニットをリストの一番目にし、バッファの作成カーネルのコアから最も遠いラインバッファユニットをリストの最後にする)。次に、このアルゴリズムは、バッファを、このバッファを収容するメモリ空間を有する、リスト上で最もランクが高いラインバッファユニットに、割り当てる。マッピングアルゴリズムは、すべてのバッファが考慮されラインバッファユニットに割り当てられるまで、このプロセスに従い各バッファを順次処理する。
カーネルマッピングおよびバッファ割り当ては、たとえば、より高いレベルのアプリケーションソフトウェアプログラムコードをより低いレベルのオブジェクト(実行可能な)プログラムコードにコンパイルするコンパイラによって実行することができる。コンパイラは、たとえば、可能なすべての内部カーネル構成および接続を表す可能なすべてのスレッドの総重みを計算することで、最も低いスレッド/構成を特定できるようにし、どのバッファがどのラインバッファユニットに割り当てられるかを定める。そうすることにより、コンパイラは、どの特定のラインバッファユニットに、特定のコア上の各作成カーネルがその出力データを送るかを特定し、どのコア上のどの消費カーネルに、各ラインバッファユニットがその待ち行列に入れたデータを転送するかを特定する。この特定は、どのカーネルをどのコア上で実行するか(または少なくともカーネル相互の位置オフセット)を調整することを含む。選択された構成を、たとえば、コンパイルされたアプリケーションソフトウェアに付随するメタデータに記録する。次に、このメタデータを使用して、たとえば、特定の値をカーネルおよび/またはプロセッサの構成レジスタ空間に入力することにより、選択した構成を、アプリケーションソフトウェアプログラムを実行のために画像プロセッサにロードすることの一部として、物理的に有効にする。
上記図5および図6の手法は、データを格納し接続の経路を通して転送するラインバッファユニットの存在を無視するカーネル間接続に重みを割り当てることに向けられているが、その他の実施形態は、さらに細分化して、作成カーネルからラインバッファユニットまでの重みを決定し、ラインバッファユニットから消費カーネルまでの重みを決定するようにしてもよい。しかしながら、このような手法は、図5および図6の手法と比較すると、探索空間を大幅に拡大する。バッファ割り当てをこのような接続に割り当ててもよく、そうすると探索空間のオーバヘッドを増す可能性がある。
図5および図6の説明は、図3の画像プロセッサアーキテクチャを有するハードウェアプラットフォームのためのアプリケーションソフトウェアプログラムを決定することに向けられているが、上記教示はその他代替の各種実施形態に適用できることに注目する。たとえば、図3の画像プロセッサの実装例は、同一数のラインバッファユニットおよびコアを備える。その他の実装形態ではラインバッファユニットおよびコアの数が異なっていてもよい。
またさらに、先に述べたように、ラインバッファユニット301は、画像のラインのグループを転送する。代替の実装形態は、必ずしも特にライングループを受けて転送する必要はない。また、図3の画像プロセッサはリングネットワーク304を含むが、その他のタイプのネットワークを使用することもできる(たとえば、スイッチドネットワーク、従来のマルチドロップバスなど)。さらに、コアは、二次元実行レーンアレイまたは二次元シフトレジスタアレイを有するシートプロセッサまたはステンシルプロセッサを含む必要はない。
図7は上述の方法を示す。この方法は、画像プロセッサ701上で実行する複数のカーネルを有するプログラムのカーネル間接続のデータ転送メトリックを計算することを含む。画像プロセッサは、複数の処理コアと、これら複数の処理コアを接続するネットワークとを含む。カーネル間接続は各々、複数の処理コアのうちの1つの処理コア上で実行する作成カーネルと、複数の処理コアのうちの別の処理コア上で実行する消費カーネルとを含む。消費カーネルは、作成カーネルが生成したデータに対して動作する。この方法はまた、計算したデータ転送メトリックに基づいて、複数のカーネルのうちのカーネルを、上記複数の処理コアのうちの対応する処理コアに割り当てることを含む。
3.0 画像プロセッサ実装の実施形態
図8a〜図8eから図12は、本明細書において先に詳細に説明した画像プロセッサおよび関連するステンシルプロセッサの各種実施形態の動作および設計に関するさらに他の詳細を示す。図2のラインバッファユニットがライングループをステンシルプロセッサに関連するシート生成部に与えるという上記説明を再び参照して、図8a〜図8eは、ラインバッファユニット201の解析アクティビティ、およびシート生成部ユニット203のより微細な粒子の解析アクティビティ、ならびにシート生成部ユニット203に結合されるステンシルプロセッサのステンシル処理アクティビティの両方のハイレベルの実施形態を示す。
図8aは、画像データ801の入力フレームの一実施形態を示す。図8aはまた、ステンシルプロセッサが動作するように設計された3つの重なり合うステンシル802(各々3ピクセル×3ピクセルの寸法を有する)の概要を示す。各ステンシルがそれぞれ出力画像データを生成する出力ピクセルは、ベタ黒で強調表示される。簡潔にするために、3つの重なり合うステンシル802は、垂直方向にのみ重なるように示されている。実際には、ステンシルプロセッサは、垂直方向および水平方向の両方に重なるステンシルを有するように設計されてもよいことを認識することが適切である。
図8aに見られるように、ステンシルプロセッサ内の垂直に重なり合うステンシル802のために、フレーム内に単一のステンシルプロセッサが動作することができる画像データの広い帯域が存在する。以下でより詳細に説明するように、一実施形態では、ステンシルプロセッサは、データを、それらの重なり合うステンシル内で、左から右への態様で、画像データにわたって処理する(そして、次のラインのセットに対して、上から下の順序で繰り返す)。このように、ステンシルプロセッサがそれらの動作を前方に進めるにつれて、ベタ黒出力ピクセルブロックの数は、水平方向に右に成長する。上述したように、ラインバッファユニット201は、ステンシルプロセッサが今後の拡張された数のサイクルにわたって動作するのに十分な入来フレームからの入力画像データのライングループを解析することを担う。ライングループの例示的な図示は、陰影領域803として示されている。一実施形態では、ラインバッファユニット201は、ライングループをシート生成部との間で送受信するための異なるダイナミクスを理解することができる。たとえば、「完全なグループ」と呼ばれる1つのモードによれば、画像データの完全な全幅のラインが、ラインバッファユニットとシート生成部との間で渡される。「仮想的に高い」と呼ばれる第2のモードによれば、ライングループは最初に全幅行のサブセットとともに渡される。その後、残りの行は、より小さい(全幅未満の)片で順番に渡される。
入力画像データのライングループ803がラインバッファユニットによって画定され、シート生成部ユニットに渡されると、シート生成部ユニットはさらに、ライングループを、ステンシルプロセッサのハードウェア制限に、より正確に適合する、より微細なシートに、解析する。より具体的には、以下でさらに詳細に説明するように、一実施形態では、各ステンシルプロセッサは、二次元シフトレジスタアレイからなる。二次元シフトレジスタアレイは、本質的に、画像データを実行レーンのアレイの「真下」にシフトし、シフトのパターンは、各実行レーンをそれ自身のステンシル内においてデータに対して動作させる(すなわち、各実行レーンは、それ自身の情報のステンシル上で処理して、そのステンシルの出力を生成する)。一実施形態では、シートは、二次元シフトレジスタアレイを「満たす」か、さもなければ二次元シフトレジスタアレイにロードされる入力画像データの表面領域である。
以下でより詳細に説明するように、さまざまな実施形態では、実際には、任意のサイクルでシフト可能な二次元レジスタデータの複数の層が存在する。便宜上、本記載の多くは、「二次元シフトレジスタ」などの用語を、シフト可能な二次元レジスタデータの1つ以上のそのような層を有する構造を指すために単純に使用する。
したがって、図8bに見られるように、シート生成部は、ライングループ803から最初のシート804を解析し、それをステンシルプロセッサに供給する(ここで、データのシートは、参照番号804によって全体的に識別される陰影領域に対応する)。図8cおよび図8dに示すように、ステンシルプロセッサは、重なるステンシル802をシート上で左から右へ効果的に移動させることによって、入力画像データのシートに対して動作する。図8dのように、シート内のデータから出力値を計算することができるピクセル数が使い果たされる(他のピクセル位置は、シート内の情報から決定される出力値を有することができない)。簡単にするために、画像の境界領域は無視されている。
図8eにおいて見られるように、シート生成部は次いで、ステンシルプロセッサが動作を継続する次のシート805を提供する。ステンシルが次のシートに対して動作を開始するときのステンシルの初期位置は、(先に図8dに示されている)最初のシート上の消耗点から右への次の進行であることに留意されたい。新たなシート805で、ステンシルプロセッサが最初のシートの処理と同じ態様で新たなシートに対して動作するにつれ、ステンシルは単に右に移動し続ける。
出力ピクセル位置を取り囲むステンシルの境界領域のために、第1のシート804のデータと第2のシート805のデータとの間にいくらかの重なりがあることに留意されたい。重なりは、シート生成部が重なり合うデータを2回再送信することによって簡単に処理することができる。別の実現例では、次のシートをステンシルプロセッサに供給するために、シート生成部は、ステンシルプロセッサに新たなデータを送るだけに進んでもよく、ステンシルプロセッサは、前のシートからの重なり合うデータを再利用する。
図9は、ステンシルプロセッサユニットアーキテクチャ900の実施形態を示す。図9において見られるように、ステンシルプロセッサは、データ計算ユニット901、スカラープロセッサ902および関連するメモリ903およびI/Oユニット904を含む。データ計算ユニット901は、実行レーンのアレイ905、二次元シフトアレイ構造906、およびアレイの特定の行または列に関連する別個のランダムアクセスメモリ907を含む。
I/Oユニット904は、シート生成部から受け取ったデータの「入力」シートをデータ計算ユニット901にロードし、ステンシルプロセッサからのデータの「出力」シートをシート生成部に格納する役割を果たす。一実施形態では、データ計算ユニット901へのシートデータのロードは、受け取ったシートを画像データの行/列に解析し、画像データの行/列を二次元シフトレジスタ構造906または実行レーンアレイの行/列のそれぞれのランダムアクセスメモリ907にロードすることを必要とする(以下でより詳細に説明する)。シートが最初にメモリ907にロードされる場合、実行レーンアレイ905内の個々の実行レーンは、適宜、ランダムアクセスメモリ907からシートデータを二次元シフトレジスタ構造906にロードすることができる(たとえば、シートのデータ上での動作のすぐ前のロード命令として)。データのシートのレジスタ構造906へのロード(シート生成部からの直接的であろうとまたはメモリ907からであろうと)が完了すると、実行レーンアレイ905の実行レーンはデータに対して動作し、最終的に、完成したデータをシートとしてシート生成部に、またはランダムアクセスメモリ907に「書き戻す」。I/Oユニット904は後にランダムアクセスメモリ907からデータをフェッチして出力シートを形成し、出力シートはシート生成部に転送される。
スカラープロセッサ902は、スカラーメモリ903からステンシルプロセッサのプログラムコードの命令を読み出し、実行レーンアレイ905の実行レーンに命令を発行するプログラムコントローラ909を含む。一実施形態では、データ計算ユニット901からSIMDのような動作を実行するために、単一の同じ命令がアレイ905内のすべての実行レーンにブロードキャストされる。一実施形態では、スカラーメモリ903から読み出され、実行レーンアレイ905の実行レーンに発行される命令の命令フォーマットは、命令当たり2つ以上のオペコードを含む非常に長い命令語(VLIW)タイプのフォーマットを含む。さらなる実施形態では、VLIWフォーマットは、(以下に説明するように、一実施形態では2つ以上の従来のALU動作を指定することができる)各実行レーンのALUによって実行される数学的機能を指示するALUオペコードと、(特定の実行レーンまたは実行レーンのセットに対してメモリ操作を指示する)メモリオペコードとの両方を含む。
「実行レーン」という用語は、命令を実行することができる1つ以上の実行ユニットのセット(たとえば、命令を実行することができる論理回路系)を指す。実行レーンは、しかしながら、さまざまな実施形態では、単なる実行ユニットを超えた、よりプロセッサに似た機能を含むことができる。たとえば、1つ以上の実行ユニットに加えて、実行レーンは、受信された命令をデコードする論理回路系、または、よりMIMDのような設計の場合、命令をフェッチおよびデコードする論理回路系も含むことができる。MIMDのようなアプローチに関しては、ここでは集中プログラム制御アプローチが主に記載されているが、より分散型のアプローチがさまざまな代替実施形態(たとえば、アレイ905の各実行レーン内のプログラムコードおよびプログラムコントローラを含む)において実施されてもよい。
実行レーンアレイ905、プログラムコントローラ909および二次元シフトレジスタ構造906の組み合わせは、広範囲のプログラマブルな機能のための幅広く適応可能/設定可能なハードウェアプラットフォームを提供する。たとえば、アプリケーションソフトウェア開発者は、個々の実行レーンが多種多様な機能を実行することができ、任意の出力アレイ位置に近接した入力画像データに容易にアクセスすることができれば、寸法(たとえばステンシルサイズ)だけでなく幅広い異なる機能能力を有するカーネルをプログラミングすることができる。
実行レーンアレイ905によって操作される画像データのためのデータ記憶装置として機能することとは別に、ランダムアクセスメモリ907は、1つ以上のルックアップテーブルを保持することもできる。さまざまな実施形態では、1つ以上のスカラールックアップテーブルをスカラーメモリ903内でインスタンス化することもできる。
スカラールックアップは、同じルックアップテーブルからの同じインデックスからの同じデータ値を実行レーンアレイ905内の各実行レーンに渡すことを含む。さまざまな実施形態では、上述のVLIW命令フォーマットは、スカラープロセッサによって実行されるルックアップ動作をスカラールックアップテーブルに向けるスカラーオペコードを含むようにも拡張される。オペコードとともに使用するために指定されたインデックスは、即値オペランドでもよいし、他のデータ記憶位置からフェッチされてもよい。いずれにせよ、一実施形態では、スカラーメモリ内のスカラールックアップテーブルからのルックアップは、基本的に同じクロックサイクル中に実行レーンアレイ905内のすべての実行レーンに同じデータ値をブロードキャストすることを含む。ルックアップテーブルの使用および動作に関する追加の詳細は、以下でさらに説明する。
図9bは、上述のVLIW命令ワードの実施形態を要約したものである。図9bにおいて見られるように、VLIW命令ワードフォーマットは、3つの別個の命令、すなわち、1)スカラープロセッサによって実行されるスカラー命令951、2)実行レーンアレイ内でそれぞれのALUによってSIMD方式でブロードキャストされ実行されるALU命令952、および3)部分的SIMD方式でブロードキャストされ実行されるメモリ命令953に対するフィールドを含む(たとえば、実行レーンアレイ内において同じ行に沿った実行レーンが同じランダムアクセスメモリを共有する場合、異なる行の各々からの1つの実行レーンが実際に命令を実行する(メモリ命令953のフォーマットは、各行からのどの実行レーンが命令を実行するかを識別するオペランドを含むことができる)。
1つ以上の即値オペランドに対するフィールド954も含まれる。命令951,952,953のどれが、どの即値オペランド情報を用いるかは命令フォーマットで識別されてもよい。命令951,952,953の各々は、また、それら自身のそれぞれの入力オペランドおよび結果情報(たとえば、ALU演算用のローカルレジスタならびにメモリアクセス命令用のローカルレジスタおよびメモリアドレス)を含む。一実施形態では、スカラー命令951は、実行レーンアレイ内の実行レーンが他の2つの命令952,953のいずれかを実行する前にスカラープロセッサによって実行される。すなわち、VLIWワードの実行は、スカラー命令951が実行される第1のサイクルと、続いて他の命令952,953が実行されてもよい第2のサイクルとを含む。(さまざまな実施形態では、命令952,953は並列して実行されてもよい)。
一実施形態では、スカラープロセッサによって実行されるスカラー命令は、シートをデータ計算ユニットのメモリもしくは2Dシフトレジスタからロードまたはそれに格納するようシート生成部に発行されるコマンドを含む。ここで、シート生成部の動作は、ラインバッファユニットの動作またはスカラープロセッサによって発行されたコマンドをシート生成部が完了するのに要するサイクル数のプレランタイムの理解を妨げる他の変数に依存し得る。したがって、一実施形態では、スカラー命令951がシート生成部に発行されるべきコマンドに対応するか、さもなければコマンドをシート生成部に発行させるVLIWワードは、他の2つの命令フィールド952,953に無操作(NOOP)命令も含む。次に、プログラムコードは、シート生成部がデータ計算ユニットに対するそのロードまたはデータ計算ユニットからのその格納を完了するまで、命令フィールド952,953についてNOOP命令のループに入る。ここで、シート生成部にコマンドを発行すると、スカラープロセッサは、シート生成部がコマンドの完了時にリセットするインターロックレジスタのビットをセットしてもよい。NOOPループの間、スカラープロセッサはインターロックビットのビットを監視する。スカラープロセッサが、シート生成部がそのコマンドを完了したことを検出すると、通常の実行が再び開始される。
図10は、データ計算コンポーネント1001の一実施形態を示す。図10において見られるように、データ計算コンポーネント1001は、二次元シフトレジスタアレイ構造1006「の上に」論理的に位置決めされる実行レーンのアレイ1005を含む。上述したように、さまざまな実施形態では、シート生成部によって提供される画像データのシートが二次元シフトレジスタ1006にロードされる。実行レーンは、レジスタ構造1006からのシートデータに対して動作する。
実行レーンアレイ1005およびシフトレジスタ構造1006は、互いに対して適所に固定される。しかし、シフトレジスタアレイ1006内のデータは、戦略的かつ調整された態様でシフトして、実行レーンアレイ内の各実行レーンがデータ内で異なるステンシルを処理するようにする。したがって、各実行レーンは、生成されている出力シートにおいて異なるピクセルに対する出力画像値を決定する。図10のアーキテクチャから、実行レーンアレイ1005が垂直に近接する実行レーンおよび水平に近接する実行レーンを含むので、重なり合うステンシルが垂直に配置されるだけでなく水平にも配置されることは明らかである。
データ計算ユニット1001のいくつかの注目すべきアーキテクチャ上の特徴には、実行レーンアレイ1005よりも広い寸法を有するシフトレジスタ構造1006が含まれる。すなわち、実行レーンアレイ1005の外側にレジスタ1009の「ハロー」が存在する。ハロー1009は、実行レーンアレイの2つの側に存在するように示されているが、実現例に応じて、実行レーンアレイ1005の2つ未満(1つ)またはそれ以上(3つまたは4つ)の側に存在してもよい。ハロー1005は、データが実行レーン1005の「下に」シフトしているときに、実行レーンアレイ1005の境界の外側にこぼれ出るデータのための「スピルオーバ」空間を提供する働きをする。単純なケースとして、実行レーンアレイ1005の右端を中心とする5×5のステンシルは、ステンシルの最も左側のピクセルが処理されるとき、さらに右側に4つのハローレジスタ位置を必要とすることになる。図面を簡単にするために、図10は、名目上の実施形態において、どちらの側(右、底)のレジスタでも水平方向接続および垂直方向接続の両方を有するであろうとき、ハローの右側のレジスタを、水平方向シフト接続を有するだけとして、およびハローの底側のレジスタを、垂直方向シフト接続を有するだけとして示す。各種実施形態において、ハロー領域は、画像処理命令を実行するための対応する実行レーンを含まない(たとえば、ALUは存在しない)。しかしながら、個々のメモリアクセスユニット(M)は、各ハロー領域位置に存在し、よって、個々のハローレジスタ位置は、個々にデータをメモリからロードしデータをメモリに格納することができる。
アレイの各行および/もしくは各列またはその一部分に結合されるランダムアクセスメモリ1007によって追加のスピルオーバールームが提供される(たとえば、ランダムアクセスメモリは、4つの実行レーン行状と2つの実行レーン列状にまたがる実行レーンアレイの「領域」に割り当てられてもよい。簡略化のために、アプリケーションの残りの部分は、主に、行および/または列に基づく割り当てスキームを指す)。ここで、実行レーンのカーネル動作が、それが(一部の画像処理ルーチンが必要とする場合がある)二次元シフトレジスタアレイ1006の外にあるピクセル値を処理することを必要とする場合、画像データの面は、たとえばハロー領域1009からランダムアクセスメモリ1007にさらにこぼれ出ることができる。たとえば、ハードウェアが実行レーンアレイの右端の実行レーンの右側にわずか4つの記憶素子のハロー領域を含む場合の6×6ステンシルを考える。この場合、ステンシルを完全に処理するために、データをハロー1009の右端からさらに右側にシフトする必要があるであろう。ハロー領域1009の外側にシフトされたデータは、ランダムアクセスメモリ1007にこぼれ出る。ランダムアクセスメモリ1007および図9のステンシルプロセッサの他の適用例を以下でさらに説明する。
図11a〜図11kは、上述のように実行レーンアレイ「の下で」二次元シフトレジスタアレイ内で画像データがシフトされる態様の実施例を示す。図11aにおいて見られるように、二次元シフトアレイのデータ内容は第1のアレイ1107に示され、実行レーンアレイはフレーム1105によって示される。また、実行レーンアレイ内の2つの近隣の実行レーン1110が簡略化して示されている。この簡単な図示1110では、各実行レーンは、シフトレジスタからデータを受け付け、ALU出力からデータを受け付け(たとえば、サイクルにわたってアキュムレータとして動作する)、または出力データを出力先に書き込むことができるレジスタR1を含む。
各実行レーンはまた、ローカルレジスタR2において、二次元シフトアレイにおけるそれ「の下の」内容が利用可能である。したがって、R1は実行レーンの物理レジスタであり、R2は二次元シフトレジスタアレイの物理レジスタである。実行レーンは、R1および/またはR2によって提供されるオペランドに対して動作可能なALUを含む。さらに詳細に後述するように、一実施形態では、シフトレジスタは、実際にはアレイ位置ごとに複数の(ある「深さ」の)記憶/レジスタ素子で実現されるが、シフト動作は記憶素子の1つの面に限られる(たとえば、記憶素子の1つの面のみがサイクルごとにシフトすることができる)。図11a〜図11kは、それぞれの実行レーンから結果のXを格納するために使用されるとしてこれらのより深いレジスタ位置の1つを示している。例示を容易にするために、より深い結果のレジスタは、その対応するレジスタR2の下ではなく、その横に図示されている。
図11a〜図11kは、実行レーンアレイ内に示された実行レーン位置1111の対に中心位置が整列された2つのステンシルの計算に焦点を当てている。例示を容易にするために、実行レーン1110の対は、実際には、以下の例によれば、それらが垂直方向の近隣実行レーンである場合に、水平方向の近隣実行レーンとして図示されている。
図11aで最初に見られるように、実行レーンはそれらの中央のステンシル位置上に中心を配される。図11bは、両方の実行レーンによって実行されるオブジェクトコードを示す。図11bにおいて見られるように、両方の実行レーンのプログラムコードは、シフトレジスタアレイ内のデータを、1つの位置だけ下にシフトさせ、1つの位置だけ右にシフトさせる。これにより、両方の実行レーンがそれらのそれぞれのステンシルの左上隅に整列される。次に、プログラムコードは、(R2において)それらのそれぞれの位置にあるデータをR1にロードさせる。
図11cに示すように、次にプログラムコードは、実行レーンの対に、シフトレジスタアレイ内のデータを1単位だけ左にシフトさせ、各実行レーンのそれぞれの位置の右の値を各実行レーンの位置にシフトさせる。R1の値(以前の値)は、次いで、(R2における)実行レーンの位置にシフトした新しい値とともに加算される。結果はR1に書き込まれる。図11dで見られるように、図11cについて上述したのと同じプロセスが繰り返され、結果のR1に対して、今度は上側実行レーンにおける値A+B+C、および下側実行レーンにおけるF+G+H値を含ませるようにする。この時点で、両方の実行レーンはそれらのそれぞれのステンシルの上側の行を処理している。(左側に存在する場合には)実行レーンアレイの左側でハロー領域に、またはハロー領域が存在しない場合にはランダムアクセスメモリにこぼれ出ることは、実行レーンアレイの左側には存在しないことに注目されたい。
図11eに示すように、次に、プログラムコードは、シフトレジスタアレイ内のデータを1単位だけ上にシフトさせ、両方の実行レーンをそれらのそれぞれのステンシルの中間行の右端に整列される。両方の実行レーンのレジスタR1は、現在、ステンシルの最上行および中間行の一番右の値の合計を含む。図11fおよび図11gは、両方の実行レーンのステンシルの中間行にわたって左方向に移動する継続的な進行を示す。累積加算は、図11gの処理の終了時に、両方の実行レーンがそれらのそれぞれのステンシルの最上行の値と中間行の値との合計を含むように、継続する。
図11hは、各実行レーンをそれの対応するステンシルの最下行に整列させる別のシフトを示す。図11iおよび図11jは、両方の実行レーンのステンシルの過程にわたって処理を完了するための継続的なシフトを示す。図11kは、各実行レーンをデータアレイにおいてそれの正しい位置に整列させ、その結果をそこに書き込むための追加のシフトを示す。
図11a〜図11kの例では、シフト動作のためのオブジェクトコードは、(X、Y)座標で表されるシフトの方向および大きさを識別する命令フォーマットを含むことができることに留意されたい。たとえば、1つの位置分の上方向シフトのためのオブジェクトコードは、オブジェクトコードでSHIFT0,+1として表現されてもよい。別の例として、1つの位置分の右方向へのシフトは、オブジェクトコードでSHIFT+1,0として表現されてもよい。さまざまな実施形態では、より大きい大きさのシフトも、オブジェクトコードで指定することができる(たとえば、SHIFT0,+2)。ここで、2Dシフトレジスタハードウェアが1サイクルにつき1つの位置だけしかシフトをサポートしない場合、命令は機械によって複数のサイクル実行を要求するように解釈されてもよく、または2Dシフトレジスタハードウェアは、1サイクルにつき2つ以上の位置分シフトをサポートするように設計されてもよい。後者の実施形態はより詳細にさらに下に記載される。
図12は、実行レーンおよび対応するシフトレジスタ構造の単位セルの別のより詳細な図を示す(ハロー領域のレジスタは、対応する実行レーンを含まないが、各種実施形態ではメモリユニットを含む)。実行レーンおよび実行レーンアレイの各位置に関連するレジスタ空間は、一実施形態では、実行レーンアレイの各ノードで、図12に示す回路系をインスタンス化することによって実施される。図12に示すように、単位セルは、4つのレジスタR2〜R5からなるレジスタファイル1202に結合される実行レーン1201を含む。任意のサイクルの間、実行レーン1201は、レジスタR1〜R5のいずれかから読み書きすることができる。2つの入力オペランドを必要とする命令の場合、実行レーンはR1〜R5のいずれかからオペランドの両方を取り出すことができる。
一実施形態では、二次元シフトレジスタ構造は、近隣のレジスタファイル間のシフトが同じ方向にあるように(たとえば、すべての実行レーンは左にシフトする、すべての実行レーンは右にシフトするなど)、それの近隣のレジスタファイルが入力マルチプレクサ1204を介する場合に、単一のサイクルの間に、レジスタR2〜R4のいずれか(ただ)1つの内容が、出力マルチプレクサ1203を介してその近隣のレジスタファイルの1つにシフト「アウト」され、対応するものからシフト「イン」される内容でレジスタR2〜R4のいずれか(ただ)1つの内容が置き換えられることによって、実現される。同じレジスタがその内容がシフトアウトされて同じサイクルでシフトインされる内容で置き換えられるのが一般的であるかもしれないが、マルチプレクサ構成1203,1204は、同じサイクル中に同じレジスタファイル内で異なるシフトソースおよびシフトターゲットレジスタを可能にする。
図12に示すように、シフトシーケンスの間、実行レーンは、内容をそのレジスタファイル1202からその左、右、上および下の近隣のレジスタファイルにシフトアウトする。同じシフトシーケンスと関連して、実行レーンは、さらに、内容をその左、右、上および下の近隣のレジスタファイルの特定のものからそれのレジスタファイルにシフトする。再び、シフトアウトターゲットおよびシフトインソースは、すべての実行レーンについて同じシフト方向と整合しなければならない(たとえば、シフトアウトが右隣に対する場合、シフトインは左隣からでなければならない)。
一実施形態では、1サイクルにつき1つの実行レーンにつき1つのレジスタの内容だけをシフトすることが許されるが、他の実施形態では、2つ以上のレジスタの内容をシフトイン/アウトすることが許されてもよい。たとえば、図12に示されたマルチプレクサ回路系1203,1204の第2の例が図12の設計に組み込まれる場合、同じサイクルの間に2つのレジスタの内容がシフトアウト/インされてもよい。もちろん、1つのレジスタの内容だけがサイクルごとにシフトされることが許される実施形態では、数学的演算間のシフトのためにより多くのクロックサイクルを消費することによって、複数のレジスタからのシフトが数学的演算間に起こってもよい(たとえば、2つのレジスタの内容が、数学的演算間で2つのシフト演算を消費することによって数学的演算間でシフトされてもよい)。
実行レーンのレジスタファイルのすべての内容未満がシフトシーケンス中にシフトアウトされる場合、各実行レーンのシフトアウトされないレジスタの内容は適所に残る(シフトしない)ことに留意されたい。したがって、シフトインされる内容と置き換えられないシフトされない内容は、シフトサイクルにわたって実行レーンにローカルに維持される。各実行レーンで見られるメモリユニット(「M」)は、データを、実行レーンアレイ内の実行レーンの行および/または列に関連付けられるランダムアクセスメモリ空間からロードまたはそれに格納するために使用される。ここで、Mユニットは、実行レーンの自身のレジスタ空間からロードまたはそれに格納できないデータをロード/格納するためによく使用されるという点で、標準的なMユニットとして機能する。さまざまな実施形態では、Mユニットの主な動作は、ローカルレジスタからメモリにデータを書き込み、メモリからデータを読み出してそれをローカルレジスタに書き込むことである。
ハードウェア実行レーン1201のALUユニットによってサポートされるISAオペコードに関して、さまざまな実施形態において、ハードウェアALUによってサポートされる数学的オペコードは、(たとえば、ADD、SUB、MOV、MUL、MAD、ABS、DIV、SHL、SHR、MIN/MAX、SEL、AND、OR、XOR、NOT)を含む。上述のように、メモリアクセス命令は、実行レーン1201によって実行され、データをそれらの関連付けられるランダムアクセスメモリからフェッチまたはそれに格納することができる。さらに、ハードウェア実行レーン1201は、シフト演算命令(右、左、上、下)をサポートし、二次元シフトレジスタ構造内でデータをシフトする。上述したように、プログラム制御命令は主にステンシルプロセッサのスカラープロセッサによって実行される。
4.0 実装実施形態
上述したさまざまな画像プロセッサアーキテクチャの特徴は、必ずしも従来の意味での画像処理に限定されず、したがって、画像プロセッサを再特徴付けしてもよい(またはしなくてもよい)他のアプリケーションに適用することができることを指摘することが適切である。たとえば、実際のカメラ画像の処理とは対照的に、アニメーションの作成および/または生成および/またはレンダリングにおいて上述した様々な画像プロセッサアーキテクチャの特徴のいずれかが使用される場合、画像プロセッサはグラフィックス処理ユニットとして特徴付けられてもよい。さらに、上述した画像プロセッサアーキテクチャの特徴は、ビデオ処理、視覚処理、画像認識および/または機械学習などの他の技術的用途にも適用することができる。このように適用されて、画像プロセッサは、より汎用的なプロセッサ(たとえば、コンピューティングシステムのCPUであるか、またはその一部である)と(たとえばコプロセッサとして)一体化されてもよく、またはコンピューティングシステム内のスタンドアロンプロセッサであってもよい。
上述したハードウェア設計の実施形態は、半導体チップ内において、および/または最終的に半導体製造プロセスに向けての回路設計の記述として実施することができる。後者の場合、そのような回路記述は、(たとえばVHDLまたはVerilog)レジスタ転送レベル(RTL)回路記述、ゲートレベル回路記述、トランジスタレベル回路記述もしくはマスク記述またはそれらのさまざまな組み合わせの形態をとってもよい。回路記述は、典型的には、コンピュータ可読記憶媒体(たとえばCD−ROMまたは他のタイプの記憶技術)上に実施される。
先のセクションから、上記の画像プロセッサは、(たとえば、ハンドヘルド装置のカメラからのデータを処理するハンドヘルド装置のシステムオンチップ(SOC)の一部として)コンピュータシステム上のハードウェアで実施できることを認識することに関係する。画像プロセッサがハードウェア回路として実施される場合、画像プロセッサによって処理される画像データはカメラから直接受信されてもよいことに留意されたい。ここで、画像プロセッサは、別体のカメラの一部であってもよいし、一体化されたカメラを有するコンピューティングシステムの一部であってもよい。後者の場合、画像データは、カメラから直接、またはコンピューティングシステムのシステムメモリから受信することができる(たとえば、カメラは、その画像データを画像プロセッサではなくシステムメモリに送信する)。先のセクションで説明した機能の多くは、(アニメーションをレンダリングする)グラフィックスプロセッサユニットにも適用可能であることにも留意されたい。
図13は、コンピューティングシステムの例示的な図である。以下に説明するコンピューティングシステムのコンポーネントの多くは、一体化されたカメラおよび関連する画像プロセッサ(たとえば、スマートフォンまたはタブレットコンピュータなどのハンドヘルドデバイス)を有するコンピューティングシステムに適用可能である。当業者は、2つの間の範囲を容易に定めることができるであろう。加えて、図13のコンピューティングシステムはまた、ワークステーションまたはスーパーコンピュータといった高性能コンピューティングシステムの多くの特徴を含む。
図13に見られるように、基本的なコンピューティングシステムは、中央処理ユニット1301(たとえば、マルチコアプロセッサまたはアプリケーションプロセッサ上に配置された複数の汎用処理コア1315_1〜1315_Nおよびメインメモリコントローラ1317を含み得る)、システムメモリ1302、ディスプレイ1303(たとえばタッチスクリーン、フラットパネル)、ローカル有線ポイントツーポイントリンク(たとえばUSB)インタフェース1304、さまざまなネットワークI/O機能1305(イーサネット(登録商標)インタフェースおよび/またはセルラーモデムサブシステムなど)、無線ローカルエリアネットワーク(たとえばWiFi)インタフェース1306、ワイヤレスポイントツーポイントリンク(たとえばブルートゥース(登録商標))インタフェース1307およびグローバルポジショニングシステムインタフェース1308、さまざまなセンサ1309_1〜1309_N、1つ以上のカメラ1310、バッテリ1311、電力管理制御ユニット1312、スピーカおよびマイクロホン1313、ならびに音声コーダ/デコーダ1314を含んでもよい。
アプリケーションプロセッサまたはマルチコアプロセッサ1350は、そのCPU1201内における1つ以上の汎用処理コア1315、1つ以上のグラフィカル処理ユニット1316、メモリ管理機能1317(たとえばメモリコントローラ)、I/O制御機能1318および画像処理ユニット1319を含んでもよい。汎用処理コア1315は、典型的には、コンピューティングシステムのオペレーティングシステムおよびアプリケーションソフトウェアを実行する。グラフィックス処理ユニット1316は、典型的には、たとえばディスプレイ1303上に提示されるグラフィックス情報を生成するために、グラフィックス集中型機能を実行する。メモリ制御機能1317は、システムメモリ1302とインタフェースして、システムメモリ1302との間でデータの書込/読出を行う。電力管理制御ユニット1312は、システム1300の電力消費を全体的に制御する。
画像処理ユニット1319は、先のセクションで説明した画像処理ユニットの実施形態のいずれかに従って実現することができる。代替的にまたは組み合わせて、IPU1319は、GPU1316およびCPU1301のいずれかまたは両方にそのコプロセッサとして結合されてもよい。さらに、さまざまな実施形態では、GPU1316は、上で説明した画像プロセッサの特徴のいずれかを用いて実現することができる。画像処理ユニット1319は、先に詳述したようにアプリケーションソフトウェアで構成することができる。加えて、図13のコンピューティングシステムのようなコンピューティングシステムは、画像プロセッサ上のアプリケーションソフトウェアプログラムの構成を決定する上記計算を行うプログラムコードを実行することができる。
タッチスクリーンディスプレイ1303、通信インタフェース1304〜1307、GPSインタフェース1308、センサ1309、カメラ1310、およびスピーカ/マイクコーデック1313,1314の各々はすべて、適切な場合には、一体化された周辺装置(たとえば1つ以上のカメラ1310)も含むコンピューティングシステム全体に対してさまざまな形態のI/O(入力および/または出力)として見ることができる。実現例によっては、これらのI/Oコンポーネントのさまざまなものは、アプリケーションプロセッサ/マルチコアプロセッサ1350上に統合されてもよく、またはアプリケーションプロセッサ/マルチコアプロセッサ1350のダイから離れて、またはそのパッケージ外に配置されてもよい。
一実施形態では、1つ以上のカメラ1310は、カメラとその視野内の対象との間の深度を測定することができる深度カメラを含む。アプリケーションプロセッサまたは他のプロセッサの汎用CPUコア(もしくはプログラムコードを実行するために命令実行パイプラインを有する他の機能ブロック)上で実行されるアプリケーションソフトウェア、オペレーティングシステムソフトウェア、デバイスドライバソフトウェアおよび/またはファームウェアは、上記の機能のいずれかを実行してもよい。
本発明の実施形態は、上述したようなさまざまなプロセスを含むことができる。これらのプロセスは、機械実行可能命令で実施されてもよい。これらの命令は、汎用または特殊目的のプロセッサに特定のプロセスを実行させるために使用できる。代替的に、これらのプロセスは、プロセスを実行するためのハードワイヤードおよび/またはプログラマブル論理を含む特定のハードウェアコンポーネントによって、またはプログラミングされたコンピュータコンポーネントとカスタムハードウェアコンポーネントとの任意の組み合わせによって実行されてもよい。
本発明の要素はまた、機械実行可能命令を記憶するための機械可読媒体として提供されてもよい。機械可読媒体は、フロッピー(登録商標)ディスク、光ディスク、CD−ROM、および光磁気ディスク、フラッシュメモリ、ROM、RAM、EPROM、EEPROM、磁気もしくは光カード、伝搬媒体、または電子命令を記憶するのに適した他のタイプの媒体/機械可読媒体を含むが、それらに限定はされない。たとえば、本発明は、搬送波または通信リンク(たとえばモデムもしくはネットワーク接続)を介する他の伝搬媒体で実施されたデータ信号によって、遠隔のコンピュータ(たとえばサーバ)から要求側コンピュータ(たとえばクライアント)に転送され得るコンピュータプログラムとしてダウンロードすることができる。
前述の明細書では、本発明をその特定の例示的な実施形態を参照しながら説明した。しかしながら、特許請求の範囲に記載される本発明のより広い精神および範囲から逸脱することなく、さまざまな修正および変更がなされ得ることは明らかであろう。したがって、明細書および図面は、限定的ではなく例示的なものとみなされるべきである。

Claims (17)

  1. 1つ以上のコンピュータによって実行される方法であって、前記方法は、
    複数のステンシルプロセッサを有するデバイス上で実行される画像処理アプリケーションプログラムの最終カーネル割り当てを計算することを求める要求を受けるステップを含み、前記画像処理アプリケーションプログラムは、複数のカーネルを含む画像処理パイプラインを定義し、
    複数の候補カーネル割り当てを生成するステップを含み、各カーネル割り当ては、前記画像処理パイプラインの各カーネルを、前記複数のステンシルプロセッサのうちの対応する1つのステンシルプロセッサに割り当て、前記複数の候補カーネル割り当てを生成するステップは、
    前記画像処理パイプライン内のすべてのカーネルが前記複数のステンシルプロセッサのうちの対応するステンシルプロセッサに割り当てられるまで、前記画像処理パイプライン内のカーネルを、前記画像処理パイプライン内のカーネルがまだ割り当てられていない利用可能なステンシルプロセッサに順次割り当てるステップを含み、前記方法は、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当ての総重みを計算するステップを含み、前記各候補カーネル割り当ての総重みは、データ転送効率の尺度を表し、カーネル間で転送されるデータぞれぞれの転送サイズと、前記複数のステンシルプロセッサを接続するネットワークに沿うそれぞれの転送距離とに基づいており、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当てについて計算した前記総重みに従い、データ転送効率が最高である候補カーネル割り当てを選択するステップと、
    前記選択した候補カーネル割り当てに従い、前記複数のカーネルのうちのカーネルを、対応するステンシルプロセッサに割り当てるステップとを含む、方法。
  2. 前記デバイスは複数のラインバッファユニットをさらに含み、
    前記方法は、どのラインバッファユニットがどのカーネルをソースするかを判断しどのラインバッファユニットがどのカーネルをシンクするかを判断するステップをさらに含む、請求項1に記載の方法。
  3. どのラインバッファユニットがどのカーネルをシンクするかを判断するステップは、
    特定のステンシルプロセッサに割り当てられた特定の作成カーネルに対し、前記特定のステンシルプロセッサからの転送距離に基づいてソートされたラインバッファユニットのリストを生成するステップと、
    前記特定の作成カーネルに、前記特定の作成カーネルが生成したデータをバッファするのに十分なメモリを有する最も近いラインバッファユニットを割り当てるステップとを含む、請求項2に記載の方法。
  4. 前記転送距離は、対応する、前記ネットワーク内のカーネル間のノーダルホップの数に基づく、請求項1に記載の方法。
  5. 前記転送距離は、前記ネットワークのネットワークリングに沿う距離に基づく、請求項1に記載の方法。
  6. 1つ以上のコンピュータによって実行されると前記1つ以上のコンピュータに動作を実行させるコンピュータプログラム命令を備えるコンピュータプログラムであって、前記動作は、
    複数のステンシルプロセッサを有するデバイス上で実行される画像処理アプリケーションプログラムの最終カーネル割り当てを計算することを求める要求を受けることを含み、前記画像処理アプリケーションプログラムは、複数のカーネルを含む画像処理パイプラインを定義し、
    複数の候補カーネル割り当てを生成することを含み、各カーネル割り当ては、前記画像処理パイプラインの各カーネルを、前記複数のステンシルプロセッサのうちの対応する1つのステンシルプロセッサに割り当て、前記複数の候補カーネル割り当てを生成することは、
    前記画像処理パイプライン内のすべてのカーネルが前記複数のステンシルプロセッサのうちの対応するステンシルプロセッサに割り当てられるまで、前記画像処理パイプライン内のカーネルを、前記画像処理パイプライン内のカーネルがまだ割り当てられていない利用可能なステンシルプロセッサに順次割り当てることを含み、前記動作は、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当ての総重みを計算することを含み、前記各候補カーネル割り当ての総重みは、データ転送効率の尺度を表し、カーネル間で転送されるデータぞれぞれの転送サイズと、前記複数のステンシルプロセッサを接続するネットワークに沿うそれぞれの転送距離とに基づいており、前記動作は、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当てについて計算した前記総重みに従い、データ転送効率が最高である候補カーネル割り当てを選択することと、
    前記選択した候補カーネル割り当てに従い、前記複数のカーネルのうちのカーネルを、対応するステンシルプロセッサに割り当てることとを含む、コンピュータプログラム。
  7. 前記デバイスは、複数のラインバッファユニットをさらに含み、
    どのラインバッファユニットがどのカーネルをソースするかを判断しどのラインバッファユニットがどのカーネルをシンクするかを判断することをさらに含む、請求項6に記載のコンピュータプログラム。
  8. どのラインバッファユニットがどのカーネルをシンクするかを判断することは、
    特定のステンシルプロセッサに割り当てられた特定の作成カーネルに対し、前記特定のステンシルプロセッサからの転送距離に基づいてソートされたラインバッファユニットのリストを生成することと、
    前記特定の作成カーネルに、前記特定の作成カーネルが生成したデータをバッファするのに十分なメモリを有する最も近いラインバッファユニットを割り当てることとを含む、請求項7に記載のコンピュータプログラム。
  9. 前記転送距離は、対応する、前記ネットワーク内のカーネル間のノーダルホップの数に基づく、請求項6に記載のコンピュータプログラム。
  10. 前記転送距離は、前記ネットワークのネットワークリングに沿う距離に基づく、請求項6に記載のコンピュータプログラム。
  11. 各ステンシルプロセッサは、実行レーンアレイと、二次元シフトレジスタアレイとを含む、請求項6に記載のコンピュータプログラム。
  12. コンピューティングシステムであって、
    1つ以上のコンピュータと命令を格納する1つ以上の記憶装置とを備え、前記命令は、前記1つ以上のコンピュータによって実行されると前記1つ以上のコンピュータに動作を実行させるように作用し、前記動作は、
    複数のステンシルプロセッサを有するデバイス上で実行される画像処理アプリケーションプログラムの最終カーネル割り当てを計算することを求める要求を受けることを含み、前記画像処理アプリケーションプログラムは、複数のカーネルを含む画像処理パイプラインを定義し、
    複数の候補カーネル割り当てを生成することを含み、各カーネル割り当ては、前記画像処理パイプラインの各カーネルを、前記複数のステンシルプロセッサのうちの対応する1つのステンシルプロセッサに割り当て、前記複数の候補カーネル割り当てを生成することは、
    前記画像処理パイプライン内のすべてのカーネルが前記複数のステンシルプロセッサのうちの対応するステンシルプロセッサに割り当てられるまで、前記画像処理パイプライン内のカーネルを、前記画像処理パイプライン内のカーネルがまだ割り当てられていない利用可能なステンシルプロセッサに順次割り当てることを含み、前記動作は、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当ての総重みを計算することを含み、前記各候補カーネル割り当ての総重みは、データ転送効率の尺度を表し、カーネル間で転送されるデータぞれぞれの転送サイズと、前記複数のステンシルプロセッサを接続するネットワークに沿うそれぞれの転送距離とに基づいており、前記動作は、
    前記複数の候補カーネル割り当てのうちの各候補カーネル割り当てについて計算した前記総重みに従い、データ転送効率が最高である候補カーネル割り当てを選択することと、
    前記選択した候補カーネル割り当てに従い、前記複数のカーネルのうちのカーネルを、対応するステンシルプロセッサに割り当てることとを含む、コンピューティングシステム。
  13. 前記デバイスは、複数のラインバッファユニットをさらに含み、
    どのラインバッファユニットがどのカーネルをソースするかを判断しどのラインバッファユニットがどのカーネルをシンクするかを判断することをさらに含む、請求項12に記載のコンピューティングシステム。
  14. どのラインバッファユニットがどのカーネルをシンクするかを判断することは、
    特定のステンシルプロセッサに割り当てられた特定の作成カーネルに対し、前記特定のステンシルプロセッサからの転送距離に基づいてソートされたラインバッファユニットのリストを生成することと、
    前記特定の作成カーネルに、前記特定の作成カーネルが生成したデータをバッファするのに十分なメモリを有する最も近いラインバッファユニットを割り当てることとを含む、請求項13に記載のコンピューティングシステム。
  15. 前記転送距離は、対応する、前記ネットワーク内のカーネル間のノーダルホップの数に基づく、請求項12に記載のコンピューティングシステム。
  16. 前記転送距離は、前記ネットワークのネットワークリングに沿う距離に基づく、請求項12に記載のコンピューティングシステム。
  17. 各ステンシルプロセッサは、実行レーンアレイと、二次元シフトレジスタアレイとを含む、請求項12に記載のコンピューティングシステム。
JP2019539225A 2017-05-12 2018-01-12 マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成 Active JP6820428B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/594,529 2017-05-12
US15/594,529 US10467056B2 (en) 2017-05-12 2017-05-12 Configuration of application software on multi-core image processor
PCT/US2018/013445 WO2018208338A1 (en) 2017-05-12 2018-01-12 Configuration of application software on multi-core image processor

Publications (2)

Publication Number Publication Date
JP2020519977A JP2020519977A (ja) 2020-07-02
JP6820428B2 true JP6820428B2 (ja) 2021-01-27

Family

ID=61094605

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019539225A Active JP6820428B2 (ja) 2017-05-12 2018-01-12 マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成

Country Status (7)

Country Link
US (2) US10467056B2 (ja)
EP (1) EP3622396B1 (ja)
JP (1) JP6820428B2 (ja)
KR (1) KR102217969B1 (ja)
CN (1) CN110192184B (ja)
TW (1) TWI694412B (ja)
WO (1) WO2018208338A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108614460B (zh) * 2018-06-20 2020-11-06 东莞市李群自动化技术有限公司 分布式多节点控制系统及方法
CN110032407B (zh) * 2019-03-08 2020-12-22 创新先进技术有限公司 提升cpu并行性能的方法及装置和电子设备
GB2595696B (en) * 2020-06-04 2022-12-28 Envisics Ltd Forming a hologram of a target image for projection using data streaming
TW202219760A (zh) * 2020-11-06 2022-05-16 圓剛科技股份有限公司 協同運算裝置及其協同運算方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7499960B2 (en) 2001-10-01 2009-03-03 Oracle International Corporation Adaptive memory allocation
US7331037B2 (en) 2004-08-12 2008-02-12 National Instruments Corporation Static memory allocation in a graphical programming system
US7818725B1 (en) 2005-04-28 2010-10-19 Massachusetts Institute Of Technology Mapping communication in a parallel processing environment
JP4923602B2 (ja) 2006-02-10 2012-04-25 富士ゼロックス株式会社 画像形成処理シミュレーション装置及び画像形成処理シミュレーション方法
WO2007149476A2 (en) * 2006-06-19 2007-12-27 Trustees Of Columbia University In The City Of New York Assays for non-apoptotic cell death and uses thereof
US8306348B2 (en) * 2007-04-24 2012-11-06 DigitalOptics Corporation Europe Limited Techniques for adjusting the effect of applying kernels to signals to achieve desired effect on signal
US7890314B2 (en) 2007-12-05 2011-02-15 Seagate Technology Llc Method for modeling performance of embedded processors having combined cache and memory hierarchy
US8856794B2 (en) * 2009-10-13 2014-10-07 Empire Technology Development Llc Multicore runtime management using process affinity graphs
US20110191758A1 (en) 2010-01-29 2011-08-04 Michael Scharf Optimized Memory Allocator By Analyzing Runtime Statistics
TW201206165A (en) 2010-07-16 2012-02-01 Primax Electronics Ltd Image testing method of image pickup device and image testing device using the same
US9152468B2 (en) 2010-10-25 2015-10-06 Samsung Electronics Co., Ltd. NUMA aware system task management
US10235220B2 (en) * 2012-01-23 2019-03-19 Advanced Micro Devices, Inc. Multithreaded computing
KR20130093995A (ko) * 2012-02-15 2013-08-23 한국전자통신연구원 계층적 멀티코어 프로세서의 성능 최적화 방법 및 이를 수행하는 멀티코어 프로세서 시스템
US8819345B2 (en) 2012-02-17 2014-08-26 Nokia Corporation Method, apparatus, and computer program product for inter-core communication in multi-core processors
US9213781B1 (en) * 2012-09-19 2015-12-15 Placemeter LLC System and method for processing image data
DE102013205608A1 (de) * 2013-03-28 2014-10-02 Siemens Aktiengesellschaft Montagevorrichtung für ein Seitenwandverkleidungselement eines Schienenfahrzeugs
TW201604805A (zh) * 2014-07-30 2016-02-01 林政毅 帳號驗證方法及其系統
US9756268B2 (en) 2015-04-23 2017-09-05 Google Inc. Line buffer unit for image processor
US9785423B2 (en) * 2015-04-23 2017-10-10 Google Inc. Compiler for translating between a virtual image processor instruction set architecture (ISA) and target hardware having a two-dimensional shift array structure
US9965824B2 (en) * 2015-04-23 2018-05-08 Google Llc Architecture for high performance, power efficient, programmable image processing
KR102384346B1 (ko) * 2015-06-01 2022-04-07 삼성전자주식회사 저장 방식에 상관없이 데이터를 억세스하는 애플리케이션 프로세서 및 이를 포함하는 모바일 장치

Also Published As

Publication number Publication date
TW201901608A (zh) 2019-01-01
JP2020519977A (ja) 2020-07-02
US10467056B2 (en) 2019-11-05
KR20190095462A (ko) 2019-08-14
US20180329746A1 (en) 2018-11-15
EP3622396A1 (en) 2020-03-18
CN110192184B (zh) 2023-07-07
CN110192184A (zh) 2019-08-30
KR102217969B1 (ko) 2021-02-19
US20200050486A1 (en) 2020-02-13
TWI694412B (zh) 2020-05-21
EP3622396B1 (en) 2023-03-08
WO2018208338A1 (en) 2018-11-15
US11030005B2 (en) 2021-06-08

Similar Documents

Publication Publication Date Title
JP7202987B2 (ja) 高性能で、電力効率の良い、プログラマブルな画像処理のためのアーキテクチャ
JP6858239B2 (ja) プログラムコードを、高性能で電力効率の良いプログラマブルな画像処理ハードウェアプラットフォームにマッピングするためのコンパイラ技法
JP6793228B2 (ja) 画像プロセッサのためのシート生成部
JP6612403B2 (ja) 画像プロセッサのためのエネルギ効率的なプロセッサコアアーキテクチャ
JP6389571B2 (ja) 画像プロセッサのための二次元シフトアレイ
JP6726752B2 (ja) 画像プロセッサのためのコンパイラ管理メモリ
JP6820428B2 (ja) マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成
TWI736880B (zh) 處理器、電腦程式產品及處理器所執行之方法
EP3622399B1 (en) Determination of per line buffer unit memory allocation
JP6967597B2 (ja) 設定可能な数のアクティブなコアを有する画像処理プロセッサおよびサポートする内部ネットワーク
JP6775088B2 (ja) 画像プロセッサランタイム効率を向上するためのプログラムコード変形

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191125

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191125

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20191125

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20200706

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200714

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200911

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210104

R150 Certificate of patent or registration of utility model

Ref document number: 6820428

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250