JP7208920B2 - ラインバッファユニット単位メモリ割り当ての決定 - Google Patents

ラインバッファユニット単位メモリ割り当ての決定 Download PDF

Info

Publication number
JP7208920B2
JP7208920B2 JP2019559299A JP2019559299A JP7208920B2 JP 7208920 B2 JP7208920 B2 JP 7208920B2 JP 2019559299 A JP2019559299 A JP 2019559299A JP 2019559299 A JP2019559299 A JP 2019559299A JP 7208920 B2 JP7208920 B2 JP 7208920B2
Authority
JP
Japan
Prior art keywords
data
line buffer
execution
simulated
image
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
JP2019559299A
Other languages
English (en)
Other versions
JP2020519993A (ja
JP2020519993A5 (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 JP2020519993A publication Critical patent/JP2020519993A/ja
Publication of JP2020519993A5 publication Critical patent/JP2020519993A5/ja
Application granted granted Critical
Publication of JP7208920B2 publication Critical patent/JP7208920B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0664—Virtualisation aspects at device level, e.g. emulation of a storage device or system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/068—Hybrid storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/36—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
    • G09G5/363—Graphics controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084—Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2117/00—Details relating to the type or aim of the circuit design
    • G06F2117/08—HW-SW co-design, e.g. HW-SW partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/455—Image or video data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/601—Reconfiguration of cache memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • Y—GENERAL 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE 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/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Computer Graphics (AREA)
  • Image Processing (AREA)
  • Advance Control (AREA)

Description

本発明の分野
本発明の分野は、一般に、計算科学に関し、より具体的には、ラインバッファユニット単位メモリ割り当ての決定に関する。
背景
画像処理には、通常、アレイに編成された画素値の処理が伴う。ここで、空間的に編成された２次元アレイは、画像の２次元の特性をキャプチャする（さらなる次元として、時間（たとえば、一続きの２次元画像）およびデータ型（たとえば、色）を含み得る）。通常のシナリオでは、配列された画素値は、静止画像または動きを撮影するための一続きのフレームを生成したカメラによって提供される。従来の画像処理プロセッサは、通常、両極端に分かれる。
第１の極端な側面として、汎用プロセッサまたは汎用のようなプロセッサ（たとえば、ベクトル命令が強化された汎用プロセッサ）上で実行されるソフトウェアプログラムとして、画像処理タスクが実行される。第１の極端は、通常、高度の多目的アプリケーションソフトウェア開発プラットフォームを提供するが、細粒度のデータ構造を、関連するオーバーヘッド（たとえば、命令フェッチおよびデコード、オンチップデータおよびオフチップデータの処理、投機的実行）と組み合わせて利用することによって、最終的には、プログラムコードの実行時にデータの単位当たりに消費されるエネルギーの量が多くなってしまう。
正反対の第２な極端の側面として、より大きな単位のデータに、固定機能結線回路が適用される。カスタム設計された回路に直接適用される（細粒度とは対照的な）より大きな単位のデータを利用することによって、データの単位当たりの消費電力が大幅に抑えられる。しかしながら、カスタム設計された固定関数回路を利用することによって、一般に、プロセッサが実行できるタスクのセットが限られてしまう。このように、第２の極端な側面では、（第１の極端な側面に関連する）広く多目的なプログラミング環境がない。
高度の多目的アプリケーションソフトウェア開発機会およびデータの単位当たりの電力効率の向上を可能にするテクノロジープラットフォームが依然として望まれているが、いまだ解決策が見つかっていない。
概要
ある方法について記載する。この方法は、画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを含む。シミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファメモリでカーネル間通信をインターセプトすることを含む。シミュレートすることは、シミュレーションランタイムにわたって、それぞれのラインバッファメモリに格納されるそれぞれの画像データの量を追跡することをさらに含む。この方法は、追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファメモリのそれぞれのハードウェアメモリ割り当てを決定することも含む。この方法は、画像処理アプリケーションソフトウェアプログラムを実行するために、画像プロセッサのために構成情報を生成することも含む。構成情報は、画像プロセッサのハードウェアラインバッファメモリのハードウェアメモリ割り当てを記述する。
以下の説明および添付の図面を用いて、本発明の実施形態を説明する。
ステンシルプロセッサのアーキテクチャのハイレベルビューを示す図である。 画像処理プロセッサのアーキテクチャをより詳細に示した図である。 画像プロセッサで実行することができるアプリケーションソフトウェアプログラムを示す。 複数のカーネルモデルを示す。 ラインバッファユニットモデルの書き込みポインタおよび読み出しポインタの挙動を示す。 ラインバッファユニットモデルの書き込みポインタおよび読み出しポインタの挙動を示す。 フルライングループ転送モード、実質的に高い転送モード、およびブロック画像転送の読み出しポインタの挙動を示す。 フルライングループ転送モード、実質的に高い転送モード、およびブロック画像転送の読み出しポインタの挙動を示す。 フルライングループ転送モード、実質的に高い転送モード、およびブロック画像転送の読み出しポインタの挙動を示す。 フルライングループ転送モード、実質的に高い転送モード、およびブロック画像転送の読み出しポインタの挙動を示す。 フルライングループ転送モード、実質的に高い転送モード、およびブロック画像転送の読み出しポインタの挙動を示す。 ラインバッファユニット単位のメモリ割り当てを決定する方法を示す。 画像データをライングループに解析すること、ライングループをシートに解析すること、および重なり合うステンシルを有するシートに対して行う動作を示した図である。 画像データをライングループに解析すること、ライングループをシートに解析すること、および重なり合うステンシルを有するシートに対して行う動作を示した図である。 画像データをライングループに解析すること、ライングループをシートに解析すること、および重なり合うステンシルを有するシートに対して行う動作を示した図である。 画像データをライングループに解析すること、ライングループをシートに解析すること、および重なり合うステンシルを有するシートに対して行う動作を示した図である。 画像データをライングループに解析すること、ライングループをシートに解析すること、および重なり合うステンシルを有するシートに対して行う動作を示した図である。 ステンシルプロセッサの実施形態を示す図である。 ステンシルプロセッサの命令語の実施形態を示した図である。 ステンシルプロセッサ内のデータ演算部の実施形態を示す図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 重なり合うステンシルを有する隣接する出力画素値のペアを判定するための２次元シフトアレイおよび実行レーンアレイの使用例を示した図である。 統合型実行レーンアレイおよび２次元シフトアレイの単位セルの実施形態を示す図である。 画像プロセッサの別の実施形態を示す。
詳細な説明
１．０ ユニークな画像処理プロセッサのアーキテクチャ
当技術分野において周知であるように、プログラムコードを実行するための基本的な回路構成は、実行ステージと、レジスタ空間とを含む。実行ステージは、命令を実行するための実行部を含んでいる。実行される命令のための入力オペランドがレジスタ空間から実行ステージに提供される。実行ステージが命令を実行することによって生成される結果は、レジスタ空間に書き戻される。
従来のプロセッサ上でのソフトウェアスレッドの実行には、実行ステージによる、一連の命令の順次実行が伴う。最も一般的には、１つの入力オペランドセットから１つの結果が生成されると言う意味では、演算は、「スカラー」である。しかしながら、「ベクトル」プロセッサの場合、実行ステージによる命令の実行によって、入力オペランドのベクトルから結果のベクトルが生成されることになる。
図１は、２次元シフトレジスタアレイ１０２に連結された実行レーン（ｅｘｅｃｉｔｉｏｎ ｌａｎｅ）１０１のアレイを含むユニークな画像処理プロセッサのアーキテクチャ１００のハイレベルビューを示す図である。ここで、実行レーンアレイに含まれる各実行レーンは、プロセッサ１００がサポートする命令セットを実行するために必要な実行部を含んだ離散実行ステージとして見ることができる。様々な実施形態では、プロセッサが２次元ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）プロセッサとして動作するよう、各実行レーンは、同じマシンサイクルで実行する同じ命令を受け付ける。
各実行レーンは、２次元シフトレジスタアレイ１０２内の対応する位置に専用のレジスタ空間を有する。たとえば、隅にある実行レーン１０３は、隅にあるシフトレジスタ位置１０４に専用のレジスタ空間を有し、隅にある実行レーン１０５は、隅にあるシフトレジスタ位置１０６に専用のレジスタ空間を有する。
これに加えて、前のマシンサイクル時に別の実行レーンのレジスタ空間にあった値を各実行レーンが自分のレジスタ空間から直接操作できるよう、シフトレジスタアレイ１０２はコンテンツをシフトさせることができる。たとえば、ａ＋１水平シフトによって、各実行レーンのレジスタ空間に、その左端の隣接するレジスタ空間から値を受け付けさせる。水平軸に沿って左右両方向に値をシフトさせ、垂直軸に沿って上下両方向に値をシフトさせることができる機能のおかげで、プロセッサは、画像データのステンシルを効率よく処理することができる。
ここで、当技術分野において周知であるように、ステンシルとは、基本的データ単位として利用される画像表面領域のスライスである。たとえば、出力画像の特定の画素位置の新しい値が、この特定の画素位置が中心にある入力画像の領域の画素値の平均として算出されてもよい。たとえば、ステンシルが縦に３画素、横に３画素の大きさを有している場合、特定の画素位置は、３×３画素アレイの中央の画素に対応してもよく、３×３画素アレイ内の９つすべての画素の平均が算出されてもよい。
図１のプロセッサ１００の様々な動作の実施形態によると、実行レーンアレイ１０１の各実行レーンは、出力画像の特定の位置の画素値を算出する役割を果たす。よって、上記３×３ステンシルを平均する例で引き続き説明すると、入力画素データ、およびシフトレジスタ内の８つのシフト演算からなる調整されたシフトシーケンスを初期ロードした後、実行レーンアレイに含まれる各実行レーンは、対応する画素位置についての平均を算出するのに必要な９つすべての画素値をローカルレジスタ空間に受け付けさせる。つまり、プロセッサは、たとえば、隣接する出力画像の画素位置の中心に存在する複数の重なり合うステンシルを同時に処理することができる。図１のプロセッサのアーキテクチャは、特に画像ステンシルの処理に長けているので、ステンシルプロセッサとも称され得る。
図２は、複数のステンシルプロセッサ２０２＿１～２０２＿Ｎを有する画像処理プロセッサのアーキテクチャ２００の実施形態を示した図である。図２に見られるように、アーキテクチャ２００は、ネットワーク２０４（たとえば、オンチップスイッチネットワーク、オンチップリングネットワークまたはその他の種類のネットワークを含むＮＯＣ（Ｎｅｔｗｏｒｋ Ｏｎ Ｃｈｉｐ））を通して複数のステンシルプロセッサユニット２０２＿１～２０２＿Ｎおよび対応するシート生成部２０３＿１～２０３＿Ｎと互いに接続された複数のラインバッファ部２０１＿１～２０１＿Ｍを含む。実施形態では、いずれのラインバッファ部２０１＿１～２０１＿Ｍも、ネットワーク２０４を通していずれのシート生成部２０３＿１～２０３＿Ｎおよび対応するステンシルプロセッサ２０２＿１～２０２＿Ｎに接続してもよい。
プログラムコードがコンパイルされ、対応するステンシルプロセッサ２０２上にロードされて、ソフトウェア開発者が以前に定義した画像処理演算が実行される（また、プログラムコードは、たとえば、設計および実装に応じて、ステンシルプロセッサの関連するシート生成部２０３にロードされてもよい）。少なくともいくつかの例では、第１のパイプラインステージ用の第１カーネルプログラムを第１のステンシルプロセッサ２０２＿１にロードし、第２のパイプラインステージ用の第２のカーネルプログラムを第２のステンシルプロセッサ２０２＿２にロードするなどして画像処理パイプラインが実現されてもよく、たとえば、第１カーネルがパイプラインの第１のステージの関数を実行し、第２カーネルがパイプラインの第２のステージの関数を実行し、パイプラインのあるステージからパイプラインの次のステージに出力画像データを渡すためのさらなる制御フロー方法がインストールされる。
その他の構成では、画像処理プロセッサは、同じカーネルプログラムコードを動作させる２つ以上のステンシルプロセッサ２０２＿１、２０２＿２を有する並列マシンとして実現されてもよい。たとえば、高密度かつ高データ転送速度の画像データストリームを、各々が同じ関数を実行する複数のステンシルプロセッサ間にフレームを分散させることによって処理してもよい。
さらに他の構成では、カーネルの本質的にいずれの有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）も、それぞれのステンシルプロセッサを自身のプログラムコードのカーネルで構成し、ＤＡＧ設計において、あるカーネルからの出力画像を次のカーネルの入力に向けるよう適切な制御フローフックをハードウェアに構成することによって、画像処理プロセッサ上にロードされてもよい。
一般的なフローとして、画像データのフレームは、マクロ入出力部２０５によって受け付けられ、フレーム単位でラインバッファ部２０１のうちの１つ以上に渡される。特定のラインバッファ部は、画像データのそのフレームを、「ライングループ」と呼ばれる、画像データよりも小さな領域に解析し、その後、当該ライングループを、ネットワーク２０４を通して特定のシート生成部に渡す。完全または「フルの（full）」１つのライングループは、たとえば、複数の連続した完全な行または列からなるフレームのデータで構成されてもよい（わかりやすくするために、本明細書では、主に、連続した行を例に用いる）。シート生成部は、さらに、画像データのライングループを、「シート」と呼ばれる、画像データのさらに小さな領域に解析し、このシートを対応するステンシルプロセッサに提示する。
１つの入力を有する画像処理パイプラインまたはＤＡＧフローの場合、一般に、入力フレームは、同じラインバッファ部２０１＿１に向けられ、ラインバッファ部２０１＿１は、画像データをライングループに解析し、これらのライングループをシート生成部２０３＿１に向ける。シート生成部２０３＿１の対応するステンシルプロセッサ２０２＿１は、パイプライン／ＤＡＧにおいて第１カーネルのコードを実行している。ステンシルプロセッサ２０２＿１が処理するライングループに対する処理が完了すると、シート生成部２０３＿１は、出力ライングループを「下流」ラインバッファ部２０１＿２に送る（ユースケースによっては、出力ライングループは、入力ライングループを以前に送った同じラインバッファ部２０１＿１に送り返してもよい）。
次に、自身の各々のその他のシート生成部およびステンシルプロセッサ（たとえば、シート生成部２０３＿２およびステンシルプロセッサ２０２＿２）上で実行されるパイプライン／ＤＡＧにおける次のステージ／演算を表す１つ以上の「コンシューマ」カーネルが、第１のステンシルプロセッサ２０２＿１によって生成された画像データを下流ラインバッファ部２０１＿２から受け取る。このように、第１のステンシルプロセッサ上で動作する「プロデューサ」カーネルが、第２のステンシルプロセッサ上で動作する「コンシューマ」カーネルに出力データを転送する。第２のステンシルプロセッサでは、コンシューマカーネルが、パイプラインまたはＤＡＧ全体の設計と整合性のあるプロデューサカーネルの後に次のタスクセットを実行する。
図１で上述したように、各ステンシルプロセッサ２０２＿１～２０２＿Ｎは、画像データの複数の重なり合うステンシルを同時に処理するように設計されている。複数の重なり合うステンシルおよびステンシルプロセッサの内蔵ハードウェア処理能力によって、シートのサイズが効果的に決定される。ここでも、上述したように、任意のステンシルプロセッサ２０２＿１～２０２＿Ｎ内で、実行レーンのアレイが一斉に動作し、複数の重なり合うステンシルで覆われた画像データ表面領域を同時に処理する。
これに加えて、様々な実施形態では、ステンシルプロセッサ２０２の対応する（たとえば、ローカルの）シート生成部２０３によって、当該ステンシルプロセッサの２次元シフトレジスタアレイに画像データのシートがロードされる。シートおよび２次元シフトレジスタアレイ構造の使用によって、たとえば、実行レーンアレイによってその直後に大量のデータに対して直接実行される処理タスクを用いた１つのロード動作として当該データを大量のレジスタ空間に移動することによって、消費電力の改善が効果的に可能になると考えられている。これに加えて、実行レーンアレイおよび対応するレジスタアレイの使用によって、簡単にプログラム可能／構成可能なそれぞれ異なるステンシルサイズが可能になる。ラインバッファ部、シート生成部、およびステンシルプロセッサの動作について、より詳細を下記のセクション３．０でさらに説明する。
２．０ ラインバッファユニット単位のメモリ割り当ての決定
上記の説明から理解することができるように、ハードウェアプラットフォームは無数の異なるアプリケーションソフトウェアプログラム構造をサポートすることができる。つまり、実質的に無制限の数の異なる複雑なカーネル間接続をサポートすることができる。
１つの課題は、各ラインバッファユニット２０１＿１から２０１＿Ｍが特定のソフトウェアアプリケーションについてどれだけのメモリ空間を割り当てられるべきかを理解することである。ここで、一実施形態では、ラインバッファユニットのさまざまなものは、例えば物理的に共有されたメモリからそれらに割り当てられたそれら自体のそれぞれのメモリに対するアクセスを有する。したがって、ラインバッファユニットは、より一般的にはラインバッファメモリとして特徴付けられ得る。プログラムの実行中に、ラインバッファユニットは、たとえば生成カーネルから受け取ったデータを、それの対応のメモリに一時的に格納する。消費カーネルがデータを受け取る準備ができると、ラインバッファユニットはそれの対応のメモリからデータを読み出し、消費カーネルに転送する。
ラインバッファユニットの１つ以上またはすべてが同じ共有メモリリソースに物理的に結合されているため、画像プロセッサで実行するためのアプリケーションソフトウェアプログラムの構成には、メモリリソースを共有する各ラインバッファユニットに、共有メモリリソースのメモリ容量のうちどれほどを個別に割り当てるべきかを規定することが含まれる。各ラインバッファユニットについて実行可能なメモリ割り当てを明確にすることは、特に複雑なデータフローおよび関連するデータ依存性を有する複雑なアプリケーションソフトウェアプログラムの場合、判断するのが非常に困難である。
図３は、画像プロセッサ上の例示的ないくぶん複雑なアプリケーションソフトウェアプログラム（またはその一部）およびそのラインバッファユニット構成の一例を示す。さまざまな実装形態において、生成カーネルは、異なる消費カーネルに対して別々の異なる出力画像ストリームを生成することを許可される。さらに、生成カーネルは、２つ以上の異なるカーネルによって消費される単一の出力ストリームを生成することも許可される。最後に、さまざまな実施形態において、ラインバッファユニットは、１つの生成カーネルからしか入力ストリームを受け取ることができないが、そのストリームを１つ以上の消費カーネルに供給することができる。
図３のアプリケーションソフトウェア構成は、これらの構成の可能性の各々を示す。ここで、カーネルＫ１は、カーネルＫ２とＫ３との両方に対して第１のデータストリームを生成し、カーネルＫ４に対して第２の異なるデータストリームを生成する。カーネルＫ１は、第１のデータストリームをラインバッファユニット３０４＿１に送り、ラインバッファユニット３０４＿１は、そのデータをカーネルＫ２およびＫ３の両方に転送する。カーネルＫ１は、さらに、第２のデータストリームをラインバッファユニット３０４＿２に送り、ラインバッファユニット３０４＿２はそのデータをカーネルＫ４に転送する。さらに、カーネルＫ２はデータストリームをカーネルＫ４に送り、カーネルＫ３はデータストリームをカーネルＫ４に送る。カーネルＫ２は、それのデータストリームをラインバッファユニット３０４＿３に送り、ラインバッファユニット３０４＿３はそのデータをカーネルＫ４に転送する。カーネルＫ３は、それのデータストリームをラインバッファユニット３０４＿４に送り、ラインバッファユニット３０４＿４はそのデータをカーネルＫ４に転送する。
ここで、ラインバッファユニット３０４＿１～３０４＿４の各々に独自に割り当てられるメモリの量は、明示的に計算するのが難しい。このような各メモリ割り当てを待ち行列として見ると、ラインバッファユニットが時間の経過とともに生成カーネルから大量のデータを受け取る場合、必要なメモリ量は増加する傾向がある。対照的に、ラインバッファユニットが時間の経過とともに生成カーネルから少量のデータを受け取る場合、必要なメモリ量は減少する傾向がある。同様に、ラインバッファユニットが、時間の経過とともに、より多数の消費カーネルに少量のデータを送る場合、必要なメモリ量は増加する傾向があり、または、ラインバッファユニットが、時間の経過とともに、より少数の消費カーネルに大量のデータを送る場合、必要なメモリ量は減少する傾向がある。
プロデューサカーネルから時間の経過とともにラインバッファユニットが受け取るデータの量は、次のいずれかの関数とすることができる：１）生成カーネルがそれ自身の入力データに対して有する依存性；２）上記１）の依存性／レートに関係なく、生成カーネルが出力データを生成するレート；および３）生成カーネルがラインバッファユニットに送るデータユニットのサイズ。同様に、ラインバッファユニットが時間の経過とともに送るデータの量は、次のいずれかの関数とすることができる：１）生成カーネルが供給を行う消費カーネルの数；２）１）の各消費カーネルが新たなデータを受け取る準備ができているそれぞれのレート（消費カーネルが有する他のデータ依存性の関数であることができる）；および３）消費カーネルがラインバッファユニットから受け取るデータユニットのサイズ。
少なくともやや複雑なアプリケーションソフトウェアプログラム構造では、さまざまな相互依存性および接続速度の複雑な性質により、各ラインバッファユニットに割り当てられるメモリ空間の正しい量を明示的に計算することが非常に困難になるため、さまざまな実施形態においては、シミュレーション環境でランタイム前にアプリケーションソフトウェアプログラムの実行をシミュレートし、シミュレートされたプログラムの内部データフローから生じる、各ラインバッファユニットにおいて待ち行列に入れられたデータ量を監視するヒューリスティックなアプローチが採用される。
図４は、シミュレーション環境をセットアップするために行われる図３のアプリケーションソフトウェアプログラムの準備プロシージャを示す。一実施形態において、各カーネルのシミュレーションモデルが、各カーネルをそのロード命令およびそのストア命令にストリップすることにより作成される。カーネルのロード命令は、カーネルがラインバッファユニットから入力データを消費することに対応し、カーネルのストア命令は、カーネルがラインバッファユニットに書き込むために出力データを生成することに対応する。上述のように、カーネルは、例えば、複数の異なるカーネル／ラインバッファユニットから複数の異なる入力ストリームを受け取るように構成することができる。そのため、実際のカーネルおよびそのシミュレーションモデルカーネルは、複数のロード命令（各異なる入力ストリームにつき１つ）を含むことができる。また、上記で説明したように、カーネル（およびしたがってシミュレーションモデルカーネル）は、異なるカーネルに異なる生成ストリームを供給するように構成することができる。そのため、実際のカーネルおよびそれのシミュレーションモデルカーネルは、複数のストア命令を含むことができる。
図４を参照すると、シミュレーションモデルカーネルＫ１は、１つのロード命令（ＬＤ＿１）と２つのストア命令と（ＳＴ＿１およびＳＴ＿２）を示し、これは、カーネルＫ１が１つの入力ストリーム（画像プロセッサへの入力データ）を受け取り２つの出力ストリームを（１つはラインバッファユニット３０４＿１に、もう１つはラインバッファユニット３０４＿２に）与えることを示す、図３のカーネルＫ１の描写と一致している。図４は、シミュレーションモデルカーネルＫ２に対する１つのロード命令および１つのストア命令も示し、これは、カーネルＫ２がラインバッファユニット３０４＿１から１つの入力ストリームを受け取りラインバッファユニット３０４＿３への１つの出力ストリームを生成する、図３のカーネルＫ２の描写と一致している。図４は、シミュレーションモデルカーネルＫ３に対する１つのロード命令および１つのストア命令も示し、これは、カーネルＫ３がラインバッファユニット３０４＿１から１つの入力ストリームを受け取りラインバッファユニット３０４＿４への１つの出力ストリームを生成する、図３のカーネルＫ３の描写と一致している。最後に、図４は、３つのロード命令と１つのストア命令とを有するシミュレーションモデルカーネルＫ４を示し、これは、シミュレーションモデルカーネルＫ３がラインバッファユニット３０４＿２から第１の入力ストリームを受け取り、ラインバッファユニット３０４＿３から第２の入力ストリームを受け取り、ラインバッファユニット３０４＿４から第３の入力ストリームを受け取る、図３のカーネルＫ４の描写と一致している。カーネルＫ４は、図３において、１つの出力ストリームを生成するものとしても示されている。
図４のループ４０１＿１～４０１＿４で示されるように、シミュレーションモデルカーネル（実際のカーネルと同様）は、繰り返しループする。つまり、実行の開始時に、あるカーネルは、それのロード命令を実行してそれの入力データを受け取り、実行の終わりに、あるカーネルは、それのストア命令を実行して、それがそれのロード命令から受け取った入力データから出力データを生成する。その後、プロセスが繰り返される。さまざまな実施形態において、各シミュレーションモデルカーネルは、それがそれの出力データを生成するために入力データに対して演算を実行するのに消費する時間量（それの伝播遅延）を示す値も含んでもよい。つまり、シミュレーションモデルカーネルは、それのロード命令が実行されてから一定のサイクル数が経過するまで、それのストア命令の実行を許可しない。加えて、さまざまな実施形態において、シミュレーションの実行に費やされる時間を削減するために、カーネルモデルからそれらの実際の画像処理ルーチンが取り除かれる。つまり、シミュレーションでは実際の画像処理は実行されず、「ダミー」データのデータ転送のみがシミュレートされる。
シミュレーションモデルカーネルが構築された後、それらはアプリケーションソフトウェアプログラム全体の設計／アーキテクチャと一致するラインバッファユニットのそれぞれのシミュレーションモデルを介して互いに接続される。本質的に、例として図３のアプリケーションソフトウェアプログラムを使用し続けて、アプリケーションソフトウェアプログラム３００のシミュレーションモデルは、シミュレーションモデルが、図３に示したアーキテクチャと一致するラインバッファユニット３０４＿１～３０４＿４のそれぞれのシミュレーションモデルを介して相互接続される、図４のカーネルＫ１～Ｋ４のシミュレーションモデルを含む、シミュレーション環境で構築される。
各ラインバッファユニットでのメモリのニーズを調べるために、シミュレートされた入力画像データストリーム（たとえば、図３の入力画像データ３０１のシミュレーション）が、アプリケーションのシミュレーションモデルに提示される。次に、アプリケーションソフトウェアプログラムのシミュレーションモデルが実行され、シミュレーションモデルカーネルは、それらのロード命令の実行を通じて、シミュレートされた量の入力データを繰り返し消費し、それらのストア命令によって、受け取られた入力データからシミュレートされた量の出力データを生成し、反復する。
ここで、各シミュレートされたロード命令は、元のソースカーネルに存在する何らかの入力画像データフォーマッティング（入力ライングループのライン数、最大入力ライングループレート、入力ブロックの次元／サイズ、最大入力ブロックレートなど）を組み込むか、またはそうでなければそれに基づいて、消費される入力データのシミュレートされた量およびレートを判断してもよい。ここで、各ストア命令は、元のソースカーネルに存在する何らかの出力画像フォーマッティング（出力ライングループのライン数、最大出力ライングループレート、出力ブロックの次元／サイズ、最大出力ブロックレートなど）を特定するか、またはそうでなければそれに基づいて、生成される出力データの量およびレートを判断してもよい。一実施形態では、カーネルモデルのロード／ストア命令およびそれらのラインバッファユニットモデルの処理は、例えば生成される画像データの特定の次の部分が生成モデルカーネルのストア命令によって識別され、要求される画像データの特定の次の部分が消費モデルカーネルのロード命令によって識別されるという点で、アプリケーションソフトウェアおよび基底のハードウェアプラットフォームの実際のハンドシェイクを反映する。
各ラインバッファユニットモデルは、それのそれぞれの生成モデルカーネルからそれのそれぞれのシミュレートされた入力ストリームを受け取り、それをたとえば無制限の容量を有するシミュレートされたメモリリソースに格納する。ここでも、トランザクションごとに転送されるデータの量は、生成モデルカーネルの元のソースカーネルの量と一致している。ラインバッファユニットモデルによって受け取られる画像ストリームの消費カーネルがそれらのそれぞれのロード命令を実行すると、それらは、それらの元のソースカーネルのトランザクションごとの量と一致する次の量の入力画像ストリームをラインバッファユニットモデルに要求する。応答して、ラインバッファユニットモデルは、それのメモリリソースから、要求された次のデータユニットを与える。
アプリケーションソフトウェアプログラムのモデルがシミュレーション環境で実行されると、各ラインバッファユニットモデルのそれぞれのメモリ状態は、それの消費カーネルのロード命令要求に応答してそれから読み取りを行うアクティビティ、およびそれの消費カーネルのストア命令要求に応答してそれに書き込みを行うアクティビティとともに、エブアンドフローすることになる。最終的に各ラインバッファユニットの必要なメモリ容量を判断するために、図５ａおよび図５ｂを参照すると、各ラインバッファユニットシミュレーションモデルは、書き込みポインタおよび読み出しポインタを含む。書き込みポインタは、生成カーネルモデルからの入力画像データが、ラインバッファユニットモデルのメモリにこれまでにどれだけ書き込まれたかを特定する。読み出しポインタは、ラインバッファユニットモデルの消費カーネルモデルからのロード命令要求を処理するために、書き込まれた入力画像データのうち、これまでにどれだけの量がラインバッファユニットモデルのメモリから読み出された特定する。
図５ａの描写は、特定の消費カーネルが、ロード命令要求ごとにＸ量の画像データを要求することを示す（Ｘは、例えば、特定の画像ライン数、ブロックサイズなどに対応し得る）。つまり、消費カーネルモデルが既に読み出しポインタに至るデータ量を送られているため、ラインバッファユニットは、メモリに書き込まれるデータ量が読み出しポインタ＋Ｘに対応する量にメモリに到達するまで（つまり、書き込みポインタが読み出しポインタ＋Ｘに等しい値を指すまで）、消費カーネルモデルからの次のロード命令要求を処理することはできないことになる。図５ａに具体的に示すように、書き込みポインタはまだこのレベルに達していない。そのため、消費カーネルが既に次の量（読み出しポインタ＋Ｘまで）を要求している場合、消費カーネルは現在、生成カーネルからのより多くの出力データがメモリに書き込まれるのを待機してストールされている。消費カーネルがまだ次の量を要求していない場合、消費カーネルはまだ事実上ストールされておらず、生成カーネルが少なくとも（読み出しポインタ＋Ｘ）－書き込みポインタ）に等しい量を与える時間が依然としてあるため、それは、消費カーネルがそれを要求する前にメモリに書き込まれることができる。この特定のイベントを図５ｂに示す。
ラインバッファユニットに必要なメモリ容量の最大量は、アプリケーションソフトウェアプログラムの十分に長いシミュレーションランタイム実行での読み出しポインタと書き込みポインタとの最大観測差である。したがって、各ラインバッファユニットのメモリ容量の判断には、十分なサイクル数の間プログラムの実行をシミュレートしながら、書き込みポインタと読み出しポインタとの差を継続的に追跡し、新たな各最大観測差を記録する必要がある。十分な数の実行サイクルが完了すると、シミュレーション全体で観測された最大差に対応する、各ラインバッファユニットモデルについての残りの記録された最大観測差は、各ラインバッファユニットに必要なメモリ容量に対応する。
さまざまな実施形態において、プロデューサが、そのコンシューマが出力データを消費できるよりもはるかに速いレートで出力データを生成し、ラインバッファユニットに、継続的にそのメモリに書き込ませ、その無制限の容量を限度なく使用させる非現実的な状態を回避するために、各カーネルモデルは、そのストア命令の各々で強制される書き込みポリシーも含む。
つまり、書き込みポリシーは、生成カーネルモデルの出力データで書き込まれるラインバッファユニットメモリの量に対するチェックとして機能する。具体的には、一実施形態では、対応する消費カーネルのすべてがストールされる（「準備完了」とも呼ばれる）まで、生成カーネルのストア命令は実行されない。つまり、生成カーネルのロード命令は、各消費カーネルの読み出しポインタ＋Ｘが生成カーネルの画像ストリームの書き込みポインタよりも大きい場合にのみ、実行が許可される。
この状態では、消費カーネルの各々はストールされる（データはまだ生成カーネルによって生成されておらず、ラインバッファユニットメモリに書き込まれていないため、消費カーネルの各々はそれらのそれぞれのロード命令を生成カーネルの画像ストリームの次のユニットに対して実行できない）。そのため、シミュレーション環境は、プロデューサが、特定のラインバッファユニットに向けられる特定の出力ストリームに対してストア命令を実行することは、ラインバッファユニットからの出力ストリームを消費する各カーネルが、ラインバッファユニットからストリームのデータの次のユニットをロードする、それらのそれぞれのロード命令でストールされるまで、できないことを特徴としている。繰り返すが、これは実際のシステムのランタイム挙動の典型ではないが、（書き込みポリシーが有効な状態で書き込みポインタ対読み出しポインタの最大観測差によって判断される）ラインバッファユニットで必要なメモリ量の上限をおおまかに設定する。
たとえば、各ラインバッファユニットに実際に割り当てられるメモリの量が、書き込みポインタ対読み出しポインタの最大観測差から判断される量と同じである（かまたはそれよりわずかに多い）場合、実際のシステムでコンシューマストールが発生することは決してないであろうと思われ、なぜならば、プロデューサはラインバッファユニットのメモリがいっぱいになる（その時点で、ラインバッファユニットは実際のシステムではプロデューサがそれ以上データを送ることを許可しない）までストア命令を自由自在に実行することが頻繁であるからである。ただし、各プロデューサは、シミュレーション中において、それのすべてのコンシューマがストールされるまでそれのストア命令を実行することを許可されなかったため、シミュレーションを通じて決定されたメモリ割り当ては、実際のシステムでは、プロデューサが、消費するための新たなデータを、おおよそそれのコンシューマがストールするまでに生成することに変換される。そのため、平均して、コンシューマは実際のシステムではストールしないはずである。このように、シミュレーション結果により、各ラインバッファユニットで必要な最小メモリ容量が本質的に判断される。
理想的には、十分な数のシミュレートされたランタイムサイクルの後、各ラインバッファユニットに割り当てられるべきメモリの量を決定することができる。しかしながら、さまざまなシミュレーションランタイム経験において、シミュレートされたシステムは、システム内のどこにもデータが流れない完全なデッドロックに達し得る。つまり、システム内のすべてのカーネルは次のロード命令を実行できず、なぜならば、データはまだ生成されておらず、すべてのプロデューサが次の量のデータを書き込むことができないからである（たとえば、それら自体のロード命令がストールしており、生成カーネルに出力データを作成するための新たな入力がないからである）。
上記のようにシステムが完全なデッドロックに達すると、システムの状態が分析され、デッドロックサイクルが検出される。デッドロックサイクルは、特定のストアの実行を待機している特定のストールされたロードを含む、アプリケーションのデータフロー内の閉じられたループであるが、その特定のストアはストールされたロードの実行を待っているため実行することができない（ストールされたロードおよびストールされたストアは、互いに直接通信するカーネルに関連付けられる必要はないことに注意されたい）。
例えば、図３のソフトウェアプログラムのシミュレーションモデルでは、ラインバッファユニット３０４＿４からデータを読み出すＫ４のカーネルのモデルのロード命令は、カーネルＫ３によってデータが生成されるのを待っているかもしれない。この特定のロードのストールは、本質的にカーネルＫ４のすべてをストールし、したがって、ラインバッファ３０４＿２から読み出すＫ４のロード命令の実行を妨げる。（たとえば、Ｋ１がラインバッファ３０４＿２に大きなデータユニットを書き込むため、）ラインバッファ３０４＿２の状態が書き込みポインタが読み出しポインタ＋Ｘよりも進んでいる場合、ラインバッファ３０４＿２に書き込むＫ１のストア命令はストールし、それは、ラインバッファ３０４＿１に書き込むストア命令を含むＫ１のすべてをストールする。
ラインバッファ３０４＿１は書き込まれていないため、Ｋ３はストールされ、それにより、デッドロックサイクルの識別分析が完了する。つまり、デッドロックサイクルは、１）Ｋ１からラインバッファユニット３０４＿１を介してカーネルＫ３に、２）カーネルＫ３からラインバッファユニット３０４＿４を介してカーネルＫ４に、および３）カーネルＫ４からラインバッファ３０４＿２を介してカーネルＫ１に戻るよう実行される。この特定のデッドロックサイクルが存在すると、Ｋ２もストールし、システム全体の完全なデッドロックが発生する（これは、システム内において、より多くのデッドロックサイクルも引き起こす）。一実施形態においては、デッドロックサイクルが識別されると、サイクルに沿ったストールされたストア命令は、システムが「キックスタート」されて動作に戻ることを期待して、１つのデータユニットを前進させることを許可される。たとえば、ラインバッファユニット３０４＿１に書き込むカーネルＫ１のストア命令が１データユニット前進させられる場合、それは、カーネルＫ３のストールされたロード命令の実行を引き起こすのに十分であるかもしれず、それは、次いで、システムに再び動作を開始させるかもしれない。
一実施形態では、デッドロックサイクルに沿った１つのストールされたストア命令のみが、１ユニットを前進させることが許可される。そのような前進によってシステムが再び動作を開始しない場合、デッドロックサイクルに沿った別のストア命令が前進のために選択される。前進のために一度に１つのストア命令を選択するプロセスは、システムが動作を開始するまで、またはデッドロックサイクルに沿ったすべてのストア命令が１データユニットを前進させることを許可された後、完全にデッドロックのままであるまで、続く。後者の条件に達した（システムは完全なデッドロックのままである）場合、デッドロックサイクルに沿ったライタの１つが選択され、システムが再び動作を開始することを期待して、自由に書き込むことを許可される。システムが動作を開始しない場合、デッドロックサイクルに沿った別のストア命令が選択され、自由に書き込むことを許可されるなどする。最終的に、システムは動作を開始するはずである。
さまざまな実施形態において、生成／消費カーネルモデルは、それらのそれぞれのラインバッファユニットモデルとの間で、異なる転送モードに従って、画像データを送り／読み出してもよい。「フルライングループ」と呼ばれる第１のモードによれば、多数の同じ幅の画像データのラインがカーネルモデルとラインバッファユニットモデルとの間で転送される。
図６ａおよび図６ｂは、フルライングループモード動作の実施形態を示す。図６ａで見られるように、画像領域６００は、フレーム全体の画像データまたはフレーム全体のうちの一部のセクションの画像データに対応する（読者は、描かれた行列が、画像全体が有する異なる画素位置を示すことを理解するであろう）。図６ａに示すように、カーネルモデルとラインバッファユニットモデルとの間で送られる画像データの第１の転送（たとえば、第１のパケット）は、転送されるフレームまたはその一部のセクション６００を横断して完全に延在する、第１のグループの同幅画像ライン６０１を含む。次に、図６ｂに示されるように、第２の転送は、フレームまたはその一部のセクション６００を横断して完全に延在する第２のグループの同幅画像ライン６０２を含む。
ここで、図６ａのグループ６０１の転送は、ラインバッファユニットモデルの書き込みおよび／または読み出しポインタを１ユニット分先に進めるだろう。同様に、図６ｂのグループ６０２の転送は、ラインバッファユニットモデルの書き込みおよび／または読み出しポインタを別の１ユニット分進めるだろう。そのため、図５ａおよび図５ｂに関して上記で説明した書き込みポインタおよび読み出しポインタの挙動は、フルライングループモードと一致している。
「実質的に高い（virtually tall）」と呼ばれる別の転送モードを用いて、画像データのブロック（画像データの２次元表面領域）を転送することができる。ここで、図１に関して上述し、以下により詳細に説明するように、さまざまな実施形態において、画像プロセッサ全体が有する１つ以上の処理コアは各々、２次元実行レーンアレイおよび２次元シフトレジスタアレイを含む。そのため、処理コアのレジスタ空間には、（単なるスカラー値または単一ベクトル値ではなく、）画像データの全ブロックがロードされる。
処理コアによって処理されるデータユニットの２次元の性質と整合して、実質的に高いモードは、画像データのブロックを図６ｃおよび図６ｄに示すように転送することができる。図６ｃを参照すると、最初に、例えば、第１の生成カーネルモデルからラインバッファユニットモデルに、より小さい高さの全幅のライングループが転送される（６１１）。その点から先は、少なくとも画像領域６００について、画像データは、生成カーネルモデルから、ラインバッファユニットモデルに、より小さな幅のライングループ６１２＿１、６１２＿２などで転送される。
ここで、より小さな幅のライングループ６１２＿１は、例えば、生成カーネルモデルからラインバッファユニットモデルへの第２のトランザクションで転送される。次に、図６ｄで観察されるように、次の、より小さい幅のライングループ６１２＿２が、例えば、生成カーネルモデルからラインバッファユニットモデルへの第３のトランザクションで転送される。そのため、ラインバッファユニットモデルの書き込みポインタは、最初は大きな値で増分され（フルライングループ６１１の転送を表すため）、次いで、より小さな値で増分される（例えば、より小さな幅のライングループ６１２＿１の転送を表すための、第１の、より小さな値、および次いで再び、より小さな幅のライングループ６１２＿２の転送を表すための、次の、より小さな値で、増分される）。
前述のように、図６ｃおよび図６ｄは、生成カーネルモデルによって送られる内容のラインバッファユニットモデルメモリへの書き込みを示す。消費カーネルモデルは、上記のように画像データも受け取りもする（その場合、読み出しポインタの挙動はちょうど上に記載される書き込みポインタの挙動と同じである）ように、または画像データのブロックがラインバッファメモリに形成されるとそれら画像データのブロックを受け取るように、構成されてもよい。
つまり、後者に関しては、最初に消費カーネルモデルに第１のフルライングループ６１１は送信されない。次いで、消費モデルに第２の５×５のアレイの画素値が送られ、これらの画素値の下端は、第２のより小さい線幅のライングループ６１２＿２がラインバッファメモリに書き込まれた後、参照６１２＿２によって輪郭が描かれる。ちょうど上に記載される消費カーネルモデルへのブロック転送の場合、図６ｅに示すように、転送される次の量には、ラインバッファメモリに、より最近書き込まれた、より小さなデータ片と、しばらく前にラインバッファメモリに書き込まれた、より大きなデータ片とが含まれる。
図７は、ラインバッファユニットごとのメモリ割り当てを決定するための上記の方法を示す。この方法は、画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすること７０１を含む。シミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するラインバッファメモリのモデルでカーネル間通信をインターセプトすること７０２を含む。シミュレートすることは、シミュレーションランタイムにわたって、それぞれのシミュレートされたラインバッファメモリに格納されるそれぞれの画像データの量を追跡すること７０３をさらに含む。この方法は、追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファメモリのそれぞれのハードウェアメモリ割り当てを決定すること７０４も含む。
シミュレートされたラインバッファメモリストレージ状態の追跡された観測からのハードウェアメモリ割り当ての決定は、少なくとも部分的に、シミュレートされたラインバッファメモリを互いの観点からスケーリングすることにより、実現することができる。たとえば、第１のシミュレートされたラインバッファメモリが、第２のシミュレートされたラインバッファメモリの２倍の最大の書き込み対読み出しポインタの差を示した場合、第１のハードウェアラインバッファユニットの対応する実際のハードウェアメモリ割り当ては、第２のハードウェアラインバッファユニットの対応する実際のハードウェアメモリの割り当てのそれの約２倍になるであろう。残りの割り当てはそれに応じてスケーリングされるであろう。
アプリケーションソフトウェアプログラムに対してメモリ割り当てが決定された後、アプリケーションソフトウェアプログラムは、ターゲット画像プロセッサで実行される構成情報を用いて構成することができ、構成情報は、画像プロセッサのハードウェアに、シミュレーションから行われた判断に従って、ラインバッファユニットのメモリ空間がそれぞれのハードウェアラインバッファユニットに割り当てられる量を通知する。構成情報には、たとえば、画像プロセッサの特定のステンシルプロセッサで実行し、特定のハードウェアラインバッファユニットに対して生成し、特定のハードウェアラインバッファユニットから消費するよう、カーネルを割り当てることも含まれ得る。次いで、アプリケーション用に生成された構成情報のコーパスが、例えば、アプリケーションを実行するために画像プロセッサハードウェアを「セットアップ」するために、画像プロセッサの構成レジスタ空間および/または構成メモリリソースにロードされ得る。
さまざまな実施形態において、前述のラインバッファユニットは、より一般的には、生成カーネルと消費カーネルとの間で画像データを格納および転送するバッファとして特徴付けられ得る。すなわち、さまざまな実施形態において、バッファは必ずしもライングループを待ち行列に入れる必要はない。加えて、画像プロセッサのハードウェアプラットフォームは、関連付けられたメモリリソースを有する複数のラインバッファユニットを含んでもよく、１つ以上のラインバッファが、単一のラインバッファユニットから動作するように構成されてもよい。つまり、ハードウェアにおける単一のラインバッファユニットは、異なる生成／消費カーネルペア間で異なる画像データフローを格納および転送するように構成することができる。
さまざまな実施形態では、実際のカーネルは、それらのモデルをシミュレートするのではなく、シミュレーション中にシミュレートされてもよい。さらに、シミュレーション中にカーネルとラインバッファユニットとの間で転送される画像データは、画像データの表現（たとえば、各ラインが特定のデータサイズに対応すると理解されるラインの数）であってもよい。簡単にするために、画像データという用語は、実際の画像データまたは画像データの表現に適用されると理解されるべきである。
３．０ 画像処理プロセッサ実装の実施形態
図８ａ～図８ｅ～図１２は、上述した画像処理プロセッサおよび関連するステンシルプロセッサの様々な実施形態のより詳細な動作および設計を提供する図である。ライングループをステンシルプロセッサの関連するシート生成部にラインバッファ部が送るという図２の説明を思い返すと、図８ａ～図８ｅは、ラインバッファ部２０１の解析アクティビティ、シート生成部２０３の細粒度の解析アクティビティ、およびシート生成部２０３に連結されるステンシルプロセッサ７０２のステンシル処理アクティビティの実施形態をハイレベルで示す図である。
図８ａは、画像データ８０１の入力フレームの実施形態を示した図である。また、図８ａは、ステンシルプロセッサが処理するように設計された、３つの重なり合うステンシル８０２（各々の寸法は、３画素×３画素である）の輪郭も示している。各ステンシルが出力画像データを生成する出力画素を、黒い実線で強調表示している。わかりやすくするために、３つの重なり合うステンシル８０２は、垂直方向にのみ重なり合うよう示されている。ステンシルプロセッサは、実際には、垂直方向および水平方向の両方に重なり合うステンシルを有するように設計されてもよいことを認識することが適切である。
ステンシルプロセッサ内でステンシル８０２が縦に重なり合っているために、図８ａに見られるように、フレーム内に１つのステンシルプロセッサが処理できる幅広い帯状の画像データが存在する。より詳細は以下に説明するが、実施形態では、ステンシルプロセッサは、重なり合うステンシル内のデータを、画像データの端から端まで左から右へ処理する（次に、上から下の順に、次のラインセットに対して繰り返す）。よって、ステンシルプロセッサがこの動作で前進を続けると黒い実線の出力画素ブロックの数が水平右方向に増える。上述したように、ラインバッファ部２０１は、ステンシルプロセッサが今後の多くの周期数にわたって処理するのに十分な受信フレームからの入力画像データのライングループを、解析する役割を果たす。ライングループの例を、影付き領域８０３として示している。実施形態では、ラインバッファ部２０１は、シート生成部にライングループを送信／シート生成部からライングループを受信するためのそれぞれ異なる力学を理解できる。たとえば、「グループ全体」と称するあるモードによると、画像データの完全な全幅のラインがラインバッファ部とシート生成部との間で渡される。「実質的に高い」と称する第２モードによると、最初に１つのライングループが全幅の行のサブセットとともに渡される。その後、残りの行がより小さい（全幅未満の）一部として順番に渡される。
入力画像データのライングループ８０３がラインバッファ部によって規定されてシート生成部に渡されると、シート生成部は、さらに、このライングループを、ステンシルプロセッサのハードウェア制約により正確に適合するより細かいシートに解析する。より具体的には、より詳細は以下にさらに説明するが、実施形態では、各ステンシルプロセッサは、２次元シフトレジスタアレイから構成される。２次元シフトレジスタアレイは、本質的に、画像データを実行レーンのアレイの「下」にシフトさせる。シフトパターンは、各実行レーンに、レーン自身の個々のステンシル内のデータを処理させる（つまり、各実行レーンは、自身の情報のステンシルを処理し、そのステンシルの出力を生成する）。実施形態では、シートは、２次元シフトレジスタアレイを「埋める」または２次元シフトレジスタアレイにロードされる入力画像データの表面領域である。
より詳細はさらに後述するが、様々な実施形態では、実際には、任意の周期でシフトさせることができる２次元レジスタデータから構成されるレイヤは、複数ある。便宜上、本明細書のほとんどでは、単に、用語「２次元シフトレジスタ」などを用いて、シフトさせることができる２次元レジスタデータから構成される１つ以上のこのようなレイヤを有する構造を指す。
よって、図８ｂに見られるように、シート生成部は、ライングループ８０３からの最初のシート８０４を解析し、ステンシルプロセッサに提供する（ここで、データのシートは、参照番号８０４で全体的に識別される陰影領域に対応する）。図８ｃおよび図８ｄに見られるように、ステンシルプロセッサは、重なり合うステンシル８０２を入力画像データのシートの左から右へ効果的に移動することによってシートを処理する。図８ｄの時点では、シート内のデータから出力値を算出できる画素数はなくなっている（他の画素位置はでシート内の情報から決定される出力値を有し得るものはない）。わかりやすくするために、画像の境界領域は無視している。
図８ｅに見られるように、次に、シート生成部は、ステンシルプロセッサに引き続き処理させるために次のシート８０５を提供する。なお、次のシートに対する処理を開始するときのステンシルの初期位置は、第１シートの画素数がなくなっている箇所から右隣に進んだ場所である（すでに図８ｄで示したように）ことが分かる。新しいシート８０５では、ステンシルプロセッサが第１シートの処理と同じ方法でこの新しいシートを処理するにつれて、ステンシルは、右に移動し続けるだけである。
なお、出力画素位置を囲むステンシルの境界領域のために、第１シート８０４のデータと第２シート８０５のデータとの間に重なりがある。この重なりは、シート生成部が重なり合うデータを２回再送信するだけで処理できる。別の実装形態では、次のシートをステンシルプロセッサに送るために、シート生成部は、新しいデータをステンシルプロセッサに送るだけであってもよく、ステンシルプロセッサは、重なり合うデータを前のシートから再利用する。
図９は、ステンシルプロセッサのアーキテクチャ９００の実施形態を示す図である。図９に見られるように、ステンシルプロセッサは、データ演算部９０１と、スカラープロセッサ９０２および関連するメモリ９０３と、入出力部９０４とを備える。データ演算部９０１は、実行レーン９０５のアレイと、２次元シフトアレイ構造９０６と、アレイの特定の行または列に対応付けられた別個のＲＡＭ９０７とを含む。
入出力部９０４は、シート生成部から受け付けたデータの「入力」シートをデータ演算部９０１にロードして、ステンシルプロセッサからのデータの「出力」シートをシート生成部に格納する役割を果たす。実施形態では、シートデータをデータ演算部９０１にロードすることは、受け付けたシートを画像データの行／列に解析し、画像データの行／列を２次元シフトレジスタ構造９０６または実行レーンアレイ（より詳細は後述する）の行／列のＲＡＭ９０７のそれぞれにロードすることを伴う。シートがメモリ９０７に最初にロードされた場合、実行レーンアレイ９０５内の個々の実行レーンは、適宜、シートデータをＲＡＭ９０７から２次元シフトレジスタ構造９０６にロードしてもよい（たとえば、シートのデータの処理をする直前のロード命令として）。データのシートのレジスタ構造９０６へのロードが完了すると（シート生成部から直接であろうと、メモリ９０７からであろうと）、実行レーンアレイ９０５に含まれる実行レーンが当該データを処理し、最終的には、仕上がったデータをシートとしてシート生成部またはＲＡＭ９０７に直接「書き戻す」。後者の場合、入出力部９０４がデータをＲＡＭ９０７からフェッチして出力シートを形成し、その後、出力シートはシート生成部に転送される。
スカラープロセッサ９０２は、プログラムコントローラ９０９を含む。プログラムコントローラ９０９は、ステンシルプロセッサのプログラムコードの命令をスカラーメモリ９０３から読み出し、実行レーンアレイ９０５に含まれる実行レーンにこの命令を発行する。実施形態では、１つの同じ命令がアレイ９０５内のすべての実行レーンに一斉送信され、データ演算部９０１がＳＩＭＤのような動作を行う。実施形態では、スカラーメモリ９０３から読み出されて実行レーンアレイ９０５の実行レーンに発行される命令の命令フォーマットは、命令あたり２つ以上のオペコードを含むＶＬＩＷ（Ｖｅｒｙ－Ｌｏｎｇ－Ｉｎｓｔｒｕｃｔｉｏｎ－Ｗｏｒｄ）型フォーマットを含む。さらなる実施形態では、ＶＬＩＷフォーマットは、（後述するが、実施形態では、２つ以上の従来のＡＬＵ演算を指定し得る）各実行レーンのＡＬＵによって実行される数学関数を指示するＡＬＵオペコード、および（特定の実行レーンまたは特定の実行レーンセットのメモリ操作を指示する）メモリオペコードの両方を含む。
用語「実行レーン」とは、１つの命令を実行可能な１つ以上の実行部からなるセットを指す（たとえば、命令を実行できる論理回路）。しかしながら、実行レーンは、様々な実施形態では、ただの実行部ではなく、よりプロセッサのような機能を含み得る。たとえば、１つ以上の実行部以外に、実行レーンは、受け付けた命令をデコードする論理回路、または、よりＭＩＭＤのような設計の場合、命令をフェッチおよびデコードする論理回路を含んでもよい。ＭＩＭＤのような手法に関しては、本明細書では集中プログラム制御手法について詳細を説明したが、様々な別の実施形態では、より分散した手法が実施されてもよい（アレイ９０５の各実行レーン内にプログラムコードとプログラムコントローラとを含むなど）。
実行レーンアレイ９０５と、プログラムコントローラ９０９と、２次元シフトレジスタ構造９０６とを組み合わせることによって、広範囲のプログラム可能な機能のための広く受け容れられる／構成可能なハードウェアプラットフォームがもたらされる。たとえば、個々の実行レーンが広く多様な機能を実行でき、かつ、任意の出力アレイ位置に近接した入力画像データに容易にアクセスできるならば、アプリケーションソフトウェア開発者は、広範囲にわたる異なる機能能力および寸法（たとえば、ステンシルサイズ）を有するカーネルをプログラミングすることができる。
実行レーンアレイ９０５によって処理されている画像データ用のデータストアとして機能すること以外に、ＲＡＭ９０７は、１つ以上のルックアップテーブルを保持してもよい。様々な実施形態では、１つ以上のスカラールックアップテーブルもスカラーメモリ９０３内でインスタンス化されてもよい。
スカラー検索では、同じインデックスからの同じルックアップテーブルからの同じデータ値を実行レーンアレイ９０５内の実行レーンの各々に渡すことを伴う。様々な実施形態では、スカラープロセッサによって行われるスカラールックアップテーブルの検索動作を指示するスカラーオペコードも含むよう、上述したＶＬＩＷ命令フォーマットが拡大される。オペコードとともに使用するために指定されるインデックスは、即値オペランドであってもよく、または、他のデータ記憶位置からフェッチされてもよい。いずれにせよ、実施形態では、スカラーメモリ内のスカラールックアップテーブルの検索は、本質的に、同じクロック周期の間に実行レーンアレイ９０５内のすべての実行レーンに同じデータ値を一斉送信することを伴う。ルックアップテーブルの使用および操作のより詳細は、以下でさらに説明する。
図９ｂは、上述したＶＬＩＷ命令語の実施形態（複数可）を要約した図である。図９ｂに見られるように、ＶＬＩＷ命令語フォーマットは、次の３つの別個の命令に対するフィールドを含む。（１）スカラープロセッサによって実行されるスカラー命令９５１、（２）実行レーンアレイ内のそれぞれのＡＬＵによってＳＩＭＤ式で一斉送信および実行されるＡＬＵ命令９５２、（３）部分ＳＩＭＤ式で一斉送信および実行されるメモリ命令９５３（たとえば、実行レーンアレイの同じ行にある実行レーンが同じＲＡＭを共有する場合、異なる行の各々からの１つの実行レーンが実際に命令を実行する（メモリ命令９５３のフォーマットは、各行のどの実行レーンが命令を実行するのかを識別するオペランドを含んでもよい）。
１つ以上の即値オペランド用のフィールド９５４も含まれていてもよい。命令９５１、９５２、９５３のうちのいずれがどの即値オペランド情報を使用するかは、命令フォーマットで識別されてもよい。また、命令９５１、９５２、９５３の各々は、自身の入力オペランドおよび結果情報も含む（たとえば、ＡＬＵ演算のためのローカルレジスタ、ならびにメモリアクセス命令のためのローカルレジスタおよびメモリアドレス）。実施形態では、スカラー命令９５１は、実行レーンアレイ内の実行レーンがその他２つの命令９５２、９５３を実行する前に、スカラープロセッサによって実行される。つまり、ＶＬＩＷ語の実行は、スカラー命令９５１が実行される第１周期を含み、その次にその他の命令９５２、９５３が実行され得る第２周期を含む（なお、様々な実施形態では、命令９５２および９５３は、並列で実行されてもよい）。
実施形態では、スカラープロセッサによって実行されるスカラー命令は、データ演算部のメモリまたは２Ｄシフトレジスタからシートをロードする／データ演算部のメモリまたは２Ｄシフトレジスタにシートを格納するためにシート生成部に発行されるコマンドを含む。ここで、シート生成部の動作は、ラインバッファ部の動作、または、スカラープロセッサが発行したコマンドをシート生成部が完了させるのにかかる周期の数を実行時前に理解することを防ぐその他の変数によって異なり得る。このように、実施形態では、シート生成部に発行されるコマンドにスカラー命令９５１が対応するまたはスカラー命令９５１がコマンドをシート生成部に対して発行させるＶＬＩＷ語は、いずれも、その他の２つの命令フィールド９５２、９５３にＮＯＯＰ（ｎｏ－ｏｐｅｒａｔｉｏｎ）命令も含む。次に、シート生成部がデータ演算部へのロード／データ演算部からの格納を完了するまで、プログラムコードは、命令フィールド９５２、９５３のＮＯＯＰ命令のループに入る。ここで、シート生成部にコマンドを発行すると、スカラープロセッサは、コマンドが完了するとシート生成部がリセットするインターロックレジスタのビットを設定してもよい。ＮＯＯＰループの間、スカラープロセッサは、インターロックビットのビットを監視する。シート生成部がそのコマンドを完了したことをスカラープロセッサが検出すると、通常の実行が再び開始される。
図１０は、データ演算コンポーネント１００１の実施形態を示す図である。図１０に見られるように、データ演算コンポーネント１００１は、２次元シフトレジスタアレイ構造１００６の「上方」に論理的に位置する実行レーンのアレイ１００５を含む。上述したように、様々な実施形態では、シート生成部が提供する画像データのシートが２次元シフトレジスタ１００６にロードされる。次に、実行レーンがレジスタ構造１００６からのシートデータを処理する。
実行レーンアレイ１００５およびシフトレジスタ構造１００６は、互いに対して定位置に固定されている。しかしながら、シフトレジスタアレイ１００６内のデータは、効果的かつ調整された方法でシフトし、実行レーンアレイに含まれる各実行レーンにデータ内の異なるステンシルを処理させる。このように、各実行レーンは、生成された出力シートに含まれる異なる画素の出力画像値を判断する。図１０のアーキテクチャから、実行レーンアレイ１００５が上下に隣接する実行レーンおよび左右に隣接する実行レーンを含むので、重なり合うステンシルは、縦方向だけでなく、横方向にも配置されていることは明らかである。
データ演算部１００１のいくつかの注目すべきアーキテクチャ上の特徴として、シフトレジスタ構造１００６の寸法は、実行レーンアレイ１００５よりも広い。つまり、実行レーンアレイ１００５の外側にレジスタ１００９の「ハロー（ｈａｌｏ）」が存在する。ハロー１００９は、実行レーンアレイの２つの側面に存在するように図示されているが、実装によっては、ハローは、実行レーンアレイ１００５のより少ない（１つ）またはより多い（３つまたは４つの）側面に存在してもよい。ハロー１００５は、実行レーン１００５の「下」をデータがシフトすると実行レーンアレイ１００５の境界の外側にこぼれ出るデータの「スピルオーバ」空間を提供する役割を果たす。簡単な例として、ステンシルの左端の画素が処理されると、実行レーンアレイ１００５の右端の中心にある５×５ステンシルは、さらに右側に４つのハローレジスタ位置を必要とすることになる。図をわかりやすくするために、図１０は、標準的な実施形態において、いずれの側面（右、下）のレジスタも横接続および縦接続の両方を有し得るとき、ハローの右側のレジスタを横方向にのみシフト接続していると示し、ハローの下側のレジスタを縦方向にのみシフト接続していると示している。様々な実施形態では、ハロー領域は、画像処理命令を実行するための対応する実行レーン論理を含まない（たとえば、ＡＬＵは存在しない）。しかしながら、個々のハローレジスタ位置がメモリから個々にデータをロードし、データをメモリに格納できるよう、個々のメモリアクセスユニット（Ｍ）がハロー領域位置の各々に存在する。
アレイの各行および／または各列、またはそれらの一部に連結されたさらなるスピルオーバ空間がＲＡＭ１００７によって提供される（たとえば、行方向に４つの実行レーン、列方向に２つの実行レーンにまたがる実行レーンアレイの「領域」に１つのＲＡＭが割り当てられてもよい）。わかりやすくするために、残りの明細書では、主に、行ベースおよび／または列ベースの割り当て方式について言及する）。ここで、実行レーンのカーネル動作は、２次元シフトレジスタアレイ１００６の外側の画素値を処理する必要がある場合、（いくつかの画像処理ルーチンが必要とし得る）、画像データの面は、たとえば、ハロー領域１００９からＲＡＭ１００７にさらにこぼれ出る（スピルオーバする）ことができる。たとえば、実行レーンアレイの右端の実行レーンの右側に４つのストレージ要素のみから構成されるハロー領域をハードウェアが含む、６×６ステンシルを考える。この場合、ステンシルを完全に処理するためには、データは、さらに右にシフトされてハロー１００９の右端からはみ出る必要がある。ハロー領域１００９の外にシフトされるデータは、その後、ＲＡＭ１００７にこぼれ出る。ＲＡＭ１００７および図９のステンシルプロセッサのその他の適用例をさらに以下に説明する。
図１１ａ～図１１ｋは、上述したように実行レーンアレイの「下」の２次元シフトレジスタアレイ内で画像データがシフトされる方法の例を説明する図である。図１１ａに見られるように、２次元シフトアレイのデータコンテンツが第１アレイ１１０７に図示され、実行レーンアレイがフレーム１１０５によって図示されている。また、実行レーンアレイ内の２つの隣接する実行レーン１１１０を簡略化して図示している。この単純化した図示１１１０では、各実行レーンは、シフトレジスタからデータを受け付ける、（たとえば、周期間の累算器として動作するための）ＡＬＵ出力からデータを受け付ける、または、出力データを出力先に書き込むことができるレジスタＲ１を含む。
また、各実行レーンは、その「下」に、ローカルレジスタＲ２において、利用可能なコンテンツを２次元シフトアレイに有する。よって、Ｒ１は、実行レーンの物理レジスタであるのに対して、Ｒ２は、２次元シフトレジスタアレイの物理レジスタである。実行レーンは、Ｒ１および／またはＲ２が提供するオペランドを処理できるＡＬＵを含む。より詳細はさらに後述するが、実施形態では、シフトレジスタは、実際には、アレイ位置当たり複数のストレージ／レジスタ要素（の「深度」）を有して実装されるがシフトアクティビティは、ストレージ要素の１つの面に限られる（たとえば、ストレージ要素の１つの面のみが周期ごとにシフトできる）。図１１ａ～１１ｋは、これらの深度がより深いレジスタ位置のうちの１つを、それぞれの実行レーンからの結果Ｘを格納するのに用いられているものとして図示している。図をわかりやすくするために、深度がより深い結果レジスタは、対応するレジスタＲ２の下ではなく、横に並べて図示されている。
図１１ａ～１１ｋは、実行レーンアレイ内に図示された実行レーン位置１１１１のペアと中央位置が揃えられた２つのステンシルの算出に焦点を当てている。図をわかりやすくするために、実行レーン１１１０のペアは、実際には下記の例によると縦方向に隣接している場合に、横方向に隣接していると図示されている。
最初に、図１１ａに見られるように、実行レーンは、その中央のステンシル位置の中心に位置決めされる。図１１ｂは、両方の実行レーンによって実行されるオブジェクトコードを示す図である。図１１ｂに見られるように、両方の実行レーンのプログラムコードによって、シフトレジスタアレイ内のデータは、位置を下に１つシフトし、位置を右に１つシフトさせられる。これによって、両方の実行レーンがそれぞれのステンシルの左上隅に揃えられる。次に、プログラムコードは、（Ｒ２において）それぞれの位置にあるデータをＲ１にロードさせる。
図１１ｃに見られるように、次に、プログラムコードは、実行レーンのペアに、シフトレジスタアレイ内のデータを１単位だけ左にシフトさせ、これによって、各実行レーンのそれぞれの位置の右にある値が、各実行レーンの位置にシフトされる。次に、（Ｒ２における）実行レーンの位置までシフトされた新しい値がＲ１の値（前の値）に加算される。その結果がＲ１に書き込まれる。図１１ｄに見られるように、図１１ｃで説明したのと同じ処理が繰り返され、これによって、結果Ｒ１は、ここで、上部実行レーンにおいて値Ａ＋Ｂ＋Ｃを含み、下部実行レーンにおいてＦ＋Ｇ＋Ｈを含む。この時点で、両方の実行レーンは、それぞれのステンシルの上側の行を処理済みである。なお、データは、実行レーンアレイの左側のハロー領域（左側に存在する場合）にこぼれ出るが、ハロー領域が実行レーンアレイの左側に存在しない場合はＲＡＭにこぼれ出る。
図１１ｅに見られるように、次に、プログラムコードは、シフトレジスタアレイ内のデータを１単位だけ上にシフトさせ、これによって、両方の実行レーンがそれぞれのステンシルの中央行の右端に揃えられる。両方の実行レーンのレジスタＲ１は、現在、ステンシルの最上行および中央行の右端の値の総和を含む。図１１ｆおよび図１１ｇは、両方の実行レーンのステンシルの中央行を左方向に移動する続きの進行を説明する図である。図１１ｇの処理の終わりに両方の実行レーンがそれぞれのステンシル最上行および中央行の値の総和を含むよう、累積加算が続く。
図１１ｈは、各実行レーンを対応するステンシルの最下行に揃えるための別のシフトを示す図である。図１１ｉおよび図１１ｊは、両方の実行レーンのステンシルに対する処理を完了するための、続きのシフト処理を示す図である。図１１ｋは、データ配列において各実行レーンをその正しい位置に揃えて結果をそこに書き込むためのさらなるシフト処理を示す図である。
なお、図１１ａ～図１１ｋの例では、シフト演算用のオブジェクトコードは、（Ｘ，Ｙ）座標で表されるシフトの方向および大きさを識別する命令フォーマットを含んでもよい。たとえば、位置を１つ上にシフトさせるためのオブジェクトコードは、ＳＨＩＦＴ０、＋１というオブジェクトコードで表されてもよい。別の例として、位置を右に１つシフトすることは、ＳＨＩＦＴ＋１、０というオブジェクトコードで表現されてもよい。また、様々な実施形態では、より大きなシフトも、オブジェクトコード（たとえば、ＳＨＩＦＴ０、＋２）で指定されてもよい。ここで、２Ｄシフトレジスタハードウェアが周期あたり位置１つ分のシフトしかサポートしない場合、命令は、マシンによって、複数周期の実行を必要とすると解釈されてもよく、または、周期あたり位置２つ分以上のシフトをサポートするよう２Ｄシフトレジスタハードウェアが設計されてもよい。後者の実施形態をより詳細にさらに後述する。
図１２は、実行レーンおよび対応するシフトレジスタ構造（ハロー領域のレジスタは、対応する実行レーンを含まないが、様々な実施形態のメモリを含む）の単位セルをより詳細に示す別の図である。実行レーン、および実行レーンアレイの各位置に対応付けられたレジスタ空間は、実施形態では、図１２に見られる回路を実行レーンアレイの各ノードにおいてインスタンス化することによって実現される。図１２に見られるように、単位セルは、４つのレジスタＲ２～Ｒ５から構成されるレジスタファイル１２０２に連結された実行レーン１２０１を含む。いずれの周期の間も、実行レーン１２０１は、レジスタＲ１～Ｒ５のうちのいずれかから読み出されたり、書き込まれたりしてもよい。２つの入力オペランドを必要とする命令については、実行レーンは、両方のオペランドをＲ１～Ｒ５のうちのいずれかから取り出してもよい。
実施形態では、２次元シフトレジスタ構造は、１つの周期の間、レジスタＲ２～Ｒ４のうちのいずれか１つ（のみ）のコンテンツを出力マルチプレクサ１２０３を通してその隣接するレジスタのレジスタファイルのうちの１つにシフト「アウト」させ、隣接するレジスタ間のシフトが同じ方向になるよう、レジスタＲ２～Ｒ４のうちのいずれか１つ（のみ）のコンテンツを対応するレジスタファイルから入力マルチプレクサ１２０４を通してシフト「イン」されるコンテンツと置き換えることによって実現される（たとえば、すべての実行レーンが左にシフトする、すべての実行レーンが右にシフトする、など）。同じレジスタのコンテンツがシフトアウトされて、同じ周期上でシフトされるコンテンツと置き換えられることは一般的であり得るが、マルチプレクサ配列１２０３、１２０４は、同じ周期の間、同じレジスタファイル内で異なるシフト元および異なるシフト対象のレジスタを可能にする。
図１２に示すように、シフトシーケンスの間、実行レーンは、そのレジスタファイル１２０２からその左隣、右隣、上隣、および下隣の各々にコンテンツをシフトアウトすることになることが分かる。同じシフトシーケンスと連動して、実行レーンは、そのレジスタファイルに左隣、右隣、上隣、および下隣のうちの特定のレジスタファイルからコンテンツをシフトする。ここでも、シフトアウトする対象およびシフトインする元は、すべての実行レーンについて同じシフト方向に一致しなければならない（たとえば、右隣にシフトアウトする場合、シフトインは左隣からでなければならない）。
一実施形態において、周期あたり実行レーン１つにつき１つのレジスタのコンテンツのみをシフトさせることが可能であるが、その他の実施形態は、２つ以上のレジスタのコンテンツをシフトイン／アウトさせることが可能であってもよい。たとえば、図１２に見られるマルチプレクサ回路１２０３、１２０４の第２インスタンスが図１２の設計に組み込まれている場合、同じ周期で２つのレジスタのコンテンツをシフトアウト／インしてもよい。当然、周期ごとに１つのレジスタのコンテンツのみをシフトさせることができる実施形態では、数値演算間のシフトのためにより多くのクロック周期を消費することによって複数のレジスタからのシフトが数値演算間で生じてもよい（たとえば、数値演算間の２つのシフト演算を消費することによって２つのレジスタのコンテンツが当該数値演算間でシフトされてもよい）。
なお、シフトシーケンス時に実行レーンのレジスタファイルのすべてのコンテンツよりも少ない数のコンテンツがシフトアウトされた場合、各実行レーンのシフトアウトされなかったレジスタのコンテンツは、所定の位置に留まっている（シフトしない）ことが分かる。このように、シフトインされたコンテンツに置き換えられないシフトされなかったコンテンツは、いずれも、シフト周期にわたって、実行レーンにローカルに留まる。各実行レーンに見られるメモリユニット（「Ｍ」）を使用して、実行レーンアレイ内の実行レーンの行および／または列に対応付けられたランダムアクセスメモリ空間からデータをロード／またはそれに格納する。ここで、Ｍユニットは、標準Ｍユニットとして機能し、標準Ｍユニットは、実行レーン自体のレジスタ空間からロード／またはそれに格納できないデータをロード／格納するために利用される場合が多い。様々な実施形態では、Ｍユニットの主な動作は、ローカルレジスタからのデータをメモリに書き込み、メモリからデータを読み出してローカルレジスタに書き込むことである。
ハードウェア実行レーン１２０１のＡＬＵ装置がサポートするＩＳＡオペコードに関して、様々な実施形態では、ハードウェアＡＬＵがサポートする数値演算オペコードは、（たとえば、ＡＤＤ、ＳＵＢ、ＭＯＶ、ＭＵＬ、ＭＡＤ、ＡＢＳ、ＤＩＶ、ＳＨＬ、ＳＨＲ、ＭＩＮ／ＭＡＸ、ＳＥＬ、ＡＮＤ、ＯＲ、ＸＯＲ、ＮＯＴ）を含む。先ほど記載したように、実行レーン１２０１によって、関連するＲＡＭからデータをフェッチ／当該ＲＡＭにデータを格納するためのメモリアクセス命令が実行され得る。これに加えて、ハードウェア実行レーン１２０１は、２次元シフトレジスタ構造内でデータをシフトさせるためのシフト演算命令（右、左、上、下）をサポートする。上述したように、プログラム制御命令は、主に、ステンシルプロセッサのスカラープロセッサによって実行される。
４．０ 実装の実施形態
上述した様々な画像処理プロセッサのアーキテクチャの特徴は、必ずしも従来の意味での画像処理に限られないため、画像処理プロセッサを新たに特徴付け得る（または、させ得ない）その他のアプリケーションに適用してもよいことを指摘することが適切である。たとえば、上述した様々な画像処理プロセッサのアーキテクチャの特徴のうちのいずれかが、実際のカメラ画像の処理とは対照的に、アニメーションの作成ならびに／または生成および／もしくは描画に使用される場合、画像処理プロセッサは、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）として特徴付けられてもよい。これに加えて、上述した画像処理プロセッサアーキテクチャの特徴を、映像処理、ビジョンプロセッシング、画像認識および／または機械学習など、その他の技術用途に適用してもよい。このように適用すると、画像処理プロセッサは、（たとえば、コプロセッサとして）、（たとえば、コンピューティングシステムのＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔまたはその一部である）より汎用的なプロセッサと統合されてもよく、または、コンピューティングシステム内のスタンドアロン型のプロセッサであってもよい。
上述したハードウェア設計の実施形態は、半導体チップ内に実施されてもよく、および／または、最終的に半導体製造プロセスに向けての回路設計の記述として実施されてもよい。後者の場合、このような回路記述は、（たとえば、ＶＨＤＬまたはＶｅｒｉｌｏｇ）レジスタ転送レベル（ＲＴＬ：Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）回路記述、ゲートレベル回路記述、トランジスタレベル回路記述もしくはマスク記述、またはそれらの様々な組合せなどの形態をとり得る。回路記述は、通常、コンピュータ読み取り可能な記憶媒体（ＣＤ－ＲＯＭまたはその他の種類のストレージ技術など）上に実施される。
先のセクションから、後述する画像処理プロセッサをコンピュータシステム上のハードウェアで（たとえば、ハンドヘルド端末のカメラからのデータを処理するハンドヘルド端末のＳＯＣ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ）の一部として）実施してもよいことを認識することが適切である。なお、画像処理プロセッサがハードウェア回路として実施された場合、画像処理プロセッサによって処理される画像データをカメラから直接受け付けてもよいことが分かる。ここで、画像処理プロセッサは、単品カメラの一部、またはカメラを内蔵したコンピューティングシステムの一部であってもよい。後者の場合、カメラからまたはコンピューティングシステムのシステムメモリから画像データを直接受け付けてもよい（たとえば、カメラは、その画像データを、画像処理プロセッサではなくシステムメモリに送る）。また、先のセクションに記載の特徴の多くは、（アニメーションを描画する）ＧＰＵに適用可能である。
図１３は、コンピューティングシステムの例示的な図である。上述したコンピューティングシステムの構成要素のうちの多くは、内蔵カメラおよび関連する画像処理プロセッサ（たとえば、スマートフォンまたはタブレットコンピュータなどのハンドヘルド端末）を有するコンピューティングシステムに適用可能である。当業者は、これら２つの違いを容易に明確にするであろう。これに加えて、図１３のコンピューティングシステムは、ワークステーションまたはスーパーコンピュータなどの高性能なコンピューティングシステムの多くの特徴も含んでいる。
図１３に見られるように、基本的なコンピューティングシステムは、ＣＰＵ１３０１（たとえば、マルチコアプロセッサまたはアプリケーションプロセッサ上に配置された複数の汎用処理コア１３１５＿１～１３１５＿Ｎおよびメインメモリコントローラ１３１７を含んでもよい）と、システムメモリ１３０２と、ディスプレイ１３０３（たとえば、タッチスクリーン、フラットパネル）と、ローカル有線ポイントツーポイントリンク（たとえば、ＵＳＢ）インタフェース１３０４と、様々なネットワーク入出力機能部１３０５（Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースおよび／またはセルラーモデムサブシステムなど）と、無線ローカルエリアネットワーク（たとえば、ＷｉＦｉ）インタフェース１３０６と、無線ポイントツーポイントリンク（たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標））インタフェース１３０７およびＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）インタフェース１３０８と、様々なセンサ１３０９＿１～１３０９＿Ｎと、１つ以上のカメラ１３１０と、バッテリー１３１１と、電力管理制御部１３１２と、スピーカ／マイクロフォン１３１３と、オーディオコーダ／デコーダ１３１４とを含んでもよい。
アプリケーションプロセッサまたはマルチコアプロセッサ１３５０は、そのＣＰＵ１２０１内に１つ以上の汎用処理コア１３１５を含み、１つ以上のＧＰＵ１３１６、メモリ管理機能部１３１７（たとえば、メモリコントローラ）、入出力制御機能部１３１８、および画像処理部１３１９を含んでもよい。汎用処理コア１３１５は、通常、コンピューティングシステムのオペレーティングシステムおよびアプリケーションソフトウェアを実行する。ＧＰＵ１３１６は、通常、グラフィックスを多く使う機能を実行して、たとえば、ディスプレイ１３０３上に提示されるグラフィックス情報を生成する。メモリ制御機能部１３１７は、システムメモリ１３０２とインタフェース接続され、システムメモリ１３０２にデータを書き込む／システムメモリ１３０２からデータを読み出す。電力管理制御部１３１２は、一般に、システム１３００の消費電力を制御する。
画像処理部１３１９は、先のセクションで詳細に上述した画像処理部の実施形態のいずれかに従って実現されてもよい。これに加えて、またはこれと組み合わせて、ＩＰＵ１３１９がＧＰＵ１３１６およびＣＰＵ１３０１のいずれかまたは両方に、そのコプロセッサとして連結されてもよい。これに加えて、様々な実施形態では、ＧＰＵ１３１６は、詳細に上述した画像処理プロセッサの特徴のいずれかを有して実現されてもよい。画像処理部１３１９は、詳細に上述したようなアプリケーションソフトウェアを有して構成されてもよい。これに加えて、図１３のコンピューティングシステムなどのコンピューティングシステムは、上述した画像処理アプリケーションソフトウェアプログラムをシミュレートするプログラムコードを実行してそれぞれのラインバッファユニットのそれぞれのメモリ割り当てが決定できるようにしてもよい。
タッチスクリーンディスプレイ１３０３、通信インタフェース１３０４～１３０７、ＧＰＳインタフェース１３０８、センサ１３０９、カメラ１３１０、およびスピーカ／マイクロフォンコーデック１３１３、１３１４の各々は、すべて、内蔵型周辺機器（たとえば、１つ以上のカメラ１３１０）も適宜備えたコンピュータシステム全体に対する様々な形態のＩ／Ｏ（入力部および／または出力部）として見ることができる。実装形態によっては、これらのＩ／Ｏコンポーネントのうちの様々なＩ／Ｏコンポーネントがアプリケーションプロセッサ／マルチコアプロセッサ１３５０上に集積されてもよく、ダイからずれて配置、またはアプリケーションプロセッサ／マルチコアプロセッサ１３５０のパッケージの外に配置されてもよい。
実施形態では、１つ以上のカメラ１３１０は、カメラと視野に存在するオブジェクトとの間の奥行きを測定可能な深度カメラを含む。アプリケーションプロセッサまたはその他のプロセッサの汎用ＣＰＵコア（または、プログラムコードを実行するための命令実行パイプラインを有するその他の機能ブロック）上で実行されるアプリケーションソフトウェア、オペレーティングシステムソフトウェア、デバイスドライバソフトウェア、および／またはファームウェアが、上述した機能のいずれかを実行してもよい。
本発明の実施形態は、上述した様々な処理を含んでもよい。処理は、機械によって実行可能な命令に含まれてもよい。命令を用いて、汎用プロセッサまたは特定用途向けプロセッサに特定の処理を実行させることができる。これに代えて、これらの処理は、処理を実行するための結線ロジックおよび／またはプログラム可能なロジックを含んだ専用のハードウェア部品によって実行されてもよく、プログラムを組み込まれたコンピュータ構成要素とカスタムハードウェア部品との任意の組み合わせによって実行されてもよい。
また、本発明の要素は、機械によって実行可能な命令を格納するための機械読み取り可能な媒体として提供されてもよい。機械読み取り可能な媒体は、フロッピー（登録商標）ディスク、光ディスク、ＣＤ－ＲＯＭ、および光磁気ディスク、ＦＬＡＳＨメモリ、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、電子命令を格納するのに適した伝播媒体またはその他の種類の媒体／機械読み取り可能な媒体などがあり得るが、これらに限定されない。たとえば、本発明は、コンピュータプログラムとしてダウンロードされてもよく、コンピュータプログラムは、搬送波またはその他の伝播媒体に含んだデータ信号として、通信リンク（たとえば、モデムまたはネットワーク接続）を介してリモートコンピュータ（たとえば、サーバ）から要求元コンピュータ（たとえば、クライアント）に転送され得る。
上記の明細書において、具体的、例示的な実施形態を用いて本発明を説明したが、特許請求の範囲に記載の本発明のより広義の趣旨および範囲から逸脱することなく、様々な変形、変更を行ってもよいことは明らかであろう。したがって、明細書および図面は、厳密ではなく、例示的であるとみなされるべきである。
以下に、いくつかの例を記載する。
例１：コンピューティングシステムによって処理されると、上記コンピューティングシステムに方法を実行させるプログラムコードを含む機械可読記憶媒体であって、上記方法は、
ａ）画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを含み、上記シミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファメモリでカーネル間通信をインターセプトすることを含み、上記シミュレートすることは、さらに、シミュレーションランタイムにわたって、それぞれのラインバッファメモリに格納されるそれぞれの画像データの量を追跡することを含み、上記方法はさらに、
ｂ）追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファメモリのそれぞれのハードウェアメモリ割り当てを決定することと、
ｃ）上記画像処理アプリケーションソフトウェアプログラムを実行するよう、画像プロセッサのために構成情報を生成することとを含み、上記構成情報は、上記画像プロセッサのハードウェアラインバッファメモリのハードウェアメモリ割り当てを記述する、機械可読記憶媒体。
例２：上記追跡することは、シミュレートされたラインバッファメモリ書き込みポインタとシミュレートされたラインバッファメモリ読み出しポインタとの間の差を追跡することをさらに含む、例１の機械可読記憶媒体。
例３：上記決定することは、上記シミュレートされたラインバッファメモリ書き込みポインタと上記シミュレートされたラインバッファメモリ読み出しポインタとの間の最大観測差に基づく、例１または例２の機械可読記憶媒体。
例４：上記シミュレートすることは、上記画像データを消費するカーネルの１つ以上のモデルが次の画像データのユニットを受け取るべく待機状態となるまで、上記次の画像データのユニットがシミュレートされたラインバッファメモリに書き込まれることを防ぐ書き込みポリシーを課すことをさらに含む、先行する例のいずれか１つの機械可読記憶媒体。
例５：上記書き込みポリシーは、上記次の画像データのユニットを生成する生成カーネルのモデルで実施される、先行する例のいずれか１つの機械可読記憶媒体。
例６：上記方法は、さらに、上記アプリケーションソフトウェアプログラムのシミュレートされた実行がデッドロックする場合に、上記書き込みポリシーに違反することを許可することを含む、先行する例のいずれか１つの機械可読記憶媒体。
例７：上記カーネルは、ハードウェア画像プロセッサの異なる処理コア上で動作し、上記ハードウェア画像プロセッサは、上記処理コア間で渡されるライングループを格納および転送するハードウェアラインバッファユニットを含む、先行する例のいずれか１つの機械可読記憶媒体。
例８：上記異なる処理コアは、２次元実行レーンおよび２次元シフトレジスタアレイを含む、先行する例のいずれか１つの機械可読記憶媒体。
例９：上記生成カーネルのモデルおよび上記消費カーネルのモデルは、画像データをシミュレートされたラインバッファメモリに送る命令を含み、シミュレートされたラインバッファメモリから画像データを読み出す命令を含むが、画像データを実質的に処理する命令は含まない、先行する例のいずれか１つの機械可読記憶媒体。
例１０：画像プロセッサアーキテクチャが、２次元シフトレジスタアレイに結合された実行のアレイを含む、先行する例のいずれか１つの機械可読記憶媒体。
例１１：上記画像プロセッサのアーキテクチャは、ラインバッファ、シート生成部、および／またはステンシルプロセッサのうちの少なくとも１つを含む、先行する例のいずれか１つの機械可読記憶媒体。
例１２：上記ステンシルプロセッサは、重複するステンシルを処理するように構成される、例１１の機械可読記憶媒体。
例１３：データ計算ユニットが、実行レーンアレイよりも広い次元を有するシフトレジスタ構造を備え、特に上記実行レーンアレイの外側にレジスタがある、先行する例のいずれか１つの実行ユニット回路。
例１４：コンピューティングシステムであって、
中央処理ユニットと、
システムメモリと、
上記システムメモリと上記中央処理ユニットとの間のシステムメモリコントローラと、
上記コンピューティングシステムによって処理されると上記コンピューティングシステムに方法を実行させるプログラムコードを含む機械可読記憶媒体とを備え、上記方法は、
ａ）画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを含み、上記シミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファメモリでカーネル間通信をインターセプトすることを含み、上記シミュレートすることは、さらに、シミュレーションランタイムにわたって、それぞれのラインバッファメモリに格納されるそれぞれの画像データの量を追跡することを含み、上記方法はさらに、
ｂ）追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファメモリのそれぞれのハードウェアメモリ割り当てを決定することと、
ｃ）上記画像処理アプリケーションソフトウェアプログラムを実行するよう、画像プロセッサのために構成情報を生成することとを含み、上記構成情報は、上記画像プロセッサのハードウェアラインバッファメモリのハードウェアメモリ割り当てを記述する、コンピューティングシステム。
例１５：上記追跡することは、シミュレートされたラインバッファメモリ書き込みポインタとシミュレートされたラインバッファメモリ読み出しポインタとの間の差を追跡することをさらに含む、例１４のコンピューティングシステム。
例１６：上記決定することは、上記シミュレートされたラインバッファメモリ書き込みポインタと上記シミュレートされたラインバッファメモリ読み出しポインタとの間の最大観測差に基づく、例１４または例１５のコンピューティングシステム。
例１７：上記シミュレートすることは、上記画像データを消費するカーネルの１つ以上のモデルが次の画像データのユニットを受け取るべく待機状態となるまで、上記次の画像データのユニットがシミュレートされたラインバッファメモリに書き込まれることを防ぐ書き込みポリシーを課すことをさらに含む、例１４～例１６のいずれか１つのコンピューティングシステム。
例１８：上記書き込みポリシーは、上記次の画像データのユニットを生成する生成カーネルのモデルで実施される、例１４～例１７のいずれか１つのコンピューティングシステム。
例１９：上記方法は、さらに、上記アプリケーションソフトウェアプログラムのシミュレートされた実行がデッドロックする場合に、上記書き込みポリシーに違反することを許可することを含む、例１４～例１８のいずれか１つのコンピューティングシステム。
例２０：画像プロセッサアーキテクチャが、２次元シフトレジスタアレイに結合された実行のアレイを含む、例１４～例１９のいずれか１つのコンピューティングシステム。
例２１：上記画像プロセッサのアーキテクチャは、ラインバッファ、シート生成部、および／またはステンシルプロセッサのうちの少なくとも１つを含む、例１４～例２０のいずれか１つのコンピューティングシステム。
例２２：上記ステンシルプロセッサは、重複するステンシルを処理するように構成される、例２１のコンピューティングシステム。
例２３：データ計算ユニットが、実行レーンアレイよりも広い次元を有するシフトレジスタ構造を備え、特に上記実行レーンアレイの外側にレジスタがある、例１４～例２２のいずれか１つのコンピューティングシステム。
例２４：方法であって、
ａ）画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを備え、上記シミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファメモリでカーネル間通信をインターセプトすることを含み、上記シミュレートすることは、さらに、シミュレーションランタイムにわたって、それぞれのラインバッファメモリに格納されるそれぞれの画像データの量を追跡することを含み、上記方法はさらに、
ｂ）追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファメモリのそれぞれのハードウェアメモリ割り当てを決定することと、
ｃ）上記画像処理アプリケーションソフトウェアプログラムを実行するよう、画像プロセッサのために構成情報を生成することとを備え、上記構成情報は、上記画像プロセッサのハードウェアラインバッファメモリのハードウェアメモリ割り当てを記述する、方法。
例２５：上記追跡することは、シミュレートされたラインバッファメモリ書き込みポインタとシミュレートされたラインバッファメモリ読み出しポインタとの間の差を追跡することをさらに含む、例２４の方法。
例２６：上記決定することは、上記シミュレートされたラインバッファメモリ書き込みポインタと上記シミュレートされたラインバッファメモリ読み出しポインタとの間の最大観測差に基づく、例２４または例２５の方法。
例２７：上記シミュレートすることは、上記画像データを消費するカーネルの１つ以上のモデルが次の画像データのユニットを受け取るべく待機状態となるまで、上記次の画像データのユニットがシミュレートされたラインバッファメモリに書き込まれることを防ぐ書き込みポリシーを課すことをさらに含む、例２４～例２６のいずれか１つの方法。
例２８：上記書き込みポリシーは、上記次の画像データのユニットを生成する生成カーネルのモデルで実施される、例２４～例２７のいずれか１つの方法。
例２９：画像プロセッサアーキテクチャが、２次元シフトレジスタアレイに結合された実行のアレイを含む、例２４～例２８のいずれか１つの方法。
例３０：上記画像プロセッサのアーキテクチャは、ラインバッファ、シート生成部、および／またはステンシルプロセッサのうちの少なくとも１つを含む、例２４～例２９のいずれか１つの方法。
例３１：上記ステンシルプロセッサは、重複するステンシルを処理するように構成される、例２４～例３０のいずれか１つの方法。
例３２：データ計算ユニットが、実行レーンアレイよりも広い次元を有するシフトレジスタ構造を備え、特に上記実行レーンアレイの外側にレジスタがある、例２４～例３１のいずれか１つの方法。

Claims (29)

  1. 方法であって、
    ａ）コンピューティングシステムが、複数のカーネルを含む画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを含み、各カーネルは、ラインバッファから他のカーネルによって生成された格納データを読み出すロード命令、または、ラインバッファに他のカーネルによって消費される格納データを書き込むストア命令、または両方を備え、前記画像処理アプリケーションソフトウェアプログラムの前記実行をシミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファでカーネルモデル間通信をインターセプトすることによって、複数のラインバッファの動作を複数のシミュレートされたラインバッファを用いてシミュレートすることを含み、前記シミュレートすることは、さらに、シミュレーションランタイムにわたって、以下の動作を実行することによってそれぞれの前記シミュレートされたラインバッファに格納されるそれぞれの画像データの量を追跡することを含み、前記以下の動作は、
    前記ロード命令によって参照されるラインバッファをシミュレートするそれぞれのシミュレートされたラインバッファに対するそれぞれの読み出しポインタを更新することを含めて、複数のカーネルに生じる各ロード命令をシミュレートすることと、
    前記ストア命令によって参照されるラインバッファをシミュレートするそれぞれのシミュレートされたラインバッファに対するそれぞれの書き込みポインタを更新することを含めて、複数のカーネルに生じる各ストア命令をシミュレートすることとを含み、各読み出しポインタは、対応するシミュレートされたラインバッファからこれまでにどれだけのデータが読み出されたかを特定し、各書き込みポインタは、対応するシミュレートされたラインバッファにこれまでにどれだけのデータが書き込まれたかを特定し、前記方法はさらに、
    ｂ）前記コンピューティングシステムが、前記シミュレートされたラインバッファの各々に対して、前記シミュレーションの間に遭遇する前記シミュレートされたラインバッファのそれぞれの読み出しポインタとそれぞれの書き込みポインタとの間のそれぞれの最大差を計算することによって、追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファのそれぞれのハードウェアメモリ割り当てを決定することと、
    ｃ）前記コンピューティングシステムが、前記シミュレートされたラインバッファの各々に対して計算された前記それぞれの最大差に基づいて、画像プロセッサの前記ラインバッファの各々に割り当てるそれぞれメモリサイズを生成することによって、前記画像処理アプリケーションソフトウェアプログラムを実行するための前記画像プロセッサの構成情報を生成することとを含み、前記構成情報は、前記画像プロセッサのハードウェアラインバッファのハードウェアメモリ割り当てを記述する、方法。
  2. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、前記画像データを消費するカーネルの１つ以上のモデルが次の画像データのユニットを受け取るべく待機状態となるまで、前記次の画像データのユニットがシミュレートされたラインバッファに書き込まれることを防ぐ書き込みポリシーを課すことをさらに含む、請求項１に記載の方法。
  3. 前記書き込みポリシーは、前記次の画像データのユニットを生成する生成カーネルのモデルで実施される、請求項２に記載の方法。
  4. 前記方法は、さらに、前記画像処理アプリケーションソフトウェアプログラムのシミュレートされた実行がデッドロックする場合に、前記書き込みポリシーに違反することを許可することを含む、請求項２または請求項３に記載の方法。
  5. 前記カーネルは、ハードウェア画像プロセッサの異なる処理コア上で動作し、前記ハードウェア画像プロセッサは、前記処理コア間で渡されるライングループを格納および転送するハードウェアラインバッファユニットを含む、請求項１～請求項４のいずれか１項に記載の方法。
  6. 前記異なる処理コアは、２次元実行レーンおよび２次元シフトレジスタアレイを含む、請求項５に記載の方法。
  7. 前記生成カーネルのモデルおよび前記消費カーネルのモデルは、画像データをシミュレートされたラインバッファに送る命令を含み、シミュレートされたラインバッファから画像データを読み出す命令を含むが、画像データを実質的に処理する命令は含まない、請求項１～請求項６のいずれか１項に記載の方法。
  8. 前記画像プロセッサのアーキテクチャが、２次元シフトレジスタアレイに結合された実行のアレイを含む、請求項１～請求項７のいずれか１項に記載の方法。
  9. 前記画像プロセッサのアーキテクチャは、ラインバッファ、シート生成部、および／またはステンシルプロセッサのうちの少なくとも１つを含む、請求項１～請求項８のいずれか１項に記載の方法。
  10. 前記ステンシルプロセッサは、重複するステンシルを処理するように構成される、請求項９に記載の方法。
  11. データ計算ユニットが、実行レーンアレイよりも広い次元を有するシフトレジスタ構造を備え、特に前記実行レーンアレイの外側にレジスタがある、請求項１～請求項１０のいずれか１項に記載の方法。
  12. コンピューティングシステムであって、
    中央処理ユニットと、
    システムメモリと、
    前記システムメモリと前記中央処理ユニットとの間のシステムメモリコントローラと、
    前記コンピューティングシステムによって処理されると前記コンピューティングシステムに方法を実行させるプログラムコードを含む機械可読記憶媒体とを備え、前記方法は、
    ａ）複数のカーネルを含む画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることを含み、各カーネルは、ラインバッファから他のカーネルによって生成された格納データを読み出すロード命令、または、ラインバッファに他のカーネルによって消費される格納データを書き込むストア命令、または両方を備え、前記画像処理アプリケーションソフトウェアプログラムの前記実行をシミュレートすることは、生成カーネルのモデルから消費カーネルのモデルに通信される画像データのラインを格納および転送するシミュレートされたラインバッファでカーネルモデル間通信をインターセプトすることによって、複数のラインバッファの動作を複数のシミュレートされたラインバッファを用いてシミュレートすることを含み、前記シミュレートすることは、さらに、シミュレーションランタイムにわたって、以下の動作を実行することによってそれぞれの前記シミュレートされたラインバッファに格納されるそれぞれの画像データの量を追跡することを含み、前記以下の動作は、
    前記ロード命令によって参照されるラインバッファをシミュレートするそれぞれのシミュレートされたラインバッファに対するそれぞれの読み出しポインタを更新することを含めて、複数のカーネルに生じる各ロード命令をシミュレートすることと、
    前記ストア命令によって参照されるラインバッファをシミュレートするそれぞれのシミュレートされたラインバッファに対するそれぞれの書き込みポインタを更新することを含めて、複数のカーネルに生じる各ストア命令をシミュレートすることとを含み、各読み出しポインタは、対応するシミュレートされたラインバッファからこれまでにどれだけのデータが読み出されたかを特定し、各書き込みポインタは、対応するシミュレートされたラインバッファにこれまでにどれだけのデータが書き込まれたかを特定し、前記方法はさらに、
    ｂ）前記シミュレートされたラインバッファの各々に対して、前記シミュレーションの間に遭遇する前記シミュレートされたラインバッファのそれぞれの読み出しポインタとそれぞれの書き込みポインタとの間のそれぞれの最大差を計算することによって、追跡されたそれぞれの画像データの量から、対応するハードウェアラインバッファのそれぞれのハードウェアメモリ割り当てを決定することと、
    ｃ）前記シミュレートされたラインバッファの各々に対して計算された前記それぞれの最大差に基づいて、画像プロセッサの前記ラインバッファの各々に割り当てるそれぞれメモリサイズを生成することによって、前記画像処理アプリケーションソフトウェアプログラムを実行するための前記画像プロセッサの構成情報を生成することとを含み、前記構成情報は、前記画像プロセッサのハードウェアラインバッファのハードウェアメモリ割り当てを記述する、コンピューティングシステム。
  13. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、前記画像データを消費するカーネルの１つ以上のモデルが次の画像データのユニットを受け取るべく待機状態となるまで、前記次の画像データのユニットがシミュレートされたラインバッファに書き込まれることを防ぐ書き込みポリシーを課すことをさらに含む、請求項１２に記載のコンピューティングシステム。
  14. 前記書き込みポリシーは、前記次の画像データのユニットを生成する生成カーネルのモデルで実施される、請求項１３に記載のコンピューティングシステム。
  15. 前記方法は、さらに、前記画像処理アプリケーションソフトウェアプログラムのシミュレートされた実行がデッドロックする場合に、前記書き込みポリシーに違反することを許可することを含む、請求項１３または請求項１４に記載のコンピューティングシステム。
  16. 前記画像プロセッサのアーキテクチャが、２次元シフトレジスタアレイに結合された実行のアレイを含む、請求項１２～請求項１５のいずれか１項に記載のコンピューティングシステム。
  17. 前記画像プロセッサのアーキテクチャは、ラインバッファ、シート生成部、および／またはステンシルプロセッサのうちの少なくとも１つを含む、請求項１２～請求項１６のいずれか１項に記載のコンピューティングシステム。
  18. 前記ステンシルプロセッサは、重複するステンシルを処理するように構成される、請求項１７に記載のコンピューティングシステム。
  19. データ計算ユニットが、実行レーンアレイよりも広い次元を有するシフトレジスタ構造を備え、特に前記実行レーンアレイの外側にレジスタがある、請求項１２～請求項１８のいずれか１項に記載のコンピューティングシステム。
  20. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、１つ以上のシミュレートされたロード命令がストールされるまで次の画像データのユニットが特定のシミュレートされたラインバッファに書き込まれることを防ぐ書き込みポリシーを、前記特定のシミュレートされたラインバッファに対して課すことを含む、請求項１～請求項１１のいずれか１項に記載の方法。
  21. 前記コンピューティングシステムが、前記複数のカーネルのうちの１つ以上からロード命令でもストア命令でもない１つ以上の命令を取り除くことをさらに含む、請求項１～請求項１１および請求項２０のいずれか１項に記載の方法。
  22. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、前記複数のカーネルのうちの１つ以上から取り除かれた命令に対するそれぞれの遅延をシミュレートすることを含む、請求項２１に記載の方法。
  23. 前記複数のシミュレートされたラインバッファの各々は、前記画像プロセッサの複数の処理コア間のデータをバッファリングするように構成された複数のラインバッファを有する画像プロセッサのそれぞれのラインバッファに対応する、請求項１～請求項１１および請求項２０～請求項２２のいずれか１項に記載の方法。
  24. 前記画像処理アプリケーションソフトウェアプログラムは、２次元実行レーンアレイおよび２次元シフトレジスタアレイを有する処理コアによって実行されるようにコンパイルされたコードである、請求項２３に記載の方法。
  25. 前記複数のシミュレートされたラインバッファの各々は、メモリの無制限の部分を備える、請求項１～請求項１１および請求項２０～請求項２４のいずれか１項に記載の方法。
  26. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、１つ以上のシミュレートされたロード命令がストールされるまで次の画像データのユニットが特定のシミュレートされたラインバッファに書き込まれることを防ぐ書き込みポリシーを、前記特定のシミュレートされたラインバッファに対して課すことを含む、請求項１２～請求項１９のいずれか１項に記載のコンピューティングシステム。
  27. 前記方法は、前記複数のカーネルのうちの１つ以上からロード命令でもストア命令でもない１つ以上の命令を取り除くことをさらに含む、請求項１２～請求項１９および請求項２６のいずれか１項に記載のコンピューティングシステム。
  28. 前記画像処理アプリケーションソフトウェアプログラムの実行をシミュレートすることは、前記複数のカーネルのうちの１つ以上から取り除かれた命令に対するそれぞれの遅延をシミュレートすることを含む、請求項２７に記載のコンピューティングシステム。
  29. コンピューティングシステムによって処理されると、前記コンピューティングシステムに請求項１～請求項１１および請求項２０から請求項２５のいずれか１項に記載の方法を実行させるプログラム。
JP2019559299A 2017-05-12 2018-01-09 ラインバッファユニット単位メモリ割り当ての決定 Active JP7208920B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/594,512 US10430919B2 (en) 2017-05-12 2017-05-12 Determination of per line buffer unit memory allocation
US15/594,512 2017-05-12
PCT/US2018/012875 WO2018208334A1 (en) 2017-05-12 2018-01-09 Determination of per line buffer unit memory allocation

Publications (3)

Publication Number Publication Date
JP2020519993A JP2020519993A (ja) 2020-07-02
JP2020519993A5 JP2020519993A5 (ja) 2020-08-13
JP7208920B2 true JP7208920B2 (ja) 2023-01-19

Family

ID=61599563

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019559299A Active JP7208920B2 (ja) 2017-05-12 2018-01-09 ラインバッファユニット単位メモリ割り当ての決定

Country Status (7)

Country Link
US (2) US10430919B2 (ja)
EP (1) EP3622399B1 (ja)
JP (1) JP7208920B2 (ja)
KR (1) KR102279120B1 (ja)
CN (1) CN110574011B (ja)
TW (2) TWI750557B (ja)
WO (1) WO2018208334A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10387988B2 (en) * 2016-02-26 2019-08-20 Google Llc Compiler techniques for mapping program code to a high performance, power efficient, programmable image processing hardware platform
US10489878B2 (en) * 2017-05-15 2019-11-26 Google Llc Configurable and programmable image processor unit
US10534639B2 (en) * 2017-07-06 2020-01-14 Bitfusion.io, Inc. Virtualization of multiple coprocessors
CN110706147B (zh) * 2019-09-29 2023-08-11 阿波罗智联(北京)科技有限公司 图像处理的环境确定方法、装置、电子设备和存储介质
US11093400B2 (en) 2019-10-15 2021-08-17 Sling Media Pvt. Ltd. Lock-free sharing of live-recorded circular buffer resources
CN114168524B (zh) * 2021-12-07 2023-10-20 平头哥(上海)半导体技术有限公司 行缓存单元、加速单元、片上系统和行缓存配置方法
CN114333930B (zh) * 2021-12-23 2024-03-08 合肥兆芯电子有限公司 多通道存储器存储装置、控制电路单元及其数据读取方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140040855A1 (en) 2011-07-28 2014-02-06 National Instruments Corporation Optimization of a Data Flow Program Based on Access Pattern Information
US20160313980A1 (en) 2015-04-23 2016-10-27 Google Inc. Virtual Image Processor Instruction Set Architecture (ISA) And Memory Model And Exemplary Target Hardware Having A Two-Dimensional Shift Array Structure

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5398079A (en) * 1993-01-27 1995-03-14 General Instrument Corporation Half-pixel interpolation for a motion compensated digital video system
US7499960B2 (en) 2001-10-01 2009-03-03 Oracle International Corporation Adaptive memory allocation
WO2005114646A2 (en) 2004-05-14 2005-12-01 Nvidia Corporation Low power programmable processor
US7331037B2 (en) 2004-08-12 2008-02-12 National Instruments Corporation Static memory allocation in a graphical programming system
US8024549B2 (en) * 2005-03-04 2011-09-20 Mtekvision Co., Ltd. Two-dimensional processor array of processing elements
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 富士ゼロックス株式会社 画像形成処理シミュレーション装置及び画像形成処理シミュレーション方法
US7890314B2 (en) 2007-12-05 2011-02-15 Seagate Technology Llc Method for modeling performance of embedded processors having combined cache and memory hierarchy
US20110191758A1 (en) 2010-01-29 2011-08-04 Michael Scharf Optimized Memory Allocator By Analyzing Runtime Statistics
US9256915B2 (en) * 2012-01-27 2016-02-09 Qualcomm Incorporated Graphics processing unit buffer management
US20150055861A1 (en) * 2013-08-23 2015-02-26 Amlogic Co., Ltd Methods and Systems for Image Demosaicing
US10055342B2 (en) 2014-03-19 2018-08-21 Qualcomm Incorporated Hardware-based atomic operations for supporting inter-task communication
US9756268B2 (en) 2015-04-23 2017-09-05 Google Inc. Line buffer unit for image processor
US11016742B2 (en) 2015-06-24 2021-05-25 Altera Corporation Channel sizing for inter-kernel communication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140040855A1 (en) 2011-07-28 2014-02-06 National Instruments Corporation Optimization of a Data Flow Program Based on Access Pattern Information
US20160313980A1 (en) 2015-04-23 2016-10-27 Google Inc. Virtual Image Processor Instruction Set Architecture (ISA) And Memory Model And Exemplary Target Hardware Having A Two-Dimensional Shift Array Structure

Also Published As

Publication number Publication date
CN110574011B (zh) 2023-06-27
TWI750557B (zh) 2021-12-21
TW201907298A (zh) 2019-02-16
JP2020519993A (ja) 2020-07-02
KR102279120B1 (ko) 2021-07-20
CN110574011A (zh) 2019-12-13
US20180330467A1 (en) 2018-11-15
US10430919B2 (en) 2019-10-01
KR20190135034A (ko) 2019-12-05
US20200098083A1 (en) 2020-03-26
EP3622399A1 (en) 2020-03-18
TW202014888A (zh) 2020-04-16
US10685423B2 (en) 2020-06-16
EP3622399B1 (en) 2023-10-04
TWI684132B (zh) 2020-02-01
WO2018208334A1 (en) 2018-11-15

Similar Documents

Publication Publication Date Title
JP6858239B2 (ja) プログラムコードを、高性能で電力効率の良いプログラマブルな画像処理ハードウェアプラットフォームにマッピングするためのコンパイラ技法
JP7208920B2 (ja) ラインバッファユニット単位メモリ割り当ての決定
JP7202987B2 (ja) 高性能で、電力効率の良い、プログラマブルな画像処理のためのアーキテクチャ
JP6967570B2 (ja) 画像プロセッサのためのエネルギ効率的なプロセッサコアアーキテクチャ
JP6793162B2 (ja) 画像プロセッサのためのラインバッファユニット
JP6793228B2 (ja) 画像プロセッサのためのシート生成部
CN107430760B (zh) 用于图像处理器的二维移位阵列
CN107533750B (zh) 虚拟图像处理器及在其上处理图像数据的方法和系统
JP6967597B2 (ja) 設定可能な数のアクティブなコアを有する画像処理プロセッサおよびサポートする内部ネットワーク
JP6775088B2 (ja) 画像プロセッサランタイム効率を向上するためのプログラムコード変形
TWI752343B (zh) 用於執行絕對差計算之加總的執行單元電路、影像處理器以及方法
JP6820428B2 (ja) マルチコア画像プロセッサ上のアプリケーションソフトウェアの構成

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200608

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200608

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210719

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210803

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211104

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20211116

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220316

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20220316

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20220331

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20220405

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20220415

C211 Notice of termination of reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C211

Effective date: 20220420

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20220726

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20221025

C23 Notice of termination of proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C23

Effective date: 20221115

C03 Trial/appeal decision taken

Free format text: JAPANESE INTERMEDIATE CODE: C03

Effective date: 20221213

C30A Notification sent

Free format text: JAPANESE INTERMEDIATE CODE: C3012

Effective date: 20221213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230106

R150 Certificate of patent or registration of utility model

Ref document number: 7208920

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150