グラフィックオペレーションのための高レベルプログラムインターフェース
【課題】イメージ処理のツールにプログラマが容易にアクセスできることや、グラフィック計算が効率的であることの重要性が常に高まっている。ＯｐｅｎＧＬ（登録商標）とプログラム可能ＧＰＵの組み合わせは、グラフィックプログラムが可能であることについて広範な進歩を遂げたが、更に高レベルのインターフェースを実現する。
【解決手段】フィルタとイメージとの間の関係を定義することによって、イメージを生成するためのＡＰＩ及び技術を含み、このような関係は、要求しているアプリケーションとグラフィックサービス資源との間の協働セッションによってプログラム的にオブジェクトで組み立てられる。本システムはまた、プログラム的に組み立てられたオブジェクトの最適化とマルチプロセッサ環境でのレンダリングのための技術とに関する態様を含む。
【解決手段】フィルタとイメージとの間の関係を定義することによって、イメージを生成するためのＡＰＩ及び技術を含み、このような関係は、要求しているアプリケーションとグラフィックサービス資源との間の協働セッションによってプログラム的にオブジェクトで組み立てられる。本システムはまた、プログラム的に組み立てられたオブジェクトの最適化とマルチプロセッサ環境でのレンダリングのための技術とに関する態様を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
ここ数年にわたって、全ての種類のハードウェアにおいてグラフィックサブシステムが重要となる需要が増えてきた。例えば、汎用コンピュータ関連分野において、プレゼンテーションソフトウェアのような従来からの日常的なプログラムでさえ、より高速でより複雑な図形処理機能を必要とするアニメーションや他のツールが含まれている。更に、ビデオ、写真編集、ゲームのような従来のグラフィック性が強いアプリケーションは、適用範囲とグラフィック強度の両方で成長しつつある。更に、ゲームやグラフィック専用演算処理のような垂直システム（例えば、任天堂ゲームキューブなど）では、グラフィックの優位性に関して、汎用コンピューティングアーキテクチャとの高速駆動の競争が加速してきた。
【背景技術】
【０００２】
これと同じ期間に、ハードウェア製造業者は、増大する一方の容量を備えた専用グラフィックプロセッサに関して高まる需要を満たし、これを越えようと努めてきた。現在では、プログラム可能な幾つかの市販されているグラフィックス・プロセッシング・ユニット（ＧＰＵ）がある。プログラム可能ＧＰＵや非プログラム可能ＧＰＵの両方がグラフィック計算において高速化をもたらすが、プログラム可能ＧＰＵは、高い柔軟性を提供する点で異なっている。例えば、プログラム可能ＧＰＵ以前には、アプリケーションプログラマは、より興味深いグラフィックをレンダリングするためにＣＰＵ時間を消費するか、又は理想的ではないグラフィックを表示する代償として全体のアプリケーション性能を向上させるためにＧＰＵを使用するか、そのいずれかを判断していた。プログラム可能ＧＰＵは、従来のＧＰＵの速度上の利点とかなりの程度の柔軟性とを組み合わせたものである。実際の問題として、プログラム可能であることは、システムマイクロプロセッサに類似する方法でプログラムがグラフィックチップを利用可能となるので重要な利点である。このようにＧＰＵを使用することによって、本システムは、システムＣＰＵをロードすることなく事実上無限のグラフィックエフェクトを生成することができる。
【０００３】
プログラム可能ＧＰＵは、一般的にフラグメントプログラムと呼ばれるプログラムを実行する。「フラグメント」プログラムという名称は、動作しているデータの単位が一般に画素−すなわちイメージのフラグメントであることに由来する。ＧＰＵは、同時に幾つかの画素上でフラグメントプログラムを実行し、一般的には常駐するバッファの名称で呼ばれる結果をもたらす。ＧＰＵは、画素の集合に類似した一般にテクスチャと呼ばれるデータ入力を使用する。
【０００４】
また、ＧＰＵが企図され開発された同じ期間中に、グラフィック専用ハードウェアの使用を求めるアプリケーションプログラムのために幾つかのプログラミングインターフェースを提供する取り組みが進行していた。１つのこのような取り組みは、ＯｐｅｎＧＬとして一般に知られている。ＯｐｅｎＧＬの目標は、ハードウェアに依存せずにプログラマがグラフィック機能を利用しやすくすることである。このようにすることで、ＯｐｅｎＧＬは状態機械のように動作する。特に、ＯｐｅｎＧＬライブラリを使用するプログラムは、現カラー、ライティング、ブレンドなどのステート（状態）を設定しなければならない。プログラムが実行されると、結果として生じるコンテキストは、プログラムされたものに依存する組合せなどの状態と入力テクスチャとの組合せとなる。状態機械型のオペレーションの場合、オペレーションの結果は、必ずしも容易に予測できるとは限らない。
【０００５】
コンピュータが視覚的に更にリッチなコンテンツに移行するにつれて、イメージ処理はより重要になっている。その結果、これらのツールにプログラマが容易にアクセスできることや、グラフィック計算が効率的であることの重要性が常に高まっている。ＯｐｅｎＧＬとプログラム可能ＧＰＵの組み合わせは、グラフィックプログラムが可能であることについて広範な進歩を遂げたが、依然としてグラフィックサブシステムへのより高レベルのインターフェースに対する必要性がある。この必要性は、イメージ処理（例えば、ＰｈｏｔｏＳｈｏｐ、ＡｆｔｅｒＥｆｆｅｃｔｓ、又は類似のソフトウェア）に直接関連するアプリケーションにおいて高まっている。これらのアプリケーションやその他においては、そのインフラストラクチャを利用するアプリケーションからグラフィックハードウェアの複雑さを隠す抽象レイヤを有することが望ましい。更に、オペレーティングシステムは、全てのアプリケーションに対してこのような抽象レイヤを提示することによって全体的にリッチなユーザーグラフィック体験を容易にすることを求める可能性がある。
【０００６】
このようなインターフェースは、プログラマ又はプログラムが所与のイメージにフィルタ又はエフェクトを簡単に適用できるようにする必要がある。より高いレベルのＡＰＩに対する暗黙的な必要性は、高速と効率の両方の方法でそのＡＰＩを実装する必要性である。効率的であるためには、システムは、理解が容易で且つ動作が容易な方法でグラフィックプログラミングを概念化するメカニズムを有する必要がある。更に、このようなシステムは、ＣＰＵとＧＰＵとの間で作業を効率的に分担しながら同時にメモリの使用と計算時間を最小にしなければならない。最終的には、デュアルプロセッサシステム（ＧＰＵとＣＰＵ）のために構築されたプログラムがＣＰＵだけを有するレガシーシステム上で実行することができるように、単一のプロセッサ上でエミュレートできるシステムを有することが望ましい。
【発明の概要】
【０００７】
他の利点の中でも、本発明は、上述の問題を解決し、上述の必要性と要求を満たそうとするものである。これを行う場合、本発明の幾つかの実施態様は、グラフィックオペレーション、或いは二次的なプロセッサ資源を利用できる潜在的な他のオペレーションのための高レベルプログラムインターフェースを含む。このタイプの更に特定の実施態様において、高レベルプログラムインターフェースは、ユーザー又はシステム内のプログラムが呼び出すことができるグラフィックフィルタリング機能を含む。プログラム又はユーザーは、エフェクトを生成することによって、或いは事前に定義されたリストからフィルタ機能を指定することによって高レベルプログラムインターフェースを利用する。別の実施態様において、プログラマ又はプログラムは、フィルタを事前に定義されたリストに加えるために拡張可能なインフラストラクチャへアクセスすることができる。
【０００８】
本発明の１つの一般的な実施態様において、ソフトウェアは、イメージタスクのグラフ状記述を構成するためにシステム内の選択されたプロセッサを利用する。グラフ状記述は、イメージのノードやリンク表示であり、ここでノードはオペレータを表し、リンクは、中間段階の結果と中間段階の結果を保持するのに必要な記憶装置を表す。詳細には、グラフ状記述のノードは、別のプロセッサ上の全体的なイメージオペレーションの一部分を計算するためのスレッド又はプログラムを最終的に含むことができる。更に、全体的なイメージタスクのグラフ状記述を有することで、最適化コンパイラの使用は全体的なイメージタスクに対して必要な資源を低減させることができる。このコンパイリング機能は、ノードプログラムがコンパイラを実行するプロセッサ以外のプロセッサ上で一般的に実行するので特に有用である。
【０００９】
前述の一般的な実施態様は、単一のＣＰＵと単一のＧＰＵとの一時的なペアのコンテキストで説明することができる。この実施態様は、全体的なイメージタスクを評価し、そのグラフ状記述を構成するためにＣＰＵ上で実行するソフトウェアを提案する。これは、上述されたような関連づけを備えたノードやリンクのツリーグラフとして視覚的に表現することができる。ノード−プログラムがＧＰＵ上で実行できるので、プログラムの構成は、ＧＰＵのプロパティを考慮する。とりわけ一般的な意味では、プログラム可能ＧＰＵは幾つかの並列実行ストリームを操作し、そのためノードプログラムは並行処理可能言語で表すことができる。例えば、ノードプログラムはＧＰＵフラグメントプログラムとすることができる。全体的なイメージタスクを表すグラフの構成後、グラフは、ＣＰＵ上で実行されるコンパイラによって最適化することができる。或いは、グラフは、該グラフが作成されるときに別の部分においてコンパイラによって最適化することができる。最適化の目的は、メモリ使用量やＣＰＵ又はＧＰＵ時間を最小にすること、或いはイメージが計算されるときの効率を高めることである。
【００１０】
本発明の種々の実施態様によると、最適化は、多くの機能的特性を有する。例えば最適化は、中間段階の結果をキャッシュする段階、複数のフラグメントプログラムを１つに統合する段階、閉じこめられた定義ドメインや関心領域内のエリアにメモリと計算を制限する段階、又はプロセッサ間での計算の分割を最適化する段階を含む。
【００１１】
最新のグラフィックコンテキストにこれらの技術を適用することは、非常に効率的であり、これによって開発者はコンパイラが占めるシステム内の特定のハードウェアを考慮することなく、１つ又は複数の素子（例えば画素）で実行されるオペレーションを表現することによってフィルタを記述することができる。更に、マルチプロセッサシステム内に装備するためのＡＰＩや効率的な処理インフラストラクチャを作成したことで、多くの実施態様はまた、シングルプロセッサシステム上のＡＰＩを利用する機能を含む。ごく一般的な意味で、これはエミュレーションによって達成される。
【図面の簡単な説明】
【００１２】
【図１】サンプルハードウェア構成を示す図である。
【図２（ａ）】ハードウェア構成のサンプルを示す図である。
【図２（ｂ）】ハードウェア構成のサンプルを示す図である。
【図３】ソフトウェアスタックの説明図である。
【図４】グラフを示す図である。
【図５】グラフ及びサンプルプログラムステップを示す図である。
【図６】グラフを示す図である。
【図７】イメージ生成のための例示的なフローチャートを示す図である。
【図８】ノード結合のための例示的なフローチャートを示す図である。
【図９】ノード結合のための例示的なフローチャートを示す図である。
【図１０】ノード結合のための例示的なフローチャートを示す図である。
【図１１】グラフを示す図（ａ）とグラフ最適化のための例示的なフローチャートを示す図（ｂ）である。
【図１２】グラフ最適化のための例示的なフローチャートを示す図である。
【図１３】最適化のための例示的なフローチャートを示す図である。
【図１４】グラフ最適化のための例示的なフローチャートを示す図である。
【図１５（ａ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１５（ｂ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１５（ｃ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１６】最適化のための例示的なフローチャートを示す図である。
【図１７】多角形分割の実施例を示す図である。
【発明を実施するための形態】
【００１３】
Ａ．技術及び用語
１．技術
本明細書で説明される本発明の実施形態は、特に種々のタイプのプロセッサが１つのシステム内で利用される、全てのタイプのマルチプロセッサコンピューティングシステムに関連し、用途を有する。本明細書での説明のほとんどは、ＣＰＵ資源やＧＰＵ資源を有する一般的なコンピューティング構成に焦点を絞っている。この説明は、例証のためのものであり、ＧＰＵなし、複数のＣＰＵと１つのＧＰＵ、複数のＧＰＵと１つのＣＰＵ、或いは複数のＧＰＵと複数のＣＰＵのいずれかを有する他のシステムに対して本発明の適用を制限するものではない。この注意に関して、発明者らは典型的なハードウェアとソフトウェア動作環境に関する情報を提供するものとする。
【００１４】
図１を参照すると、一般的なハードウェアコンピューティング構成が示されている。極めて一般的であるが、マイクロプロセッサ１１は、チップセットサポート集積回路１３、１７に結合されている。マイクロプロセッサは、２３、２４、又は２５のようなインテルペンティアム（登録商標）ファミリー又はＩＢＭ／モトローラパワーＰＣチップのうちの１つのような、いずれかのマイクロプロセッサ又はコントローラとすることができる。チップセットＩＣ（本明細書ではノースブリッジ１３、サウスブリッジ１７として表現される）は、１つ又はそれ以上のＩＣに実装することができる。チップセット１３、１７は一般に、バス１２を介して又は現在当該技術分野で公知の直接リンクによってマイクロプロセッサに結合される。チップセット１３、１７が１つより多いＩＣに実装される場合、ノースブリッジの機能（ＡＧＰ、メモリ管理など）が共通バスへの接続又は前述のリンクのいずれかによるプロセッサへのより直接的な接続を有することは一般的である。サウスブリッジ機能を含む別のチップは、ノースブリッジを介して極めて一般的にマイクロプロセッサ１１に結合される。しかしながら、発明者らは、現在又は将来的に存在する利用可能な他の構成を排除することを意図するものではない。可能性のあるサウスブリッジ機能は、ディスクドライブのような周辺接続機構のためのＡＴＡバス１６、あらゆる種類の周辺機器の接続機構のためのＰＣＩバス１８、ＵＳＢデバイスの接続機構のためのＵＳＢコントローラ１９、イーサネット（登録商標）又は場合によっては他のネットワークをサポートするためのネットワークインターフェースコントローラ１１０、音声サポート１１１を含む。更に関連するものとして、標準的なノースブリッジ機能は、メインメモリ１１４をサポートするメモリコントローラと、ビデオサブシステムのサポートのためのアクセラレイティッド・グラフィックス・ポート１５を含む。メモリは通常、種々のタイプのダイナミックランダムアクセスメモリのいずれかであるが、代替の構成では、スタティックＲＡＭ、磁気メモリ、光メモリ、又は現在又は将来的に存在する可能性のある他のいずれか適切な記憶媒体とすることができる。ＡＧＰ１５は、グラフィックサブシステムがマイクロプロセッサやメインメモリなどのシステム資源に高速にアクセスするようにする、チップセット内に配置された特別なポートである。種々の新しく出てきたＡＧＰ系、及びコア資源とグラフィックサブシステムとの間の対話速度を確実に加速する他の方法が存在する。この説明は、類似の機能を実行するいずれかの特定の方法に用途を限定するものではない。最後に、図２は別のコンピューティングハードウェア構成２４、２５を示しており、これは２４と２５のマイクロプロセッサそれぞれとの緩い連係を意図するものである。
【００１５】
上述のように、本明細書で開示される本発明の実施形態はソフトウェアを含む。従って、図３のレイヤ図に表されるような、一般的なコンピューティングソフトウェアアーキテクチャの説明を行う。ハードウェア実施例と同様に、これらは、どのような意味においても限定するものではなく、むしろ例証に過ぎない。これは、ソフトウェア開発者が幾分異なる方法で表す傾向にあるレイヤタイプの図に特に当てはまる。この場合、Ｏ／Ｓカーネルから始まるレイヤを表したので、低レベルのソフトウェア及びファームウェアは省略した。発明者らの表記は一般に、レイヤ内に示されたソフトウェア要素が、その下のレイヤからの資源を使用して、その上のレイヤにサービスすることを意味する。しかしながら実際には、特定のソフトウェア要素の全ての構成要素は、完全にその様態で動作するというわけではない場合がある。
【００１６】
ソフトウェアに関する注意では、図３（ａ）を参照すると、レイヤ３１は、高度に保護された環境でコアＯ／Ｓ機能を提供するＯ／Ｓカーネルである。Ｏ／Ｓカーネルの上には、上位のレイヤにディスクや通信アクセスのような拡張機能がサービスされるレイヤ３２のＯ／Ｓコアサービスが存在する。レイヤ３３は、ＯｐｅｎＧＬライブラリや類似の資源の一般的な相対的位置付けを示すようにここに挿入されている。レイヤ３４は、２つのレイヤ、すなわちアプリケーションフレームワークとアプリケーションサービスとして通常表される機能の融合である。説明の目的のために、これらの両方のレイヤは、ここでは３５で示される最高レイヤでの常駐によってアプリケーションプログラムの高レベルで且つ頻繁な機能サポートを提供する。アイテム３１００は、「Ｃｏｒｅ Ｉｍａｇｉｎｇ」、ソフトウェアスーツ、モニカの相対的位置付けを示すもものであり、これは、本発明の多くの実施形態を説明するための媒体を提供する（本発明の実施形態の一部、いずれか、又は全てを含むソフトウェアスーツを意味する場合、用語「Ｃｏｒｅ Ｉｍａｇｉｎｇ」を一般的に用いることにする）。
【００１７】
ここで３（ｂ）を参照すると、アイテム１０１は、Ｃｏｒｅ Ｉｍａｇｉｎｇスーツの相対的な位置付けを表している。図３（ｂ）において、図３（ａ）と比較すると、別のグラフィック機能−合成に対してレイヤ３２４が加えられたことが明らかである。合成器のジョブは、多くの実施形態において説明されるようにウィンドウイングシステムにおけるウィンドウ合成と管理を実行することである。
【００１８】
２．ツリーとグラフ
数学や他の計算科学において、問題を、機械実行の計算やこのような機械のプログラミングに結び付くパーズ（構文解析）方式で表することができる。パーズ表現の実施例は、図４に示されるような一般化ツリー構造である。図４を参照すると、ツリー構造４１は、最も近い従属ノードの結果を表すリンク（４２、４３、４４、４５、４６、４７、４８、４９、４１０、４１１、４１２、４１３、４１４）と、２つのタイプのノードとから構成される。事前に存在している計算入力（例えば、オペランド）、４１９、４２４、４２５、４２６、４２７、４２８、４２９を表すリーフ（葉）ノードが存在する。或いは、計算関数（例えば演算子）４１５、４１６、４１７、４１８、４２０、４２１、４２２、４２３を表す機能ノードが存在する。全体的な実施例として、図４を参照すると、リンク４６は、機能ノード４１７への入力として役割を果たし、リーフノード４２４の結果（単にリーフであるリーフノードの結果）を表す。
【００１９】
ここで図５を参照すると、別のツリーが、円ではなく矩形のノードを使用して示されている。しかしながら、図の表示の性質は同じであり、リーフノード５１はオペランドに類似しており、機能ノード５２、５３、５４は、演算子を表し、リンク５１００、５１０１、５１０２、５１０３、５１０４は、結果を表している。
【００２０】
本開示の種々の箇所では、図４、５にあるようなツリーを使用し、コンピュータシステム内で使用又は組み立てられる「グラフ」のコンテキストにおけるツリーを説明する。発明者らは一般に、描写されるグラフィックツリーをコンピュータシステムが構成又は使用することを意味するものではなく、むしろ人への例証の目的で描かれるグラフィックツリーの何らかの表示をシステムが作成、保持、又は使用することを意味するものとする。
【００２１】
更に、グラフィック技術やソフトウェアを説明するコンテキストにおいては、一般にツリー（又はグラフ）を使用する。アプリケーションプログラム又はプログラマの観点から、ツリー又はグラフによって定義されるイメージは、画素のアレイによって定義されたイメージとは通常区別できない。イメージの両方のタイプは、同じ最終のオブジェクトを定義し、アプリケーションプログラムがイメージと関連付けるのがオブジェクトである。幾つかの点で、同じことがＣｏｒｅ Ｉｍａｇｉｎｇ（又は本明細書で本発明を具現化する他のソフトウェア）の観点に関して当てはまる。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフを評価することによってイメージ計算タスクを評価することができる。その点に関して、グラフのルート（根）ノードの結果は最終結果である。図４、５を参照すると、ノード４１５、５４は、グラフのそれぞれのルートノードである。
【００２２】
本発明の実施形態及びＣｏｒｅ Ｉｍａｇｉｎｇの説明においては、これらの例証的なツールを引用することが多い。従って、本明細書で説明される実施形態の多くに関する前置きとして、図４を参照すると、以下の関連付けは発明者らの説明のコンテキストにおいて一般に適切であり、すなわち、（ｉ）図示されるツリーは一般に低レベルグラフと呼ばれ；（ii）機能ノード４１５、４１６、４１７、４１８、４２０、４２１、４２２、４２３は、ＧＰＵのようなマイクロプロセッサ上で実行される「カーネル」又はフラグメントプログラムを表し；（iii）リーフノード４１９、４２４、４２５、４２６、４２７、４２８、４２９は一般的にイメージを表し、換言すると、画素の集合又はその表現であり；（iv）リンク４２、４３、４４、４５、４６、４７、４８、４９、４１０、４１１、４１２、４１３、４１４は結果を表すが、実際に生じるであろうオペレーションのコンテキストでは、これらの結果は、これらを記憶するためのバッファに通常関連付けられる。
【００２３】
更に、本明細書で説明される実施形態の多くに関する前置きとして図５を参照すると、以下の関連付けは、発明者らの説明のコンテキストにおいて適切であり、すなわち：（ｉ）図示されるツリーは、一般的に高レベルグラフと呼ばれ；リーフノード５１はイメージを表し；機能ノード５２、５３、５４は、一般に事前に定義されたフィルタである高レベルフィルタを表し；リンク５１００、５１０１、５１０２、５１０３、５１０４は、フィルタの結果を表すが、低レベルのグラフとは異なり必ずしもバッファに関連付けられない。
【００２４】
Ｂ．プログラマの観点からのＣｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩ
本発明の多くの実施形態は、オブジェクト指向のプログラミングを含み、４つのタイプのオブジェクトをプログラマに利用可能にする。これらのオブジェクトタイプは、イメージ、フィルタ、コンテキスト、ベクトルである。各々については、簡潔に説明するが、その普遍性を制限しないようにする。
【００２５】
イメージは、レンダリングの２次元結果（画素イメージ）又はその表現のいずれかである。高レベルのプログラムオペレーションでは、当該オブジェクトが実際の画素値になるために計算を必要とすることで、イメージを表すオブジェクトが維持される場合が多い。本発明の種々の実施形態は、イメージの定義として画素値イメージと未計算のイメージのいずれか又は両方を利用することができる。特定の意味は、コンテキスト的な使用（「コンテキスト」オブジェクトへの関連性がない）からかなり容易に得られる。一般的な意味において、フィルタに関する説明の中では、イメージは、ある関数又はフィルタへの入力として解釈される必要がある。
【００２６】
フィルタは、イメージに影響を与えるのに使用される高レベルな機能である。フィルタは、この開示の最後にリストされる事前に定義されたフィルタの１つ又はそれ以上を含むことができる。フィルタは、フラグメントプログラムに類似したものとすることができ、同様にイメージに（又はより正確に一般的にはテクスチャに）影響を与えるが、一度に１つの画素だけを生成する。本発明の実施形態の多くにおいて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、フィルタベースのイメージ操作をコンパイルし、このような操作を、フラグメントプログラムを使用してＧＰＵ上で行うことができるようにする。フィルタとフラグメントプログラムとの間には必ずしも１対１の対応がある訳ではない。
【００２７】
コンテキストは、フィルタリングオペレーションの結果が常駐するメモリ内の定義された場所などの空間である。上記で提案されたように、イメージが入力と仮定すると、コンテキストは出力と仮定される。
【００２８】
ベクトルは、浮動小数点数の集合である。本明細書で説明されるほとんどの実施形態では、ベクトルは、４つの浮動小数点数に関連付けられ、各数は、同じ固定ビット数（通常は３２）を有する。グラフィックでは、ベクトルを用いて、（ｉ）画素の外観（Ｒ（赤）；Ｇ（緑）；Ｂ（青）、アルファ（透明性））を記述するのに必要な４次元；又は（ii）それぞれＸ、Ｙ、Ｚ、Ｗの２空間、３空間、又は４空間（均一）座標を記述するのに必要な２又は３次元を表すことができる。
【００２９】
Ｃ．Ｃｏｒｅ ＩｍａｇｉｎｇとＣｏｒｅ ＩｍａｇｉｎｇＡＰＩ
Ｃｏｒｅ Ｉｍａｇｉｎｇは、多くのルーチンを含み、特にグラフィック機能のために構成された高レベルプログラミング言語又はＡＰＩとして機能するが、数値計算単独（例えば畳み込みオペレーション）などの他の機能にも適用可能なソフトウェアスーツである。いずれか１つの実施形態又は実施形態のいずれかのグループに言及するためにモニカＣｏｒｅ Ｉｍａｇｉｎｇを使用するが、「Ｃｏｒｅ Ｉｍａｇｉｎｇ」に関するどのような特定のコメントにも本発明を限定するものではない点を想起されたい。同様に、Ｃｏｒｅ Ｉｍａｇｉｎｇとして或いはＣｏｒｅ Ｉｍａｇｉｎｇ内でルーチン又はプロセスに言及するが、それにより、本発明が単一のユニット又はレイヤとしてこのようなソフトウェアが実装されることを意味するものではない。
【００３０】
Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフィックフレームワークやグラフィック固有アプリケーションサービススーツと通信するための高レベル言語又はＡＰＩを含む。これはまた、高レベル言語からアセンブリを生成するためのコンパイラを含む。グラフィックフレームワークと従属のソフトウェアレイヤがプラットフォーム又はハードウェアの差違を考慮することができるので、言語／ＡＰＩはプラットフォームやハードウェアに依存しない。ＡＰＩによりプログラマは、（１）ＯｐｅｎＧＬ又は類似のインターフェースによって要求される状態と他のパラメータ、或いは（２）グラフィックレンダリングを実行するＧＰＵ又は他の資源のためのアセンブリ言語を懸念することなく、イメージにエフェクトを加えることができる。
【００３１】
ソフトウェアとして概念化される場合、Ｃｏｒｅ Ｉｍａｇｉｎｇ（又はＡＰＩと関連するコンパイラの実施形態）は、一般には、アプリケーションプログラムとオペレーティングシステムとの間に位置付けられるグラフィックサービスルーチンの組として見ることができる。階レイヤソフトウェアの概念化は、様々な解釈の影響を受けるので、この説明は、Ｃｏｒｅ Ｉｍａｇｉｎｇの階レイヤ化位置（又は本発明の実施形態によるあらゆるグラフィックサービスソフトウェアスーツ）を概念化するために他の方法を排除するものではない。図３（ａ）、３（ｂ）を参照すると、この注意で、グラフィックサービスソフトウェアスーツ３１００と３１０１がそれぞれ示されている。
【００３２】
これらのグラフィックサービス３１００、３１０１の位置付けは、これらのスーツがアプリケーションフレームワーク、アプリケーションサービス、グラフィック資源の構成要素を含むことができることを意味している。要約すると、この位置付けの意図は、Ｃｏｒｅ Ｉｍａｇｉｎｇ３１００、３１０１が、レイヤ３５、３２７のアプリケーション；レイヤ３４、３２６の他のフレームワーク又はサービス；レイヤ３３、３２５のＯｐｅｎＧＬなどの資源；レイヤ２４の合成器；レイヤ３２、３２３のＯ／Ｓサービスと対話することができることを意味するものである。
【００３３】
一般的な意味では、グラフィックに適用されたように、Ｃｏｒｅ Ｉｍａｇｉｎｇによってプログラマとプログラムは、（１）事前に定義された高レベルフィルタを使用する、或いは（２）ＡＰＩ又は本発明の１つ又はそれ以上の別の実施形態を使用する一連の事前に定義されたフィルタをアセンブリする、これらのいずれかによってエフェクトを実装することができる。後者の場合、プログラマ又はプログラムは、事前に定義されたフィルタのゼロ又はそれ以上の高レベルの記述のためにＣｏｒｅ ＩｍａｇｉｎｇへのＡＰＩ呼出しを行う。プログラム又はプログラマは、発明者らが高レベルグラフと呼ぶデータ構造内にその高レベル記述（又はその基準）を配置する。高レベルグラフは、新しいフィルタを作成するプログラマ又はプログラムによってアセンブリされる。高レベルグラフは、事前に定義されたフィルタと新しいフィルタで用いられるイメージとの間の関係を定義する。プログラマ又はプログラムは、その高レベルグラフの構築を完了すると、新しいフィルタを作成するためのそのタスクを効率良く完了する。すなわち、新しいフィルタを作成するのに必要な情報の全ては、高レベルグラフにおいて具現化される。
【００３４】
別の実施形態では、プログラマ又はプログラムがＣｏｒｅ Ｉｍａｇｉｎｇと協働してグラフをアセンブリするときに、作成されたグラフは、低レベルグラフ又は相当に低レベルのグラフになる可能性がある。例えば、プログラム又はプログラマの観点からは、要求は高レベルフィルタに対して行うことができるが、Ｃｏｒｅ Ｉｍａｇｉｎｇは、低レベルフィルタ又は低レベルフィルタと高レベルフィルタ間のある中間段階のオブジェクトを作成し配信することができる。プログラム又はプログラマは実際にはオブジェクトを検査しないので、Ｃｏｒｅ Ｉｍａｇｉｎｇは、低レベルコードで高レベルコードの要求に対応することができる。このようにして、Ｃｏｒｅ Ｉｍａｇｉｎｇは、プログラムが高レベルフィルタやオブジェクトと共に機能していると考えられる限り低レベルグラフをアセンブリすることができる。
【００３５】
Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベルグラフ（いずれかの適用可能な入力パラメータと共に）を最終的に最適化してコンパイルし、ＧＰＵ対応プログラムを得る追加タスクを有する。コンパイリングステップは、最終イメージの使用に間に合うように実行することができる。以上をまとめると、プログラマ又はプログラムは、生成し、達成するためＡＰＩの高レベル言語（事前に定義されたフィルタを含む）を使用したが、これは種々の他のフィルタと入力から構成される本質的に新しいフィルタである。プログラマ又はプログラムはまた、プログラムによりこのフィルタをイメージに適用することができる。本発明の種々の実施形態は、ＧＰＵとＣＰＵとの間の作業の種々の分割を企図している。一般に、ＣＰＵはＣｏｒｅ Ｉｍａｇｉｎｇを実行し、ＧＰＵはＣｏｒｅ Ｉｍａｇｉｎｇの最終製品を実行することになる。しかしながら、ハードウェア能力及び最終的な最適化に応じて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ＣＰＵとＧＰＵのためのタスクを生成することができる。更に、システム内にプログラム可能ＧＰＵがない場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ＣＰＵのためのオブジェクトを生成し、イメージをコンテキストにレンダリングすることができる。
【００３６】
Ｄ．Ｃｏｒｅ Ｉｍａｇｉｎｇ基本機能の実施形態
ここでＣｏｒｅ Ｉｍａｇｉｎｇの機能を更に詳しく見てみると、１つの実施形態においてＡＰＩは、プログラマ及び最終的にはアプリケーションプログラムのユーザーのための６つの高レベル機能、すなわち、コンテキストの作成、イメージの生成、フィルタの生成、フィルタに関連したパラメータを設定する機能（例えば、フィルタ関数の引数）、アセンブリされたフィルタ又はフィルタのグループの出力を要求する機能、イメージをコンテキストにレンダリングする機能を提供する。
【００３７】
１．コンテキストの作成
コンテキストを作成する機能はメモリ内のオブジェクトの定義を可能にするツールから得られるので、一般に出力はコンテキストと呼ばれる。オペレーションの結果に対するデスティネーションが存在することができるように、このようなオブジェクトの定義が必要とされる。例えば、コンテキストは、メインメモリ内のビットマップ又はＯｐｅｎＧＬビューに関連付けることができる。これらの関連付けられたイメージコンテナは、レンダリングのデスティネーションとして使用される。本発明は、システムのグラフィック機能に関連するビデオメモリなどのメモリを第一に企図しており、ここで説明される概念は、システム内のいずれかで見出される、或いはシステムにアクセス可能なあらゆるメモリ又は記憶装置に等しく適用される。従って限定ではないが、メモリは、ダイナミックメモリ又はスタティックメモリのような全てのタイプの半導体メモリを含むことができ、これは、特にグラフィックサブシステムに関連付けられるか、グラフィックサブシステムと共用されるか、或いはメインシステム又はメインシステムによってアクセス可能な別のサブシステムに名目上専用であるか否かに関係しない。更に、速度は確かに問題であるが、本明細書の概念は磁気又は光メモリを排除するものではない。
【００３８】
コンテキストを作成する実施例としては、アプリケーションプログラムは画面に最終的に何かを表示することを意図していると仮定することができる。ＡｐｐｌｅのｉＰｈｏｔｏアプリケーションがユーザーコマンドに応答して海岸のイメージの表示を要求しているものと仮定する。ｉＰｈｏｔｏは、コンテキストの作成を要求する関数を呼び出すことによって、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩを利用することができる。Ｃｏｒｅ Ｉｍａｇｉｎｇは、可能な中でも特に、作成されたコンテキストの識別のハンドルを返すことになる。ハンドルが「空コンテキスト」であると仮定する。
【００３９】
２．イメージの生成
一般的に入力をイメージと呼ぶ、なぜなら、イメージ内の座標又は画素は、関連性のある値が得られるようにサンプリングすることができるからである。本発明のＡＰＩの実施形態を使用すると、イメージを、ゼロから或いは別のイメージから生成することができる。画素値を生成するメカニズムが提供されることによりイメージがゼロから生成される。例えばイメージを色又は色の数値的な組合せ（チェッカーボード又は縞模様のページのような）として単純に定義することにより、イメージをゼロから生成することができる。より一般的には、イメージは、１つ又はそれ以上のフィルタを既存のイメージに加えることによって別のイメージから生成される。
【００４０】
上記のｉＰｈｏｔｏの実施例に続いて、ｉＰｈｏｔｏは、海岸での子供の既存のイメージを取り、フィルタ（例えば、ブラー）を子供の外側のあるエリアに加えるようグラフィックサービスに要求することによって、イメージを生成することができる。このフィルタの適用により、新しいイメージが生成される。理解を容易にするために、これは、新しい画素値の計算が完了していないのではなく、ブラーフィルタがプログラムにより加えられている未計算イメージであり、画素を計算するのに必要な他のエレメントの全てが記憶又は参照されるイメージバッファ内において常駐又は参照される。
【００４１】
３．フィルタの作成
一般的にフィルタを、ゼロ又はそれ以上のイメージ（最終的には画素）上で実行できるいずれかの機能と呼ぶことにする。更に具体的に言うと、フィルタは、入力としてイメージと他のパラメータ（特定のフィルタに関連付けられ、これに依存する）を受け入れて新しいイメージを生成する機能とすることができる。ＡＰＩは現在のところ、この開示内容のいずれかでリストされ説明される数十のフィルタを提供する。しかしながら、本発明の実施形態は、発明者らが継続してフィルタを開発し、その上フィルタを開発するために他の機能を提供したような拡張的な性質を求めている。本発明は、事前定義タイプのフィルタの追加を可能にする拡張性を企図しており、この説明は、ゼロ又はそれ以上の事前定義フィルタの組合せと処理によって作成された新しいフィルタに注目する。
【００４２】
フィルタの作成が企図される１つの方法は、プログラマ又はプログラムが、ＡＰＩ事前定義フィルタの１つ又はそれ以上並びにプログラマが加えることを意図した他のいずれかのアイテム又は機能を共に結び付ける本発明のＡＰＩの実施形態を用いることによって開始する。上述のように、新しいフィルタを作成するためには、プログラム又はプログラマは、使用される全イメージと事前定義フィルタの表示とこれらのオブジェクト間の関係を含む高レベルのグラフを作成する。幾つかの実施形態において、事前定義フィルタは、基本的なグラフィック機能を可能な限り包括的にするものとし、プログラマ又はプログラムがＧＰＵのためのアセンブリを記述する必要性又は誘因を最小にする。実際、Ｃｏｒｅ Ｉｍａｇｉｎｇの全体的な利点は、特定のグラフィックハードウェアに関係なくアプリケーションレイヤでプログラムする能力である。
【００４３】
新しいフィルタが高レベルグラフによって定義されると、アプリケーションプログラム又はユーザー（ＣＰＵレベルでの）は、高レベルのグラフを実装するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出す（グラフによって定義される方法でグラフにおいて参照されるイメージ上で、グラフ内で参照されるフィルタに影響を与える）。もちろん、高レベルグラフは、１つより多いイメージを取り込むように記述されるが、技術は同じである。フィルタを実装する場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、フィルタが後でリストされるフィルタ定義において規定されているようなブラーのブラー半径、幾何学的パラメータ、又は他のいずれかの入力などのフィルタ指定入力を通常は有するので、他の入力データを必要とすることがある。
【００４４】
Ｃｏｒｅ Ｉｍａｇｉｎｇの重要な機能は、その後で１つ又はそれ以上のオブジェクトをアプリケーションプログラム又はユーザーに返すことである。本発明の種々の実施形態によれば、返されたオブジェクトは、ＧＰＵ、ＣＰＵ、又はこれらの２つのある組合せでレンダリングされ、又は計算する状態にすることができる。１つの別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベル要素のためのアプリケーションプログラム要求に応答しながら、低レベルグラフの全て又は一部を構築する。この実施形態において、アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇがより低いレベルのコードを供給している間は、アプリケーションプログラムがより高いレベルのコードを要求していると考えられる（アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇによって与えられたオブジェクトを解析しないので、その違いを検出できない）。或いは、好ましい実施形態において、アプリケーションがコンテキスト内のイメージを要求する場合、返されたオブジェクトは、ジャストインタイムコンパイルの準備ができた最適化された低レベルグラフとすることができる。幾つかの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ジャストインタイムコンパイルされＧＰＵで実行される１つだけのオブジェクトを返すことになる。このようにするために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベルグラフを変換（及び一般的に最適化）し、イメージをテクスチャに変換する必要がある（ＧＰＵは、計算のためにイメージではなくテクスチャを使用する）。イメージをテクスチャに変換する場合、Ｃｏｒｅ ＩｍａｇｉｎｇはＣＰＵを用いて最初にイメージをサンプラーに変換する。サンプラーは、イメージにその状態をプラスしたものであり、サンプラーへの変換は、（ｉ）透過、クランプ、又は複製などのラップモード、（ii）最も近い画素全体からサブジェクト画素までの値を使用すること、或いはサブジェクト画素を囲む４つの画素の格子間を補間するなどの補間モード、（iii）回転、スケール、スキュー、平行移動、ミラーなどのアフィン変換のような状態情報を組み入れるステップを含む。次いで、サンプラーは、ＧＰＵで使用するために容易にテクスチャに変換される。入力としてのこれらの全てに関して、Ｃｏｒｅ Ｉｍａｇｉｎｇを実行するＣＰＵは、実行時には実際の画素（上記で作成されたテクスチャによって提供される）上でフィルタを実装することになるＧＰＵプログラムを含むオブジェクトを作成する。
【００４５】
次に図５を参照し、フィルタ作成の一般的な実施例に進む。ｉＰｈｏｔｏの海岸の実施例を振り返ると、ユーザーは、ｉＰｈｏｔｏに写真の自動画質向上を要求することができる。純粋に例証の目的で、自動画質向上が以下のフィルタ作成を必要とすると仮定する。これは、現在のｉＰｈｏｔｏ画質向上機能が実際にはこのようには動作しないという点で、純粋に例証のためのものである。ｉＰｈｏｔｏは最初に、その要求のフィルタを作成する。このプロセスは、この時点ではグラフ又は画素形式とすることができる基本イメージ５１を割り当てるために、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出すことによって始める。これは、図５、高レベルグラフツリー図のステップ１で見られる。次にｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出し、プログラムステップ（及び対応するツリーポジション）を追加して、カラー補正フィルタ５２をイメージ５１に加える。これは、図５のステップ２及び高レベルグラフツリー図で見られる。図５のステップ２の出力は、プレースホルダーＣＣ（カラー補正された）の海岸として定義される点に留意されたい。この時点では、この中間段階の結果（ＣＣ海岸）が常に存在するかどうかは不確かであるので、バッファを割り当てずに、中間段階の結果の可能性を示す高レベルグラフ内にプレースホルダーを配置する。自動画質向上機能の強化において、ｉＰｈｏｔｏは、疑似色フィルタ５３を５２のフィルタリングの結果に更に加えることができる。上記のように、ｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出して、高レベル疑似色フィルタを取得し、マウントする高レベルグラフ（及び例証の目的の図５のツリー）にこれを挿入する。次に自動画質向上機能を完成させるために、ｉＰｈｏｔｏは、５３フィルタリングの結果（ＦＣ ＣＣ海岸）をオリジナルの海岸イメージ（５１）で平均化するよう選択することができ、その結果、適切なフィルタ５４をＣｏｒｅ Ｉｍａｇｉｎｇから呼出して高レベルグラフに挿入する。これは、図５のツリーグラフとサンプルプログラムステップの両方で見られる。
【００４６】
実施例において、ｉＰｈｏｔｏは今や、自動画質向上の海岸イメージの要求された結果についての高レベルグラフを有する。この実施例の実施形態によるこの結果を利用可能にするために、ｉＰｈｏｔｏは、上述のように高レベルプログラムを変換、最適化、又はコンパイルするためにＣｏｒｅ Ｉｍａｇｉｎｇのルーチンを順次呼び出すことができる（或いはＣｏｒｅ Ｉｍａｇｉｎｇは単独で動作することができる）。例証の目的において、単一の形式で表現される結果（図５に類似した）が図６に表示される。フラグメントプログラム（６２、６３、６４）は、図５に示された自動画質向上の高レベルツリーを含む高レベル事前定義フィルタに似せる必要がないことが図６で理解される。各高レベルフィルタは、その目的を果たすために１つ又はそれ以上のフラグメントプログラムを含むことができる。更に、プログラムが最適化された場合、フラグメントプログラムを置き換え、再配置、或いは削除を行うことができる。最後に、図６に示されたＧＰＵ実装は、イメージではなくテクスチャで始まり、物理的な場所（バッファ−それ以上プレースホルダーはない）に結果を配置することによって終了することが分かる。
【００４７】
４．フィルタのための設定値
上記で参照されたように、各高レベルフィルタは、上記のように作成されるか、或いは本明細書のリストで事前に定義されるかに関わらず、必要とされ且つフィルタ機能によって定義される入力値のセットを有することができる。海岸の実施例においては、一般的な入力を表すためにベクトル"パラメータ（Ｘ、Ｙ、Ｚ、Ｗ）としてこれらの入力パラメータを示した（図５を参照）。別の一般的でない実施例は、ブラーフィルタであり、入力パラメータとしてほぼ確実にブラーの半径が必要となる。更に他の実施例は、入力カラー、入力の強さ、入力飽和度などである。（コンテキストにおけるより多くの実施例のフィルタのリストを参照。）Ｃｏｒｅ ＩｍａｇｉｎｇのためのＡＰＩは、これらの入力パラメータの設定機能をプログラマ及びプログラムに必然的に提供し、イメージの予測可能な作成又は編集を可能にする。
【００４８】
ｉＰｈｏｔｏの海岸の実施例を参照すると、写真のエリアにブラーを行った。正確な入力パラメータは特定のブラーフィルタに依存することになり、ｉＰｈｏｔｏは、ブラーの半径を供給する必要性が高い。
【００４９】
５．フィルタの出力要求
１つの実施形態において、特定のフィルタに対するグラフが存在すると、プログラム又はプログラマは、そのフィルタを出力するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出すことができる。これに応じて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ジャストインタイムコンパイル、次いでＧＰＵ上での通常の実行の準備ができたオブジェクトを作成する。高レベルフィルタのこの出力は、単に未計算の又は代表的なイメージである。別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この時点でグラフの最適化或いはイメージの計算のいずれかを行うことができる。最適化には処理サイクルが必要とされ、計算は処理サイクル及びメモリを用いることになるので、多くの場合、前者の最適化の実施形態が好ましい。これらの資源は通常、イメージをコンテキストにレンダリングする必要があることを確認するまで保存するのが適切である。
【００５０】
一般的により好ましい実施形態（メモリとプロセッサ時間を節約する）においてｉＰｈｏｔｏの実施例を参照すると、ｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出して、ジャストインタイムコンパイル及び実行の準備ができた未計算イメージを生成する。
【００５１】
ａ．フィルタ出力を作成することに対する注意
多くのグラフィック処理エンジンと同様に、Ｃｏｒｅ Ｉｍａｇｉｎｇは、１つだけのカラー空間、例えば「ライトリニア」で動作するように構築される可能性が高い。従ってグラフを処理するために、幾つかの実施形態では、カラー空間をライトリニアに変換する必要があり、結果を返す前にカラー空間をその元のカラーに変換して戻さなければならない。幾つかの実施形態において、この変換は、高レベルグラフの入力と出力に適切なカラー変換高レベルフィルタを配置することによって、高レベルグラフ上で行われる。別の実施形態においては、これは、低レベルグラフ上で極めて類似の方式で行う。低レベルグラフの場合、カラー変換のための「カーネル」又はフラグメントプログラムノードは、グラフの入力と出力に配置される。ノードがグラフ（高又は低レベル）に配置されるほとんどの実施形態では、この状況は、そのカラー変換ノードの結果が今後極めて有用となる可能性が高いことを決定付ける。従って、カラー変換ノードの結果は、ほとんどの実施形態でキャッシュしなければならない。カラー変換のためのグラフノードを作成する代替の方法は、このような変換をＣｏｒｅ Ｉｍａｇｉｎｇルーチンの１つにプログラムすることである。
【００５２】
６．コンテキストへイメージをレンダリング
最終的に、ほとんどのイメージはディスプレイのような視覚的用途のために生成される。従って、イメージ生成のこの実施形態における極めて一般的なステップは、イメージをある定義されたコンテキストにレンダリングする段階を呼び出すことである。ほとんどの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この時点でグラフの最適化を実行することになる。要約すると、最適化は、以下のいずれか又は全てを含むことができ、すなわち、（１）低レベルグラフを作成する段階、ここで概念化の目的において、グラフのノードはフラグメントプログラムを表し、低レベルグラフはイメージとフラグメントプログラムとの間の関係を定義する（これは、イメージと高レベルフィルタさらにその内部関係を含む高レベルグラフと対照的である）、（２）定義ドメインに対する最適化段階、（３）関心領域に対する最適化段階、（４）フラグメントプログラムを組み合わせて、グラフのサイズ又は最終的にはその実行が必要となるメモリ空間を低減させる段階、（５）最適化された低レベルグラフの実行要件を常駐ハードウェア（ＧＰＵ、ＣＰＵ、メモリなど）と比較する段階である。最適化されると、低レベルグラフはコンパイルされ、１つ又はそれ以上の実行可能なオブジェクトが作成される。説明されたように、一般的にはＧＰＵのための１つの実行可能なオブジェクトが存在するが、最適化又はコンパイル中に、複数のプロセッサを用いることを決定することができる。コンパイル後、結果として得られたオブジェクトが実行され、イメージが指定コンテキストにレンダリングされる。
【００５３】
再度ｉＰｈｏｔｏの実施例を参照すると、画面上にイメージを配置するためには、ｉＰｈｏｔｏがＣｏｒｅ Ｉｍａｇｉｎｇを呼出し、オブジェクトを画面にレンダリングする。一般的な実施形態では、このステップは、イメージ内の関連する画素の全てに対してＧＰＵコードを実行し、拡張写真イメージを生成する段階を含む。イメージは、画面ディスプレイと関連付けられたバッファ内に該イメージを配置することによって画面上に配置される。
【００５４】
Ｅ．最適化
最適化は、タスクが実際に実行されたときに最も効率良く或いは容易に実行されるように、プログラム又はタスクを解析し変更するプロセスである。本明細書で説明されるほとんどの実施形態のコンテキストでは、１つのマイクロプロセッサを使用して別のマイクロプロセッサのためのプログラムコードを最適化するよう試みている。更に特定の実施形態において、システムＣＰＵ資源を使用して、ＧＰＵ上で実行されるプログラムを最適化しようと試みている。また更に特定の実施形態において、グラフとして表されたグラフィックタスク（通常はイメージへのエフェクトの適用）を解析したＣＰＵはグラフを最適化し、グラフがジャストインタイムコンパイルされたときにＧＰＵ上で最も効率良く実行するようにする。
【００５５】
発明者らは、汎用及び特殊コンテキストの両方で最適化及びコンパイルを説明してきた。上記の開示事項の範囲を限定することなく、最適化のための４つの異なる汎用技術のいずれか１つを含む、Ｃｏｒｅ Ｉｍａｇｉｎｇの実施形態を説明する。これらの４つの汎用技術は、中間段階の結果のキャッシング、定義ドメインに対する計算と記憶の制限、関心領域に対する計算と記憶の制限、グラフを縮小又は簡略化するためのグラフ再書き込みである。
【００５６】
最適化はＣＰＵサイクル、ＧＰＵサイクル、メモリ空間のような現実世界のアイテムにおける節約を扱うので、通常は導入した最も低いレベル（ハードウェアに最も近い）の概念例証ツールに関連した最適化技術を説明することになる。そのツールが低レベルグラフである。しかしながら、これらの技術は、概念化の単一のレベルに限定されたものと見なすべきではない。実際、これらの技術を、例示的な抽象概念の高レベルと低レベル（例えば高レベルのグラフ又はコンパイルコード）での効率を適用し実現することができる。
【００５７】
開示される最適化技術は、種々の順序及び、シーケンシャル技術が一度に１つのノードに或いはグラフのセクションに再帰的に加えられる混成順序で用いられる場合にでも有用であ。しかしながら、最も分かり易く説明するために、図７に示されるような論理シーケンシャル順序で技術を導入する。ここで図７を参照すると、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ステップ７１００でアプリケーションプログラムからグラフィックタスクを受け取る。タスクが低レベルグラフで未だ具現化されていない限り、ステップ７１０１において、Ｃｏｒｅ Ｉｍａｇｉｎｇは低レベルグラフを作成する必要がある。次にステップ７１０２で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ノード低減解析を行い、可能であればノードを除去する。不要な（又はコラプス可能な(collapsible)）ノードが最適化されるとＣｏｒｅ Ｉｍａｇｉｎｇはステップ７１０３に進み、ここでバッファのサイズとイメージ入力を最終的に制限するために最適化が行われる。このステップは、定義ドメイン（「ＤＯＤ」）と関心領域（「ＲＯＩ」）と呼ばれる２つの領域を交差する段階を含む。ＲＯＩ／ＤＯＤ最適化後、グラフは、ステップ７１０４でコンパイルをする状態にある。最後に、全てのこの上記の作業がＣＰＵ上で実行されると、プログラムは、レンダリングのためにＧＰＵに送られる（全体を通して説明したように、幾つかの実施形態では、グラフの一部をコンパイルして更にＣＰＵに送ることができる。）
【００５８】
上述の最適化技術を説明する場合、より深く理解するためにグラフにおけるノードの実施形態を用いることができる。低レベルグラフのノードに関して説明するが、この概念は、どのような類似の説明にも当てはまる。ここまでは、機能、フィルタ、フラグメントプログラムとしてノードを説明してきた。しかしながら、グラフの解析を行うためには、より具体的でより豊富な情報を有するノード表現が必要である。従って本発明の種々の実施形態では、要望又は必要に応じて、低レベルグラフノードは、以下の関連する情報すなわち（ｉ）説明されているフラグメントプログラムのようなプログラム、（ii）サンプラー（状態付きイメージ）と１つ又はそれ以上のベクトル（ベクトルは浮動小数点数の集まりであることを想起されたい）を含むプログラムのための引数、（iii）ノードの出力の定義ドメイン、（iv）出力形状が与えられた場合のノードの入力形状の正確な予測をもたらすＲＯＩ関数（両方の形状は、座標系、恐らくは同じグローバル座標系で定義される）を有する。
【００５９】
１．中間段階の結果のキャッシング
最新のコンピューティングに内在する理由から、アプリケーションプログラムは、同一又は類似のイメージの計算を何度も要求する場合が多い。アプリケーションプログラムはまた、以前に計算されたイメージのサブセット又はスーパーセットであるイメージの計算を要求する場合が多い。この理由のために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、不必要な作業をさせないためにキャッシング技術を利用する。ほとんどの実施形態において、グラフノードはキャッシュ管理のためのベースを形成する。詳細には、図５のツリーによって表されるような高レベルグラフを説明したことを想起されたい。同様に、図４や図６に示されるツリーのように概念化することができる低レベルグラフについても言及している。幾つかの実施形態において、グラフ内の各ノードは不変であり、その下のグラフの部分によって定義（すなわちノードを解くのに必要なオブジェクト及び計算）されると仮定する。このように仮定すると、発明者らはノードの結果（通常はイメージ）をキャッシュし、次いで同じノード（その下のグラフの和として定義される）が再計算される待ち行列にあるかどうかを判定することができる。ノードを再計算するのではなく、メモリから結果を単にフェッチしてもよい。種々の実施形態によれば、これは全ノードに対して行うことができる。メモリを効率的に使用するために、様々なタイミング（例えば、メモリ使用量が多い場合、又はキャッシュされた入力が古い場合、又は関連するアプリケーションプログラムがクローズした場合、又はシステムがシャットダウンした場合）でキャッシュの削除を選ぶことができる。更に、メモリを効率的に使用するために、別の記憶装置を使用することができる。ほとんどの実施形態においては、ビデオサブシステム又はＧＰＵに割り当てられたスタティックメモリ又はダイナミックメモリが主として使用されている。しかしながら、システムメモリ、ハードドライブ、或いはシステム又は場合によってはネットワークアクセス可能な記憶装置内の他の磁気メモリなど、どのようなアクセス可能な記憶装置内にこれらのキャッシュを配置するように選択してもよい。
【００６０】
種々の実施形態において、キャッシングは、最適化中（例えばＣＰＵ上で）、レンダリング中（例えばＧＰＵ上で）、又は両方のタイミングで利用することができる。
【００６１】
２．グラフを低減又は簡単化するためのグラフ再書込み
本発明の幾つかの実施形態で利用される別の効率化技術は、不要なノードを削除することによってグラフを最適化することである。成功すると、これは、一般的に一時イメージ全体及びこれに応じたバッファの必要性が排除されるので、その節約において重大な意味を持つ。更に、ノードの統合又は削除は、実行中の処理サイクルを節約することになる。
【００６２】
統合のために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、削減することのできる隣接するノードのペアを見つけなければならない。一般的に２つのノードは、１つのノードの出力が第２のノードの入力である場合には１つに減らすことができる。例えば、ノードアルファの出力がアルファバッファとして定義され、ノードベータの入力がアルファバッファに格納されたテクスチャである場合、２つのノードは結合することができる。
【００６３】
コンピューテーションサイクルの点では、２つのノードを結合できるかどうかを判定することは、比較的高コストの解析となる可能性がある。従って、２つのノードを結合できるかどうかに関する判定を行う際にその判定をキャッシュすることができる。明確にするために、幾つかの実施形態では、肯定的な結果と否定的な結果の両方をキャッシュすることで、プログラムは、キャッシュされた結合を見つけるためだけでなく、結合が不可能であるか否かを判定するためにもキャッシュを用いることができ、その結果、解析を行う時間が無駄にならないようになる。例示的な実施形態が図８に示されている。結合照会８１００の実施において、第１ステップ８１０１で、これらのノードでの解析の結果が以前に行ったものでありキャッシュに常駐しているかどうかを判定する。従って、ステップ８１０１でシステムは、事前に解析された結合結果のキャッシュをチェックする。更に、説明しているルーチンは通常ＣＰＵ上で実行しているので、このキャッシュは多くの実施形態においてシステムメモリを使用する。最後に、キャッシュにタグを付ける方法の実施例として、１つの実施形態において、キャッシュキーは４つのデータの要素、すなわち（１と２）２つのノードプログラムの表示、（３）従属ノードプログラムからの出力を受け取る上位ノードプログラムのテクスチャユニットインデックスの表示、（４）出力値を範囲０，１にクランプする必要があるかどうかを指定するブール値の表示を有する。
【００６４】
ステップ８１０１に戻ると、この決定ステップで３つの可能な経路が存在する。第１に、結果をキャッシュすることができ、ノードを結合することができる。この場合、制御はステップ８１０３に進み、キャッシュ結果を使用して結合が行われる。次いで制御はステップ８１０４に進み、次のノードを見つけて解析する。第２に、結果はキャッシュされるが、ノードは結合されない。この場合、制御は次のノードステップ８１０４に直接進む。第３に、最終的には結果はキャッシュ内に存在しない場合がある。この場合、制御はステップ８１０２に進み、提案されたノードの結合が可能であるかどうかを判定する。ステップ８１０５で示されるように、結合が可能であるか否かに関係なく、結果はキャッシュされる（結合が不可能であるか、又は結合が可能であるかを示し、結果を記憶する）。ステップ８０１２で、結合が可能である場合には、ステップ８１０６で行われるが、実際には、幾つかの実施形態では解析中に結合を行う。結合が行われた後、制御は次のノードのための８１０４に進む。最後に、結合が不可能であるとステップ８１０２が判定した場合、制御は次のノードのためのステップ８１０４に進む。
【００６５】
３．２つのノード結合の実施形態
図４及び図９を参照し、ノード４１５、４２０が結合できるか否かをＣｏｒｅ Ｉｍａｇｉｎｇが解析すると仮定する。ステップ９１００で始まると、ほとんどの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ノード４１５の出力がノード４２０の入力に事実上十分に近い場合にこれらのノードを結合しようとする。多くの実施形態において、ノード４１５の出力は、出力バッファが入力テクスチャの常駐する場所に存在するはずである点において、ノード４２０の入力と同じでなくてはならない。しかしながら、別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、このような出力と入力から正確な結果が得られ、或いは更に別の実施形態では正確に近い結果が得られるほど十分に類似しているかどうかを評価することができる。
【００６６】
決定９１００に戻り、それぞれの出力と入力が十分類似していない場合、ノードはステップ９１０３に示されるように結合されない。しかしながら、それぞれの出力と入力が十分類似している場合には、制御はステップ９１０１に進み、第２ノード（この実施例ではノード４２０）に関連したフラグメントプログラムの各ラインをチェックする。ラインチェックについては後述するが、このプロセスのレベルでは、各ラインは、ノード４１５と４２０の結合の可能性を否定しないことを確認するためにチェックされると仮定する。更に、結合を容易にするために些少の変更が幾つかのラインで行われる。従って、ステップ９１０１でのラインチェックがノード結合を否定する結果をもたらす場合には、ノード４１５、４２０は、ステップ９１０３で示されるように結合されないことになる。或いは、ステップ９１０１でのラインチェックがノード結合の可能性を継続して示す場合には、制御は、ハードウェアが結合されたノードを扱うことができるか否かを判定する、決定ステップ９１０２に進む。一般的な意味で、これは、メモリ、いずれかのマイクロプロセッサの特性、又はシステム状態などのシステム内の何らかのハードウェア制限を意味する可能性がある。更に特定の意味において、ほとんどの実施形態は、必要なルックアップ又はレジスタが多すぎるかどうかを確認するために常駐ＧＰＵの能力のチェックだけを必要とする。明らかに、（エミュレーションが使用されない場合）常駐ハードウェアがノード４１５、４２０の結合を処理できないとステップ９１０２が判定した場合には、ステップ９１０３で示されるように結合を行うことはできない。或いは、ハードウェアが結合されたノードを扱うことができるとステップ９１０２が判定した場合には、制御は、一連のタスクがノードの結合を終了し始めるステップ９１０４に進む。
【００６７】
ステップ９１０４で、ノードのためのプログラムコードが実際に連結される。ステップ９１０５で、標準的なプリコンパイラ・オプティマイザープログラムが適用される。これは、本発明の幾つかの実施形態の主題である最適化ではない。これは、容易に利用可能なプリコンパイル最適化ルーチンである。次にステップ９１０６で、レジスタを割り当てる命令が適用される。最後にステップ９１０７で、結果が今後の結合解析のためにキャッシュされる。
【００６８】
この実施例を説明する場合、第２プログラムの各ラインのチェックであるステップ９１０１に僅かな注意しか払われていなかった。ここで図１０を参照し、更に詳細にこのプロセスを調べることにする。ステップ１０１０７で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、解析のための次のプログラムラインを探す。次のラインは、第２ノード４２０を表すプログラムの第１ラインとすることができる。制御は決定ステップ１０１００に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇは、プログラムラインにローカル変数があるかどうかを判定する。このようなローカル変数がある場合、該ローカル変数は、第１プログラム（この実施例でノード４１５を表すプログラム）のローカル変数と競合しないようにリネームする必要があるので、制御はステップ１０１０１に進む。幾つかの実施形態において、全てのローカル変数は、各フラグメントプログラムにおいてゼロから始まる連続した整数で番号が付与される。従って、第２フラグメントプログラム（ノード４２０を表す）のローカル変数をリネームする際に、（１）第１の新しい名前は、第１プログラムの最も大きな番号が付けられたローカル変数に単に加算することによって得られ、（２）次のローカル変数は、基本名として第１リネームローカル変数を用いて順次名前が付けられる。
【００６９】
プログラムラインのローカル変数がリネームされると、制御は決定ステップ１０１０２に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇがプログラムラインにおいてテクスチャ基準を捜す。リネームが必要なローカル変数がない場合には、決定ステップ１０１００もステップ１０１０２に至ることは注目に値する。いずれの場合でも、決定ステップ１０１０２でＣｏｒｅ Ｉｍａｇｉｎｇは、プログラムラインにおいてあらゆるテクスチャ基準を捜す。テクスチャ基準が見つからなかった場合、制御は決定ステップ１０１０５に進む。テクスチャ基準が見つかった場合には、制御はステップ１０１０３に進み、見つかったテクスチャ基準が第１ノード（４１５）の処理のプロダクトであるかどうかを調べる。見つかったテクスチャ基準が第１ノードの処理のプロダクトでない場合、制御はステップ１０１０８に進み、必要に応じてテクスチャをリネームする。
【００７０】
見つかったテクスチャが第１ノードの処理のプロダクトであると仮定すると、制御は、ステップ１０１０３からステップ１０１０４に進み、そのテクスチャを単一の画素に置き換える。一般的な意味では、フラグメントプログラムが入力のテクスチャ全体と出力のバッファ全体を有するときには、フラグメントプログラムは一度に１つだけの画素を処理するので、１つのテクスチャを単一の画素に置き換える。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇが２つのフラグメントプログラムを結合又は連結することになる場合、これらのプログラムは、結合されたプログラムの拡張された長さ全体にわたり同じ画素を渡すために書き換える必要があり、単一の（結合又はそれ以外の）フラグメントプログラムによって生成された中間バッファは存在できない。結果として、幾つかの実施形態においてステップ１０１０４は、サブジェクト入力テクスチャに対するどのような基準も排除し、これをオペレーション中の画素を保持するレジスタ基準と置き換える段階を含む。ステップ１０１０４が終了した後、制御はステップ１０１０８に進み、必要に応じてテクスチャをリネームする。
【００７１】
テクスチャのリネームは、ローカル変数リネームと同じ原理とプロセスであるので、追加のコメントは実質上必要ではない。テクスチャリネームが行われた後、制御は決定ステップ１０１０５に進む。
【００７２】
決定ステップ１０１０５では、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レジスタによって識別された入力テクスチャの画素に対する何らかの基準をチェックする。このステップを詳細に説明するために、第２ノード（４２０）への入力テクスチャはテクスチャアルファであったと仮定する。また、テクスチャアルファは、レジスタベータの画素を優先してプログラムから書き出されたと仮定する。ステップ１０１０５で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レジスタベータに記憶された画素ではなく、テクスチャアルファの画素に対する何らかの基準を捜している。これは、２つのフラグメントプログラムの結合がテクスチャアルファ（中間イメージ）の生成を排除することになり、更に実行時において、テクスチャアルファに対するシステムだけの基準がレジスタベータ内の単一の画素になるためである。従って、第２ノード（４２０）のベースにあるプログラムがレジスタベータの画素以外の画素に対する実質的な基準を有する場合には、結合が生じることはできず、ステップ１０１０６で示されるように中止されるはずである。このような画素に対する基準が存在しない場合、プログラム制御はステップ１０１０７に進み、次のラインに移る。
【００７３】
本明細書で説明されるプログラムステップをレビューする場合、説明される機能と変更を有するコードのラインを処理するための多くの方法がある点に留意されたい。例えば、プログラムは、各ラインで一度に１つの項目を調べて特定の項目について全てのオプションにわって処理し、その後、単一のラインが終了するまで同じラインの次の項目に移ることができる。別の実施例では、プログラムは第１項目を読み取ることができ、それがローカル変数かどうかをチェックし、ローカル変数である場合これをリネームし、これがテクスチャ基準であるかどうかをチェックし、そうである場合にはこの基準が第１プログラムの出力に対するものであるかどうかをチェックし、以下同様である。重要なのは、開示された技術を考えると、熟練のプログラマであれば解析し、ラインチェックを進める方法を決定することができるということである。
【００７４】
４．定義ドメインに対する計算と記憶の制限
一般的な意味では、イメージは、これらが存在する座標系以外の何れによっても境界付けられない。ほとんどの座標系では、この「境界」は有用な制限を加えない。従って、イメージを考察する場合、発明者らはその定義ドメインを考慮することができる。イメージの定義ドメインは、イメージが定義される全ての場所の表現である（すなわち名前「定義ドメイン」）。定義ドメインに関して考察する実用的な方法は、明示的に定義され且つ透明でないイメージの全ての場所の表現としてのものである。定義ドメインの１つの実施例は、全ての不透明な画素が存在する幾何学形状である。
【００７５】
最適化技術を開発する場合、定義ドメイン（「ＤＯＤ」）は、ＤＯＤの外側の画素を計算又は描画する必要がないので魅力的である。従って、グラフを最適化する場合、ルートノード（最も高いノード、例えば図４のノード４１５）のＤＯＤを最初に計算する段階において用途がある。ルートノードのＤＯＤを有する場合、ノードの実質的な結果をその形状に交差させ、ＤＯＤの外に常駐する実質的な結果の全ての部分をレンダリングタスクと描画タスクから除去することができる。残念ながら、ノードのＤＯＤは、必ずしも利用可能ではなく、このような場合、ＤＯＤは有限とみなす必要がある。
【００７６】
一般的な意味では、ルートノードのＤＯＤは、グラフの底部から上向きに伝播させることによって計算される。図４を参照すると、リーフノード４２４、４２５、４２６、４２７、４２８、４２９から始めることによってルートノード４１５のＤＯＤを計算する。リーフノードが既に定義されているイメージを表現するので、これらは、より低いノード（実際的な問題として、リーフノードは通常、グラフでの読み取りコマンドである）に関係なくＤＯＤを有することができる。より高レベルのノードのＤＯＤは、ノードへの入力とノードが実行する機能を使用して計算される。幾つかの実施形態の実施において、システム内の各ノードタイプは、その利用可能な入力を考慮してＤＯＤを決定するための関数呼び出しを有する（これは、ノードがその出力ＤＯＤを含むことができる以前のステートメントをビューする１つの方法である）。別の実施形態において、最適化プログラムは、最適化中にＤＯＤ自体を計算する。また別の実施形態において、幾つかのノードに対するＤＯＤは最適化中に直接計算され、他のノードは、関数を呼び出すことによって間接的に計算される。例えば１つの実施形態では、簡単なノード（入力と出力の形状が同じであるノード）に対するＤＯＤを直接計算することができ、且つ難しいノード（入力と出力の形状が変わるノード）に対しては関数呼び出しを行うことができる。例証としてＤＯＤの計算を極めて要約して評価する。
【００７７】
ＤＯＤのこの計算は、解析されるノードのタイプに応じて僅かに異なる。例えば、ノード４１８の関数が単にカラー変換である場合、ノード４１７のＤＯＤは、リーフノード４２４のＤＯＤと同じになる。この同じ実施例は、入力イメージＤＯＤの形状（すなわち、範囲変更、カラー空間変換、イメージ色調）を変化させない全オペレーションに当てはまる。しかしながら、幾つかのノードは、いずれも複数の入力を有するので、或いは関数が入力ノードのＤＯＤの形状を変える（例えば、幾何学的変化）ので、計算がより複雑になる可能性がある。最初に複数のノード問題をみると、ノード４１７、４１８、４１９に対するＤＯＤは既に有しており、ノード４１６に対するＤＯＤを計算するものと仮定する。ノード４１６に対するＤＯＤは、入力ノードのＤＯＤの単純な関数であり、通常は入力ノードのＤＯＤの結合又は交差のいずれかである。結果のＤＯＤが、交差、結合、又は幾分複雑な関数であるかどうかはノードの関数に依存し、どのようなプログラマも評価しやすい。
【００７８】
ＤＯＤを計算する際、関数によって引き起こされるイメージ形状の変化は更なる検討を必要とする。これらのタイプの関数は、限定ではないが、関数の純粋なオペレーションに起因してイメージが形状を変化させるブラー（ブラー又はスケールオペレーションなど、通常ブラーはイメージをより大きくすることになる）のようなアイテムを含む。或いは、関数は、イメージを単に再配向（回転、オフセットなど）する。そのオペレーションは座標系内のロケーションを変えるだけである。いずれの場合においても、ほとんどの実施形態は、何らかの利用可能な入力に応じて出力に対するＤＯＤを呼び出す関数を要求することになる。あらゆる熟練のプログラマはこのような関数を記述することができる。
【００７９】
最後に、幾つかのノードは定義されたＤＯＤを持たないことを想起されたい。このような場合、ほとんどの実施形態は、ＤＯＤの値として無限を割り当てることになる。
【００８０】
５．関心領域に対する計算と記憶の制限
ノードに対するＤＯＤを有する場合、次に、関連するノードの関心領域（ＲＯＩ）を決定する。要約すると、関心領域は、所与の出力ＤＯＤを計算するのに必要な入力イメージの部分である。従って、各ノードはその出力上にＤＯＤを有し、各入力に対するＲＯＩを有する（グラフをビューする際に、リンク毎にＲＯＩとしてこれを概念化することができる）。ＲＯＩの実施例として、「大きな矩形」である入力イメージと「小さな矩形」である出力ＤＯＤを備えたブラーであるノード関数を仮定する。このブラー用のＲＯＩ関数は、入力イメージ「大きな矩形」のどの部分が出力ＤＯＤのブラー結果の部分を計算するのに関係するかを定義する形状を返すことになる。このＲＯＩ領域を理解することの重要性は、発明者らは単に入力イメージの関連部分を記憶する必要があるに過ぎず、中間段階の結果（及び同様に最終結果の幾つか）を記憶するためのメモリが節約され、最終的に無関係とすることができる画素にエフェクトを加える処理時間が節約されることである。例えば、リンク４６で発生するはずのバッファは、ノード２４の出力ＤＯＤとノード１７のＲＯＩの交差である関連の結果を記憶することのみ必要とし、このような交差は、最適化された結果の領域である。
【００８１】
ＤＯＤ計算のように、幾つかの実施形態の実施において、ノードのＲＯＩを決定するために関数が使用される。またＤＯＤと同様に、幾つかのＲＯＩは、これらがノード両端のリンク上に見られる値に単に同一であるので容易に決定される。例えば、リンク４５が「アルファ」のＲＯＩを有し、且つノード４１７がカラー変換である場合には、リンク４６に対するＲＯＩもアルファであるが、ノード４１７がブラーである場合には、リンク４６に対するＲＯＩを決定することは、より難しい（これは、アルファとは異なる可能性が高く、恐らくは小さい）。幾つかの実施形態において、ノードに関連する関数は、決定が難しいＲＯＩを解決するために呼び出される。別の実施形態において、最適化ルーチンは、最適化中にＲＯＩ自体を計算する。更に別の実施形態において、幾つかのリンクに対するＲＯＩは最適化中に直接計算され、他のリンクは、関数を呼び出すことによって間接的に計算される。例えば、１つの実施形態は、易しいリンク（入力と出力形状が同じリンク）に対するＲＯＩを直接計算することができ、難しいリンク（出力形状が入力形状と異なるリンク）に対し関数呼び出しを行うことができる。例証として、ＲＯＩの計算について極めて簡潔に説明することにする。
【００８２】
ＤＯＤ計算と同様に、ＲＯＩ計算はグラフツリーを介して伝播させる必要があるが、下のルートから上を意味する（ＤＯＤのように上のリーフからではない）。Ｃｏｒｅ Ｉｍａｇｉｎｇがグラフィックタスクの実行することを求められる場合、要求エンティティが出力に対するＲＯＩを提供するので、ルートノード（例えば４１５）は既知であると仮定することができる。他のＲＯＩを決定するためには、単にグラフツリーから後方へ伝播するだけである。例えば、入力／リンク４３に対するＲＯＩを計算するためには、結果における「既知の」ＲＯＩと４１５の関数とを考慮する。
【００８３】
６．ＲＯＩとＤＯＤの例示的な実施形態
上記で説明されたように、アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩを使用して高レベルグラフを構成する。これらのグラフの１つを使用するか、或いは他の手段により、アプリケーションプログラムのプログラマは、グラフィックタスクの実行をＣｏｒｅ Ｉｍａｇｉｎｇに依頼することができる。図１１（ａ）を参照し、タスクは結果ＲＯＩを描画するものであると仮定する。図１１（ｂ）を参照すると、Ｃｏｒｅ Ｉｍａｇｉｎｇに対する第１タスクは、ステップ１１１００で低レベルグラフを作成することである。低レベルグラフ（図１１（ａ）にツリーで示される）の作成にはより多く関わっているものがあるが、この実施例の目的においては、グローバルＤＯＤ（ルートノード１１６のＤＯＤ）を含む出力ＤＯＤがこのステップ１１１００の最後のノードで計算され表現されることを認識することだけが重要である。次にステップ１１１０１で、Ｃｏｒｅ ＩｍａｇｉｎｇはグローバルＤＯＤ及び結果ＲＯＩの交差を求める。便宜上、これを「結果交差」と呼ぶことにする。
【００８４】
次いで、Ｃｏｒｅ Ｉｍａｇｉｎｇは、決定ステップ１１１０２に進み、調べるべき更なるノードがあるかどうか判定する。この決定１１１０２は、熟練したプログラマには明らかである何らかの適切な方法で行うことができる。調べるべき更なるノードがない場合、プログラムは、ステップ１１１０３でこの最適化タスクを終了し、ジャストインタイムコンパイルの準備が整う。「更にノードがあるか？」決定１１１０２に戻り、最適化すべき更なるノードがある場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、次のノードの入力に対するＲＯＩを求める。ツリー歩行においてどれが次のノードであるかを決定するための種々の公知の方法があるので、ここではその話題については説明しない。
【００８５】
図１１の実施例の目的のために、ノード１１６（すなわちルートノード）に対する入力ＲＯＩを計算するタスクに関して、ノード１１６に留まり、ステップ１１１０４に留まる。上記で説明されたように、これは、直接或いは関数を呼び出すことによって決定することができる。いずれの場合も、リンク１１４、１１５に対するＲＯＩが決定され、グラフに挿入される。
【００８６】
ＲＯＩがノード１１６の入力に対して決定された後で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、決定１１１０２に戻り、クエリー「更にノードはあるか？」に答える。ノードがまだある場合、Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０４に進みノード１１５の入力ＲＯＩを決定する。ノード１１３がリーフノードであり入力を持たないので、ノード１１３についてのＲＯＩ計算はない点に留意されたい。従って、入力ＲＯＩがリンク１１８、１１２に対して決定されグラフに挿入される。
【００８７】
Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０２に戻り、更にノードがあるかどうかを判定し、ノードある場合には再度ステップ１１１０４に進み、ノード１１４に対するＲＯＩを決定する。１１２はリーフノードであり、そのため計算は必要ではない点に留意されたい。１１１に対するＲＯＩが決定されグラフに入力される。
【００８８】
制御は決定ノード１１１０２に戻り、もはやノードがないことを判定する（ノード１１１はリーフである）。Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０３に進み、終了する！
【００８９】
グラフはＲＯＩとＤＯＤに対して最適化されているが、ノードの統合やキャッシングのような他の最適化は、この上にレイヤを形成することができ、或いは同時に実行できる。
【００９０】
７．再帰的実行の実施形態
上述のように、プログラマは、種々の順序で最適化技術の編成の効率を求めることができる。しかしながら、本発明の幾つかの実施形態は、グラフの一部分だけにわたる定義シーケンスにおける技術の１つ又はそれ以上を実施する。特に、同じ（又は類似の）プログラムシーケンスは、グラフの一部分に対し一度に１つの部分を再帰的に加えることができる。この方法は、メモリ再使用及びシーケンシャル処理（ある程度までの）に対する機会を提供することによって、効率の向上を可能にする。簡単にするために、キャッシングの概念はこれらの実施形態の説明から大部分が省かれている。しかしながら、本明細書の開示事項が与えられると、当業者であれば、キャッシングステップを実装する必要がある場合を理解するであろう。
【００９１】
例証のために、図１２を参照すると、結果に到達するための本発明の再帰的実行の実施形態についてのフローチャートが示されている。別の言い方をすれば、実施例の目的はルートノードを計算することである。ステップ１２１００で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ルートノードを隣接するノードと結合しようとする。ノードが結合できる場合、そのプロセスは、各入力リンクに沿った複数のノードをルートノードにできる限り吸収するように実行される。制御はステップ１２１０１に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇは、（できる限りマージされた）ルートノードに対するＤＯＤを決定する。ＤＯＤが既知である場合、制御はステップ１２１０２に進み、ここでＲＯＩがルートノードへの子リンクについて計算される。ＲＯＩとＤＯＤを有する場合、この２つは、結果領域を決定するために交差させることができる。制御はステップ１２１０４に進み、ルートノードの入力に対するテクスチャを作成する。これらの入力テクスチャは、ルートノードをレンダリングするために必要である。しかしながら、多くの場合ノードの入力テクスチャは未計算であり、グラフによってのみ表現される。このような場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この実施例で説明されるステップに類似のステップを各従属ノード上で再帰的に処理しなければならない。従って、図１２に示されるプロセスはネストされた方式で加え、グラフを下に移動し、ルートノードを計算するために最終的には解決する必要のあるノードを解決する。別の言い方をすると、ノードを解決するためのプロセスは、ルートノードへの入力のためのテクスチャを計算するのに必要な全ノードを制御が解決するまでネストされた方式で加えられる。ルートノード入力テクスチャが計算された後で、制御は、結果に対するバッファの作成のステップ１２１０４に進む。最後に、制御はステップ１２１０５に進み、ここでＧＰＵが結果をステップ１２１０４で作成されたバッファにレンダリングするのに使用される。
【００９２】
再帰的プロセスに焦点を合わせるために、上記説明からキャッシングの概念が故意に省かれていたことを理解されたい。しかしながら、キャッシングは、ノード結果とノード結合の解析と結果を限定ではなく含む、種々の場所で利用することができる。
【００９３】
更に別の再帰的に処理される実施形態が、図１３にフローチャートで示されている。図１３を参照すると、ステップ１３１は、ルートノードの計算に取り組んでいることを示している。その際に、ステップ１３２では、ルートノードを隣接するノードと結合することが可能かどうかを判定する。ステップ１３３に従って、結合が可能である場合、結合が行われ、更なる結合が可能ではないと判定されるまで継続して結合を行う（ステップ１３１、１３２、１３３を介して）。このような判定の後で、制御は、ＤＯＤとＲＯＩ最適化のステップ１３４、１３５に進む。次に、決定ステップ１３６は、ルートノードをレンダリングすることが可能かどうかを判定する。ルートノードへの入力の全てが計算された場合のみルートノードをレンダリングすることが可能になる。従って、決定１３６への答えがノーであると仮定すると、制御は、ルートノードを求めるのに必要な紛失子テクスチャ(missing child texture)を生成するタスクのためのステップ１３１０に進む。１３１０の下の次のプロセスがルートノードを求めるプロセス全体に極めて類似していることは注目すべきである。特に、サブノードとルートノードを求めるために同じルーチンが使用される。しかしながら、これらのルーチンは、グラフの複数のノードを求めるためにネストされた方式で呼び出すことができる。或いは、これらのルーチンは、一度に幾つかのノード、関係のないグラフの偶数ノードを求めるために並行して実行することができる。
【００９４】
ここでステップ１３１１に戻り、次の子ノードを決定する必要があり、解析する次のノードを単に適切に選択する。ステップ１３１２、１３１３は、ステップ１３２、１３３に類似する。ステップ１３１４、１３１５、１３１６は、ステップ１３４、１３５、１３６に類似する。ステップ１３１７は、ステップ１３７、１３８に（略して）類似する。ステップ１３１９は、サブノードがその入力テクスチャが利用不能であるためにレンダリングできない場合、次のノード（ステップ１３１１）はネストされた演算処理で計算される可能性があることを示している。同様にステップ１３１８は、ノードが求められてレンダリングされた後にレベルをネストしていない可能性を示している。
【００９５】
最終的に、ステップ１３１１で、求めるべき子がない場合、制御はステップ１３７、１３８に進み、ここでバッファがルートノードの結果に対して形成され、ルートノードがコンテキストにレンダリングされる。
【００９６】
更に別の実施形態又は再帰的オペレーションにおいて、図４、１４を参照し、図４に示されたグラフをＣｏｒｅ Ｉｍａｇｉｎｇによって最適化及びレンダリングしなければならないと仮定する。ルートノード４１５から始めて、Ｃｏｒｅ ＩｍａｇｉｎｇはグローバルＤＯＤとのグローバルＲＯＩ交差を計算することによってステップ１４１００で開始する。制御はステップ１４１０１に進み、次のノードがあるかどうかを判定する。次のノードがない場合、処理はステップ１４１０６で示されるように完了する。しかしながら、この場合、ルートノード４１５は次のノードである。制御はステップ１４１０２に進み、入力リンク４２上のノード４１５に対する入力ＲＯＩを得る。このような入力ＲＯＩを取得すると、制御は決定１４１０３に進み、４１５／ＲＯＩの結果がキャッシュ内にあるかどうかを判定する。４１５／ＲＯＩイメージがキャッシュ内にある場合、制御は決定ブロック１４１０１に戻り、処理すべき更なるノードがあるかどうかチェックする（その結果がキャッシュ内で見つかった場合は、システムは見つけたノードの下の全グラフを処理する必要がないことを想起されたい）。この場合において、４１５／ＲＯＩの結果がキャッシュ内に存在せず、制御がバッファ割り当てステップ１４１０４に進んだと仮定する。このステップで、バッファが定義され、４１５入力ＲＯＩのサイズに割り当てることができる。次いで、制御は決定ステップ１４１０５に進み、ノード（４１５）がこの時点でレンダリングすることができるかどうかを判定する。実際には、これは、直前で定義されたバッファにノード４１５をレンダリングするコマンドとすることができる。
【００９７】
図４から分かるように、ノード４１５はルートノードであり、レンダリングする準備が整っていない。ステップ１４１０５でＹの決定を後で処理する。ノード４１５はレンダリングする準備ができていないので、制御はステップ１４１０７に進み、次の隣接するノードをノード４１５にコラプス(collapse)されるかどうかを判定する。このステップではシステムは、ノード４１５を次の隣接するノードにコラプスされる（上記で詳述されたように）かどうかを判定しなければならない。本明細書の他の場所でも説明されるように、結合決定とオペレーションは第２キャッシングシステムを含み、システムは、２つのノードをコラプスされるかどうか、その場合、コラプスの結果をルックアップすることができることができる。
【００９８】
ステップ１４１０７での決定に戻り、４１５が隣接するノードに結合できる場合には、制御はステップ１４１１２に進み、結合が行われる。次いで制御はノード１４１０１に戻り、ここで解析のための次のノードが新たに作成される４１５。結合が不可能であることをステップ１４１０７が判定した場合には、制御は決定ステップ１４１０１に戻り、解析のための次のノードを決定する。幾つかの実施形態の実施において、ステップ１４１０７での「ＮＯ」はノード４１５をそのまま残し、ステップ１４１０１への戻りは、ネストされた方式で次のノード上でルーチンを実行する。ネストは無限に深く進むことができ、最終的には次のノードステップ１４１０１でネストを解除する（一度に１つのネスト）ことによって解くことができる。
【００９９】
次にステップ１４１０１に戻り、次のノードが４２０であることを判定して、制御はステップ１４１０２に進み、ノード４２０に対する入力ＲＯＩを検索又は計算する。ＲＯＩが決定されると、制御は決定ノード１４１０３に進み、ここで４２０／ＲＯＩ結合がキャッシュ内でチェックされる。キャッシュミスがあると仮定すると、制御はステップ１４１０４に進み、バッファが割り当てられる。次いで制御は、ステップ１４１０５に進み、レンダリングが可能であるかどうかの決定を行う（この場合も実際にはこれは、単に４２０をレンダリングしようとする試みとすることができる）。図４は、ノード４２０がレンダリングできないことを示しており、その結果、制御はステップ１４１０７に進み、ノードのコラプスの可能性に関して判定する。判定がやはり否定であると仮定すると、制御はステップ１４１０１（幾つかの実施形態においてはルーチンの第２ネストのためのもの）に戻る。
【０１００】
１４１０１で、次のノードはノード４２２であると決定される。入力ＲＯＩがステップ１４１０２で求められ、制御はステップ１４１０３のキャッシュチェックに進む。ここで、ノード４２２とその下の全てが解決され記憶されるようなキャッシュヒットを有すると仮定する。次いで制御はステップ１４１０１に戻り、ここで次のノードはノード４２１になる（ノード４２０は、リンク４９に続くツリーの小さな部分によりレンダリングできないままである）。４２１に関しては、入力ＲＯＩがステップ１４１０２で求められ、決定１４１０３でのキャッシュミスを仮定する。ステップ１４１０４で、４２１ＲＯＩに対するバッファが定義され、ステップ１４１０５で、ノード４２１がレンダリングすることができることが分かる（ノード４２７、４２８はツリーリーフ又は入力イメージであるので、ノード４２１のレンダリングを妨げない）。
【０１０１】
ノード４２１をレンダリングする能力を考慮して、制御はＲＯＩ／ＤＯＤ最適化のためのステップ１４１０８に進む。ここでノード４２１の出力ＤＯＤをノード２０の入力ＲＯＩと交差させ、レンダリング中に書き込まれることになる最終のバッファのサイズを最小にする。幾つかの実施形態では、ステップ１０４で行われたバッファ設定を調整する。次いでノード４２１はコンパイラに渡され（ステップ１４１０９）、コンパイルされた結果がレンダリングされる（ステップ１４１１０）。レンダリングの後で（又はこのプロセスの幾つかのポイントで）、多くの実施形態は、バッファによって発生するメモリ使用量と、その空間を自由に又は再利用するよう設定することができるか否かを再検討することになる。この考察はステップ１４１１１において表す。
【０１０２】
制御はここでステップ１４１０１に戻り、ここでノード４２０がレンダリングの準備ができていることが最終的に判定されることになる（ステップ１４１０５）。レンダリングが上記で説明されたように行われることになり、最終的に制御は、ノード４１０の検討のためのステップ１４１０１に戻る。ノード４１０／ＲＯＩがキャッシュされると仮定すると、レンダリングは最終的には結果ノード４１５上で行われることになる。
【０１０３】
Ｆ．簡単なコードの実施例
例証として、以下は、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩが簡単な露出フィルタにどのように用いることができるかを示すコードの実施例である。
【０１０４】
【表１】
【０１０５】
同様に例証として、以下は、本発明の実施形態によるフラグメントを結合する実施例である。
【０１０６】
【表２】
【０１０７】
Ｇ．Ｃｏｒｅ Ｉｍａｇｉｎｇが作成するＣＰＵコードとＧＰＵコード
高レベルフィルタ結合をコンパイルする際に、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レンダリング中に実行するための複数のオブジェクトを生成する。Ｃｏｒｅ Ｉｍａｇｉｎｇのこの特徴は、複数の異機種プロセッサを備えたシステムに広く適用可能である。例えばこれは、ジャストインタイムコンパイルを行い、航行中の航空機で行われる天気予報計算を分割するのに有用である。ジャストインタイムコンパイルにより、効率アルゴリズムがどの処理資源を使用するかを判定する際に航空機（飛行中）の状態を考慮に入れることができる。この一般的なプロセスは、７つのステップに要約できるが、効率的なシステムでは、これらのステップのサブセット上で動作することができ、すなわち、（１）プロセッサ、コントローラ、メモリ空間などのどの資源が有功に利用可能であるかをチェックする；（２）資源の各々の能力を評価する；（３）各資源の動作状態をチェックする；（４）現在のタスクの要件を評価する；（５）利用可能な資源の一部又は全てに関してタスクの要件を解析する；（６）システム内のハードウェア使用量の全体的な効率を高めながら（一般的にはタスクによって使用される資源を低減させるが、恐らくは十分に利用されていない資源又は使用されていない資源を用いる）、タスクの要件を満たすようにソフトウェアを最適化しコンパイルする；（７）コンパイルされたコードを実行する；である。実施形態によっては、１から５までのステップを実行時又は実行前に行ってもよいが、ステップ６と７は、実行時又は実行時の近くで行う場合にプロセスにおいて最も有用である点は注目すべきである。
【０１０８】
ハードウェア能力、タスクの特性と困難度、作業の効率的な分割を決定する際のリアルタイムの状態を考慮することができるこのプロセス（全体又は短縮型）に対し実質上無限のアプリケーションが存在する。これらの実質上無限のアプリケーションにも関わらず、Ｃｏｒｅ ＩｍａｇｉｎｇがＣＰＵコードを作成する３つの一般的な理由がある。その１つは、ＣＰＵ上でＧＰＵをエミュレートするためであり、これは後で説明する。二番目の理由は、オフラインレンダリングを行うためにＣＰＵを使用することにより効率が厳しくなるためである。最後の理由は、タスクがＧＰＵのハードウェア能力を越える場合のような絶対的な必要性のためである（これも後の部分で幾分説明する）。
【０１０９】
第１及び第３の理由を他の箇所で説明するので、ここで第２の理由について実施例を提供して簡潔に説明する。複数のプロセッサに対する最も重要な恩恵は、並行して作動する能力である。アプリケーションプログラムが、フィルタリングルーチンのシリアルアプリケーションを必要とするタスクを提示する場合には、並行処理は最も容易に設定される。一例として、図１５（ａ）を参照すると、６フレームシーケンス上でシリアルに動作するＣＰＵとＧＰＵのタイミングを示すチャートが示されている。この実施例の目的のために、各フレームにシーケンシャルに加えられる２つのエフェクトがあり、ＣＰＵが第１のエフェクトを加え、ＧＰＵが第２のエフェクトを加える。ＧＰＵはフレーム１を始め、ＧＰＵはアイドル状態又は他の動作中である。第１エフェクトがフレーム１に加えられた後、フレームは、第２のエフェクトを加えるためにＧＰＵに渡される。ＧＰＵは第２のエフェクトをフレーム１に加えるときには、ＣＰＵは第１のエフェクトをフレーム２に加えている。プロセスが続行し（チャート１５（ａ）に示される）、簡単な並行処理を使用してハードウェアを極めて効率的に利用し、２つのエフェクトをストリームに迅速に加えるようになる。図１５（ｂ）と図１５（ｃ）を参照すると、４つのプロセッサ（図１５（ｂ））又は２つのプロセッサ（図１５（ｃ））のいずれかで４つのエフェクトを加えることに関する効率を伝える類似のチャートが示されている。図１５（ｃ）でのネストが多くの方法で配置され、どのような数のエフェクトをどのような数のプロセッサにも加えることができることは注目すべきである。効率は、エフェクトの適用をシリアル化することで実現される。効率は、各エフェクトに対して必要な作業がタスクを実行するプロセッサに最適である場合に更に向上させることができる。例えば図１５（ａ）で、ＣＰＵが第２エフェクトを加えるために好適である場合には、ＣＰＵとＧＰＵとの間で処理するフレームの順序が逆にされる。
【０１１０】
Ｈ．エミュレーション：Ｃｏｒｅ Ｉｍａｇｉｎｇ生成ＣＰＵコード
上記で説明されたように、過去数年の間、フレキシブルなグラフィック関連ハードウェアとソフトウェア技術は、本発明の多くの実施形態のような有用な技術のベースを発展させ提供してきた。特に、ＯｐｅｎＧＬとプログラム可能ＧＰＵなどの技術の出現は、本明細書で説明される技術革新の多くに対するツールを提供した。しかしながら、これらのツールは、必ずしも後方互換性があるものではなく、利用可能なインフラストラクチャ（例えばプログラム可能ＧＰＵ）がないため、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能の全てがあらゆるプラットフォームで実行可能な訳ではない場合がある。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇのサービスに依存するプログラマ又はプログラムが存在する場合、これらのプログラマ又はプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇのサービスの一部又は全てが利用可能でない場合に特定のプラットフォーム上で損なわれる可能性がある。
【０１１１】
実際的な実施例として、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能などを提供するためにオペレーティングシステムを設計する場合、恐らくは、本明細書の実施形態の多くで説明されるような高レベルグラフィックの呼出しを行うようにアプリケーションが設計される。しかしながら、新しいオペレーティングシステムが用いられるとしても、古いコンピュータでこれらのアプリケーションを実行しようと試みることを想定した場合には問題が生じる。具体的には、Ｃｏｒｅ Ｉｍａｇｉｎｇに対して呼び出しが行われ、ＧＰＵが通常通りにレンダリングを行う場合に問題が発生する。この理由のために、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能の全て又は最大限があらゆるプラットフォームでも利用可能にすることができるように、Ｃｏｒｅ Ｉｍａｇｉｎｇがエミュレーション機能を備えるのが有用である。
【０１１２】
従って、非常に高レベル（システム機能）であることにより、必須ではないが、エミュレータが極めて有効となるタイミングがあることを知ることができる。しかしながら、Ｃｏｒｅ Ｉｍａｇｉｎｇの従来の適用性は、この開示事項の誘因となるが、本明細書の革新性はこれに限定されない。従って、エミュレータを用いることができるより詳細な状況に関して、説明を簡潔に行うものとする。特に発明者らは、プログラム可能ＧＰＵ又はどのようなＧＰＵも無い場合のエミュレータの有用性を既に指摘した。しかしながらこれに加えて、ＧＰＵを含むシステムでもエミュレーションの有益な用途を有する場合がある。特に、問題であるのは、特定のＧＰＵの資源の限界を越える可能性があることである。例えば最新のＧＰＵでは、２０４８×２０４８を越えるイメージは一般に大きすぎる。更に、正確な結果を得るには、ＣＰＵを必要とする可能性がある（現在ＡＴＩから入手可能なような幾つかのＧＰＵは、２４ビット浮動小数点だけを使用する）。当然、特定のグラフ又はノードを求めるためにエミュレータが役立つことができる多数の他のハードウェア制限及び場合によっては低レベルのソフトウェア検討事項が存在する。
【０１１３】
１．エミュレートの決定
エミュレートを行う決定は、ホストシステムの特性とエミュレーションの事由に応じて種々のタイミングで行うことができる。例えば、プログラム可能ＧＰＵサポートがないシステムでは、ソフトウェアスイッチは適切なグラフィック呼出しをエミュレートするように構成を恒久的に設定することができる。或いは、Ｃｏｒｅ Ｉｍａｇｉｎｇが特定のタスクに対して呼び出された後でこの決定を行うことができる。この場合、タスクの特性は、常駐ＧＰＵの特定の機能を考慮するだけでなく、場合によってはプロセスの状態やハードウェア項目を考慮する。幾つかの特定の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフィック呼出しの時点でエミュレーションに関する決定を行う。このような実施形態の幾つかにおいては、エミュレーションは、常駐ＧＰＵが存在しないか、或いは常駐ＧＰＵがプログラム可能でない場合に使用される。これらの実施形態の他のものでは、グラフ最適化が少なくとも部分的に加えられた後で決定が行われ、ＧＰＵが特定のフラグメントを処理できないか、或いはこのような特定のフラグメントはＣＰＵ上でのエミュレーションにより処理する方が賢明であるかが判定される。更に別の実施形態において、エミュレートの決定は、グラフィック要求のソース又は出力のデスティネーションに依存する。これは、グラフィック要求に対する全体のシステム応答をメモリオペレーションの速度を向上させることによって改善することができるためである。例えば、Ｃｏｒｅ Ｉｍａｇｉｎｇが結果をシステムメモリにレンダリングするよう求められる場合、エミュレーションはＣＰＵ上で行われることにより、その最終的なデスティネーションは、エミュレーションに関する１つの要因である。メインメモリへのアクセスは一般的に、ＧＰＵからよりもＣＰＵからの方が高速である。同様に、ビデオＲＡＭ内のメモリオペレーションは一般にＧＰＵからの方が高速になる。従って、Ｃｏｒｅ ＩｍａｇｉｎｇがＶＲＡＭにレンダリングするよう求められる場合、これはＧＰＵを使用する傾向への要因である。
【０１１４】
２．ソフトウェアスタックでのレイヤとしてのエミュレーション
図３（ａ）、３（ｂ）を参照して、エリア３１００、３１０１におけるサービスを一般に提供するＣｏｒｅ Ｉｍａｇｉｎｇを説明した。Ｃｏｒｅ Ｉｍａｇｉｎｇエミュレータの多くの実施形態において、ＯｐｅｎＧＬ３６又は３２０のレイヤに存在するサービスに言及することができる。従って、これらの実施形態のエミュレータは、ＯｐｅｎＧＬでのほぼ同じレベルでサービスを提供する。これは、エミュレータがＯｐｅｎＧＬの下位のサービスを提供する別の実施形態との違いである。この違いは、1つには、前の実施形態がＯｐｅｎＧＬの（又は同様の状態にあるサービス）機能のサブセットだけに関するエミュレーションを提供することによって性能を達成することによって生じる。別の実施形態において、エミュレータはＯｐｅｎＧＬ（又は類似の）実装の一部とすることができる。更に別の実施形態において、エミュレータは、ＯｐｅｎＧＬ（又は類似のサービス）の下位とすることができ、より包括的な適用範囲を提供することができる。当然、これは性能を犠牲にする可能性がある。
【０１１５】
本発明のエミュレータ実施形態の説明の際に、実施形態の２つのセットに関する更に具体的な説明を行うものとする。実施形態の１つのセットは、ＧＰＵプログラム（例えばフラグメントプログラム）をターゲットの１つ又は複数のＣＰＵのための機械コードに直接コンパイルする段階を含む。実施形態の第２のセットは、各ＧＰＵ命令が高レベルプログラミング言語（３のような）における関数によってモデル化されるバイトコード仮想マシンを含む。実施形態のいずれのタイプにおいても、必須ではないが、低レベルグラフから始めるのが好ましい。更に、上記で説明されたようなグラフ最適化は、ノード、メモリ、計算を低減させることができるので、やはり最適化されたグラフから始めるのが好ましい。エミュレータはノードの一部とすることができるフラグメントプログラムで動作するので、エミュレータタスクは、上記で説明されたグラフウォーキングと解像技術の下位にレイヤされるものと見なすことができる。
【０１１６】
Ｉ．ＧＰＵプログラムの機械コードへの直接コンパイル
エミュレートの決定が行われると、多くの実施形態は、ＣＰＵ対応プログラムの以下の汎用プロセスを使用する。上記の説明から、ＧＰＵコードによる開始を仮定することは明らかなはずである。更に詳細には、これは通常、グラフのノードに関連付けられたフラグメントプログラムとすることができる。各フラグメントプログラムは、１つ又はそれ以上のＧＰＵ命令を有する。（これらはラインと呼ぶ場合がある。）次いでプログラムの各ラインは、ＣＰＵ等価命令に翻訳される。追加命令を含むラインのような多くのラインは、単一の命令ＣＰＵ均等物を有することができる。他のラインは、フラグメントコードの単一のラインが複数のＣＰＵ命令に翻訳する必要がある点で高度なエミュレーションを必要とする。翻訳のいずれかのタイプ（１対１又は１対多）は、熟練したプログラマが理解できるどのような種類の方式でも達成することができる。１つの好ましい実施形態において、命令翻訳は、大きな「ｉｆ」文によって行われる。別の実施形態において、テーブルやルックアップは、ＧＰＵ命令を等価の１つ又はそれ以上のＣＰＵ命令に位置合わせするために使用される。
【０１１７】
翻訳ステップ中、ＧＰＵコードは、どのようなレベルのＧＰＵ命令からもあらゆるレベルのＣＰＵ命令に翻訳することができる。例えば、翻訳はＧＰＵアセンブリからＣＰＵアセンブリに行うことができる。１つの好ましい実施形態において、翻訳は、ＧＰＵアセンブリと、現行の実装ではバイナリであるＣＰＵ機械コードとの間で行われる。
【０１１８】
プログラムがＣＰＵ命令として表現されると、コードをアンロール（展開）することができる。コードアンローリングと最終的な命令スケジューリングは、命令レベル並行処理（「ＩＬＰ」）を利用するかなり標準的な最適化技術である。ＩＬＰの一般的な目的は、ソフトウェア命令によって利用されるハードウェア並行処理の量を増大させることである。これが達成される１つの方法は、性能を最大にするために命令を再配置することである。更に具体的には、相互依存のない命令のグループを並行して実行することができる。ループアンローリングは、ＩＬＰ技術のクラスであり、ループに固有の並行処理を用いることによって効率が向上する。これは、単一のフラグメント、或いは詳細にはそのＣＰＵエミュレート等価物が多数の画素を解像するために極めて多くのループを実行する（１つの画素につき１ループ）ことになるので、グラフィックオペレーションにおいては重要である。ループアンローリングでは、ループのｎインスタンスがアンロールされ、すなわち、ループコードのｎインスタンスがプログラムラインに書き込まれる（例えば、ループに１０のラインがあり、ｎが４である場合、４０ラインのアンロールドコードがあることになる）。最後に、アンロールドコードは、この形式で実行するようにセットアップする必要があり、これは、変数のインクリメントやループを再始動させるブランチ又はｇｏｔｏコマンドへの調整が必要となる場合があることを意味している。アンローリング後、次にプログラムスケジューリングを使用して、サブジェクトハードウェアでの最大並行処理のためアンロールドコードを最適化する。アンロールドコードが最終的に実行される場合、オリジナルループの回数のｎ分の１だけのループを必要とし、各新しいループは遙かに少ない機能停止事象で実行される。
【０１１９】
アンロールされると、コード上での次の３つのステップは、標準的な最適化、レジスタ割り当て、プログラム／命令スケジューリングである。熟練したプログラマであれば、これらのステップの全てをどのように実行するかを理解するであろうが、ごく簡潔な説明を行う。この説明は網羅的或いは排他的ではない。言及されない多くの技術が存在することができる。更に、言及する技術の全てが提示するカテゴリの下で行われない場合もある。標準的なプログラム最適化は、コード短縮や重複除去などの多くの技術によって時間とメモリ性能を向上させることを目的としている。レジスタ割り当ては、競合を避け、使用されるレジスタの数を最小にし、出力エフェクトのない命令を拒否するように実行される。最後に、プログラム／命令スケジューリングは、特定のハードウェアのパイプライン及び並行処理のためのコードを最適化する。
【０１２０】
この時点までに多くを達成している場合、コードは今後このようにキャッシュされるので、この作業は不要である。
【０１２１】
１．特定の実施例の実施形態
図１６を参照すると、本発明のエミュレータの実施形態のサンプルプログラムフローが示されている。プログラムフロー及び説明は、例証のためだけのものとする。実際の実施形態は、フラットなフローチャートでは容易に説明できないオブジェクト指向手法を用いることができる。
【０１２２】
ステップ１６１を参照すると、プログラムは、通常多角形として境界付けられるイメージのレンダリング又は生成を要求するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出す。制御は決定１６２に進み、ここでエミュレータを利用する必要があるかどうかが判定される。エミュレータが利用されない場合、この例の目的において、制御はステップ１６４に進み終了する。勿論、開示事項は他の場所でエミュレーションに対する代替形態を説明する。
【０１２３】
エミュレーションを利用するための考慮事項について上記で説明したが、ステップ１６２がエミュレータを使用することを決定し、制御はステップ１６３に進み、ここでデータがＣｏｒｅ Ｉｍａｇｉｎｇの他のルーチンからエミュレータにプッシュされると仮定する。詳細には、このデータは、サブジェクトフラグメントプログラム、フラグメントプログラムをレンダリングするのに必要なテクスチャ、ローカル変数、状態である。これらの項目がエミュレータに利用可能になった後、制御は決定１６５に進み、ＣＰＵ機械コードがこのタスクのために既に作成されたかどうかを調べる。フラグメントプログラムは、キャッシュへのインデックスとして使用される。しかしながら、キャッシュを実装するための種々の方法がある。ある実施形態においては、キャッシュルックアップは、必要なデータの全てについてのフォーマットを含むことができる。例えばキャッシュは、出力の画素フォーマット（１画素につき３２ビット、ＲＧＢＡなど）、／又は各テクスチャの画素フォーマットや状態などの情報を記憶しているテーブルから入力することができる。
【０１２４】
決定１６５に戻り、キャッシュヒットがある場合、制御はステップ１６９にスキップする。例証を完全にするために、キャッシュミスを想定すると、制御は、ＧＰＵフラグメントコードをＣＰＵコードへ変換するステップ１６７に進む。この変換のための技術は上記で説明されているので、この課題に対しては簡潔に対応する。ほとんどの実施形態において、このステップ１６７は、変換、アンロール、標準的な最適化、レジスタ割り当て、プログラム／命令スケジューリングの全てを行う。しかしながら、別の実施形態は、どのステップが既に完了しているかに応じて、多少の機能を実行することができる。同様の注意点が次のステップ１６８にあてはまり、ここでＣＰＵコード結果がキャッシュされる。ほとんどの実施形態はバイナリ機械コードをキャッシュし、熟練のプログラマであればより少なく処理された結果をキャッシュする事由を理解することができるであろう。
【０１２５】
ここでステップ１６９に移ると、機械コードは、画素評価のためのＮ長ループに配置される。このループのジョブは、Ｌ画素を評価することである。好ましい実施形態において、Ｌは１２８である。本明細書で説明される本発明はＬのほぼどのような値にもあてはまり、本発明者らは、その実施において１２８のＬ値が種々の検討事項（テクスチャルックアップによって引き起こされたより大きなオーバーヘッドによって、部分的なブロックを扱うことによって一度に多くの画素を処理したいという要求）のバランスをとる際の最適な性能をもたらすことが分かった。従って、ステップ１６９のループがＬ画素を評価することである場合、アンロールドコードは、ＬをＮで除算したものに等しい回数分ループしなければならず、ここでＮは、アンロールドコードで表現されるループの反復数である。最終的にはＮはＬ／ｎに等しい。従って、全ループにつき１２８画素の好ましい実施形態が利用され、４つのアンロールド反復を想定する場合、アンロールドコードを３２回ループしなければならない。
【０１２６】
ここでステップ１６１０に移ると、エミュレータによりスラブが生成される。好ましい実施形態において、これは関数呼び出しにより達成することができる。用語「スラブ」は、グラフィックアートにおいて比較的一般的な意味で使用される。しかしながらこの実施形態においては、スラブは、出力多角形上の全頂点で水平線を引くことによって形成される。例えば図１７を参照すると、図１７（ａ）には傾いた矩形とスラブに分割された同様の傾いた矩形が示されている。図１７（ｂ）では、同じ関係を有する２つの台形を示しており、一方は描かれたスラブを伴って示されている。
【０１２７】
スラブが生成された後、制御はレンダリングのためのステップ１６１１に進む。好ましい実施形態において、スラブは一度に１つレンダリングされる。特に、各スラブは、スラブの走査線上で見られるＬの連続した画素上で、ステップ１６９で作成された画素ループを実行することによってレンダリングされる。更に詳細には、多角形は、（ｉ）第１スラブを選択する段階（Ｘ、Ｙ、Ｚグローバル座標系を想定し、好ましい実施形態ではセクションが最も小さな値から最も大きなＹ値に進むことができる）；（ii）このような第１スラブ上で第１走査線を選択する段階（Ｘ、Ｙ、Ｚグローバル座標系を想定し、好ましい実施形態ではセクションは最も小さな値から最も大きなＹ値に進むことができる）；（iii）ステップ１６９で作成されたループを使用して走査線の第１のＬ画素をレンダリングし、次いで走査線が全てレンダリングされるまでこのステップを繰り返す段階；（iv）スラブ内の全走査線が終了するまで次の走査線（Ｌ画素の部分を含む）に進む段階；（ｖ）同様の方法で全ての後続のスラブを完了する段階によってレンダリングされる。更に、Ｌ画素のＣｏｒｅ Ｉｍａｇｉｎｇの選択がサービス要求者（例えばアプリケーションプログラム）に任されるので、幾つかの実施形態では、レンダリングされた結果を１つ又はそれ以上のバッファに一度に１画素ずつ書き出す。次いで、最終的な結果が、望ましいピースで要求デスティネーション内に配置することができる。例えば、結果は、Ｌ画素の終了後、或いは全部分（スラブのような）の終了後、或いは全多角形の終了後に要求デスティネーションに移動させることができる。この追加のステップはまた、フォーマット変換（バッファと要求されるデスティネーション間）のようなどのような後処理に対しても好都合な場所を作成する。
【０１２８】
走査線全体に渡るレンダリングを説明する際に、画素カウントがＬの倍数でない走査線の処理に関する疑問が生じる可能性がある。熟練したプログラマは、このケースを実施するための種々の方法を考案することができるが、本発明の幾つかの実施形態では、図１６に示されるプロセスのフレームワーク内でこの問題を考慮する。１つの特定の実施例では、ステップ１６９の画素ループは、ある変数（例えばアルファ）に従って何度もループする。従って、１２８画素でループが４回アンロールされる場合、アルファは３２になる。しかしながら、４８画素しかない場合（例えば、走査線全体で１２８ビットの数グループを処理した後）、アルファは１２に設定することができる。或いは、６６画素の場合、アルファは、第１の６４画素の処理のために１６に設定することができ、次にアルファは６５番目の画素と６６番目の画素を処理するために１に設定される。要約すると、これらの実施形態は、ルーピングを制御するために変数を使用すること、様々な量の画素を処理するためにその変数を調整することを必要とする。
【０１２９】
Ｌ画素の非倍数を処理するための別の方法は、様々な量の画素に対しアンロールドコードセグメントを提供する。例えば、メインループが４アンロールドセグメントを有する場合、３つのアンロールドセグメント、２つのアンロールドセグメント、１つのアンロールドセグメントで作成されたコードも存在する。従って、３つの画素がある場合、３画素コードを使用できる。１つの画素がある場合、１画素コードを使用できる。
【０１３０】
前述の技術を組み合わせた実施形態もある。例えば６６画素がある場合、アルファは、最初の６４画素を処理するために１６に設定され、次いで２画素コードを６５番目と６６番目の画素を処理するために実行される。或いは、６７画素の場合、アルファは、最初の６４画素を処理するために１６に設定され、次いで１画素コードを６５番目、６６番目、６７番目の画素を処理するために３回実行される。
【０１３１】
２．スラブ
多くの実施形態がスラブを使用する。スラブの代わりとして、説明された同じ方法で全多角形をレンダリングすることができる。しかしながら、スラブは、テクスチャ計算において有意な利点を提供する。特に、出力多角形の頂点に対してテクスチャ座標が知られている。ほとんどの実施形態において、これは、上にあるレイヤ（例えばグラフオプティマイザ）がこの情報を提供することによる。しかしながら、通常ハードウェアは、その基本ユニット多角形（一般に三角形）の頂点を関連するテクスチャマップにマップすることができ、ハードウェアの基本ユニット多角形の頂点は、出力多角形の頂点と一致しなければならない。図１７（ａ）、図１７（ｂ）を参照すると、これらの頂点は、円形のドットで示されている。図１７（ａ）、図１７（ｂ）を再度参照すると、スラブが形成される場合、スラブは通常、オリジナルの多角形上の頂点ではない１つ又はそれ以上の頂点を含む。図１７の全てにおいて、これらの「新しい」頂点は三角形で示されている。従って、１つ又はそれ以上の実施形態において、スラブが形成されると、新しい頂点のテクスチャ値（図１７の三角形）を種々の技術によって計算する。幾つかの実施形態では、既知の多角形頂点から座標値を補間することによって新しい頂点のテクスチャ座標を計算する。好ましい実施形態において、直線補間を用いて、分割スラブの端部まで補間される。その結果、各スラブは、既知のテクスチャ座標で３つ又は４つの頂点を有する。スラブの頂点での３つ又は４つの既知の座標で、スラブ上のどの画素のテクスチャ値も、補間、又はより詳細には直線補間のような数学的手法によって求めることができる。
【０１３２】
最終的に、スラブは多角形より小さいので、スラブはテクスチャ値の極めて容易な計算を提供する。詳細には、ここまで説明されたように、スラブは結果として得られる多角形の一部を含み、三角形又は４つの側面を有する多角形のいずれかとして生じる。三角形の場合、全頂点についてテクスチャ座標が既知であると、いずれのポイントの座標（及び最終的には値）も数学的（例えば、補間又は直線補間）に計算することができる。更に、スラブが多角形である場合、プログラムは、複数の数学的手法を使用して、多角形の点のテクスチャ座標を考案することができる。例えば、幾つかの実施形態ではプログラムは３つの頂点を選択し、直線補間を実行する。
【０１３３】
スラブの利点は、種々の形状によって実現される。例えば幾つかの実施形態において、結果として得られる多角形は、レンダリングのため全て三角形に分割することができる。これは、常に３つの頂点だけが存在するという点でテクスチャルックアップを簡素化することができる。従って、４つの側面がある多角形のどの３つの頂点を補間のため使用すればよいかに関して決定する必要性がない。更に、熟練したプログラマであれば本明細書で教示されている概念を他の方式に適用することができ、これによって結果として得られる多角形は、レンダリングのために分割される。
【０１３４】
３．テクスチャルックアップ
例えばスラブや多角形の頂点のコンテキストにおいてテクスチャルックアップを説明した。ここで、開示されてきた実施形態の幾つかに効率的にテクスチャルックアップを組み込む方法に関してより詳細に説明する。最初に、テクスチャルックアップの２つの関連するタイプを述べ、次に前述の説明に類似する可能性のあるコンテキストを提供することによって、この詳細な説明の裏付けを与える必要がある。
【０１３５】
エミュレーションタスクにおいて、遭遇する可能性のあるテクスチャルックアップの２つの一般的なタイプがある。公知のテクスチャへの座標である独立したテクスチャルックアップがある。例えば独立したテクスチャルックアップは、既知のテクスチャでの所与の座標を参照するコードにおける場所である。或いは、ある他の項目又は事象に依存するテクスチャルックアップである従属テクスチャルックアップが存在し、そのため、座標は通常レジスタ内にプログラムによって配置される。例えば、これは、所与のテクスチャへの座標がレジスタ内で見られるコードの場所とすることができる。テクスチャルックアップは、レジスタを読み込むことができるある他のオペレーションの結果に依存する。
【０１３６】
テクスチャルックアップ技術のためのコンテキストを設定する場合、種々の実施形態のために説明されたエミュレータのメインループ内の動作をより詳細に調べる。詳細には、これは一般に１６９のような図１６に関して説明するループに類似している。この類似性及び図１６を参照することによって、ステップ１６９でループをセットアップする際に、１２８画素の処理に影響を与えるためにループ内にアンロールドコードを単に配置する以外に達成すべきことがある。特に、画素の各グループ（スラブ、走査線、又は好ましくはＬ或いは画素の残りのグループ）について、コードをセットアップしなければならない。上記で説明されたように、コードのセットアップの部分は、走査線が１２８の倍数でない画素長（Ｌ）を含む場合、コードは残りの画素を考慮に入れることができるものとすることができる。更に、コードは、テクスチャルックアップに対しセットアップすることができる。
【０１３７】
ここで、テクスチャルックアップのサブジェクトに直接的を絞ると、エミュレータの好ましい実施形態は、テクスチャルックアップのメインループをセットアップする。１つの実施形態において、このようなセットアップは、Ｌ画素毎に行われ、独立と従属テクスチャ基準に対して別々にセットアップする段階を含む。これらの実施形態では、セットアップ中に各独立したテクスチャ基準は、好ましくは同じステップでルックアップされる。また、各従属テクスチャ基準では、従属性が満たされた後でルックアップを行うためにコード中に関数が挿入される。理解し易いように、関数呼出しは、各ルックアップに対してコードに挿入される。関数は、プログラムでの従属テクスチャ基準によってアクセスされるまで、テクスチャユニット毎に作成される。テクスチャルックアップ関数に渡される唯一の値は、ルックアップのための座標と使用するテクスチャである。更に正確には、コードのこの挿入された部分は、ループの外側で呼び出すことができ、このような関数は、本質的にＧＰＵテクスチャルックアップ機能をエミュレートする。１つの好ましい実施形態において、ループ内部からの関数呼出しは、テクスチャ、状態、座標を渡し、関数はベクトルを返す。しかしながらこの関数呼出しは、他の方法で実装してもよい。
【０１３８】
４．セットアップ
発明者らは既に幾度もコードのセットアップを説明してきたが、幾つかの例示的な実施形態を提供する。例えば、所与の実施形態において、各多角形についてセットアップされるコードの部分と、各スラブのためにセットアップされる部分、各走査線のセットアップの部分と、各画素グループ（例えば、Ｌ又は残りのグループ）に対してセットアップされる部分が存在することができる。所与のセットアップでの種々のアクティビティは、本明細書での他の説明から外挿することができる。
【０１３９】
Ｊ．複数のＣＰＵ
前述の実施例に類似する技術に従う実施形態は、複数のＣＰＵに極めて良好に適合する。これは、ステップ１６９（図１６）で作成されたループ機械コードが種々のスラブ又は種々の多角形上で別々のインスタンスにおいて実行できるためである。特に、Ｃｏｒｅ Ｉｍａｇｉｎｇ又は別の適切なプログラムは、プロセッサ間でタスクを分割することによってマルチプロセッサシステム上でのグラフィックレンダリングの速度を大幅に高めることができる。好ましい実施形態において、各プロセッサに送られることになるタスクのインクリメントは、スラブ（又は他の細分化されたもの）である。しかしながら、インクリメントは、より小さいもの（例えば走査線）又はより大きいもの（例えば全多角形）であってもよい。
【０１４０】
Ｋ．バイトコード化仮想マシン
仮想マシンはまた、ＣＰＵ上でＧＰＵコードをエミュレートするのに用いることができる。仮想マシンは、命令を受け取りプロセッサ資源を別のプロセッサにエミュレートすることができる点で、ハードウェアのように動作するプロセスである。一般的な意味で、仮想マシンエミュレータソリューションの利点は、仮想マシンがよりポータブルであることである。特に、仮想マシンは高レベル言語で記述することができ、次いでどのようなプラットフォームにもコンパイルすることができる。或いは、ＧＰＵプログラムを機械コードにコンパイルする実施形態は、各ハードウェアプラットフォーム用に特注とすることができる。
【０１４１】
１つの好ましい実施形態では、本発明は、バイトコード仮想マシンエミュレータを必要とする。形容詞「バイトコード」は、コンパイルされたコード、或いは幾つかの実施形態の場合においてハードウェアが受け入れるものに類似した低レベルのコードを仮想マシンプロセスが受け入れる意味が付加される。高レベルでは、仮想マシンは、ＧＰＵ対機械コードエミュレータを説明する実施形態でのＣＰＵに類似している可能性がある。より詳細には、仮想マシンは、上記で説明されたより高レベルの機能と技術の下に存在しているものとして概念化できる。従って、上記で説明されたエミュレーションや他の方法と技術の全ては、開示される仮想マシンエミュレータに類似しこれに適用することができる。しかしながら、独立した考慮事項に値する仮想マシン実施形態の興味深い態様がある。
【０１４２】
１つの実施形態において、仮想マシンは、出力画素を構築するための極めて大きな仮想レジスタを含む。特にハードウェアの制約が無ければ、仮想マシンは、効率などの他の基準の要求を満たすレジスタサイジングを使用することができる。従って幾つかの実施形態において、仮想マシンは、Ｌ画素幅である画素のレジスタをセットアップすることになる（走査線に沿って処理される１２８画素の実施例に戻り参照されたい）。レジスタのこの幅は、メインループ処理のための多くのオプションを提供する。一方の極端では、レジスタは、一度に（単一の画素ループ）処理される１つの画素を備える出力バッファとして機能する。他の極端では、メインループの各ステップは、次のステップに移る前に各画素で影響を受ける（これは、完全にループをアンロールすることに類似する）。これらの極端間のバランスをとるために、幾つかの実施形態では、従属問題を生じさせることなく概念的に出来るだけ多くループをアンロールするように仮想マシンを実装する。システムの考慮事項に応じて、画素レジスタは、Ｌの倍数又はＬの分数とすることができる。更に画素レジスタは、走査線のサイズ又は多角形動作セグメント（スラブなど）のサイズを一致させるように動的に実装される。
【０１４３】
実際にエミュレータの実施形態が実行しているとき、その実施形態は高いレイヤからの命令を受け取る。これはＣｏｒｅ Ｉｍａｇｉｎｇのより高いレイヤであるのが好ましい。概念的には命令はどのレベルのものでもよいが、好ましい実施形態では、命令はバイトコードなどの低レベルである。次いで、仮想マシンは、命令をＣＰＵのためのタスクに変換しなければならない。このような変換の第１部分は、ＣＰＵ認識可能命令への直接変換を行う「ｉｆ」文又はジャンプテーブルである。１つの好ましい実施形態において、仮想マシンは、Ｃ関数のようにＧＰＵ命令をモデル化する。このタイプの実施形態では、エミュレートされる各ＧＰＵ命令はＣ関数に相当する。次いで、Ｃ関数は、通常のコンパイラでＣＰＵ認識可能コードに変換される。ごく一般的には、好ましい実施形態において各エミュレートされたＧＰＵ命令は、Ｃ言語などの高レベル言語でモデル化される。高レベルモデルがコンパイルされ、その結果が、仮想マシンエミュレータのオペレーション中に使用されることになるジャンプテーブルの「ｉｆ」文に組み込まれる。最後に、エミュレーション中の要素（画素など）上で動作する場合、ＣＰＵベクトルレジスタは、ベクトルを記憶するために使用することができるのが好ましい。
【０１４４】
Ｌ．機能のサブセットのエミュレーティング
性能を得るために、多くの実施形態では全ての利用可能な低レベルグラフィック呼出しをエミュレートしない。一般に、利用可能なグラフィック命令のサブセットだけをエミュレートすることによって、サポートされる呼出しについてのより多くの想定が実装により行われ、従って幾つかの偶発事象が回避され、これによって作業を短縮することができる。例えば幾つかの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、透視用法の正確な補間に対し必要ではない。特にＯｐｅｎＧＬは通常、１つの補間されたテクスチャ座標あたりの画素毎に少なくとも１つの分割命令を必要とする。分割は、コンピュータ的に極めて高コストであり、Ｃｏｒｅ Ｉｍａｇｉｎｇのこれらの実施形態が透視図を持たないので、分割は必要ではない。オペレーションのサブセットだけをサポートすることによって向上する性能の別の実施例は、Ｃｏｒｅ Ｉｍａｇｉｎｇの幾つかの実施形態が少数のテクスチャフォーマットとデスティネーションフォーマットだけをサポートものである。これはデータ変換を制限し、より容易なインラインコード作成を可能にする。
【０１４５】
機能のサブセットだけをサポートする実施例として、１つの実施形態においてエミュレータは、（ｉ）４つの側面を持つ多角形の描画；（ii）テクスチャ結合；（iii）プログラム結合；（iv）ローカル変数の設定；及び（ｖ）デスティネーション設定などのＯｐｅｎＧＬの機能のサブセットだけをサポートする。
【０１４６】
この簡潔にされたタイプのサポートを実際に適用するための幾つかの方法がある。第一に、定義された高レベルＡＰＩは、エミュレートできないコマンドを受け取る可能性がないようにこれらの機能だけをサポートすることができる。例えば、Ｃｏｒｅ Ｉｍａｇｉｎｇが機能のサブセットだけをサポートする場合、Ｃｏｒｅ Ｉｍａｇｉｎｇエミュレータはこれ以上をサポートする必要はない。この場合、プログラム又はプログラマがサポートされていないグラフィック呼出しを使用したい場合には、ＯｐｅｎＧＬへの直接呼出し、又はＧＰＵの直接利用などといった、別のメカニズムを介してこれを行わなければならない。或いは、１つのエミュレーション技術は、エミュレートされる機能のサブセット（又はある別のサブセット）のために使用でき、別の技術は、全ての他のグラフィック呼出しのために使用できる。例えば、５つのエミュレートされた機能は、ＧＰＵ対機械技術を使用する実施形態を介してエミュレートすることができ、他の機能は、仮想マシン実施形態を通じてエミュレートすることができる。この構成は、最も一般的なグラフィック呼出し関する最高の性能を可能にし、他の呼出しをサポートするためのより容易なポータビリティとプログラミングを可能にする。勿論、この分割は、呼出しをサービスする難易度、又はそれぞれの技術による呼出しサービスの適性などの他の基準に沿って設けることができる。更に、２つのセットの技術（仮想マシン及びＣＰＵ対機械）は、システム内の全体のグラフィック機能の１つ又はそれ以上のサブセットを実装するための分担を同様に分けることができる。
【０１４７】
Ｍ．サンプルフィルタリスト
本明細書の種々の箇所で、フィルタの例証的なリストに言及してきた。以下の多くのページは、そのリストに充てられる。このリスト及び添付のパラメータは例証として、説明を完全にするために提供される。上記の発明の本発明者らの実装に関して、リストされたフィルタの各々を使用又は修正してもよく、或いは使用又は修正しなくてもよい。更に、より多くのフィルタを作成することができ、これらは、開示されたものとはかなり異なる場合がある。
【０１４８】
【表３】
【０１４９】
以下の同時申請出願、すなわち、同時申請のＭａｒｋ Ｚｉｍｍｅｒによる「ＩＭＰＲＯＶＥＤ ＢＬＵＲ ＣＯＭＰＵＴＡＴＩＯＮ ＡＬＧＯＲＩＴＨＭ（改良型ブラー計算アルゴリズム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒによる「ＳＹＳＴＥＭ ＦＯＲ ＥＭＵＬＡＴＩＮＧ ＧＲＡＰＨＩＣＳ ＯＰＥＲＡＴＩＯＮＳ（グラフィックオペレーションをエミュレートするためのシステム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒ、Ｍａｒｋ Ｚｉｍｍｅｒ、Ｒａｌｐｈ Ｂｒｕｎｎｅｒ、Ｐｅｔｅｒ Ｇｒａｆｆａｇｎｉｎｏによる「ＳＹＳＴＥＭ ＦＯＲ ＯＰＴＩＭＩＺＩＮＧ ＧＲＡＰＨＩＣＳ ＯＰＥＲＡＴＩＯＮＳ（グラフィックオペレーションを最適化するためのシステム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒによる「ＳＹＳＴＥＭ ＦＯＲ ＲＥＤＵＣＩＮＧ ＴＨＥ ＮＵＭＢＥＲ ＯＦ ＰＲＯＧＲＡＭＳ ＮＥＣＥＳＳＡＲＹ ＴＯ ＲＥＮＤＥＲ ＡＮ ＩＭＡＧＥ（イメージをレンダリングするために必要なプログラムの数を低減させるためのシステム）」は、引用により本明細書に組み込まれる。
【技術分野】
【０００１】
ここ数年にわたって、全ての種類のハードウェアにおいてグラフィックサブシステムが重要となる需要が増えてきた。例えば、汎用コンピュータ関連分野において、プレゼンテーションソフトウェアのような従来からの日常的なプログラムでさえ、より高速でより複雑な図形処理機能を必要とするアニメーションや他のツールが含まれている。更に、ビデオ、写真編集、ゲームのような従来のグラフィック性が強いアプリケーションは、適用範囲とグラフィック強度の両方で成長しつつある。更に、ゲームやグラフィック専用演算処理のような垂直システム（例えば、任天堂ゲームキューブなど）では、グラフィックの優位性に関して、汎用コンピューティングアーキテクチャとの高速駆動の競争が加速してきた。
【背景技術】
【０００２】
これと同じ期間に、ハードウェア製造業者は、増大する一方の容量を備えた専用グラフィックプロセッサに関して高まる需要を満たし、これを越えようと努めてきた。現在では、プログラム可能な幾つかの市販されているグラフィックス・プロセッシング・ユニット（ＧＰＵ）がある。プログラム可能ＧＰＵや非プログラム可能ＧＰＵの両方がグラフィック計算において高速化をもたらすが、プログラム可能ＧＰＵは、高い柔軟性を提供する点で異なっている。例えば、プログラム可能ＧＰＵ以前には、アプリケーションプログラマは、より興味深いグラフィックをレンダリングするためにＣＰＵ時間を消費するか、又は理想的ではないグラフィックを表示する代償として全体のアプリケーション性能を向上させるためにＧＰＵを使用するか、そのいずれかを判断していた。プログラム可能ＧＰＵは、従来のＧＰＵの速度上の利点とかなりの程度の柔軟性とを組み合わせたものである。実際の問題として、プログラム可能であることは、システムマイクロプロセッサに類似する方法でプログラムがグラフィックチップを利用可能となるので重要な利点である。このようにＧＰＵを使用することによって、本システムは、システムＣＰＵをロードすることなく事実上無限のグラフィックエフェクトを生成することができる。
【０００３】
プログラム可能ＧＰＵは、一般的にフラグメントプログラムと呼ばれるプログラムを実行する。「フラグメント」プログラムという名称は、動作しているデータの単位が一般に画素−すなわちイメージのフラグメントであることに由来する。ＧＰＵは、同時に幾つかの画素上でフラグメントプログラムを実行し、一般的には常駐するバッファの名称で呼ばれる結果をもたらす。ＧＰＵは、画素の集合に類似した一般にテクスチャと呼ばれるデータ入力を使用する。
【０００４】
また、ＧＰＵが企図され開発された同じ期間中に、グラフィック専用ハードウェアの使用を求めるアプリケーションプログラムのために幾つかのプログラミングインターフェースを提供する取り組みが進行していた。１つのこのような取り組みは、ＯｐｅｎＧＬとして一般に知られている。ＯｐｅｎＧＬの目標は、ハードウェアに依存せずにプログラマがグラフィック機能を利用しやすくすることである。このようにすることで、ＯｐｅｎＧＬは状態機械のように動作する。特に、ＯｐｅｎＧＬライブラリを使用するプログラムは、現カラー、ライティング、ブレンドなどのステート（状態）を設定しなければならない。プログラムが実行されると、結果として生じるコンテキストは、プログラムされたものに依存する組合せなどの状態と入力テクスチャとの組合せとなる。状態機械型のオペレーションの場合、オペレーションの結果は、必ずしも容易に予測できるとは限らない。
【０００５】
コンピュータが視覚的に更にリッチなコンテンツに移行するにつれて、イメージ処理はより重要になっている。その結果、これらのツールにプログラマが容易にアクセスできることや、グラフィック計算が効率的であることの重要性が常に高まっている。ＯｐｅｎＧＬとプログラム可能ＧＰＵの組み合わせは、グラフィックプログラムが可能であることについて広範な進歩を遂げたが、依然としてグラフィックサブシステムへのより高レベルのインターフェースに対する必要性がある。この必要性は、イメージ処理（例えば、ＰｈｏｔｏＳｈｏｐ、ＡｆｔｅｒＥｆｆｅｃｔｓ、又は類似のソフトウェア）に直接関連するアプリケーションにおいて高まっている。これらのアプリケーションやその他においては、そのインフラストラクチャを利用するアプリケーションからグラフィックハードウェアの複雑さを隠す抽象レイヤを有することが望ましい。更に、オペレーティングシステムは、全てのアプリケーションに対してこのような抽象レイヤを提示することによって全体的にリッチなユーザーグラフィック体験を容易にすることを求める可能性がある。
【０００６】
このようなインターフェースは、プログラマ又はプログラムが所与のイメージにフィルタ又はエフェクトを簡単に適用できるようにする必要がある。より高いレベルのＡＰＩに対する暗黙的な必要性は、高速と効率の両方の方法でそのＡＰＩを実装する必要性である。効率的であるためには、システムは、理解が容易で且つ動作が容易な方法でグラフィックプログラミングを概念化するメカニズムを有する必要がある。更に、このようなシステムは、ＣＰＵとＧＰＵとの間で作業を効率的に分担しながら同時にメモリの使用と計算時間を最小にしなければならない。最終的には、デュアルプロセッサシステム（ＧＰＵとＣＰＵ）のために構築されたプログラムがＣＰＵだけを有するレガシーシステム上で実行することができるように、単一のプロセッサ上でエミュレートできるシステムを有することが望ましい。
【発明の概要】
【０００７】
他の利点の中でも、本発明は、上述の問題を解決し、上述の必要性と要求を満たそうとするものである。これを行う場合、本発明の幾つかの実施態様は、グラフィックオペレーション、或いは二次的なプロセッサ資源を利用できる潜在的な他のオペレーションのための高レベルプログラムインターフェースを含む。このタイプの更に特定の実施態様において、高レベルプログラムインターフェースは、ユーザー又はシステム内のプログラムが呼び出すことができるグラフィックフィルタリング機能を含む。プログラム又はユーザーは、エフェクトを生成することによって、或いは事前に定義されたリストからフィルタ機能を指定することによって高レベルプログラムインターフェースを利用する。別の実施態様において、プログラマ又はプログラムは、フィルタを事前に定義されたリストに加えるために拡張可能なインフラストラクチャへアクセスすることができる。
【０００８】
本発明の１つの一般的な実施態様において、ソフトウェアは、イメージタスクのグラフ状記述を構成するためにシステム内の選択されたプロセッサを利用する。グラフ状記述は、イメージのノードやリンク表示であり、ここでノードはオペレータを表し、リンクは、中間段階の結果と中間段階の結果を保持するのに必要な記憶装置を表す。詳細には、グラフ状記述のノードは、別のプロセッサ上の全体的なイメージオペレーションの一部分を計算するためのスレッド又はプログラムを最終的に含むことができる。更に、全体的なイメージタスクのグラフ状記述を有することで、最適化コンパイラの使用は全体的なイメージタスクに対して必要な資源を低減させることができる。このコンパイリング機能は、ノードプログラムがコンパイラを実行するプロセッサ以外のプロセッサ上で一般的に実行するので特に有用である。
【０００９】
前述の一般的な実施態様は、単一のＣＰＵと単一のＧＰＵとの一時的なペアのコンテキストで説明することができる。この実施態様は、全体的なイメージタスクを評価し、そのグラフ状記述を構成するためにＣＰＵ上で実行するソフトウェアを提案する。これは、上述されたような関連づけを備えたノードやリンクのツリーグラフとして視覚的に表現することができる。ノード−プログラムがＧＰＵ上で実行できるので、プログラムの構成は、ＧＰＵのプロパティを考慮する。とりわけ一般的な意味では、プログラム可能ＧＰＵは幾つかの並列実行ストリームを操作し、そのためノードプログラムは並行処理可能言語で表すことができる。例えば、ノードプログラムはＧＰＵフラグメントプログラムとすることができる。全体的なイメージタスクを表すグラフの構成後、グラフは、ＣＰＵ上で実行されるコンパイラによって最適化することができる。或いは、グラフは、該グラフが作成されるときに別の部分においてコンパイラによって最適化することができる。最適化の目的は、メモリ使用量やＣＰＵ又はＧＰＵ時間を最小にすること、或いはイメージが計算されるときの効率を高めることである。
【００１０】
本発明の種々の実施態様によると、最適化は、多くの機能的特性を有する。例えば最適化は、中間段階の結果をキャッシュする段階、複数のフラグメントプログラムを１つに統合する段階、閉じこめられた定義ドメインや関心領域内のエリアにメモリと計算を制限する段階、又はプロセッサ間での計算の分割を最適化する段階を含む。
【００１１】
最新のグラフィックコンテキストにこれらの技術を適用することは、非常に効率的であり、これによって開発者はコンパイラが占めるシステム内の特定のハードウェアを考慮することなく、１つ又は複数の素子（例えば画素）で実行されるオペレーションを表現することによってフィルタを記述することができる。更に、マルチプロセッサシステム内に装備するためのＡＰＩや効率的な処理インフラストラクチャを作成したことで、多くの実施態様はまた、シングルプロセッサシステム上のＡＰＩを利用する機能を含む。ごく一般的な意味で、これはエミュレーションによって達成される。
【図面の簡単な説明】
【００１２】
【図１】サンプルハードウェア構成を示す図である。
【図２（ａ）】ハードウェア構成のサンプルを示す図である。
【図２（ｂ）】ハードウェア構成のサンプルを示す図である。
【図３】ソフトウェアスタックの説明図である。
【図４】グラフを示す図である。
【図５】グラフ及びサンプルプログラムステップを示す図である。
【図６】グラフを示す図である。
【図７】イメージ生成のための例示的なフローチャートを示す図である。
【図８】ノード結合のための例示的なフローチャートを示す図である。
【図９】ノード結合のための例示的なフローチャートを示す図である。
【図１０】ノード結合のための例示的なフローチャートを示す図である。
【図１１】グラフを示す図（ａ）とグラフ最適化のための例示的なフローチャートを示す図（ｂ）である。
【図１２】グラフ最適化のための例示的なフローチャートを示す図である。
【図１３】最適化のための例示的なフローチャートを示す図である。
【図１４】グラフ最適化のための例示的なフローチャートを示す図である。
【図１５（ａ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１５（ｂ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１５（ｃ）】複数のエフェクトを加えるために複数のプロセッサを使用する段階を示す図である。
【図１６】最適化のための例示的なフローチャートを示す図である。
【図１７】多角形分割の実施例を示す図である。
【発明を実施するための形態】
【００１３】
Ａ．技術及び用語
１．技術
本明細書で説明される本発明の実施形態は、特に種々のタイプのプロセッサが１つのシステム内で利用される、全てのタイプのマルチプロセッサコンピューティングシステムに関連し、用途を有する。本明細書での説明のほとんどは、ＣＰＵ資源やＧＰＵ資源を有する一般的なコンピューティング構成に焦点を絞っている。この説明は、例証のためのものであり、ＧＰＵなし、複数のＣＰＵと１つのＧＰＵ、複数のＧＰＵと１つのＣＰＵ、或いは複数のＧＰＵと複数のＣＰＵのいずれかを有する他のシステムに対して本発明の適用を制限するものではない。この注意に関して、発明者らは典型的なハードウェアとソフトウェア動作環境に関する情報を提供するものとする。
【００１４】
図１を参照すると、一般的なハードウェアコンピューティング構成が示されている。極めて一般的であるが、マイクロプロセッサ１１は、チップセットサポート集積回路１３、１７に結合されている。マイクロプロセッサは、２３、２４、又は２５のようなインテルペンティアム（登録商標）ファミリー又はＩＢＭ／モトローラパワーＰＣチップのうちの１つのような、いずれかのマイクロプロセッサ又はコントローラとすることができる。チップセットＩＣ（本明細書ではノースブリッジ１３、サウスブリッジ１７として表現される）は、１つ又はそれ以上のＩＣに実装することができる。チップセット１３、１７は一般に、バス１２を介して又は現在当該技術分野で公知の直接リンクによってマイクロプロセッサに結合される。チップセット１３、１７が１つより多いＩＣに実装される場合、ノースブリッジの機能（ＡＧＰ、メモリ管理など）が共通バスへの接続又は前述のリンクのいずれかによるプロセッサへのより直接的な接続を有することは一般的である。サウスブリッジ機能を含む別のチップは、ノースブリッジを介して極めて一般的にマイクロプロセッサ１１に結合される。しかしながら、発明者らは、現在又は将来的に存在する利用可能な他の構成を排除することを意図するものではない。可能性のあるサウスブリッジ機能は、ディスクドライブのような周辺接続機構のためのＡＴＡバス１６、あらゆる種類の周辺機器の接続機構のためのＰＣＩバス１８、ＵＳＢデバイスの接続機構のためのＵＳＢコントローラ１９、イーサネット（登録商標）又は場合によっては他のネットワークをサポートするためのネットワークインターフェースコントローラ１１０、音声サポート１１１を含む。更に関連するものとして、標準的なノースブリッジ機能は、メインメモリ１１４をサポートするメモリコントローラと、ビデオサブシステムのサポートのためのアクセラレイティッド・グラフィックス・ポート１５を含む。メモリは通常、種々のタイプのダイナミックランダムアクセスメモリのいずれかであるが、代替の構成では、スタティックＲＡＭ、磁気メモリ、光メモリ、又は現在又は将来的に存在する可能性のある他のいずれか適切な記憶媒体とすることができる。ＡＧＰ１５は、グラフィックサブシステムがマイクロプロセッサやメインメモリなどのシステム資源に高速にアクセスするようにする、チップセット内に配置された特別なポートである。種々の新しく出てきたＡＧＰ系、及びコア資源とグラフィックサブシステムとの間の対話速度を確実に加速する他の方法が存在する。この説明は、類似の機能を実行するいずれかの特定の方法に用途を限定するものではない。最後に、図２は別のコンピューティングハードウェア構成２４、２５を示しており、これは２４と２５のマイクロプロセッサそれぞれとの緩い連係を意図するものである。
【００１５】
上述のように、本明細書で開示される本発明の実施形態はソフトウェアを含む。従って、図３のレイヤ図に表されるような、一般的なコンピューティングソフトウェアアーキテクチャの説明を行う。ハードウェア実施例と同様に、これらは、どのような意味においても限定するものではなく、むしろ例証に過ぎない。これは、ソフトウェア開発者が幾分異なる方法で表す傾向にあるレイヤタイプの図に特に当てはまる。この場合、Ｏ／Ｓカーネルから始まるレイヤを表したので、低レベルのソフトウェア及びファームウェアは省略した。発明者らの表記は一般に、レイヤ内に示されたソフトウェア要素が、その下のレイヤからの資源を使用して、その上のレイヤにサービスすることを意味する。しかしながら実際には、特定のソフトウェア要素の全ての構成要素は、完全にその様態で動作するというわけではない場合がある。
【００１６】
ソフトウェアに関する注意では、図３（ａ）を参照すると、レイヤ３１は、高度に保護された環境でコアＯ／Ｓ機能を提供するＯ／Ｓカーネルである。Ｏ／Ｓカーネルの上には、上位のレイヤにディスクや通信アクセスのような拡張機能がサービスされるレイヤ３２のＯ／Ｓコアサービスが存在する。レイヤ３３は、ＯｐｅｎＧＬライブラリや類似の資源の一般的な相対的位置付けを示すようにここに挿入されている。レイヤ３４は、２つのレイヤ、すなわちアプリケーションフレームワークとアプリケーションサービスとして通常表される機能の融合である。説明の目的のために、これらの両方のレイヤは、ここでは３５で示される最高レイヤでの常駐によってアプリケーションプログラムの高レベルで且つ頻繁な機能サポートを提供する。アイテム３１００は、「Ｃｏｒｅ Ｉｍａｇｉｎｇ」、ソフトウェアスーツ、モニカの相対的位置付けを示すもものであり、これは、本発明の多くの実施形態を説明するための媒体を提供する（本発明の実施形態の一部、いずれか、又は全てを含むソフトウェアスーツを意味する場合、用語「Ｃｏｒｅ Ｉｍａｇｉｎｇ」を一般的に用いることにする）。
【００１７】
ここで３（ｂ）を参照すると、アイテム１０１は、Ｃｏｒｅ Ｉｍａｇｉｎｇスーツの相対的な位置付けを表している。図３（ｂ）において、図３（ａ）と比較すると、別のグラフィック機能−合成に対してレイヤ３２４が加えられたことが明らかである。合成器のジョブは、多くの実施形態において説明されるようにウィンドウイングシステムにおけるウィンドウ合成と管理を実行することである。
【００１８】
２．ツリーとグラフ
数学や他の計算科学において、問題を、機械実行の計算やこのような機械のプログラミングに結び付くパーズ（構文解析）方式で表することができる。パーズ表現の実施例は、図４に示されるような一般化ツリー構造である。図４を参照すると、ツリー構造４１は、最も近い従属ノードの結果を表すリンク（４２、４３、４４、４５、４６、４７、４８、４９、４１０、４１１、４１２、４１３、４１４）と、２つのタイプのノードとから構成される。事前に存在している計算入力（例えば、オペランド）、４１９、４２４、４２５、４２６、４２７、４２８、４２９を表すリーフ（葉）ノードが存在する。或いは、計算関数（例えば演算子）４１５、４１６、４１７、４１８、４２０、４２１、４２２、４２３を表す機能ノードが存在する。全体的な実施例として、図４を参照すると、リンク４６は、機能ノード４１７への入力として役割を果たし、リーフノード４２４の結果（単にリーフであるリーフノードの結果）を表す。
【００１９】
ここで図５を参照すると、別のツリーが、円ではなく矩形のノードを使用して示されている。しかしながら、図の表示の性質は同じであり、リーフノード５１はオペランドに類似しており、機能ノード５２、５３、５４は、演算子を表し、リンク５１００、５１０１、５１０２、５１０３、５１０４は、結果を表している。
【００２０】
本開示の種々の箇所では、図４、５にあるようなツリーを使用し、コンピュータシステム内で使用又は組み立てられる「グラフ」のコンテキストにおけるツリーを説明する。発明者らは一般に、描写されるグラフィックツリーをコンピュータシステムが構成又は使用することを意味するものではなく、むしろ人への例証の目的で描かれるグラフィックツリーの何らかの表示をシステムが作成、保持、又は使用することを意味するものとする。
【００２１】
更に、グラフィック技術やソフトウェアを説明するコンテキストにおいては、一般にツリー（又はグラフ）を使用する。アプリケーションプログラム又はプログラマの観点から、ツリー又はグラフによって定義されるイメージは、画素のアレイによって定義されたイメージとは通常区別できない。イメージの両方のタイプは、同じ最終のオブジェクトを定義し、アプリケーションプログラムがイメージと関連付けるのがオブジェクトである。幾つかの点で、同じことがＣｏｒｅ Ｉｍａｇｉｎｇ（又は本明細書で本発明を具現化する他のソフトウェア）の観点に関して当てはまる。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフを評価することによってイメージ計算タスクを評価することができる。その点に関して、グラフのルート（根）ノードの結果は最終結果である。図４、５を参照すると、ノード４１５、５４は、グラフのそれぞれのルートノードである。
【００２２】
本発明の実施形態及びＣｏｒｅ Ｉｍａｇｉｎｇの説明においては、これらの例証的なツールを引用することが多い。従って、本明細書で説明される実施形態の多くに関する前置きとして、図４を参照すると、以下の関連付けは発明者らの説明のコンテキストにおいて一般に適切であり、すなわち、（ｉ）図示されるツリーは一般に低レベルグラフと呼ばれ；（ii）機能ノード４１５、４１６、４１７、４１８、４２０、４２１、４２２、４２３は、ＧＰＵのようなマイクロプロセッサ上で実行される「カーネル」又はフラグメントプログラムを表し；（iii）リーフノード４１９、４２４、４２５、４２６、４２７、４２８、４２９は一般的にイメージを表し、換言すると、画素の集合又はその表現であり；（iv）リンク４２、４３、４４、４５、４６、４７、４８、４９、４１０、４１１、４１２、４１３、４１４は結果を表すが、実際に生じるであろうオペレーションのコンテキストでは、これらの結果は、これらを記憶するためのバッファに通常関連付けられる。
【００２３】
更に、本明細書で説明される実施形態の多くに関する前置きとして図５を参照すると、以下の関連付けは、発明者らの説明のコンテキストにおいて適切であり、すなわち：（ｉ）図示されるツリーは、一般的に高レベルグラフと呼ばれ；リーフノード５１はイメージを表し；機能ノード５２、５３、５４は、一般に事前に定義されたフィルタである高レベルフィルタを表し；リンク５１００、５１０１、５１０２、５１０３、５１０４は、フィルタの結果を表すが、低レベルのグラフとは異なり必ずしもバッファに関連付けられない。
【００２４】
Ｂ．プログラマの観点からのＣｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩ
本発明の多くの実施形態は、オブジェクト指向のプログラミングを含み、４つのタイプのオブジェクトをプログラマに利用可能にする。これらのオブジェクトタイプは、イメージ、フィルタ、コンテキスト、ベクトルである。各々については、簡潔に説明するが、その普遍性を制限しないようにする。
【００２５】
イメージは、レンダリングの２次元結果（画素イメージ）又はその表現のいずれかである。高レベルのプログラムオペレーションでは、当該オブジェクトが実際の画素値になるために計算を必要とすることで、イメージを表すオブジェクトが維持される場合が多い。本発明の種々の実施形態は、イメージの定義として画素値イメージと未計算のイメージのいずれか又は両方を利用することができる。特定の意味は、コンテキスト的な使用（「コンテキスト」オブジェクトへの関連性がない）からかなり容易に得られる。一般的な意味において、フィルタに関する説明の中では、イメージは、ある関数又はフィルタへの入力として解釈される必要がある。
【００２６】
フィルタは、イメージに影響を与えるのに使用される高レベルな機能である。フィルタは、この開示の最後にリストされる事前に定義されたフィルタの１つ又はそれ以上を含むことができる。フィルタは、フラグメントプログラムに類似したものとすることができ、同様にイメージに（又はより正確に一般的にはテクスチャに）影響を与えるが、一度に１つの画素だけを生成する。本発明の実施形態の多くにおいて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、フィルタベースのイメージ操作をコンパイルし、このような操作を、フラグメントプログラムを使用してＧＰＵ上で行うことができるようにする。フィルタとフラグメントプログラムとの間には必ずしも１対１の対応がある訳ではない。
【００２７】
コンテキストは、フィルタリングオペレーションの結果が常駐するメモリ内の定義された場所などの空間である。上記で提案されたように、イメージが入力と仮定すると、コンテキストは出力と仮定される。
【００２８】
ベクトルは、浮動小数点数の集合である。本明細書で説明されるほとんどの実施形態では、ベクトルは、４つの浮動小数点数に関連付けられ、各数は、同じ固定ビット数（通常は３２）を有する。グラフィックでは、ベクトルを用いて、（ｉ）画素の外観（Ｒ（赤）；Ｇ（緑）；Ｂ（青）、アルファ（透明性））を記述するのに必要な４次元；又は（ii）それぞれＸ、Ｙ、Ｚ、Ｗの２空間、３空間、又は４空間（均一）座標を記述するのに必要な２又は３次元を表すことができる。
【００２９】
Ｃ．Ｃｏｒｅ ＩｍａｇｉｎｇとＣｏｒｅ ＩｍａｇｉｎｇＡＰＩ
Ｃｏｒｅ Ｉｍａｇｉｎｇは、多くのルーチンを含み、特にグラフィック機能のために構成された高レベルプログラミング言語又はＡＰＩとして機能するが、数値計算単独（例えば畳み込みオペレーション）などの他の機能にも適用可能なソフトウェアスーツである。いずれか１つの実施形態又は実施形態のいずれかのグループに言及するためにモニカＣｏｒｅ Ｉｍａｇｉｎｇを使用するが、「Ｃｏｒｅ Ｉｍａｇｉｎｇ」に関するどのような特定のコメントにも本発明を限定するものではない点を想起されたい。同様に、Ｃｏｒｅ Ｉｍａｇｉｎｇとして或いはＣｏｒｅ Ｉｍａｇｉｎｇ内でルーチン又はプロセスに言及するが、それにより、本発明が単一のユニット又はレイヤとしてこのようなソフトウェアが実装されることを意味するものではない。
【００３０】
Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフィックフレームワークやグラフィック固有アプリケーションサービススーツと通信するための高レベル言語又はＡＰＩを含む。これはまた、高レベル言語からアセンブリを生成するためのコンパイラを含む。グラフィックフレームワークと従属のソフトウェアレイヤがプラットフォーム又はハードウェアの差違を考慮することができるので、言語／ＡＰＩはプラットフォームやハードウェアに依存しない。ＡＰＩによりプログラマは、（１）ＯｐｅｎＧＬ又は類似のインターフェースによって要求される状態と他のパラメータ、或いは（２）グラフィックレンダリングを実行するＧＰＵ又は他の資源のためのアセンブリ言語を懸念することなく、イメージにエフェクトを加えることができる。
【００３１】
ソフトウェアとして概念化される場合、Ｃｏｒｅ Ｉｍａｇｉｎｇ（又はＡＰＩと関連するコンパイラの実施形態）は、一般には、アプリケーションプログラムとオペレーティングシステムとの間に位置付けられるグラフィックサービスルーチンの組として見ることができる。階レイヤソフトウェアの概念化は、様々な解釈の影響を受けるので、この説明は、Ｃｏｒｅ Ｉｍａｇｉｎｇの階レイヤ化位置（又は本発明の実施形態によるあらゆるグラフィックサービスソフトウェアスーツ）を概念化するために他の方法を排除するものではない。図３（ａ）、３（ｂ）を参照すると、この注意で、グラフィックサービスソフトウェアスーツ３１００と３１０１がそれぞれ示されている。
【００３２】
これらのグラフィックサービス３１００、３１０１の位置付けは、これらのスーツがアプリケーションフレームワーク、アプリケーションサービス、グラフィック資源の構成要素を含むことができることを意味している。要約すると、この位置付けの意図は、Ｃｏｒｅ Ｉｍａｇｉｎｇ３１００、３１０１が、レイヤ３５、３２７のアプリケーション；レイヤ３４、３２６の他のフレームワーク又はサービス；レイヤ３３、３２５のＯｐｅｎＧＬなどの資源；レイヤ２４の合成器；レイヤ３２、３２３のＯ／Ｓサービスと対話することができることを意味するものである。
【００３３】
一般的な意味では、グラフィックに適用されたように、Ｃｏｒｅ Ｉｍａｇｉｎｇによってプログラマとプログラムは、（１）事前に定義された高レベルフィルタを使用する、或いは（２）ＡＰＩ又は本発明の１つ又はそれ以上の別の実施形態を使用する一連の事前に定義されたフィルタをアセンブリする、これらのいずれかによってエフェクトを実装することができる。後者の場合、プログラマ又はプログラムは、事前に定義されたフィルタのゼロ又はそれ以上の高レベルの記述のためにＣｏｒｅ ＩｍａｇｉｎｇへのＡＰＩ呼出しを行う。プログラム又はプログラマは、発明者らが高レベルグラフと呼ぶデータ構造内にその高レベル記述（又はその基準）を配置する。高レベルグラフは、新しいフィルタを作成するプログラマ又はプログラムによってアセンブリされる。高レベルグラフは、事前に定義されたフィルタと新しいフィルタで用いられるイメージとの間の関係を定義する。プログラマ又はプログラムは、その高レベルグラフの構築を完了すると、新しいフィルタを作成するためのそのタスクを効率良く完了する。すなわち、新しいフィルタを作成するのに必要な情報の全ては、高レベルグラフにおいて具現化される。
【００３４】
別の実施形態では、プログラマ又はプログラムがＣｏｒｅ Ｉｍａｇｉｎｇと協働してグラフをアセンブリするときに、作成されたグラフは、低レベルグラフ又は相当に低レベルのグラフになる可能性がある。例えば、プログラム又はプログラマの観点からは、要求は高レベルフィルタに対して行うことができるが、Ｃｏｒｅ Ｉｍａｇｉｎｇは、低レベルフィルタ又は低レベルフィルタと高レベルフィルタ間のある中間段階のオブジェクトを作成し配信することができる。プログラム又はプログラマは実際にはオブジェクトを検査しないので、Ｃｏｒｅ Ｉｍａｇｉｎｇは、低レベルコードで高レベルコードの要求に対応することができる。このようにして、Ｃｏｒｅ Ｉｍａｇｉｎｇは、プログラムが高レベルフィルタやオブジェクトと共に機能していると考えられる限り低レベルグラフをアセンブリすることができる。
【００３５】
Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベルグラフ（いずれかの適用可能な入力パラメータと共に）を最終的に最適化してコンパイルし、ＧＰＵ対応プログラムを得る追加タスクを有する。コンパイリングステップは、最終イメージの使用に間に合うように実行することができる。以上をまとめると、プログラマ又はプログラムは、生成し、達成するためＡＰＩの高レベル言語（事前に定義されたフィルタを含む）を使用したが、これは種々の他のフィルタと入力から構成される本質的に新しいフィルタである。プログラマ又はプログラムはまた、プログラムによりこのフィルタをイメージに適用することができる。本発明の種々の実施形態は、ＧＰＵとＣＰＵとの間の作業の種々の分割を企図している。一般に、ＣＰＵはＣｏｒｅ Ｉｍａｇｉｎｇを実行し、ＧＰＵはＣｏｒｅ Ｉｍａｇｉｎｇの最終製品を実行することになる。しかしながら、ハードウェア能力及び最終的な最適化に応じて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ＣＰＵとＧＰＵのためのタスクを生成することができる。更に、システム内にプログラム可能ＧＰＵがない場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ＣＰＵのためのオブジェクトを生成し、イメージをコンテキストにレンダリングすることができる。
【００３６】
Ｄ．Ｃｏｒｅ Ｉｍａｇｉｎｇ基本機能の実施形態
ここでＣｏｒｅ Ｉｍａｇｉｎｇの機能を更に詳しく見てみると、１つの実施形態においてＡＰＩは、プログラマ及び最終的にはアプリケーションプログラムのユーザーのための６つの高レベル機能、すなわち、コンテキストの作成、イメージの生成、フィルタの生成、フィルタに関連したパラメータを設定する機能（例えば、フィルタ関数の引数）、アセンブリされたフィルタ又はフィルタのグループの出力を要求する機能、イメージをコンテキストにレンダリングする機能を提供する。
【００３７】
１．コンテキストの作成
コンテキストを作成する機能はメモリ内のオブジェクトの定義を可能にするツールから得られるので、一般に出力はコンテキストと呼ばれる。オペレーションの結果に対するデスティネーションが存在することができるように、このようなオブジェクトの定義が必要とされる。例えば、コンテキストは、メインメモリ内のビットマップ又はＯｐｅｎＧＬビューに関連付けることができる。これらの関連付けられたイメージコンテナは、レンダリングのデスティネーションとして使用される。本発明は、システムのグラフィック機能に関連するビデオメモリなどのメモリを第一に企図しており、ここで説明される概念は、システム内のいずれかで見出される、或いはシステムにアクセス可能なあらゆるメモリ又は記憶装置に等しく適用される。従って限定ではないが、メモリは、ダイナミックメモリ又はスタティックメモリのような全てのタイプの半導体メモリを含むことができ、これは、特にグラフィックサブシステムに関連付けられるか、グラフィックサブシステムと共用されるか、或いはメインシステム又はメインシステムによってアクセス可能な別のサブシステムに名目上専用であるか否かに関係しない。更に、速度は確かに問題であるが、本明細書の概念は磁気又は光メモリを排除するものではない。
【００３８】
コンテキストを作成する実施例としては、アプリケーションプログラムは画面に最終的に何かを表示することを意図していると仮定することができる。ＡｐｐｌｅのｉＰｈｏｔｏアプリケーションがユーザーコマンドに応答して海岸のイメージの表示を要求しているものと仮定する。ｉＰｈｏｔｏは、コンテキストの作成を要求する関数を呼び出すことによって、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩを利用することができる。Ｃｏｒｅ Ｉｍａｇｉｎｇは、可能な中でも特に、作成されたコンテキストの識別のハンドルを返すことになる。ハンドルが「空コンテキスト」であると仮定する。
【００３９】
２．イメージの生成
一般的に入力をイメージと呼ぶ、なぜなら、イメージ内の座標又は画素は、関連性のある値が得られるようにサンプリングすることができるからである。本発明のＡＰＩの実施形態を使用すると、イメージを、ゼロから或いは別のイメージから生成することができる。画素値を生成するメカニズムが提供されることによりイメージがゼロから生成される。例えばイメージを色又は色の数値的な組合せ（チェッカーボード又は縞模様のページのような）として単純に定義することにより、イメージをゼロから生成することができる。より一般的には、イメージは、１つ又はそれ以上のフィルタを既存のイメージに加えることによって別のイメージから生成される。
【００４０】
上記のｉＰｈｏｔｏの実施例に続いて、ｉＰｈｏｔｏは、海岸での子供の既存のイメージを取り、フィルタ（例えば、ブラー）を子供の外側のあるエリアに加えるようグラフィックサービスに要求することによって、イメージを生成することができる。このフィルタの適用により、新しいイメージが生成される。理解を容易にするために、これは、新しい画素値の計算が完了していないのではなく、ブラーフィルタがプログラムにより加えられている未計算イメージであり、画素を計算するのに必要な他のエレメントの全てが記憶又は参照されるイメージバッファ内において常駐又は参照される。
【００４１】
３．フィルタの作成
一般的にフィルタを、ゼロ又はそれ以上のイメージ（最終的には画素）上で実行できるいずれかの機能と呼ぶことにする。更に具体的に言うと、フィルタは、入力としてイメージと他のパラメータ（特定のフィルタに関連付けられ、これに依存する）を受け入れて新しいイメージを生成する機能とすることができる。ＡＰＩは現在のところ、この開示内容のいずれかでリストされ説明される数十のフィルタを提供する。しかしながら、本発明の実施形態は、発明者らが継続してフィルタを開発し、その上フィルタを開発するために他の機能を提供したような拡張的な性質を求めている。本発明は、事前定義タイプのフィルタの追加を可能にする拡張性を企図しており、この説明は、ゼロ又はそれ以上の事前定義フィルタの組合せと処理によって作成された新しいフィルタに注目する。
【００４２】
フィルタの作成が企図される１つの方法は、プログラマ又はプログラムが、ＡＰＩ事前定義フィルタの１つ又はそれ以上並びにプログラマが加えることを意図した他のいずれかのアイテム又は機能を共に結び付ける本発明のＡＰＩの実施形態を用いることによって開始する。上述のように、新しいフィルタを作成するためには、プログラム又はプログラマは、使用される全イメージと事前定義フィルタの表示とこれらのオブジェクト間の関係を含む高レベルのグラフを作成する。幾つかの実施形態において、事前定義フィルタは、基本的なグラフィック機能を可能な限り包括的にするものとし、プログラマ又はプログラムがＧＰＵのためのアセンブリを記述する必要性又は誘因を最小にする。実際、Ｃｏｒｅ Ｉｍａｇｉｎｇの全体的な利点は、特定のグラフィックハードウェアに関係なくアプリケーションレイヤでプログラムする能力である。
【００４３】
新しいフィルタが高レベルグラフによって定義されると、アプリケーションプログラム又はユーザー（ＣＰＵレベルでの）は、高レベルのグラフを実装するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出す（グラフによって定義される方法でグラフにおいて参照されるイメージ上で、グラフ内で参照されるフィルタに影響を与える）。もちろん、高レベルグラフは、１つより多いイメージを取り込むように記述されるが、技術は同じである。フィルタを実装する場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、フィルタが後でリストされるフィルタ定義において規定されているようなブラーのブラー半径、幾何学的パラメータ、又は他のいずれかの入力などのフィルタ指定入力を通常は有するので、他の入力データを必要とすることがある。
【００４４】
Ｃｏｒｅ Ｉｍａｇｉｎｇの重要な機能は、その後で１つ又はそれ以上のオブジェクトをアプリケーションプログラム又はユーザーに返すことである。本発明の種々の実施形態によれば、返されたオブジェクトは、ＧＰＵ、ＣＰＵ、又はこれらの２つのある組合せでレンダリングされ、又は計算する状態にすることができる。１つの別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベル要素のためのアプリケーションプログラム要求に応答しながら、低レベルグラフの全て又は一部を構築する。この実施形態において、アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇがより低いレベルのコードを供給している間は、アプリケーションプログラムがより高いレベルのコードを要求していると考えられる（アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇによって与えられたオブジェクトを解析しないので、その違いを検出できない）。或いは、好ましい実施形態において、アプリケーションがコンテキスト内のイメージを要求する場合、返されたオブジェクトは、ジャストインタイムコンパイルの準備ができた最適化された低レベルグラフとすることができる。幾つかの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ジャストインタイムコンパイルされＧＰＵで実行される１つだけのオブジェクトを返すことになる。このようにするために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、高レベルグラフを変換（及び一般的に最適化）し、イメージをテクスチャに変換する必要がある（ＧＰＵは、計算のためにイメージではなくテクスチャを使用する）。イメージをテクスチャに変換する場合、Ｃｏｒｅ ＩｍａｇｉｎｇはＣＰＵを用いて最初にイメージをサンプラーに変換する。サンプラーは、イメージにその状態をプラスしたものであり、サンプラーへの変換は、（ｉ）透過、クランプ、又は複製などのラップモード、（ii）最も近い画素全体からサブジェクト画素までの値を使用すること、或いはサブジェクト画素を囲む４つの画素の格子間を補間するなどの補間モード、（iii）回転、スケール、スキュー、平行移動、ミラーなどのアフィン変換のような状態情報を組み入れるステップを含む。次いで、サンプラーは、ＧＰＵで使用するために容易にテクスチャに変換される。入力としてのこれらの全てに関して、Ｃｏｒｅ Ｉｍａｇｉｎｇを実行するＣＰＵは、実行時には実際の画素（上記で作成されたテクスチャによって提供される）上でフィルタを実装することになるＧＰＵプログラムを含むオブジェクトを作成する。
【００４５】
次に図５を参照し、フィルタ作成の一般的な実施例に進む。ｉＰｈｏｔｏの海岸の実施例を振り返ると、ユーザーは、ｉＰｈｏｔｏに写真の自動画質向上を要求することができる。純粋に例証の目的で、自動画質向上が以下のフィルタ作成を必要とすると仮定する。これは、現在のｉＰｈｏｔｏ画質向上機能が実際にはこのようには動作しないという点で、純粋に例証のためのものである。ｉＰｈｏｔｏは最初に、その要求のフィルタを作成する。このプロセスは、この時点ではグラフ又は画素形式とすることができる基本イメージ５１を割り当てるために、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出すことによって始める。これは、図５、高レベルグラフツリー図のステップ１で見られる。次にｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出し、プログラムステップ（及び対応するツリーポジション）を追加して、カラー補正フィルタ５２をイメージ５１に加える。これは、図５のステップ２及び高レベルグラフツリー図で見られる。図５のステップ２の出力は、プレースホルダーＣＣ（カラー補正された）の海岸として定義される点に留意されたい。この時点では、この中間段階の結果（ＣＣ海岸）が常に存在するかどうかは不確かであるので、バッファを割り当てずに、中間段階の結果の可能性を示す高レベルグラフ内にプレースホルダーを配置する。自動画質向上機能の強化において、ｉＰｈｏｔｏは、疑似色フィルタ５３を５２のフィルタリングの結果に更に加えることができる。上記のように、ｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出して、高レベル疑似色フィルタを取得し、マウントする高レベルグラフ（及び例証の目的の図５のツリー）にこれを挿入する。次に自動画質向上機能を完成させるために、ｉＰｈｏｔｏは、５３フィルタリングの結果（ＦＣ ＣＣ海岸）をオリジナルの海岸イメージ（５１）で平均化するよう選択することができ、その結果、適切なフィルタ５４をＣｏｒｅ Ｉｍａｇｉｎｇから呼出して高レベルグラフに挿入する。これは、図５のツリーグラフとサンプルプログラムステップの両方で見られる。
【００４６】
実施例において、ｉＰｈｏｔｏは今や、自動画質向上の海岸イメージの要求された結果についての高レベルグラフを有する。この実施例の実施形態によるこの結果を利用可能にするために、ｉＰｈｏｔｏは、上述のように高レベルプログラムを変換、最適化、又はコンパイルするためにＣｏｒｅ Ｉｍａｇｉｎｇのルーチンを順次呼び出すことができる（或いはＣｏｒｅ Ｉｍａｇｉｎｇは単独で動作することができる）。例証の目的において、単一の形式で表現される結果（図５に類似した）が図６に表示される。フラグメントプログラム（６２、６３、６４）は、図５に示された自動画質向上の高レベルツリーを含む高レベル事前定義フィルタに似せる必要がないことが図６で理解される。各高レベルフィルタは、その目的を果たすために１つ又はそれ以上のフラグメントプログラムを含むことができる。更に、プログラムが最適化された場合、フラグメントプログラムを置き換え、再配置、或いは削除を行うことができる。最後に、図６に示されたＧＰＵ実装は、イメージではなくテクスチャで始まり、物理的な場所（バッファ−それ以上プレースホルダーはない）に結果を配置することによって終了することが分かる。
【００４７】
４．フィルタのための設定値
上記で参照されたように、各高レベルフィルタは、上記のように作成されるか、或いは本明細書のリストで事前に定義されるかに関わらず、必要とされ且つフィルタ機能によって定義される入力値のセットを有することができる。海岸の実施例においては、一般的な入力を表すためにベクトル"パラメータ（Ｘ、Ｙ、Ｚ、Ｗ）としてこれらの入力パラメータを示した（図５を参照）。別の一般的でない実施例は、ブラーフィルタであり、入力パラメータとしてほぼ確実にブラーの半径が必要となる。更に他の実施例は、入力カラー、入力の強さ、入力飽和度などである。（コンテキストにおけるより多くの実施例のフィルタのリストを参照。）Ｃｏｒｅ ＩｍａｇｉｎｇのためのＡＰＩは、これらの入力パラメータの設定機能をプログラマ及びプログラムに必然的に提供し、イメージの予測可能な作成又は編集を可能にする。
【００４８】
ｉＰｈｏｔｏの海岸の実施例を参照すると、写真のエリアにブラーを行った。正確な入力パラメータは特定のブラーフィルタに依存することになり、ｉＰｈｏｔｏは、ブラーの半径を供給する必要性が高い。
【００４９】
５．フィルタの出力要求
１つの実施形態において、特定のフィルタに対するグラフが存在すると、プログラム又はプログラマは、そのフィルタを出力するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出すことができる。これに応じて、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ジャストインタイムコンパイル、次いでＧＰＵ上での通常の実行の準備ができたオブジェクトを作成する。高レベルフィルタのこの出力は、単に未計算の又は代表的なイメージである。別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この時点でグラフの最適化或いはイメージの計算のいずれかを行うことができる。最適化には処理サイクルが必要とされ、計算は処理サイクル及びメモリを用いることになるので、多くの場合、前者の最適化の実施形態が好ましい。これらの資源は通常、イメージをコンテキストにレンダリングする必要があることを確認するまで保存するのが適切である。
【００５０】
一般的により好ましい実施形態（メモリとプロセッサ時間を節約する）においてｉＰｈｏｔｏの実施例を参照すると、ｉＰｈｏｔｏは、Ｃｏｒｅ Ｉｍａｇｉｎｇを呼び出して、ジャストインタイムコンパイル及び実行の準備ができた未計算イメージを生成する。
【００５１】
ａ．フィルタ出力を作成することに対する注意
多くのグラフィック処理エンジンと同様に、Ｃｏｒｅ Ｉｍａｇｉｎｇは、１つだけのカラー空間、例えば「ライトリニア」で動作するように構築される可能性が高い。従ってグラフを処理するために、幾つかの実施形態では、カラー空間をライトリニアに変換する必要があり、結果を返す前にカラー空間をその元のカラーに変換して戻さなければならない。幾つかの実施形態において、この変換は、高レベルグラフの入力と出力に適切なカラー変換高レベルフィルタを配置することによって、高レベルグラフ上で行われる。別の実施形態においては、これは、低レベルグラフ上で極めて類似の方式で行う。低レベルグラフの場合、カラー変換のための「カーネル」又はフラグメントプログラムノードは、グラフの入力と出力に配置される。ノードがグラフ（高又は低レベル）に配置されるほとんどの実施形態では、この状況は、そのカラー変換ノードの結果が今後極めて有用となる可能性が高いことを決定付ける。従って、カラー変換ノードの結果は、ほとんどの実施形態でキャッシュしなければならない。カラー変換のためのグラフノードを作成する代替の方法は、このような変換をＣｏｒｅ Ｉｍａｇｉｎｇルーチンの１つにプログラムすることである。
【００５２】
６．コンテキストへイメージをレンダリング
最終的に、ほとんどのイメージはディスプレイのような視覚的用途のために生成される。従って、イメージ生成のこの実施形態における極めて一般的なステップは、イメージをある定義されたコンテキストにレンダリングする段階を呼び出すことである。ほとんどの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この時点でグラフの最適化を実行することになる。要約すると、最適化は、以下のいずれか又は全てを含むことができ、すなわち、（１）低レベルグラフを作成する段階、ここで概念化の目的において、グラフのノードはフラグメントプログラムを表し、低レベルグラフはイメージとフラグメントプログラムとの間の関係を定義する（これは、イメージと高レベルフィルタさらにその内部関係を含む高レベルグラフと対照的である）、（２）定義ドメインに対する最適化段階、（３）関心領域に対する最適化段階、（４）フラグメントプログラムを組み合わせて、グラフのサイズ又は最終的にはその実行が必要となるメモリ空間を低減させる段階、（５）最適化された低レベルグラフの実行要件を常駐ハードウェア（ＧＰＵ、ＣＰＵ、メモリなど）と比較する段階である。最適化されると、低レベルグラフはコンパイルされ、１つ又はそれ以上の実行可能なオブジェクトが作成される。説明されたように、一般的にはＧＰＵのための１つの実行可能なオブジェクトが存在するが、最適化又はコンパイル中に、複数のプロセッサを用いることを決定することができる。コンパイル後、結果として得られたオブジェクトが実行され、イメージが指定コンテキストにレンダリングされる。
【００５３】
再度ｉＰｈｏｔｏの実施例を参照すると、画面上にイメージを配置するためには、ｉＰｈｏｔｏがＣｏｒｅ Ｉｍａｇｉｎｇを呼出し、オブジェクトを画面にレンダリングする。一般的な実施形態では、このステップは、イメージ内の関連する画素の全てに対してＧＰＵコードを実行し、拡張写真イメージを生成する段階を含む。イメージは、画面ディスプレイと関連付けられたバッファ内に該イメージを配置することによって画面上に配置される。
【００５４】
Ｅ．最適化
最適化は、タスクが実際に実行されたときに最も効率良く或いは容易に実行されるように、プログラム又はタスクを解析し変更するプロセスである。本明細書で説明されるほとんどの実施形態のコンテキストでは、１つのマイクロプロセッサを使用して別のマイクロプロセッサのためのプログラムコードを最適化するよう試みている。更に特定の実施形態において、システムＣＰＵ資源を使用して、ＧＰＵ上で実行されるプログラムを最適化しようと試みている。また更に特定の実施形態において、グラフとして表されたグラフィックタスク（通常はイメージへのエフェクトの適用）を解析したＣＰＵはグラフを最適化し、グラフがジャストインタイムコンパイルされたときにＧＰＵ上で最も効率良く実行するようにする。
【００５５】
発明者らは、汎用及び特殊コンテキストの両方で最適化及びコンパイルを説明してきた。上記の開示事項の範囲を限定することなく、最適化のための４つの異なる汎用技術のいずれか１つを含む、Ｃｏｒｅ Ｉｍａｇｉｎｇの実施形態を説明する。これらの４つの汎用技術は、中間段階の結果のキャッシング、定義ドメインに対する計算と記憶の制限、関心領域に対する計算と記憶の制限、グラフを縮小又は簡略化するためのグラフ再書き込みである。
【００５６】
最適化はＣＰＵサイクル、ＧＰＵサイクル、メモリ空間のような現実世界のアイテムにおける節約を扱うので、通常は導入した最も低いレベル（ハードウェアに最も近い）の概念例証ツールに関連した最適化技術を説明することになる。そのツールが低レベルグラフである。しかしながら、これらの技術は、概念化の単一のレベルに限定されたものと見なすべきではない。実際、これらの技術を、例示的な抽象概念の高レベルと低レベル（例えば高レベルのグラフ又はコンパイルコード）での効率を適用し実現することができる。
【００５７】
開示される最適化技術は、種々の順序及び、シーケンシャル技術が一度に１つのノードに或いはグラフのセクションに再帰的に加えられる混成順序で用いられる場合にでも有用であ。しかしながら、最も分かり易く説明するために、図７に示されるような論理シーケンシャル順序で技術を導入する。ここで図７を参照すると、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ステップ７１００でアプリケーションプログラムからグラフィックタスクを受け取る。タスクが低レベルグラフで未だ具現化されていない限り、ステップ７１０１において、Ｃｏｒｅ Ｉｍａｇｉｎｇは低レベルグラフを作成する必要がある。次にステップ７１０２で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ノード低減解析を行い、可能であればノードを除去する。不要な（又はコラプス可能な(collapsible)）ノードが最適化されるとＣｏｒｅ Ｉｍａｇｉｎｇはステップ７１０３に進み、ここでバッファのサイズとイメージ入力を最終的に制限するために最適化が行われる。このステップは、定義ドメイン（「ＤＯＤ」）と関心領域（「ＲＯＩ」）と呼ばれる２つの領域を交差する段階を含む。ＲＯＩ／ＤＯＤ最適化後、グラフは、ステップ７１０４でコンパイルをする状態にある。最後に、全てのこの上記の作業がＣＰＵ上で実行されると、プログラムは、レンダリングのためにＧＰＵに送られる（全体を通して説明したように、幾つかの実施形態では、グラフの一部をコンパイルして更にＣＰＵに送ることができる。）
【００５８】
上述の最適化技術を説明する場合、より深く理解するためにグラフにおけるノードの実施形態を用いることができる。低レベルグラフのノードに関して説明するが、この概念は、どのような類似の説明にも当てはまる。ここまでは、機能、フィルタ、フラグメントプログラムとしてノードを説明してきた。しかしながら、グラフの解析を行うためには、より具体的でより豊富な情報を有するノード表現が必要である。従って本発明の種々の実施形態では、要望又は必要に応じて、低レベルグラフノードは、以下の関連する情報すなわち（ｉ）説明されているフラグメントプログラムのようなプログラム、（ii）サンプラー（状態付きイメージ）と１つ又はそれ以上のベクトル（ベクトルは浮動小数点数の集まりであることを想起されたい）を含むプログラムのための引数、（iii）ノードの出力の定義ドメイン、（iv）出力形状が与えられた場合のノードの入力形状の正確な予測をもたらすＲＯＩ関数（両方の形状は、座標系、恐らくは同じグローバル座標系で定義される）を有する。
【００５９】
１．中間段階の結果のキャッシング
最新のコンピューティングに内在する理由から、アプリケーションプログラムは、同一又は類似のイメージの計算を何度も要求する場合が多い。アプリケーションプログラムはまた、以前に計算されたイメージのサブセット又はスーパーセットであるイメージの計算を要求する場合が多い。この理由のために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、不必要な作業をさせないためにキャッシング技術を利用する。ほとんどの実施形態において、グラフノードはキャッシュ管理のためのベースを形成する。詳細には、図５のツリーによって表されるような高レベルグラフを説明したことを想起されたい。同様に、図４や図６に示されるツリーのように概念化することができる低レベルグラフについても言及している。幾つかの実施形態において、グラフ内の各ノードは不変であり、その下のグラフの部分によって定義（すなわちノードを解くのに必要なオブジェクト及び計算）されると仮定する。このように仮定すると、発明者らはノードの結果（通常はイメージ）をキャッシュし、次いで同じノード（その下のグラフの和として定義される）が再計算される待ち行列にあるかどうかを判定することができる。ノードを再計算するのではなく、メモリから結果を単にフェッチしてもよい。種々の実施形態によれば、これは全ノードに対して行うことができる。メモリを効率的に使用するために、様々なタイミング（例えば、メモリ使用量が多い場合、又はキャッシュされた入力が古い場合、又は関連するアプリケーションプログラムがクローズした場合、又はシステムがシャットダウンした場合）でキャッシュの削除を選ぶことができる。更に、メモリを効率的に使用するために、別の記憶装置を使用することができる。ほとんどの実施形態においては、ビデオサブシステム又はＧＰＵに割り当てられたスタティックメモリ又はダイナミックメモリが主として使用されている。しかしながら、システムメモリ、ハードドライブ、或いはシステム又は場合によってはネットワークアクセス可能な記憶装置内の他の磁気メモリなど、どのようなアクセス可能な記憶装置内にこれらのキャッシュを配置するように選択してもよい。
【００６０】
種々の実施形態において、キャッシングは、最適化中（例えばＣＰＵ上で）、レンダリング中（例えばＧＰＵ上で）、又は両方のタイミングで利用することができる。
【００６１】
２．グラフを低減又は簡単化するためのグラフ再書込み
本発明の幾つかの実施形態で利用される別の効率化技術は、不要なノードを削除することによってグラフを最適化することである。成功すると、これは、一般的に一時イメージ全体及びこれに応じたバッファの必要性が排除されるので、その節約において重大な意味を持つ。更に、ノードの統合又は削除は、実行中の処理サイクルを節約することになる。
【００６２】
統合のために、Ｃｏｒｅ Ｉｍａｇｉｎｇは、削減することのできる隣接するノードのペアを見つけなければならない。一般的に２つのノードは、１つのノードの出力が第２のノードの入力である場合には１つに減らすことができる。例えば、ノードアルファの出力がアルファバッファとして定義され、ノードベータの入力がアルファバッファに格納されたテクスチャである場合、２つのノードは結合することができる。
【００６３】
コンピューテーションサイクルの点では、２つのノードを結合できるかどうかを判定することは、比較的高コストの解析となる可能性がある。従って、２つのノードを結合できるかどうかに関する判定を行う際にその判定をキャッシュすることができる。明確にするために、幾つかの実施形態では、肯定的な結果と否定的な結果の両方をキャッシュすることで、プログラムは、キャッシュされた結合を見つけるためだけでなく、結合が不可能であるか否かを判定するためにもキャッシュを用いることができ、その結果、解析を行う時間が無駄にならないようになる。例示的な実施形態が図８に示されている。結合照会８１００の実施において、第１ステップ８１０１で、これらのノードでの解析の結果が以前に行ったものでありキャッシュに常駐しているかどうかを判定する。従って、ステップ８１０１でシステムは、事前に解析された結合結果のキャッシュをチェックする。更に、説明しているルーチンは通常ＣＰＵ上で実行しているので、このキャッシュは多くの実施形態においてシステムメモリを使用する。最後に、キャッシュにタグを付ける方法の実施例として、１つの実施形態において、キャッシュキーは４つのデータの要素、すなわち（１と２）２つのノードプログラムの表示、（３）従属ノードプログラムからの出力を受け取る上位ノードプログラムのテクスチャユニットインデックスの表示、（４）出力値を範囲０，１にクランプする必要があるかどうかを指定するブール値の表示を有する。
【００６４】
ステップ８１０１に戻ると、この決定ステップで３つの可能な経路が存在する。第１に、結果をキャッシュすることができ、ノードを結合することができる。この場合、制御はステップ８１０３に進み、キャッシュ結果を使用して結合が行われる。次いで制御はステップ８１０４に進み、次のノードを見つけて解析する。第２に、結果はキャッシュされるが、ノードは結合されない。この場合、制御は次のノードステップ８１０４に直接進む。第３に、最終的には結果はキャッシュ内に存在しない場合がある。この場合、制御はステップ８１０２に進み、提案されたノードの結合が可能であるかどうかを判定する。ステップ８１０５で示されるように、結合が可能であるか否かに関係なく、結果はキャッシュされる（結合が不可能であるか、又は結合が可能であるかを示し、結果を記憶する）。ステップ８０１２で、結合が可能である場合には、ステップ８１０６で行われるが、実際には、幾つかの実施形態では解析中に結合を行う。結合が行われた後、制御は次のノードのための８１０４に進む。最後に、結合が不可能であるとステップ８１０２が判定した場合、制御は次のノードのためのステップ８１０４に進む。
【００６５】
３．２つのノード結合の実施形態
図４及び図９を参照し、ノード４１５、４２０が結合できるか否かをＣｏｒｅ Ｉｍａｇｉｎｇが解析すると仮定する。ステップ９１００で始まると、ほとんどの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ノード４１５の出力がノード４２０の入力に事実上十分に近い場合にこれらのノードを結合しようとする。多くの実施形態において、ノード４１５の出力は、出力バッファが入力テクスチャの常駐する場所に存在するはずである点において、ノード４２０の入力と同じでなくてはならない。しかしながら、別の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、このような出力と入力から正確な結果が得られ、或いは更に別の実施形態では正確に近い結果が得られるほど十分に類似しているかどうかを評価することができる。
【００６６】
決定９１００に戻り、それぞれの出力と入力が十分類似していない場合、ノードはステップ９１０３に示されるように結合されない。しかしながら、それぞれの出力と入力が十分類似している場合には、制御はステップ９１０１に進み、第２ノード（この実施例ではノード４２０）に関連したフラグメントプログラムの各ラインをチェックする。ラインチェックについては後述するが、このプロセスのレベルでは、各ラインは、ノード４１５と４２０の結合の可能性を否定しないことを確認するためにチェックされると仮定する。更に、結合を容易にするために些少の変更が幾つかのラインで行われる。従って、ステップ９１０１でのラインチェックがノード結合を否定する結果をもたらす場合には、ノード４１５、４２０は、ステップ９１０３で示されるように結合されないことになる。或いは、ステップ９１０１でのラインチェックがノード結合の可能性を継続して示す場合には、制御は、ハードウェアが結合されたノードを扱うことができるか否かを判定する、決定ステップ９１０２に進む。一般的な意味で、これは、メモリ、いずれかのマイクロプロセッサの特性、又はシステム状態などのシステム内の何らかのハードウェア制限を意味する可能性がある。更に特定の意味において、ほとんどの実施形態は、必要なルックアップ又はレジスタが多すぎるかどうかを確認するために常駐ＧＰＵの能力のチェックだけを必要とする。明らかに、（エミュレーションが使用されない場合）常駐ハードウェアがノード４１５、４２０の結合を処理できないとステップ９１０２が判定した場合には、ステップ９１０３で示されるように結合を行うことはできない。或いは、ハードウェアが結合されたノードを扱うことができるとステップ９１０２が判定した場合には、制御は、一連のタスクがノードの結合を終了し始めるステップ９１０４に進む。
【００６７】
ステップ９１０４で、ノードのためのプログラムコードが実際に連結される。ステップ９１０５で、標準的なプリコンパイラ・オプティマイザープログラムが適用される。これは、本発明の幾つかの実施形態の主題である最適化ではない。これは、容易に利用可能なプリコンパイル最適化ルーチンである。次にステップ９１０６で、レジスタを割り当てる命令が適用される。最後にステップ９１０７で、結果が今後の結合解析のためにキャッシュされる。
【００６８】
この実施例を説明する場合、第２プログラムの各ラインのチェックであるステップ９１０１に僅かな注意しか払われていなかった。ここで図１０を参照し、更に詳細にこのプロセスを調べることにする。ステップ１０１０７で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、解析のための次のプログラムラインを探す。次のラインは、第２ノード４２０を表すプログラムの第１ラインとすることができる。制御は決定ステップ１０１００に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇは、プログラムラインにローカル変数があるかどうかを判定する。このようなローカル変数がある場合、該ローカル変数は、第１プログラム（この実施例でノード４１５を表すプログラム）のローカル変数と競合しないようにリネームする必要があるので、制御はステップ１０１０１に進む。幾つかの実施形態において、全てのローカル変数は、各フラグメントプログラムにおいてゼロから始まる連続した整数で番号が付与される。従って、第２フラグメントプログラム（ノード４２０を表す）のローカル変数をリネームする際に、（１）第１の新しい名前は、第１プログラムの最も大きな番号が付けられたローカル変数に単に加算することによって得られ、（２）次のローカル変数は、基本名として第１リネームローカル変数を用いて順次名前が付けられる。
【００６９】
プログラムラインのローカル変数がリネームされると、制御は決定ステップ１０１０２に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇがプログラムラインにおいてテクスチャ基準を捜す。リネームが必要なローカル変数がない場合には、決定ステップ１０１００もステップ１０１０２に至ることは注目に値する。いずれの場合でも、決定ステップ１０１０２でＣｏｒｅ Ｉｍａｇｉｎｇは、プログラムラインにおいてあらゆるテクスチャ基準を捜す。テクスチャ基準が見つからなかった場合、制御は決定ステップ１０１０５に進む。テクスチャ基準が見つかった場合には、制御はステップ１０１０３に進み、見つかったテクスチャ基準が第１ノード（４１５）の処理のプロダクトであるかどうかを調べる。見つかったテクスチャ基準が第１ノードの処理のプロダクトでない場合、制御はステップ１０１０８に進み、必要に応じてテクスチャをリネームする。
【００７０】
見つかったテクスチャが第１ノードの処理のプロダクトであると仮定すると、制御は、ステップ１０１０３からステップ１０１０４に進み、そのテクスチャを単一の画素に置き換える。一般的な意味では、フラグメントプログラムが入力のテクスチャ全体と出力のバッファ全体を有するときには、フラグメントプログラムは一度に１つだけの画素を処理するので、１つのテクスチャを単一の画素に置き換える。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇが２つのフラグメントプログラムを結合又は連結することになる場合、これらのプログラムは、結合されたプログラムの拡張された長さ全体にわたり同じ画素を渡すために書き換える必要があり、単一の（結合又はそれ以外の）フラグメントプログラムによって生成された中間バッファは存在できない。結果として、幾つかの実施形態においてステップ１０１０４は、サブジェクト入力テクスチャに対するどのような基準も排除し、これをオペレーション中の画素を保持するレジスタ基準と置き換える段階を含む。ステップ１０１０４が終了した後、制御はステップ１０１０８に進み、必要に応じてテクスチャをリネームする。
【００７１】
テクスチャのリネームは、ローカル変数リネームと同じ原理とプロセスであるので、追加のコメントは実質上必要ではない。テクスチャリネームが行われた後、制御は決定ステップ１０１０５に進む。
【００７２】
決定ステップ１０１０５では、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レジスタによって識別された入力テクスチャの画素に対する何らかの基準をチェックする。このステップを詳細に説明するために、第２ノード（４２０）への入力テクスチャはテクスチャアルファであったと仮定する。また、テクスチャアルファは、レジスタベータの画素を優先してプログラムから書き出されたと仮定する。ステップ１０１０５で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レジスタベータに記憶された画素ではなく、テクスチャアルファの画素に対する何らかの基準を捜している。これは、２つのフラグメントプログラムの結合がテクスチャアルファ（中間イメージ）の生成を排除することになり、更に実行時において、テクスチャアルファに対するシステムだけの基準がレジスタベータ内の単一の画素になるためである。従って、第２ノード（４２０）のベースにあるプログラムがレジスタベータの画素以外の画素に対する実質的な基準を有する場合には、結合が生じることはできず、ステップ１０１０６で示されるように中止されるはずである。このような画素に対する基準が存在しない場合、プログラム制御はステップ１０１０７に進み、次のラインに移る。
【００７３】
本明細書で説明されるプログラムステップをレビューする場合、説明される機能と変更を有するコードのラインを処理するための多くの方法がある点に留意されたい。例えば、プログラムは、各ラインで一度に１つの項目を調べて特定の項目について全てのオプションにわって処理し、その後、単一のラインが終了するまで同じラインの次の項目に移ることができる。別の実施例では、プログラムは第１項目を読み取ることができ、それがローカル変数かどうかをチェックし、ローカル変数である場合これをリネームし、これがテクスチャ基準であるかどうかをチェックし、そうである場合にはこの基準が第１プログラムの出力に対するものであるかどうかをチェックし、以下同様である。重要なのは、開示された技術を考えると、熟練のプログラマであれば解析し、ラインチェックを進める方法を決定することができるということである。
【００７４】
４．定義ドメインに対する計算と記憶の制限
一般的な意味では、イメージは、これらが存在する座標系以外の何れによっても境界付けられない。ほとんどの座標系では、この「境界」は有用な制限を加えない。従って、イメージを考察する場合、発明者らはその定義ドメインを考慮することができる。イメージの定義ドメインは、イメージが定義される全ての場所の表現である（すなわち名前「定義ドメイン」）。定義ドメインに関して考察する実用的な方法は、明示的に定義され且つ透明でないイメージの全ての場所の表現としてのものである。定義ドメインの１つの実施例は、全ての不透明な画素が存在する幾何学形状である。
【００７５】
最適化技術を開発する場合、定義ドメイン（「ＤＯＤ」）は、ＤＯＤの外側の画素を計算又は描画する必要がないので魅力的である。従って、グラフを最適化する場合、ルートノード（最も高いノード、例えば図４のノード４１５）のＤＯＤを最初に計算する段階において用途がある。ルートノードのＤＯＤを有する場合、ノードの実質的な結果をその形状に交差させ、ＤＯＤの外に常駐する実質的な結果の全ての部分をレンダリングタスクと描画タスクから除去することができる。残念ながら、ノードのＤＯＤは、必ずしも利用可能ではなく、このような場合、ＤＯＤは有限とみなす必要がある。
【００７６】
一般的な意味では、ルートノードのＤＯＤは、グラフの底部から上向きに伝播させることによって計算される。図４を参照すると、リーフノード４２４、４２５、４２６、４２７、４２８、４２９から始めることによってルートノード４１５のＤＯＤを計算する。リーフノードが既に定義されているイメージを表現するので、これらは、より低いノード（実際的な問題として、リーフノードは通常、グラフでの読み取りコマンドである）に関係なくＤＯＤを有することができる。より高レベルのノードのＤＯＤは、ノードへの入力とノードが実行する機能を使用して計算される。幾つかの実施形態の実施において、システム内の各ノードタイプは、その利用可能な入力を考慮してＤＯＤを決定するための関数呼び出しを有する（これは、ノードがその出力ＤＯＤを含むことができる以前のステートメントをビューする１つの方法である）。別の実施形態において、最適化プログラムは、最適化中にＤＯＤ自体を計算する。また別の実施形態において、幾つかのノードに対するＤＯＤは最適化中に直接計算され、他のノードは、関数を呼び出すことによって間接的に計算される。例えば１つの実施形態では、簡単なノード（入力と出力の形状が同じであるノード）に対するＤＯＤを直接計算することができ、且つ難しいノード（入力と出力の形状が変わるノード）に対しては関数呼び出しを行うことができる。例証としてＤＯＤの計算を極めて要約して評価する。
【００７７】
ＤＯＤのこの計算は、解析されるノードのタイプに応じて僅かに異なる。例えば、ノード４１８の関数が単にカラー変換である場合、ノード４１７のＤＯＤは、リーフノード４２４のＤＯＤと同じになる。この同じ実施例は、入力イメージＤＯＤの形状（すなわち、範囲変更、カラー空間変換、イメージ色調）を変化させない全オペレーションに当てはまる。しかしながら、幾つかのノードは、いずれも複数の入力を有するので、或いは関数が入力ノードのＤＯＤの形状を変える（例えば、幾何学的変化）ので、計算がより複雑になる可能性がある。最初に複数のノード問題をみると、ノード４１７、４１８、４１９に対するＤＯＤは既に有しており、ノード４１６に対するＤＯＤを計算するものと仮定する。ノード４１６に対するＤＯＤは、入力ノードのＤＯＤの単純な関数であり、通常は入力ノードのＤＯＤの結合又は交差のいずれかである。結果のＤＯＤが、交差、結合、又は幾分複雑な関数であるかどうかはノードの関数に依存し、どのようなプログラマも評価しやすい。
【００７８】
ＤＯＤを計算する際、関数によって引き起こされるイメージ形状の変化は更なる検討を必要とする。これらのタイプの関数は、限定ではないが、関数の純粋なオペレーションに起因してイメージが形状を変化させるブラー（ブラー又はスケールオペレーションなど、通常ブラーはイメージをより大きくすることになる）のようなアイテムを含む。或いは、関数は、イメージを単に再配向（回転、オフセットなど）する。そのオペレーションは座標系内のロケーションを変えるだけである。いずれの場合においても、ほとんどの実施形態は、何らかの利用可能な入力に応じて出力に対するＤＯＤを呼び出す関数を要求することになる。あらゆる熟練のプログラマはこのような関数を記述することができる。
【００７９】
最後に、幾つかのノードは定義されたＤＯＤを持たないことを想起されたい。このような場合、ほとんどの実施形態は、ＤＯＤの値として無限を割り当てることになる。
【００８０】
５．関心領域に対する計算と記憶の制限
ノードに対するＤＯＤを有する場合、次に、関連するノードの関心領域（ＲＯＩ）を決定する。要約すると、関心領域は、所与の出力ＤＯＤを計算するのに必要な入力イメージの部分である。従って、各ノードはその出力上にＤＯＤを有し、各入力に対するＲＯＩを有する（グラフをビューする際に、リンク毎にＲＯＩとしてこれを概念化することができる）。ＲＯＩの実施例として、「大きな矩形」である入力イメージと「小さな矩形」である出力ＤＯＤを備えたブラーであるノード関数を仮定する。このブラー用のＲＯＩ関数は、入力イメージ「大きな矩形」のどの部分が出力ＤＯＤのブラー結果の部分を計算するのに関係するかを定義する形状を返すことになる。このＲＯＩ領域を理解することの重要性は、発明者らは単に入力イメージの関連部分を記憶する必要があるに過ぎず、中間段階の結果（及び同様に最終結果の幾つか）を記憶するためのメモリが節約され、最終的に無関係とすることができる画素にエフェクトを加える処理時間が節約されることである。例えば、リンク４６で発生するはずのバッファは、ノード２４の出力ＤＯＤとノード１７のＲＯＩの交差である関連の結果を記憶することのみ必要とし、このような交差は、最適化された結果の領域である。
【００８１】
ＤＯＤ計算のように、幾つかの実施形態の実施において、ノードのＲＯＩを決定するために関数が使用される。またＤＯＤと同様に、幾つかのＲＯＩは、これらがノード両端のリンク上に見られる値に単に同一であるので容易に決定される。例えば、リンク４５が「アルファ」のＲＯＩを有し、且つノード４１７がカラー変換である場合には、リンク４６に対するＲＯＩもアルファであるが、ノード４１７がブラーである場合には、リンク４６に対するＲＯＩを決定することは、より難しい（これは、アルファとは異なる可能性が高く、恐らくは小さい）。幾つかの実施形態において、ノードに関連する関数は、決定が難しいＲＯＩを解決するために呼び出される。別の実施形態において、最適化ルーチンは、最適化中にＲＯＩ自体を計算する。更に別の実施形態において、幾つかのリンクに対するＲＯＩは最適化中に直接計算され、他のリンクは、関数を呼び出すことによって間接的に計算される。例えば、１つの実施形態は、易しいリンク（入力と出力形状が同じリンク）に対するＲＯＩを直接計算することができ、難しいリンク（出力形状が入力形状と異なるリンク）に対し関数呼び出しを行うことができる。例証として、ＲＯＩの計算について極めて簡潔に説明することにする。
【００８２】
ＤＯＤ計算と同様に、ＲＯＩ計算はグラフツリーを介して伝播させる必要があるが、下のルートから上を意味する（ＤＯＤのように上のリーフからではない）。Ｃｏｒｅ Ｉｍａｇｉｎｇがグラフィックタスクの実行することを求められる場合、要求エンティティが出力に対するＲＯＩを提供するので、ルートノード（例えば４１５）は既知であると仮定することができる。他のＲＯＩを決定するためには、単にグラフツリーから後方へ伝播するだけである。例えば、入力／リンク４３に対するＲＯＩを計算するためには、結果における「既知の」ＲＯＩと４１５の関数とを考慮する。
【００８３】
６．ＲＯＩとＤＯＤの例示的な実施形態
上記で説明されたように、アプリケーションプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩを使用して高レベルグラフを構成する。これらのグラフの１つを使用するか、或いは他の手段により、アプリケーションプログラムのプログラマは、グラフィックタスクの実行をＣｏｒｅ Ｉｍａｇｉｎｇに依頼することができる。図１１（ａ）を参照し、タスクは結果ＲＯＩを描画するものであると仮定する。図１１（ｂ）を参照すると、Ｃｏｒｅ Ｉｍａｇｉｎｇに対する第１タスクは、ステップ１１１００で低レベルグラフを作成することである。低レベルグラフ（図１１（ａ）にツリーで示される）の作成にはより多く関わっているものがあるが、この実施例の目的においては、グローバルＤＯＤ（ルートノード１１６のＤＯＤ）を含む出力ＤＯＤがこのステップ１１１００の最後のノードで計算され表現されることを認識することだけが重要である。次にステップ１１１０１で、Ｃｏｒｅ ＩｍａｇｉｎｇはグローバルＤＯＤ及び結果ＲＯＩの交差を求める。便宜上、これを「結果交差」と呼ぶことにする。
【００８４】
次いで、Ｃｏｒｅ Ｉｍａｇｉｎｇは、決定ステップ１１１０２に進み、調べるべき更なるノードがあるかどうか判定する。この決定１１１０２は、熟練したプログラマには明らかである何らかの適切な方法で行うことができる。調べるべき更なるノードがない場合、プログラムは、ステップ１１１０３でこの最適化タスクを終了し、ジャストインタイムコンパイルの準備が整う。「更にノードがあるか？」決定１１１０２に戻り、最適化すべき更なるノードがある場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、次のノードの入力に対するＲＯＩを求める。ツリー歩行においてどれが次のノードであるかを決定するための種々の公知の方法があるので、ここではその話題については説明しない。
【００８５】
図１１の実施例の目的のために、ノード１１６（すなわちルートノード）に対する入力ＲＯＩを計算するタスクに関して、ノード１１６に留まり、ステップ１１１０４に留まる。上記で説明されたように、これは、直接或いは関数を呼び出すことによって決定することができる。いずれの場合も、リンク１１４、１１５に対するＲＯＩが決定され、グラフに挿入される。
【００８６】
ＲＯＩがノード１１６の入力に対して決定された後で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、決定１１１０２に戻り、クエリー「更にノードはあるか？」に答える。ノードがまだある場合、Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０４に進みノード１１５の入力ＲＯＩを決定する。ノード１１３がリーフノードであり入力を持たないので、ノード１１３についてのＲＯＩ計算はない点に留意されたい。従って、入力ＲＯＩがリンク１１８、１１２に対して決定されグラフに挿入される。
【００８７】
Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０２に戻り、更にノードがあるかどうかを判定し、ノードある場合には再度ステップ１１１０４に進み、ノード１１４に対するＲＯＩを決定する。１１２はリーフノードであり、そのため計算は必要ではない点に留意されたい。１１１に対するＲＯＩが決定されグラフに入力される。
【００８８】
制御は決定ノード１１１０２に戻り、もはやノードがないことを判定する（ノード１１１はリーフである）。Ｃｏｒｅ Ｉｍａｇｉｎｇはステップ１１１０３に進み、終了する！
【００８９】
グラフはＲＯＩとＤＯＤに対して最適化されているが、ノードの統合やキャッシングのような他の最適化は、この上にレイヤを形成することができ、或いは同時に実行できる。
【００９０】
７．再帰的実行の実施形態
上述のように、プログラマは、種々の順序で最適化技術の編成の効率を求めることができる。しかしながら、本発明の幾つかの実施形態は、グラフの一部分だけにわたる定義シーケンスにおける技術の１つ又はそれ以上を実施する。特に、同じ（又は類似の）プログラムシーケンスは、グラフの一部分に対し一度に１つの部分を再帰的に加えることができる。この方法は、メモリ再使用及びシーケンシャル処理（ある程度までの）に対する機会を提供することによって、効率の向上を可能にする。簡単にするために、キャッシングの概念はこれらの実施形態の説明から大部分が省かれている。しかしながら、本明細書の開示事項が与えられると、当業者であれば、キャッシングステップを実装する必要がある場合を理解するであろう。
【００９１】
例証のために、図１２を参照すると、結果に到達するための本発明の再帰的実行の実施形態についてのフローチャートが示されている。別の言い方をすれば、実施例の目的はルートノードを計算することである。ステップ１２１００で、Ｃｏｒｅ Ｉｍａｇｉｎｇは、ルートノードを隣接するノードと結合しようとする。ノードが結合できる場合、そのプロセスは、各入力リンクに沿った複数のノードをルートノードにできる限り吸収するように実行される。制御はステップ１２１０１に進み、ここでＣｏｒｅ Ｉｍａｇｉｎｇは、（できる限りマージされた）ルートノードに対するＤＯＤを決定する。ＤＯＤが既知である場合、制御はステップ１２１０２に進み、ここでＲＯＩがルートノードへの子リンクについて計算される。ＲＯＩとＤＯＤを有する場合、この２つは、結果領域を決定するために交差させることができる。制御はステップ１２１０４に進み、ルートノードの入力に対するテクスチャを作成する。これらの入力テクスチャは、ルートノードをレンダリングするために必要である。しかしながら、多くの場合ノードの入力テクスチャは未計算であり、グラフによってのみ表現される。このような場合、Ｃｏｒｅ Ｉｍａｇｉｎｇは、この実施例で説明されるステップに類似のステップを各従属ノード上で再帰的に処理しなければならない。従って、図１２に示されるプロセスはネストされた方式で加え、グラフを下に移動し、ルートノードを計算するために最終的には解決する必要のあるノードを解決する。別の言い方をすると、ノードを解決するためのプロセスは、ルートノードへの入力のためのテクスチャを計算するのに必要な全ノードを制御が解決するまでネストされた方式で加えられる。ルートノード入力テクスチャが計算された後で、制御は、結果に対するバッファの作成のステップ１２１０４に進む。最後に、制御はステップ１２１０５に進み、ここでＧＰＵが結果をステップ１２１０４で作成されたバッファにレンダリングするのに使用される。
【００９２】
再帰的プロセスに焦点を合わせるために、上記説明からキャッシングの概念が故意に省かれていたことを理解されたい。しかしながら、キャッシングは、ノード結果とノード結合の解析と結果を限定ではなく含む、種々の場所で利用することができる。
【００９３】
更に別の再帰的に処理される実施形態が、図１３にフローチャートで示されている。図１３を参照すると、ステップ１３１は、ルートノードの計算に取り組んでいることを示している。その際に、ステップ１３２では、ルートノードを隣接するノードと結合することが可能かどうかを判定する。ステップ１３３に従って、結合が可能である場合、結合が行われ、更なる結合が可能ではないと判定されるまで継続して結合を行う（ステップ１３１、１３２、１３３を介して）。このような判定の後で、制御は、ＤＯＤとＲＯＩ最適化のステップ１３４、１３５に進む。次に、決定ステップ１３６は、ルートノードをレンダリングすることが可能かどうかを判定する。ルートノードへの入力の全てが計算された場合のみルートノードをレンダリングすることが可能になる。従って、決定１３６への答えがノーであると仮定すると、制御は、ルートノードを求めるのに必要な紛失子テクスチャ(missing child texture)を生成するタスクのためのステップ１３１０に進む。１３１０の下の次のプロセスがルートノードを求めるプロセス全体に極めて類似していることは注目すべきである。特に、サブノードとルートノードを求めるために同じルーチンが使用される。しかしながら、これらのルーチンは、グラフの複数のノードを求めるためにネストされた方式で呼び出すことができる。或いは、これらのルーチンは、一度に幾つかのノード、関係のないグラフの偶数ノードを求めるために並行して実行することができる。
【００９４】
ここでステップ１３１１に戻り、次の子ノードを決定する必要があり、解析する次のノードを単に適切に選択する。ステップ１３１２、１３１３は、ステップ１３２、１３３に類似する。ステップ１３１４、１３１５、１３１６は、ステップ１３４、１３５、１３６に類似する。ステップ１３１７は、ステップ１３７、１３８に（略して）類似する。ステップ１３１９は、サブノードがその入力テクスチャが利用不能であるためにレンダリングできない場合、次のノード（ステップ１３１１）はネストされた演算処理で計算される可能性があることを示している。同様にステップ１３１８は、ノードが求められてレンダリングされた後にレベルをネストしていない可能性を示している。
【００９５】
最終的に、ステップ１３１１で、求めるべき子がない場合、制御はステップ１３７、１３８に進み、ここでバッファがルートノードの結果に対して形成され、ルートノードがコンテキストにレンダリングされる。
【００９６】
更に別の実施形態又は再帰的オペレーションにおいて、図４、１４を参照し、図４に示されたグラフをＣｏｒｅ Ｉｍａｇｉｎｇによって最適化及びレンダリングしなければならないと仮定する。ルートノード４１５から始めて、Ｃｏｒｅ ＩｍａｇｉｎｇはグローバルＤＯＤとのグローバルＲＯＩ交差を計算することによってステップ１４１００で開始する。制御はステップ１４１０１に進み、次のノードがあるかどうかを判定する。次のノードがない場合、処理はステップ１４１０６で示されるように完了する。しかしながら、この場合、ルートノード４１５は次のノードである。制御はステップ１４１０２に進み、入力リンク４２上のノード４１５に対する入力ＲＯＩを得る。このような入力ＲＯＩを取得すると、制御は決定１４１０３に進み、４１５／ＲＯＩの結果がキャッシュ内にあるかどうかを判定する。４１５／ＲＯＩイメージがキャッシュ内にある場合、制御は決定ブロック１４１０１に戻り、処理すべき更なるノードがあるかどうかチェックする（その結果がキャッシュ内で見つかった場合は、システムは見つけたノードの下の全グラフを処理する必要がないことを想起されたい）。この場合において、４１５／ＲＯＩの結果がキャッシュ内に存在せず、制御がバッファ割り当てステップ１４１０４に進んだと仮定する。このステップで、バッファが定義され、４１５入力ＲＯＩのサイズに割り当てることができる。次いで、制御は決定ステップ１４１０５に進み、ノード（４１５）がこの時点でレンダリングすることができるかどうかを判定する。実際には、これは、直前で定義されたバッファにノード４１５をレンダリングするコマンドとすることができる。
【００９７】
図４から分かるように、ノード４１５はルートノードであり、レンダリングする準備が整っていない。ステップ１４１０５でＹの決定を後で処理する。ノード４１５はレンダリングする準備ができていないので、制御はステップ１４１０７に進み、次の隣接するノードをノード４１５にコラプス(collapse)されるかどうかを判定する。このステップではシステムは、ノード４１５を次の隣接するノードにコラプスされる（上記で詳述されたように）かどうかを判定しなければならない。本明細書の他の場所でも説明されるように、結合決定とオペレーションは第２キャッシングシステムを含み、システムは、２つのノードをコラプスされるかどうか、その場合、コラプスの結果をルックアップすることができることができる。
【００９８】
ステップ１４１０７での決定に戻り、４１５が隣接するノードに結合できる場合には、制御はステップ１４１１２に進み、結合が行われる。次いで制御はノード１４１０１に戻り、ここで解析のための次のノードが新たに作成される４１５。結合が不可能であることをステップ１４１０７が判定した場合には、制御は決定ステップ１４１０１に戻り、解析のための次のノードを決定する。幾つかの実施形態の実施において、ステップ１４１０７での「ＮＯ」はノード４１５をそのまま残し、ステップ１４１０１への戻りは、ネストされた方式で次のノード上でルーチンを実行する。ネストは無限に深く進むことができ、最終的には次のノードステップ１４１０１でネストを解除する（一度に１つのネスト）ことによって解くことができる。
【００９９】
次にステップ１４１０１に戻り、次のノードが４２０であることを判定して、制御はステップ１４１０２に進み、ノード４２０に対する入力ＲＯＩを検索又は計算する。ＲＯＩが決定されると、制御は決定ノード１４１０３に進み、ここで４２０／ＲＯＩ結合がキャッシュ内でチェックされる。キャッシュミスがあると仮定すると、制御はステップ１４１０４に進み、バッファが割り当てられる。次いで制御は、ステップ１４１０５に進み、レンダリングが可能であるかどうかの決定を行う（この場合も実際にはこれは、単に４２０をレンダリングしようとする試みとすることができる）。図４は、ノード４２０がレンダリングできないことを示しており、その結果、制御はステップ１４１０７に進み、ノードのコラプスの可能性に関して判定する。判定がやはり否定であると仮定すると、制御はステップ１４１０１（幾つかの実施形態においてはルーチンの第２ネストのためのもの）に戻る。
【０１００】
１４１０１で、次のノードはノード４２２であると決定される。入力ＲＯＩがステップ１４１０２で求められ、制御はステップ１４１０３のキャッシュチェックに進む。ここで、ノード４２２とその下の全てが解決され記憶されるようなキャッシュヒットを有すると仮定する。次いで制御はステップ１４１０１に戻り、ここで次のノードはノード４２１になる（ノード４２０は、リンク４９に続くツリーの小さな部分によりレンダリングできないままである）。４２１に関しては、入力ＲＯＩがステップ１４１０２で求められ、決定１４１０３でのキャッシュミスを仮定する。ステップ１４１０４で、４２１ＲＯＩに対するバッファが定義され、ステップ１４１０５で、ノード４２１がレンダリングすることができることが分かる（ノード４２７、４２８はツリーリーフ又は入力イメージであるので、ノード４２１のレンダリングを妨げない）。
【０１０１】
ノード４２１をレンダリングする能力を考慮して、制御はＲＯＩ／ＤＯＤ最適化のためのステップ１４１０８に進む。ここでノード４２１の出力ＤＯＤをノード２０の入力ＲＯＩと交差させ、レンダリング中に書き込まれることになる最終のバッファのサイズを最小にする。幾つかの実施形態では、ステップ１０４で行われたバッファ設定を調整する。次いでノード４２１はコンパイラに渡され（ステップ１４１０９）、コンパイルされた結果がレンダリングされる（ステップ１４１１０）。レンダリングの後で（又はこのプロセスの幾つかのポイントで）、多くの実施形態は、バッファによって発生するメモリ使用量と、その空間を自由に又は再利用するよう設定することができるか否かを再検討することになる。この考察はステップ１４１１１において表す。
【０１０２】
制御はここでステップ１４１０１に戻り、ここでノード４２０がレンダリングの準備ができていることが最終的に判定されることになる（ステップ１４１０５）。レンダリングが上記で説明されたように行われることになり、最終的に制御は、ノード４１０の検討のためのステップ１４１０１に戻る。ノード４１０／ＲＯＩがキャッシュされると仮定すると、レンダリングは最終的には結果ノード４１５上で行われることになる。
【０１０３】
Ｆ．簡単なコードの実施例
例証として、以下は、Ｃｏｒｅ Ｉｍａｇｉｎｇ ＡＰＩが簡単な露出フィルタにどのように用いることができるかを示すコードの実施例である。
【０１０４】
【表１】
【０１０５】
同様に例証として、以下は、本発明の実施形態によるフラグメントを結合する実施例である。
【０１０６】
【表２】
【０１０７】
Ｇ．Ｃｏｒｅ Ｉｍａｇｉｎｇが作成するＣＰＵコードとＧＰＵコード
高レベルフィルタ結合をコンパイルする際に、Ｃｏｒｅ Ｉｍａｇｉｎｇは、レンダリング中に実行するための複数のオブジェクトを生成する。Ｃｏｒｅ Ｉｍａｇｉｎｇのこの特徴は、複数の異機種プロセッサを備えたシステムに広く適用可能である。例えばこれは、ジャストインタイムコンパイルを行い、航行中の航空機で行われる天気予報計算を分割するのに有用である。ジャストインタイムコンパイルにより、効率アルゴリズムがどの処理資源を使用するかを判定する際に航空機（飛行中）の状態を考慮に入れることができる。この一般的なプロセスは、７つのステップに要約できるが、効率的なシステムでは、これらのステップのサブセット上で動作することができ、すなわち、（１）プロセッサ、コントローラ、メモリ空間などのどの資源が有功に利用可能であるかをチェックする；（２）資源の各々の能力を評価する；（３）各資源の動作状態をチェックする；（４）現在のタスクの要件を評価する；（５）利用可能な資源の一部又は全てに関してタスクの要件を解析する；（６）システム内のハードウェア使用量の全体的な効率を高めながら（一般的にはタスクによって使用される資源を低減させるが、恐らくは十分に利用されていない資源又は使用されていない資源を用いる）、タスクの要件を満たすようにソフトウェアを最適化しコンパイルする；（７）コンパイルされたコードを実行する；である。実施形態によっては、１から５までのステップを実行時又は実行前に行ってもよいが、ステップ６と７は、実行時又は実行時の近くで行う場合にプロセスにおいて最も有用である点は注目すべきである。
【０１０８】
ハードウェア能力、タスクの特性と困難度、作業の効率的な分割を決定する際のリアルタイムの状態を考慮することができるこのプロセス（全体又は短縮型）に対し実質上無限のアプリケーションが存在する。これらの実質上無限のアプリケーションにも関わらず、Ｃｏｒｅ ＩｍａｇｉｎｇがＣＰＵコードを作成する３つの一般的な理由がある。その１つは、ＣＰＵ上でＧＰＵをエミュレートするためであり、これは後で説明する。二番目の理由は、オフラインレンダリングを行うためにＣＰＵを使用することにより効率が厳しくなるためである。最後の理由は、タスクがＧＰＵのハードウェア能力を越える場合のような絶対的な必要性のためである（これも後の部分で幾分説明する）。
【０１０９】
第１及び第３の理由を他の箇所で説明するので、ここで第２の理由について実施例を提供して簡潔に説明する。複数のプロセッサに対する最も重要な恩恵は、並行して作動する能力である。アプリケーションプログラムが、フィルタリングルーチンのシリアルアプリケーションを必要とするタスクを提示する場合には、並行処理は最も容易に設定される。一例として、図１５（ａ）を参照すると、６フレームシーケンス上でシリアルに動作するＣＰＵとＧＰＵのタイミングを示すチャートが示されている。この実施例の目的のために、各フレームにシーケンシャルに加えられる２つのエフェクトがあり、ＣＰＵが第１のエフェクトを加え、ＧＰＵが第２のエフェクトを加える。ＧＰＵはフレーム１を始め、ＧＰＵはアイドル状態又は他の動作中である。第１エフェクトがフレーム１に加えられた後、フレームは、第２のエフェクトを加えるためにＧＰＵに渡される。ＧＰＵは第２のエフェクトをフレーム１に加えるときには、ＣＰＵは第１のエフェクトをフレーム２に加えている。プロセスが続行し（チャート１５（ａ）に示される）、簡単な並行処理を使用してハードウェアを極めて効率的に利用し、２つのエフェクトをストリームに迅速に加えるようになる。図１５（ｂ）と図１５（ｃ）を参照すると、４つのプロセッサ（図１５（ｂ））又は２つのプロセッサ（図１５（ｃ））のいずれかで４つのエフェクトを加えることに関する効率を伝える類似のチャートが示されている。図１５（ｃ）でのネストが多くの方法で配置され、どのような数のエフェクトをどのような数のプロセッサにも加えることができることは注目すべきである。効率は、エフェクトの適用をシリアル化することで実現される。効率は、各エフェクトに対して必要な作業がタスクを実行するプロセッサに最適である場合に更に向上させることができる。例えば図１５（ａ）で、ＣＰＵが第２エフェクトを加えるために好適である場合には、ＣＰＵとＧＰＵとの間で処理するフレームの順序が逆にされる。
【０１１０】
Ｈ．エミュレーション：Ｃｏｒｅ Ｉｍａｇｉｎｇ生成ＣＰＵコード
上記で説明されたように、過去数年の間、フレキシブルなグラフィック関連ハードウェアとソフトウェア技術は、本発明の多くの実施形態のような有用な技術のベースを発展させ提供してきた。特に、ＯｐｅｎＧＬとプログラム可能ＧＰＵなどの技術の出現は、本明細書で説明される技術革新の多くに対するツールを提供した。しかしながら、これらのツールは、必ずしも後方互換性があるものではなく、利用可能なインフラストラクチャ（例えばプログラム可能ＧＰＵ）がないため、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能の全てがあらゆるプラットフォームで実行可能な訳ではない場合がある。従って、Ｃｏｒｅ Ｉｍａｇｉｎｇのサービスに依存するプログラマ又はプログラムが存在する場合、これらのプログラマ又はプログラムは、Ｃｏｒｅ Ｉｍａｇｉｎｇのサービスの一部又は全てが利用可能でない場合に特定のプラットフォーム上で損なわれる可能性がある。
【０１１１】
実際的な実施例として、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能などを提供するためにオペレーティングシステムを設計する場合、恐らくは、本明細書の実施形態の多くで説明されるような高レベルグラフィックの呼出しを行うようにアプリケーションが設計される。しかしながら、新しいオペレーティングシステムが用いられるとしても、古いコンピュータでこれらのアプリケーションを実行しようと試みることを想定した場合には問題が生じる。具体的には、Ｃｏｒｅ Ｉｍａｇｉｎｇに対して呼び出しが行われ、ＧＰＵが通常通りにレンダリングを行う場合に問題が発生する。この理由のために、Ｃｏｒｅ Ｉｍａｇｉｎｇの機能の全て又は最大限があらゆるプラットフォームでも利用可能にすることができるように、Ｃｏｒｅ Ｉｍａｇｉｎｇがエミュレーション機能を備えるのが有用である。
【０１１２】
従って、非常に高レベル（システム機能）であることにより、必須ではないが、エミュレータが極めて有効となるタイミングがあることを知ることができる。しかしながら、Ｃｏｒｅ Ｉｍａｇｉｎｇの従来の適用性は、この開示事項の誘因となるが、本明細書の革新性はこれに限定されない。従って、エミュレータを用いることができるより詳細な状況に関して、説明を簡潔に行うものとする。特に発明者らは、プログラム可能ＧＰＵ又はどのようなＧＰＵも無い場合のエミュレータの有用性を既に指摘した。しかしながらこれに加えて、ＧＰＵを含むシステムでもエミュレーションの有益な用途を有する場合がある。特に、問題であるのは、特定のＧＰＵの資源の限界を越える可能性があることである。例えば最新のＧＰＵでは、２０４８×２０４８を越えるイメージは一般に大きすぎる。更に、正確な結果を得るには、ＣＰＵを必要とする可能性がある（現在ＡＴＩから入手可能なような幾つかのＧＰＵは、２４ビット浮動小数点だけを使用する）。当然、特定のグラフ又はノードを求めるためにエミュレータが役立つことができる多数の他のハードウェア制限及び場合によっては低レベルのソフトウェア検討事項が存在する。
【０１１３】
１．エミュレートの決定
エミュレートを行う決定は、ホストシステムの特性とエミュレーションの事由に応じて種々のタイミングで行うことができる。例えば、プログラム可能ＧＰＵサポートがないシステムでは、ソフトウェアスイッチは適切なグラフィック呼出しをエミュレートするように構成を恒久的に設定することができる。或いは、Ｃｏｒｅ Ｉｍａｇｉｎｇが特定のタスクに対して呼び出された後でこの決定を行うことができる。この場合、タスクの特性は、常駐ＧＰＵの特定の機能を考慮するだけでなく、場合によってはプロセスの状態やハードウェア項目を考慮する。幾つかの特定の実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、グラフィック呼出しの時点でエミュレーションに関する決定を行う。このような実施形態の幾つかにおいては、エミュレーションは、常駐ＧＰＵが存在しないか、或いは常駐ＧＰＵがプログラム可能でない場合に使用される。これらの実施形態の他のものでは、グラフ最適化が少なくとも部分的に加えられた後で決定が行われ、ＧＰＵが特定のフラグメントを処理できないか、或いはこのような特定のフラグメントはＣＰＵ上でのエミュレーションにより処理する方が賢明であるかが判定される。更に別の実施形態において、エミュレートの決定は、グラフィック要求のソース又は出力のデスティネーションに依存する。これは、グラフィック要求に対する全体のシステム応答をメモリオペレーションの速度を向上させることによって改善することができるためである。例えば、Ｃｏｒｅ Ｉｍａｇｉｎｇが結果をシステムメモリにレンダリングするよう求められる場合、エミュレーションはＣＰＵ上で行われることにより、その最終的なデスティネーションは、エミュレーションに関する１つの要因である。メインメモリへのアクセスは一般的に、ＧＰＵからよりもＣＰＵからの方が高速である。同様に、ビデオＲＡＭ内のメモリオペレーションは一般にＧＰＵからの方が高速になる。従って、Ｃｏｒｅ ＩｍａｇｉｎｇがＶＲＡＭにレンダリングするよう求められる場合、これはＧＰＵを使用する傾向への要因である。
【０１１４】
２．ソフトウェアスタックでのレイヤとしてのエミュレーション
図３（ａ）、３（ｂ）を参照して、エリア３１００、３１０１におけるサービスを一般に提供するＣｏｒｅ Ｉｍａｇｉｎｇを説明した。Ｃｏｒｅ Ｉｍａｇｉｎｇエミュレータの多くの実施形態において、ＯｐｅｎＧＬ３６又は３２０のレイヤに存在するサービスに言及することができる。従って、これらの実施形態のエミュレータは、ＯｐｅｎＧＬでのほぼ同じレベルでサービスを提供する。これは、エミュレータがＯｐｅｎＧＬの下位のサービスを提供する別の実施形態との違いである。この違いは、1つには、前の実施形態がＯｐｅｎＧＬの（又は同様の状態にあるサービス）機能のサブセットだけに関するエミュレーションを提供することによって性能を達成することによって生じる。別の実施形態において、エミュレータはＯｐｅｎＧＬ（又は類似の）実装の一部とすることができる。更に別の実施形態において、エミュレータは、ＯｐｅｎＧＬ（又は類似のサービス）の下位とすることができ、より包括的な適用範囲を提供することができる。当然、これは性能を犠牲にする可能性がある。
【０１１５】
本発明のエミュレータ実施形態の説明の際に、実施形態の２つのセットに関する更に具体的な説明を行うものとする。実施形態の１つのセットは、ＧＰＵプログラム（例えばフラグメントプログラム）をターゲットの１つ又は複数のＣＰＵのための機械コードに直接コンパイルする段階を含む。実施形態の第２のセットは、各ＧＰＵ命令が高レベルプログラミング言語（３のような）における関数によってモデル化されるバイトコード仮想マシンを含む。実施形態のいずれのタイプにおいても、必須ではないが、低レベルグラフから始めるのが好ましい。更に、上記で説明されたようなグラフ最適化は、ノード、メモリ、計算を低減させることができるので、やはり最適化されたグラフから始めるのが好ましい。エミュレータはノードの一部とすることができるフラグメントプログラムで動作するので、エミュレータタスクは、上記で説明されたグラフウォーキングと解像技術の下位にレイヤされるものと見なすことができる。
【０１１６】
Ｉ．ＧＰＵプログラムの機械コードへの直接コンパイル
エミュレートの決定が行われると、多くの実施形態は、ＣＰＵ対応プログラムの以下の汎用プロセスを使用する。上記の説明から、ＧＰＵコードによる開始を仮定することは明らかなはずである。更に詳細には、これは通常、グラフのノードに関連付けられたフラグメントプログラムとすることができる。各フラグメントプログラムは、１つ又はそれ以上のＧＰＵ命令を有する。（これらはラインと呼ぶ場合がある。）次いでプログラムの各ラインは、ＣＰＵ等価命令に翻訳される。追加命令を含むラインのような多くのラインは、単一の命令ＣＰＵ均等物を有することができる。他のラインは、フラグメントコードの単一のラインが複数のＣＰＵ命令に翻訳する必要がある点で高度なエミュレーションを必要とする。翻訳のいずれかのタイプ（１対１又は１対多）は、熟練したプログラマが理解できるどのような種類の方式でも達成することができる。１つの好ましい実施形態において、命令翻訳は、大きな「ｉｆ」文によって行われる。別の実施形態において、テーブルやルックアップは、ＧＰＵ命令を等価の１つ又はそれ以上のＣＰＵ命令に位置合わせするために使用される。
【０１１７】
翻訳ステップ中、ＧＰＵコードは、どのようなレベルのＧＰＵ命令からもあらゆるレベルのＣＰＵ命令に翻訳することができる。例えば、翻訳はＧＰＵアセンブリからＣＰＵアセンブリに行うことができる。１つの好ましい実施形態において、翻訳は、ＧＰＵアセンブリと、現行の実装ではバイナリであるＣＰＵ機械コードとの間で行われる。
【０１１８】
プログラムがＣＰＵ命令として表現されると、コードをアンロール（展開）することができる。コードアンローリングと最終的な命令スケジューリングは、命令レベル並行処理（「ＩＬＰ」）を利用するかなり標準的な最適化技術である。ＩＬＰの一般的な目的は、ソフトウェア命令によって利用されるハードウェア並行処理の量を増大させることである。これが達成される１つの方法は、性能を最大にするために命令を再配置することである。更に具体的には、相互依存のない命令のグループを並行して実行することができる。ループアンローリングは、ＩＬＰ技術のクラスであり、ループに固有の並行処理を用いることによって効率が向上する。これは、単一のフラグメント、或いは詳細にはそのＣＰＵエミュレート等価物が多数の画素を解像するために極めて多くのループを実行する（１つの画素につき１ループ）ことになるので、グラフィックオペレーションにおいては重要である。ループアンローリングでは、ループのｎインスタンスがアンロールされ、すなわち、ループコードのｎインスタンスがプログラムラインに書き込まれる（例えば、ループに１０のラインがあり、ｎが４である場合、４０ラインのアンロールドコードがあることになる）。最後に、アンロールドコードは、この形式で実行するようにセットアップする必要があり、これは、変数のインクリメントやループを再始動させるブランチ又はｇｏｔｏコマンドへの調整が必要となる場合があることを意味している。アンローリング後、次にプログラムスケジューリングを使用して、サブジェクトハードウェアでの最大並行処理のためアンロールドコードを最適化する。アンロールドコードが最終的に実行される場合、オリジナルループの回数のｎ分の１だけのループを必要とし、各新しいループは遙かに少ない機能停止事象で実行される。
【０１１９】
アンロールされると、コード上での次の３つのステップは、標準的な最適化、レジスタ割り当て、プログラム／命令スケジューリングである。熟練したプログラマであれば、これらのステップの全てをどのように実行するかを理解するであろうが、ごく簡潔な説明を行う。この説明は網羅的或いは排他的ではない。言及されない多くの技術が存在することができる。更に、言及する技術の全てが提示するカテゴリの下で行われない場合もある。標準的なプログラム最適化は、コード短縮や重複除去などの多くの技術によって時間とメモリ性能を向上させることを目的としている。レジスタ割り当ては、競合を避け、使用されるレジスタの数を最小にし、出力エフェクトのない命令を拒否するように実行される。最後に、プログラム／命令スケジューリングは、特定のハードウェアのパイプライン及び並行処理のためのコードを最適化する。
【０１２０】
この時点までに多くを達成している場合、コードは今後このようにキャッシュされるので、この作業は不要である。
【０１２１】
１．特定の実施例の実施形態
図１６を参照すると、本発明のエミュレータの実施形態のサンプルプログラムフローが示されている。プログラムフロー及び説明は、例証のためだけのものとする。実際の実施形態は、フラットなフローチャートでは容易に説明できないオブジェクト指向手法を用いることができる。
【０１２２】
ステップ１６１を参照すると、プログラムは、通常多角形として境界付けられるイメージのレンダリング又は生成を要求するためにＣｏｒｅ Ｉｍａｇｉｎｇを呼び出す。制御は決定１６２に進み、ここでエミュレータを利用する必要があるかどうかが判定される。エミュレータが利用されない場合、この例の目的において、制御はステップ１６４に進み終了する。勿論、開示事項は他の場所でエミュレーションに対する代替形態を説明する。
【０１２３】
エミュレーションを利用するための考慮事項について上記で説明したが、ステップ１６２がエミュレータを使用することを決定し、制御はステップ１６３に進み、ここでデータがＣｏｒｅ Ｉｍａｇｉｎｇの他のルーチンからエミュレータにプッシュされると仮定する。詳細には、このデータは、サブジェクトフラグメントプログラム、フラグメントプログラムをレンダリングするのに必要なテクスチャ、ローカル変数、状態である。これらの項目がエミュレータに利用可能になった後、制御は決定１６５に進み、ＣＰＵ機械コードがこのタスクのために既に作成されたかどうかを調べる。フラグメントプログラムは、キャッシュへのインデックスとして使用される。しかしながら、キャッシュを実装するための種々の方法がある。ある実施形態においては、キャッシュルックアップは、必要なデータの全てについてのフォーマットを含むことができる。例えばキャッシュは、出力の画素フォーマット（１画素につき３２ビット、ＲＧＢＡなど）、／又は各テクスチャの画素フォーマットや状態などの情報を記憶しているテーブルから入力することができる。
【０１２４】
決定１６５に戻り、キャッシュヒットがある場合、制御はステップ１６９にスキップする。例証を完全にするために、キャッシュミスを想定すると、制御は、ＧＰＵフラグメントコードをＣＰＵコードへ変換するステップ１６７に進む。この変換のための技術は上記で説明されているので、この課題に対しては簡潔に対応する。ほとんどの実施形態において、このステップ１６７は、変換、アンロール、標準的な最適化、レジスタ割り当て、プログラム／命令スケジューリングの全てを行う。しかしながら、別の実施形態は、どのステップが既に完了しているかに応じて、多少の機能を実行することができる。同様の注意点が次のステップ１６８にあてはまり、ここでＣＰＵコード結果がキャッシュされる。ほとんどの実施形態はバイナリ機械コードをキャッシュし、熟練のプログラマであればより少なく処理された結果をキャッシュする事由を理解することができるであろう。
【０１２５】
ここでステップ１６９に移ると、機械コードは、画素評価のためのＮ長ループに配置される。このループのジョブは、Ｌ画素を評価することである。好ましい実施形態において、Ｌは１２８である。本明細書で説明される本発明はＬのほぼどのような値にもあてはまり、本発明者らは、その実施において１２８のＬ値が種々の検討事項（テクスチャルックアップによって引き起こされたより大きなオーバーヘッドによって、部分的なブロックを扱うことによって一度に多くの画素を処理したいという要求）のバランスをとる際の最適な性能をもたらすことが分かった。従って、ステップ１６９のループがＬ画素を評価することである場合、アンロールドコードは、ＬをＮで除算したものに等しい回数分ループしなければならず、ここでＮは、アンロールドコードで表現されるループの反復数である。最終的にはＮはＬ／ｎに等しい。従って、全ループにつき１２８画素の好ましい実施形態が利用され、４つのアンロールド反復を想定する場合、アンロールドコードを３２回ループしなければならない。
【０１２６】
ここでステップ１６１０に移ると、エミュレータによりスラブが生成される。好ましい実施形態において、これは関数呼び出しにより達成することができる。用語「スラブ」は、グラフィックアートにおいて比較的一般的な意味で使用される。しかしながらこの実施形態においては、スラブは、出力多角形上の全頂点で水平線を引くことによって形成される。例えば図１７を参照すると、図１７（ａ）には傾いた矩形とスラブに分割された同様の傾いた矩形が示されている。図１７（ｂ）では、同じ関係を有する２つの台形を示しており、一方は描かれたスラブを伴って示されている。
【０１２７】
スラブが生成された後、制御はレンダリングのためのステップ１６１１に進む。好ましい実施形態において、スラブは一度に１つレンダリングされる。特に、各スラブは、スラブの走査線上で見られるＬの連続した画素上で、ステップ１６９で作成された画素ループを実行することによってレンダリングされる。更に詳細には、多角形は、（ｉ）第１スラブを選択する段階（Ｘ、Ｙ、Ｚグローバル座標系を想定し、好ましい実施形態ではセクションが最も小さな値から最も大きなＹ値に進むことができる）；（ii）このような第１スラブ上で第１走査線を選択する段階（Ｘ、Ｙ、Ｚグローバル座標系を想定し、好ましい実施形態ではセクションは最も小さな値から最も大きなＹ値に進むことができる）；（iii）ステップ１６９で作成されたループを使用して走査線の第１のＬ画素をレンダリングし、次いで走査線が全てレンダリングされるまでこのステップを繰り返す段階；（iv）スラブ内の全走査線が終了するまで次の走査線（Ｌ画素の部分を含む）に進む段階；（ｖ）同様の方法で全ての後続のスラブを完了する段階によってレンダリングされる。更に、Ｌ画素のＣｏｒｅ Ｉｍａｇｉｎｇの選択がサービス要求者（例えばアプリケーションプログラム）に任されるので、幾つかの実施形態では、レンダリングされた結果を１つ又はそれ以上のバッファに一度に１画素ずつ書き出す。次いで、最終的な結果が、望ましいピースで要求デスティネーション内に配置することができる。例えば、結果は、Ｌ画素の終了後、或いは全部分（スラブのような）の終了後、或いは全多角形の終了後に要求デスティネーションに移動させることができる。この追加のステップはまた、フォーマット変換（バッファと要求されるデスティネーション間）のようなどのような後処理に対しても好都合な場所を作成する。
【０１２８】
走査線全体に渡るレンダリングを説明する際に、画素カウントがＬの倍数でない走査線の処理に関する疑問が生じる可能性がある。熟練したプログラマは、このケースを実施するための種々の方法を考案することができるが、本発明の幾つかの実施形態では、図１６に示されるプロセスのフレームワーク内でこの問題を考慮する。１つの特定の実施例では、ステップ１６９の画素ループは、ある変数（例えばアルファ）に従って何度もループする。従って、１２８画素でループが４回アンロールされる場合、アルファは３２になる。しかしながら、４８画素しかない場合（例えば、走査線全体で１２８ビットの数グループを処理した後）、アルファは１２に設定することができる。或いは、６６画素の場合、アルファは、第１の６４画素の処理のために１６に設定することができ、次にアルファは６５番目の画素と６６番目の画素を処理するために１に設定される。要約すると、これらの実施形態は、ルーピングを制御するために変数を使用すること、様々な量の画素を処理するためにその変数を調整することを必要とする。
【０１２９】
Ｌ画素の非倍数を処理するための別の方法は、様々な量の画素に対しアンロールドコードセグメントを提供する。例えば、メインループが４アンロールドセグメントを有する場合、３つのアンロールドセグメント、２つのアンロールドセグメント、１つのアンロールドセグメントで作成されたコードも存在する。従って、３つの画素がある場合、３画素コードを使用できる。１つの画素がある場合、１画素コードを使用できる。
【０１３０】
前述の技術を組み合わせた実施形態もある。例えば６６画素がある場合、アルファは、最初の６４画素を処理するために１６に設定され、次いで２画素コードを６５番目と６６番目の画素を処理するために実行される。或いは、６７画素の場合、アルファは、最初の６４画素を処理するために１６に設定され、次いで１画素コードを６５番目、６６番目、６７番目の画素を処理するために３回実行される。
【０１３１】
２．スラブ
多くの実施形態がスラブを使用する。スラブの代わりとして、説明された同じ方法で全多角形をレンダリングすることができる。しかしながら、スラブは、テクスチャ計算において有意な利点を提供する。特に、出力多角形の頂点に対してテクスチャ座標が知られている。ほとんどの実施形態において、これは、上にあるレイヤ（例えばグラフオプティマイザ）がこの情報を提供することによる。しかしながら、通常ハードウェアは、その基本ユニット多角形（一般に三角形）の頂点を関連するテクスチャマップにマップすることができ、ハードウェアの基本ユニット多角形の頂点は、出力多角形の頂点と一致しなければならない。図１７（ａ）、図１７（ｂ）を参照すると、これらの頂点は、円形のドットで示されている。図１７（ａ）、図１７（ｂ）を再度参照すると、スラブが形成される場合、スラブは通常、オリジナルの多角形上の頂点ではない１つ又はそれ以上の頂点を含む。図１７の全てにおいて、これらの「新しい」頂点は三角形で示されている。従って、１つ又はそれ以上の実施形態において、スラブが形成されると、新しい頂点のテクスチャ値（図１７の三角形）を種々の技術によって計算する。幾つかの実施形態では、既知の多角形頂点から座標値を補間することによって新しい頂点のテクスチャ座標を計算する。好ましい実施形態において、直線補間を用いて、分割スラブの端部まで補間される。その結果、各スラブは、既知のテクスチャ座標で３つ又は４つの頂点を有する。スラブの頂点での３つ又は４つの既知の座標で、スラブ上のどの画素のテクスチャ値も、補間、又はより詳細には直線補間のような数学的手法によって求めることができる。
【０１３２】
最終的に、スラブは多角形より小さいので、スラブはテクスチャ値の極めて容易な計算を提供する。詳細には、ここまで説明されたように、スラブは結果として得られる多角形の一部を含み、三角形又は４つの側面を有する多角形のいずれかとして生じる。三角形の場合、全頂点についてテクスチャ座標が既知であると、いずれのポイントの座標（及び最終的には値）も数学的（例えば、補間又は直線補間）に計算することができる。更に、スラブが多角形である場合、プログラムは、複数の数学的手法を使用して、多角形の点のテクスチャ座標を考案することができる。例えば、幾つかの実施形態ではプログラムは３つの頂点を選択し、直線補間を実行する。
【０１３３】
スラブの利点は、種々の形状によって実現される。例えば幾つかの実施形態において、結果として得られる多角形は、レンダリングのため全て三角形に分割することができる。これは、常に３つの頂点だけが存在するという点でテクスチャルックアップを簡素化することができる。従って、４つの側面がある多角形のどの３つの頂点を補間のため使用すればよいかに関して決定する必要性がない。更に、熟練したプログラマであれば本明細書で教示されている概念を他の方式に適用することができ、これによって結果として得られる多角形は、レンダリングのために分割される。
【０１３４】
３．テクスチャルックアップ
例えばスラブや多角形の頂点のコンテキストにおいてテクスチャルックアップを説明した。ここで、開示されてきた実施形態の幾つかに効率的にテクスチャルックアップを組み込む方法に関してより詳細に説明する。最初に、テクスチャルックアップの２つの関連するタイプを述べ、次に前述の説明に類似する可能性のあるコンテキストを提供することによって、この詳細な説明の裏付けを与える必要がある。
【０１３５】
エミュレーションタスクにおいて、遭遇する可能性のあるテクスチャルックアップの２つの一般的なタイプがある。公知のテクスチャへの座標である独立したテクスチャルックアップがある。例えば独立したテクスチャルックアップは、既知のテクスチャでの所与の座標を参照するコードにおける場所である。或いは、ある他の項目又は事象に依存するテクスチャルックアップである従属テクスチャルックアップが存在し、そのため、座標は通常レジスタ内にプログラムによって配置される。例えば、これは、所与のテクスチャへの座標がレジスタ内で見られるコードの場所とすることができる。テクスチャルックアップは、レジスタを読み込むことができるある他のオペレーションの結果に依存する。
【０１３６】
テクスチャルックアップ技術のためのコンテキストを設定する場合、種々の実施形態のために説明されたエミュレータのメインループ内の動作をより詳細に調べる。詳細には、これは一般に１６９のような図１６に関して説明するループに類似している。この類似性及び図１６を参照することによって、ステップ１６９でループをセットアップする際に、１２８画素の処理に影響を与えるためにループ内にアンロールドコードを単に配置する以外に達成すべきことがある。特に、画素の各グループ（スラブ、走査線、又は好ましくはＬ或いは画素の残りのグループ）について、コードをセットアップしなければならない。上記で説明されたように、コードのセットアップの部分は、走査線が１２８の倍数でない画素長（Ｌ）を含む場合、コードは残りの画素を考慮に入れることができるものとすることができる。更に、コードは、テクスチャルックアップに対しセットアップすることができる。
【０１３７】
ここで、テクスチャルックアップのサブジェクトに直接的を絞ると、エミュレータの好ましい実施形態は、テクスチャルックアップのメインループをセットアップする。１つの実施形態において、このようなセットアップは、Ｌ画素毎に行われ、独立と従属テクスチャ基準に対して別々にセットアップする段階を含む。これらの実施形態では、セットアップ中に各独立したテクスチャ基準は、好ましくは同じステップでルックアップされる。また、各従属テクスチャ基準では、従属性が満たされた後でルックアップを行うためにコード中に関数が挿入される。理解し易いように、関数呼出しは、各ルックアップに対してコードに挿入される。関数は、プログラムでの従属テクスチャ基準によってアクセスされるまで、テクスチャユニット毎に作成される。テクスチャルックアップ関数に渡される唯一の値は、ルックアップのための座標と使用するテクスチャである。更に正確には、コードのこの挿入された部分は、ループの外側で呼び出すことができ、このような関数は、本質的にＧＰＵテクスチャルックアップ機能をエミュレートする。１つの好ましい実施形態において、ループ内部からの関数呼出しは、テクスチャ、状態、座標を渡し、関数はベクトルを返す。しかしながらこの関数呼出しは、他の方法で実装してもよい。
【０１３８】
４．セットアップ
発明者らは既に幾度もコードのセットアップを説明してきたが、幾つかの例示的な実施形態を提供する。例えば、所与の実施形態において、各多角形についてセットアップされるコードの部分と、各スラブのためにセットアップされる部分、各走査線のセットアップの部分と、各画素グループ（例えば、Ｌ又は残りのグループ）に対してセットアップされる部分が存在することができる。所与のセットアップでの種々のアクティビティは、本明細書での他の説明から外挿することができる。
【０１３９】
Ｊ．複数のＣＰＵ
前述の実施例に類似する技術に従う実施形態は、複数のＣＰＵに極めて良好に適合する。これは、ステップ１６９（図１６）で作成されたループ機械コードが種々のスラブ又は種々の多角形上で別々のインスタンスにおいて実行できるためである。特に、Ｃｏｒｅ Ｉｍａｇｉｎｇ又は別の適切なプログラムは、プロセッサ間でタスクを分割することによってマルチプロセッサシステム上でのグラフィックレンダリングの速度を大幅に高めることができる。好ましい実施形態において、各プロセッサに送られることになるタスクのインクリメントは、スラブ（又は他の細分化されたもの）である。しかしながら、インクリメントは、より小さいもの（例えば走査線）又はより大きいもの（例えば全多角形）であってもよい。
【０１４０】
Ｋ．バイトコード化仮想マシン
仮想マシンはまた、ＣＰＵ上でＧＰＵコードをエミュレートするのに用いることができる。仮想マシンは、命令を受け取りプロセッサ資源を別のプロセッサにエミュレートすることができる点で、ハードウェアのように動作するプロセスである。一般的な意味で、仮想マシンエミュレータソリューションの利点は、仮想マシンがよりポータブルであることである。特に、仮想マシンは高レベル言語で記述することができ、次いでどのようなプラットフォームにもコンパイルすることができる。或いは、ＧＰＵプログラムを機械コードにコンパイルする実施形態は、各ハードウェアプラットフォーム用に特注とすることができる。
【０１４１】
１つの好ましい実施形態では、本発明は、バイトコード仮想マシンエミュレータを必要とする。形容詞「バイトコード」は、コンパイルされたコード、或いは幾つかの実施形態の場合においてハードウェアが受け入れるものに類似した低レベルのコードを仮想マシンプロセスが受け入れる意味が付加される。高レベルでは、仮想マシンは、ＧＰＵ対機械コードエミュレータを説明する実施形態でのＣＰＵに類似している可能性がある。より詳細には、仮想マシンは、上記で説明されたより高レベルの機能と技術の下に存在しているものとして概念化できる。従って、上記で説明されたエミュレーションや他の方法と技術の全ては、開示される仮想マシンエミュレータに類似しこれに適用することができる。しかしながら、独立した考慮事項に値する仮想マシン実施形態の興味深い態様がある。
【０１４２】
１つの実施形態において、仮想マシンは、出力画素を構築するための極めて大きな仮想レジスタを含む。特にハードウェアの制約が無ければ、仮想マシンは、効率などの他の基準の要求を満たすレジスタサイジングを使用することができる。従って幾つかの実施形態において、仮想マシンは、Ｌ画素幅である画素のレジスタをセットアップすることになる（走査線に沿って処理される１２８画素の実施例に戻り参照されたい）。レジスタのこの幅は、メインループ処理のための多くのオプションを提供する。一方の極端では、レジスタは、一度に（単一の画素ループ）処理される１つの画素を備える出力バッファとして機能する。他の極端では、メインループの各ステップは、次のステップに移る前に各画素で影響を受ける（これは、完全にループをアンロールすることに類似する）。これらの極端間のバランスをとるために、幾つかの実施形態では、従属問題を生じさせることなく概念的に出来るだけ多くループをアンロールするように仮想マシンを実装する。システムの考慮事項に応じて、画素レジスタは、Ｌの倍数又はＬの分数とすることができる。更に画素レジスタは、走査線のサイズ又は多角形動作セグメント（スラブなど）のサイズを一致させるように動的に実装される。
【０１４３】
実際にエミュレータの実施形態が実行しているとき、その実施形態は高いレイヤからの命令を受け取る。これはＣｏｒｅ Ｉｍａｇｉｎｇのより高いレイヤであるのが好ましい。概念的には命令はどのレベルのものでもよいが、好ましい実施形態では、命令はバイトコードなどの低レベルである。次いで、仮想マシンは、命令をＣＰＵのためのタスクに変換しなければならない。このような変換の第１部分は、ＣＰＵ認識可能命令への直接変換を行う「ｉｆ」文又はジャンプテーブルである。１つの好ましい実施形態において、仮想マシンは、Ｃ関数のようにＧＰＵ命令をモデル化する。このタイプの実施形態では、エミュレートされる各ＧＰＵ命令はＣ関数に相当する。次いで、Ｃ関数は、通常のコンパイラでＣＰＵ認識可能コードに変換される。ごく一般的には、好ましい実施形態において各エミュレートされたＧＰＵ命令は、Ｃ言語などの高レベル言語でモデル化される。高レベルモデルがコンパイルされ、その結果が、仮想マシンエミュレータのオペレーション中に使用されることになるジャンプテーブルの「ｉｆ」文に組み込まれる。最後に、エミュレーション中の要素（画素など）上で動作する場合、ＣＰＵベクトルレジスタは、ベクトルを記憶するために使用することができるのが好ましい。
【０１４４】
Ｌ．機能のサブセットのエミュレーティング
性能を得るために、多くの実施形態では全ての利用可能な低レベルグラフィック呼出しをエミュレートしない。一般に、利用可能なグラフィック命令のサブセットだけをエミュレートすることによって、サポートされる呼出しについてのより多くの想定が実装により行われ、従って幾つかの偶発事象が回避され、これによって作業を短縮することができる。例えば幾つかの実施形態において、Ｃｏｒｅ Ｉｍａｇｉｎｇは、透視用法の正確な補間に対し必要ではない。特にＯｐｅｎＧＬは通常、１つの補間されたテクスチャ座標あたりの画素毎に少なくとも１つの分割命令を必要とする。分割は、コンピュータ的に極めて高コストであり、Ｃｏｒｅ Ｉｍａｇｉｎｇのこれらの実施形態が透視図を持たないので、分割は必要ではない。オペレーションのサブセットだけをサポートすることによって向上する性能の別の実施例は、Ｃｏｒｅ Ｉｍａｇｉｎｇの幾つかの実施形態が少数のテクスチャフォーマットとデスティネーションフォーマットだけをサポートものである。これはデータ変換を制限し、より容易なインラインコード作成を可能にする。
【０１４５】
機能のサブセットだけをサポートする実施例として、１つの実施形態においてエミュレータは、（ｉ）４つの側面を持つ多角形の描画；（ii）テクスチャ結合；（iii）プログラム結合；（iv）ローカル変数の設定；及び（ｖ）デスティネーション設定などのＯｐｅｎＧＬの機能のサブセットだけをサポートする。
【０１４６】
この簡潔にされたタイプのサポートを実際に適用するための幾つかの方法がある。第一に、定義された高レベルＡＰＩは、エミュレートできないコマンドを受け取る可能性がないようにこれらの機能だけをサポートすることができる。例えば、Ｃｏｒｅ Ｉｍａｇｉｎｇが機能のサブセットだけをサポートする場合、Ｃｏｒｅ Ｉｍａｇｉｎｇエミュレータはこれ以上をサポートする必要はない。この場合、プログラム又はプログラマがサポートされていないグラフィック呼出しを使用したい場合には、ＯｐｅｎＧＬへの直接呼出し、又はＧＰＵの直接利用などといった、別のメカニズムを介してこれを行わなければならない。或いは、１つのエミュレーション技術は、エミュレートされる機能のサブセット（又はある別のサブセット）のために使用でき、別の技術は、全ての他のグラフィック呼出しのために使用できる。例えば、５つのエミュレートされた機能は、ＧＰＵ対機械技術を使用する実施形態を介してエミュレートすることができ、他の機能は、仮想マシン実施形態を通じてエミュレートすることができる。この構成は、最も一般的なグラフィック呼出し関する最高の性能を可能にし、他の呼出しをサポートするためのより容易なポータビリティとプログラミングを可能にする。勿論、この分割は、呼出しをサービスする難易度、又はそれぞれの技術による呼出しサービスの適性などの他の基準に沿って設けることができる。更に、２つのセットの技術（仮想マシン及びＣＰＵ対機械）は、システム内の全体のグラフィック機能の１つ又はそれ以上のサブセットを実装するための分担を同様に分けることができる。
【０１４７】
Ｍ．サンプルフィルタリスト
本明細書の種々の箇所で、フィルタの例証的なリストに言及してきた。以下の多くのページは、そのリストに充てられる。このリスト及び添付のパラメータは例証として、説明を完全にするために提供される。上記の発明の本発明者らの実装に関して、リストされたフィルタの各々を使用又は修正してもよく、或いは使用又は修正しなくてもよい。更に、より多くのフィルタを作成することができ、これらは、開示されたものとはかなり異なる場合がある。
【０１４８】
【表３】
【０１４９】
以下の同時申請出願、すなわち、同時申請のＭａｒｋ Ｚｉｍｍｅｒによる「ＩＭＰＲＯＶＥＤ ＢＬＵＲ ＣＯＭＰＵＴＡＴＩＯＮ ＡＬＧＯＲＩＴＨＭ（改良型ブラー計算アルゴリズム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒによる「ＳＹＳＴＥＭ ＦＯＲ ＥＭＵＬＡＴＩＮＧ ＧＲＡＰＨＩＣＳ ＯＰＥＲＡＴＩＯＮＳ（グラフィックオペレーションをエミュレートするためのシステム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒ、Ｍａｒｋ Ｚｉｍｍｅｒ、Ｒａｌｐｈ Ｂｒｕｎｎｅｒ、Ｐｅｔｅｒ Ｇｒａｆｆａｇｎｉｎｏによる「ＳＹＳＴＥＭ ＦＯＲ ＯＰＴＩＭＩＺＩＮＧ ＧＲＡＰＨＩＣＳ ＯＰＥＲＡＴＩＯＮＳ（グラフィックオペレーションを最適化するためのシステム）」、同時申請のＪｏｈｎ Ｈａｒｐｅｒによる「ＳＹＳＴＥＭ ＦＯＲ ＲＥＤＵＣＩＮＧ ＴＨＥ ＮＵＭＢＥＲ ＯＦ ＰＲＯＧＲＡＭＳ ＮＥＣＥＳＳＡＲＹ ＴＯ ＲＥＮＤＥＲ ＡＮ ＩＭＡＧＥ（イメージをレンダリングするために必要なプログラムの数を低減させるためのシステム）」は、引用により本明細書に組み込まれる。
【特許請求の範囲】
【請求項１】
１つまたはそれ以上のプログラム可能なプロセッシング・ユニットを含むコンピュータ上で初期イメージを編集する方法であって、この方法は、
第１プロセスが第１のプロセッシング・ユニット上で実行されて前記第１のプロセッシング・ユニット上で実行される第２プロセスにフィルタを要求するステップと、
前記第１プロセスが前記フィルタと前記初期イメージ間の関係を定義するステップであって、その関係付けられたフィルタと初期イメージがプログラムを含む、前記定義するステップと、
前記第２プロセスが前記プログラムをコンパイルして、コンパイルされたプログラムを作成するステップと、
前記コンパイルされたプログラムの少なくとも一部を第２のプロセッシング・ユニット上で実行して、前記フィルタの関数を前記イメージに加え、画素イメージ結果を得るステップと、を含み、
前記１つまたはそれ以上のプログラム可能なプロセッシング・ユニットを含むコンピュータはこれらのステップを実行するように構成されて成る、前記方法。
【請求項２】
前記プログラムを最適化する追加ステップを有する請求項１に記載の方法。
【請求項３】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、キャッシュルックアップを使用して前記画素イメージ結果が既にキャッシュ内にあるかどうかを調べるステップを含む請求項１に記載の方法。
【請求項４】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含む請求項１に記載の方法。
【請求項５】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、前記コンパイルされたプログラムの実行中に、前記計算された交差を使用して、計算を必要とする画素数を制限するステップを更に含む請求項１に記載の方法。
【請求項６】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、
前記計算された交差を使用して、計算されたイメージを記憶するのに必要なメモリの量を制限するステップを更に含む請求項１に記載の方法。
【請求項７】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であることを特徴とする請求項１に記載の方法。
【請求項８】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であり、前記単一のプロセッシング・ユニットはＣＰＵであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であり、前記単一のプロセッシング・ユニットはプログラム可能ＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１のプロセッシング・ユニットはＣＰＵであり、前記第２のプロセッシング・ユニットはＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１２】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１と第２のプロセッシング・ユニットは両方ともＣＰＵであることを特徴とする請求項１に記載の方法。
【請求項１３】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１と第２のプロセッシング・ユニットは両方ともＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１４】
前記初期イメージはカラーだけであることを特徴とする請求項１に記載の方法。
【請求項１５】
前記第１プロセスはアプリケーションプログラムであることを特徴とする請求項１に記載の方法。
【請求項１６】
前記第２プロセスは、一式のグラフィックサービス機能を含むことを特徴とする請求項１に記載の方法。
【請求項１７】
オペレーティングシステムは前記第２プロセスを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記第１プロセスは、高レベルフィルタを要求し、前記第２プロセスは、低レベルフィルタを表現するオブジェクトに応答することを特徴とする請求項１に記載の方法。
【請求項１９】
前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２０】
前記プログラムを最適化する追加ステップを有し、前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２１】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、前記コンパイルされたプログラムの実行中に、前記計算された交差を使用して、計算を必要とする画素数を制限するステップを更に含み、前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２２】
初期イメージを編集するためのシステムであって、
第１プロセスからの要求をサービスするため前記第１プロセスと第２プロセスを実行する第１のプロセッシング・ユニットと、
前記第１プロセスによって要求されたフィルタを記憶するためのメモリと、
前記初期イメージと前記フィルタとの間の関係を含み、前記第１プロセスにより作成されるデータ構造を記憶するための第２メモリと、
前記データ構造を使用して作成されたプログラムを実行するための第２のプロセッシング・ユニットと、
前記プログラムを実行することで得られる画素イメージを記憶するための第３メモリと、を備えるシステム。
【請求項２３】
前記第１と第２メモリは同じものであることを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記第１、第２、第３メモリは同じものであることを特徴とする請求項２２に記載のシステム。
【請求項２５】
前記第１と第２メモリはシステムメモリ内にあり、前記第３メモリはビデオメモリ内にあることを特徴とする請求項２２に記載のシステム。
【請求項２６】
前記第１のプロセッシング・ユニットは前記データ構造を処理し、前記第２のプロセッシング・ユニット上で使用するための前記プログラムを生成することを特徴とする請求項２２に記載のシステム。
【請求項２７】
前記第２のプロセッシング・ユニットにより、前記プログラムの制御下で前記画素イメージが前記第３メモリ内に記憶されることを特徴とする請求項２２に記載のシステム。
【請求項２８】
請求項１に記載された方法をコンピュータに実行させるためのコンピュータ実行可能命令を格納するコンピュータ可読媒体。
【請求項１】
１つまたはそれ以上のプログラム可能なプロセッシング・ユニットを含むコンピュータ上で初期イメージを編集する方法であって、この方法は、
第１プロセスが第１のプロセッシング・ユニット上で実行されて前記第１のプロセッシング・ユニット上で実行される第２プロセスにフィルタを要求するステップと、
前記第１プロセスが前記フィルタと前記初期イメージ間の関係を定義するステップであって、その関係付けられたフィルタと初期イメージがプログラムを含む、前記定義するステップと、
前記第２プロセスが前記プログラムをコンパイルして、コンパイルされたプログラムを作成するステップと、
前記コンパイルされたプログラムの少なくとも一部を第２のプロセッシング・ユニット上で実行して、前記フィルタの関数を前記イメージに加え、画素イメージ結果を得るステップと、を含み、
前記１つまたはそれ以上のプログラム可能なプロセッシング・ユニットを含むコンピュータはこれらのステップを実行するように構成されて成る、前記方法。
【請求項２】
前記プログラムを最適化する追加ステップを有する請求項１に記載の方法。
【請求項３】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、キャッシュルックアップを使用して前記画素イメージ結果が既にキャッシュ内にあるかどうかを調べるステップを含む請求項１に記載の方法。
【請求項４】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含む請求項１に記載の方法。
【請求項５】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、前記コンパイルされたプログラムの実行中に、前記計算された交差を使用して、計算を必要とする画素数を制限するステップを更に含む請求項１に記載の方法。
【請求項６】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、
前記計算された交差を使用して、計算されたイメージを記憶するのに必要なメモリの量を制限するステップを更に含む請求項１に記載の方法。
【請求項７】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であることを特徴とする請求項１に記載の方法。
【請求項８】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であり、前記単一のプロセッシング・ユニットはＣＰＵであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記コンパイルされたプログラムは、単一のプロセッシング・ユニット用であり、前記単一のプロセッシング・ユニットはプログラム可能ＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１のプロセッシング・ユニットはＣＰＵであり、前記第２のプロセッシング・ユニットはＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１２】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１と第２のプロセッシング・ユニットは両方ともＣＰＵであることを特徴とする請求項１に記載の方法。
【請求項１３】
前記コンパイルされたプログラムは、第１のプロセッシング・ユニット用の構成要素と第２のプロセッシング・ユニット用の構成要素とを含み、前記第１と第２のプロセッシング・ユニットは両方ともＧＰＵであることを特徴とする請求項１に記載の方法。
【請求項１４】
前記初期イメージはカラーだけであることを特徴とする請求項１に記載の方法。
【請求項１５】
前記第１プロセスはアプリケーションプログラムであることを特徴とする請求項１に記載の方法。
【請求項１６】
前記第２プロセスは、一式のグラフィックサービス機能を含むことを特徴とする請求項１に記載の方法。
【請求項１７】
オペレーティングシステムは前記第２プロセスを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記第１プロセスは、高レベルフィルタを要求し、前記第２プロセスは、低レベルフィルタを表現するオブジェクトに応答することを特徴とする請求項１に記載の方法。
【請求項１９】
前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２０】
前記プログラムを最適化する追加ステップを有し、前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２１】
前記プログラムを最適化する追加ステップを有し、この最適化するステップは、前記画素イメージ結果が定義され且つ前記第２プロセスの要求された結果領域にあるエリアを表す交差を計算するステップを含み、前記コンパイルされたプログラムの実行中に、前記計算された交差を使用して、計算を必要とする画素数を制限するステップを更に含み、前記第１プロセスと第２プロセスはＣＰＵ上で実行され、前記コンパイルされたプログラムはＧＰＵ上で実行されることを特徴とする請求項１に記載の方法。
【請求項２２】
初期イメージを編集するためのシステムであって、
第１プロセスからの要求をサービスするため前記第１プロセスと第２プロセスを実行する第１のプロセッシング・ユニットと、
前記第１プロセスによって要求されたフィルタを記憶するためのメモリと、
前記初期イメージと前記フィルタとの間の関係を含み、前記第１プロセスにより作成されるデータ構造を記憶するための第２メモリと、
前記データ構造を使用して作成されたプログラムを実行するための第２のプロセッシング・ユニットと、
前記プログラムを実行することで得られる画素イメージを記憶するための第３メモリと、を備えるシステム。
【請求項２３】
前記第１と第２メモリは同じものであることを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記第１、第２、第３メモリは同じものであることを特徴とする請求項２２に記載のシステム。
【請求項２５】
前記第１と第２メモリはシステムメモリ内にあり、前記第３メモリはビデオメモリ内にあることを特徴とする請求項２２に記載のシステム。
【請求項２６】
前記第１のプロセッシング・ユニットは前記データ構造を処理し、前記第２のプロセッシング・ユニット上で使用するための前記プログラムを生成することを特徴とする請求項２２に記載のシステム。
【請求項２７】
前記第２のプロセッシング・ユニットにより、前記プログラムの制御下で前記画素イメージが前記第３メモリ内に記憶されることを特徴とする請求項２２に記載のシステム。
【請求項２８】
請求項１に記載された方法をコンピュータに実行させるためのコンピュータ実行可能命令を格納するコンピュータ可読媒体。
【図１】
【図２（ａ）】
【図２（ｂ）】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５（ａ）】
【図１５（ｂ）】
【図１５（ｃ）】
【図１６】
【図１７】
【図２（ａ）】
【図２（ｂ）】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５（ａ）】
【図１５（ｂ）】
【図１５（ｃ）】
【図１６】
【図１７】
【公開番号】特開２０１０−１１３７２４（Ｐ２０１０−１１３７２４Ａ）
【公開日】平成２２年５月２０日（２０１０．５．２０）
【国際特許分類】
【出願番号】特願２００９−２８１４１９（Ｐ２００９−２８１４１９）
【出願日】平成２１年１２月１１日（２００９．１２．１１）
【分割の表示】特願２００７−５０８３５６（Ｐ２００７−５０８３５６）の分割
【原出願日】平成１７年３月１６日（２００５．３．１６）
【出願人】（５０３２６０９１８）アップル インコーポレイテッド (568)
【Ｆターム（参考）】
【公開日】平成２２年５月２０日（２０１０．５．２０）
【国際特許分類】
【出願日】平成２１年１２月１１日（２００９．１２．１１）
【分割の表示】特願２００７−５０８３５６（Ｐ２００７−５０８３５６）の分割
【原出願日】平成１７年３月１６日（２００５．３．１６）
【出願人】（５０３２６０９１８）アップル インコーポレイテッド (568)
【Ｆターム（参考）】
[ Back to top ]