タイリングレンダリングを実施するパイプライン中で、バックエンドワークに要する時間を推算する段階を有する、タイルを分割する方法。前記推算されたコストに基づいて、タイルを複数のサブタイルに分割するかいなかを決定する段階を有する、請求項1に記載の方法。三角形状のタイプを識別する段階と、前記タイプを前記推算に用いる段階と、を有する、請求項1に記載の方法。三角形状がタイルの全体を覆うか否かに基づいて、前記三角形状の前記タイプを識別する段階を有する、請求項3に記載の方法。三角形状によって覆われるサンプルの数に基づいて、三角形状のタイプを識別する段階を有する、請求項2に記載の方法。早期Zカルが有効化されているか否かを決定して、前記時間を推算する段階を有する、請求項1に記載の方法。複数のコアを用いる段階と、特定のタイルから分割された特定のサブタイルを処理するそれぞれのコアが、前記タイル中のすべての三角形状を調べて、どの前記三角形状が、前記コアに割り当てられたサブタイルの範囲内にあるかを決定することを可能にする段階と、を有する、請求項1に記載の方法。コンピュータに、タイリングレンダリングを実施するパイプライン中で、コスト推算モデルを用いて、タイルごとに、バックエンドワークに要する時間を推算する手順、を実行させるためのプログラム。前記コンピュータに、前記コスト推算モデルを用いて、タイルをサブタイルに分割するか否かを決定する手順、をさらに実行させるための請求項8に記載のプログラム。前記コンピュータに、三角形状のタイプを識別する手順と、前記タイプを推算に用いる手順と、をさらに実行させるための請求項8に記載のプログラム。前記コンピュータに、三角形状がタイルの全体を覆うか否かに基づいて、前記三角形状の前記タイプを識別する手順、をさらに実行させるための請求項10に記載のプログラム。前記コンピュータに、前記三角形状によって覆われるサンプルの数に基づいて、前記三角形状の前記タイプを識別する手順、をさらに実行させるための請求項10に記載のプログラム。前記コンピュータに、早期Zカルが有効化されているか否かを決定して、前記時間を推算する手順、をさらに実行させるための請求項8に記載のプログラム。前記コンピュータに、複数のコアを用いる手順と、特定のタイルから分割された特定のサブタイルを処理するそれぞれのコアが、前記タイル中の全ての三角形状を調べて、どの前記三角形状が、前記コアに割り当てられたサブタイルの範囲内にあるかを決定することを可能にする手順と、をさらに実行させるための請求項8に記載のプログラム。タイルを分割するか否かを決定するコスト推算ユニットと、コアのそれぞれが、前記タイル中の全ての三角形状を調べて、どの前記三角形状が、前記コアに割り当てられたサブタイルの範囲内にあるかを決定することで、分割されていないタイル、および、特定のタイルから分割された特定のサブタイルを処理することができるマルチコアプロセッサmultiplecoreprocessorと、を備える、装置。前記コアのそれぞれに関する、一式のカウンタであって、コスト推算モデルに利用される一式のカウンタを備える、請求項15に記載の装置。前記カウンタが加算装置に結合される、請求項16に記載の装置。前記コスト推算ユニットが、前記加算装置に結合される、請求項17に記載の装置。タイリングレンダリングを実施するパイプライン中で、バックエンドワークに要する時間を推算する推算ユニットを備える、請求項15に記載の装置。前記推算ユニットが、三角形状のタイプを識別して、前記タイプを前記推算に用いる、請求項19に記載の装置。技術の組み合わせが、タイリングレンダリングパイプラインにおいて、バックエンドのロードのバランスをとるのに用いられてよい。図1に示すように、フロントエンドワークfrontendwork42の後、いくつかの実施形態においては、要素は、特定のタイルのコストの推算estimateに用いられるパイプライン40と、コストモデルcostmodelに必要となる情報を記録するフロントエンドのタイルごとのカウンタfrontendpertilecounter44と、タイルを分割するときに用いられるヒューリスティックheuristic46と、コアへのワークの発送dispatchingを順序付けるorderためのヒューリスティック48と、サブタイルの外側にある三角形状および断片を放棄するdiscard、専用のspecialラスタライザrasterizer50とを有する。次に、バックエンドワークbackendwork52がなされてよい。単一のコアが特定のタイルのバックエンドワークを実行するのに要する時間を正確に調べるただ1つの方法は、実際にそのワークを実行することである。しかしながら、実際にそのワークをすることなく、要求される時間の近似値を把握することが好ましい。そこで、一実施形態において、コストのかからないinexpensiveコスト推算モデルが、特定のタイルのバックエンドワークを実行するのにどれくらいの時間が必要とされるのかを見積もる。全てのタイルについて見積もりがなされた場合、全てのタイルのワークを、利用可能なコアに均等に分配することができる可能性chanceがはるかに高くなる。コスト推算モデルは、ある特定のタイルをバックエンドで処理するのに必要とされる時間を見積もる典型的なフロントエンドから記録されうるデータを使用してよい。単一の三角形状のコストを見積もるためには、当該三角形状が、おおよそどの程度の数のサンプルをカバーするのかを把握する必要がある。理想的には、親タイルと三角形状とが交差する領域が、三角形状がカバーするサンプルの数を評価する基準measureとして用いられてよい。しかし、これにはそれぞれの三角形状のコストのかかるクリッピングexpensiveclippingが関係してくる場合があるので、計算できないこともある。逆に、例えば、もし、三角形状がタイルの全体を覆っている場合などには、重なり合うタイルoverlappingtileを決定するときにフロントエンドにおいて得られた所見observationを用いて、三角形状のそれぞれを大まかに分類することができる。加えて、本当に小さな三角形状であれば、ラスタライザにおいて、専用のコードパスspecialcodepathを用いるであろうから、このような三角形状には、専用の分類を行う必要があろう。その区別されたdifferent分類は、三角形状のタイプtriangletypeと呼ばれる。ここで、三角形状のタイプは、ピクセルシェーディングまたはzバッファモードといった現在のレンダリング状態と無関係であることに留意すべきである。特定のタイルに関するデータは、これに限定されるものではないが、そのタイルに蓄えられたbinned特定の三角形状のタイプを有する三角形状の数、ピクセルシェーディングのコストの合計例えば、そのタイルに蓄えられたbinned特定の三角形状のタイプを有する三角形状のそれぞれに関する単一の断片に対して、特定のcertainピクセルシェーディングを実行するのに必要なサイクル、および、特定のspecificレンダリング状態に調和するadheringタイルに蓄えられたbinned特定の三角形状のタイプを有する三角形状の数を含んでよい。特定のレンダリング状態としては、ステンシル専用stencilonlyの状態、または、早期Zカルearlyzcullが有効な状態を例示することができる。タイルに重なる三角形状を含むジオメトリバッチの数のような上位の構成概念higherlevelconstructに関するカウンタを含めることは、有益である。それぞれのジオメトリバッチは、一般的に、ある程度のオーバーヘッドを招く。モデルは、このデータを用いて、線形項と対数項とを形成してよい。いくつかの実施形態において、線形項および対数項の加重和weightedsumは、タイルを処理するのに要する時間を示す。対数項は、隠蔽occlusionのモデル化に役立つ。すなわち、三角形状が目に見えるものvisibleである場合、三角形状によって覆われたピクセルについて全てのシェーディングを計算する必要があるので、通常、その三角形状の処理には、より長い時間を要する。三角形状が、すでにレンダリングされている三角形状によって隠蔽されているoccluded隠されているobscured場合、より少ないコストで実行することができる。ピクセルごとに、重なり合う三角形状の数の対数を1つにまとめるモデルが用いられてよい。1993年のパラレルレンダリングシンポジウムの議事録の49~56ページに掲載されているCox、MichaelおよびPatHanrahanによるオブジェクトパラレルレンダリングobjectparallelrenderingのためのピクセル結合:分散型スヌーピングアルゴリズムを参照されたい。加重和の重みは、モデルを実測のタイミングにフィッティングさせることで決定される。フィッティングは、実行時に、適当な間隔でまたはオフラインで、多数のシーンから提供されたデータを用いて実施されてよい。使用される対数関数は、底が2の対数thefloorofthe2logarithmであってよい。底が2の対数は、整数を効率よく計算することができる。非線形モデルの1つは式1である。ここで、tは処理時間であり、xiはカウンタの値である。A、Bi、CおよびDiは、フィッティングによって見出された定数である。このモデルは非線形であるので、オフラインでフィッティングすることが好ましい。寄与するカウンタがないときに、結果として生じる値が0であることを確かにする目的で、対数項の中に1という値が追加されている。線形モデルの1つは、式2である。このモデルは、線形のフィッティングを実行するコストが比較的少ないので、実行時にフィッティングするruntimefittingことが好ましい。全てのカウンタに対して対数項を含めるのは意味をなさない。目的は、断片が隠蔽されている場合に、シェーディング時間が短くなるように、隠蔽をモデル化することなので、いくつかの実施形態においては、earlyzcullが有効な形状に関するシェーディングを利用するカウンタだけが含まれてよい。すなわち、他の対数項に関する定数は、0であろう。コストの推算において、どの項を含むかの決定は、レンダリングパイプラインの実装者次第である。線形モデル式2が用いられる場合、フレームnをレンダリングしているときに、全ての情報が収集されてよい。そして、フレームn1のレンダリングを開始する前に、収集された情報に基づいて、係数が再計算される。次に、式2の中でこれらの係数が使用されて、それぞれのタイルのコストを推算する。例えば式3のような移動平均の更新情報slidingaverageupdateを用いて、係数を更新してよい。an1=kanew1-kan3ここで、aiは、線形モデルの全ての係数、すなわちA、BjおよびCjを含むベクトルである。このアプローチは、コスト推算モデルにおける急転suddenjumpを抑制する。そうしなければ、同一のフレームについて複数回レンダリングを実行した場合であっても、値が振動する。モデルの変更によりタイルの分割方法が変更するので、振動が起こうる。このことは、モデルの修正に用いられた実測値measurementを次々に変更してよい。kの値は、ユーザ次第で、0から1の範囲内に設定される。k=1の場合、前回のaの値が使用されず、k=0の場合、新しい値が使用されないそれゆえ、無意味である。。kの値は、0と1との間のどこか、例えば、k=0.5となるであろう。フロントエンドは、コスト推算モデルにより要求される情報に関するタイルごとのカウンタpertilecounterを含めるよう修正される。フロントエンドに先立って、そのようなカウンタの全てが0に初期化される。三角形状がタイルに蓄積されるbinnedたびに、その三角形状のタイプが決定され、当該三角形状のタイプに関するカウンタがインクリメントされる。例えば、特定の三角形状のタイプに関するピクセルシェーダのコストpixelshadercostの合計値を収容するカウンタのような、その他のカウンタもまた、それに応じて修正される。ここで、例えば、オフラインフィッティングから予め重みが分かっている場合には、重みを予め掛けておくことで、線形項に関する全てのカウンタを単一の値にしておくことができ、これにより、記憶装置に対する要求storagerequirementを低減させることができる。典型的には、いくつかのコアが同一のカウンタにアクセスするので、図2に示すように、それぞれのコアについて、固有のカウンタ12の集合set10を有することは有益である。このように、コア間の同期intercoresynchronizationを抑制することができる。これらのコアごとのカウンタpercorecounter12はフロントエンドワーク18に結合され、タイルに関するコストを推算する場合、14に示されるように累算されて、コスト推算モデル16により使用される一式のsetカウンタとなる。三角形状がタイルに蓄積されるbinned場合に、フロントエンドがそのカウンタをインクリメントする方法の一例が、図3に示されている。20において、タイル/三角形状の対tiletrianglepairが受信される。菱形22のチェックは、三角形状がタイルに重なるか否かを決定する。三角形状がタイルと重ならない場合には、24に示すように、フローが終了する。三角形状がタイルと重なる場合には、菱形26のチェックは、この三角形状が、このタイルのジオメトリバッチの最初の三角形状であるか否かを決定する。この三角形状が、このタイルのジオメトリバッチの最初の三角形状である場合、28において、バッチカウンタがインクリメントされる。次に、菱形30において、三角形状のタイプが決定される。32に示される次の段階において、三角形状がタイルの全体を覆っている場合には、タイプ1が示される。他のタイプに当てはまらない場合には、タイプ2が示される。三角形状が16×16のサンプルを覆っている場合には、タイプ3が示される。三角形状が2×2のサンプルを覆っている場合には、タイプ4が示される。ラスタライズするアーキテクチャによっては、その他の三角形状のタイプが用いられてよい。次に、34において、トライアングルカウンタ[タイプ]がインクリメントされ、現在のシェーダの長さshaderlengthがシェーダカウンタ[タイプ]に追加される。菱形36のチェックにおいて、早期Zカルearlyzcullが有効であるか否かが決定されるすなわち、ピクセルをシェーディングする前に、ZカリングZcullingが実施されているか否かが決定される。。早期Zカルearlyzcullが有効でない場合、フローは終了する。そうでない場合、ブロック38において、早期Zカルカウンタ[タイプ]がインクリメントされ、現在のシェーダの長さshaderlengthが早期ZシェーダカウンタEarlyZShadingCounter[タイプ]に追加される。フロントエンドの後、分割のためのヒューリスティック46splittingheuristic図1が用いられて、どのタイルを分割するかが決定される。一例として、あるタイルが128×128ピクセルを覆っている場合、そのタイルは、2つの重なり合っていない64×128ピクセルのサブタイルに分割されてよい。そのようなサブタイルのレンダリング時間に関するコストは、そのタイル全体のレンダリング時間のおおよそ半分になると考えられる。したがって、タイルが分割され、サブタイルのバックエンドワークが2つのコアによって並列に処理される場合、もしかすると、タイルを分割することにより、タイルをレンダリングするのに要する時間を50に減らすことができるかもしれない。分割のためのヒューリスティックの第1のステップは、コスト推算モデルおよびタイルごとのカウンタを用いて、すべてのタイルのコストを推算することである。次に、タイル全体のコストと比較したときのサブタイルのコストは、ピクセル中におけるサブタイルの面積に直接的に比例するという仮定のもと、n個のもっともコストのかかるタイルが選択され、それぞれのサブタイルのコストが特定の閾値thを下回るまで、繰り返し分割される。通常、タイルを分割することに関連するオーバーヘッドが存在する。それゆえ、本当に必要な場合に限って分割することが有益である。過度の分割は、パフォーマンスの低下を招く可能性がある。あるシーンの中に、いくつかの独立したレンダリング対象、および/または、同時に複数のインフライトなinflightフレームが含まれる場合、コストのかかるタイルでさえ、分割することは有益ではないかもしれない。このため、閾値thは、同時発生のconcurrentレンダリング対象中のワークの総量に応じて修正される。順序付けのためのヒューリスティック48orderingheuristic図1は、コストのかかるタイルのバックエンドワークが、できるだけ早く開始されるように試みる。これにより、バックエンドの最後に、ロードの不均衡が低減される。それゆえ、分割の後、推算されたコストに基づいて、タイルがソートされる。次に、その順序で、もっともコストのかかるサブタイルから、利用可能なコアに発送される。分割段階の間にタイルがソートされる場合には、タイルを再度ソートする必要はない。この場合、サブタイルは、ワーク列workqueue中の適切な位置に挿入され、概算コストを利用した順序を保証してよい。タイルを分割する目的で、専用のラスタライザ50図1が用いられてよい。専用のラスタライザを用いなければ、タイルを分割することのメリットが少なくなるであろう。分割の後、タイルの三角形状をサブタイルの間で再分配してよい。すなわち、三角形状がどのサブタイルに重なるかを検証して、そのようなサブタイルのそれぞれについて、サブタイルの三角形状のリストtrianglelistの中に、その三角形状を記載する。しかしながら、この方法は、フロントエンド/バックエンドに分割されたパイプラインではうまく機能しない場合がある。この実行には、単に、現在のパイプラインに多くの変更が必要であろう。よりよい方法は、サブタイルを処理するそれぞれのコアに、親タイルの三角形状のリスト全体を調べさせることである。次に、専用のラスタライザが、サブタイルの領域の外側の三角形状を放棄するdiscard。走査変換scanconversionの間に、サブタイルの外側の断片fragmentを効率よく放棄するように変更されてもよい。階層的ラスタライゼーションhierarchicalrasterizationの間、コアが、サブタイルのピクセル領域の外側のピクセル領域に達すると、専用のラスタライザは、階層的トラバーサルhierarchicaltraversalを単に終了させる。これにより、現在のパイプラインに対する変更が非常に小さくコンパクトになり、いくつかの実施形態において、非常に好ましい。サブタイルの全く外側に存在する三角形状を迅速に却下する目的で、それが、走査変換に先立つ三角形状結合ボックステストtriangleboundingboxtestに組み込まれてもよい。一実施形態において、タイルが、常に、長手方向longeraxisに沿って半分に分割され、結果として、親タイルの次元が2のべき乗であると仮定すると、常に2のべき乗の次元になる。例えば、効率のよいシフト操作を用いて、大抵の却下テストrejectiontestが実施されてよい。いくつかの実施形態において、ラスタライゼーションに基づくレンダラーを用いたオフラインレンダリングが用いられてよい。この場合、レンダリングにはるかに多くのコストがかかるので、推算のコストは、相対的に小さくなるであろう。それゆえ、その意味でも、このような技術を用いることは意味がある。加えて、より高次の基本形状higherorderprimitive例えば、置換されたベジエ曲面displacedBeziersurface、置換された細分化曲面displacedsubdivisionsurfaceおよび任意の変位シェーダarbitrarydisplacementshaderについても、いくつかの実施形態を利用することで、大きな効果が得られる場合がある。いくつかの実施形態は、単一のレンダリング対象のロードを均等化して、利用を最大化し、レイテンシを最小化してよい。同時に、メモリのフットプリントはあまり増加しなくてもよい。いくつかのケースにおいて、専用のラスタライザは、その実行を実質的に容易にする。図4に示されるコンピュータシステムcomputersystem130は、バス104によってチップセットのコアロジック110に結合されるハードドライブ134およびリムーバブルメディアremovablemedium136を備えてよい。バス108を介して、キーボードおよびマウス120またはその他の通常の要素が、チップセットのコアロジックに結合されてよい。一実施形態において、コアロジックは、バス105を介して、グラフィックプロセッサ112およびメインまたはホストプロセッサ100に結合されてよい。グラフィックプロセッサ112は、バス106を介して、フレームバッファ114に結合されてもよい。フレームバッファ114は、バス107を介して、表示画面118に結合されてもよい。一実施形態において、グラフィックプロセッサ112は、単一命令複数データSIMDアーキテクチャを用いた、マルチスレッド、マルチコアの並列プロセッサであってよい。図2に示されるように、グラフィックプロセッサは、複数のコアを含んでよく、それぞれのコアは、カウンタと関連付けられてよい。ソフトウエアにより実行される場合、適切なコードが、メインメモリ132またはグラフィックプロセッサに含まれるなんらかの利用可能なメモリを含む、なんらかの適切な半導体、磁気的または光学的な記憶装置に記憶されてよい。一実施形態において、図1から図3までのシーケンスを実行するコード139が、メインメモリ132またはグラフィックプロセッサ112のような、不揮発性の機械またはコンピュータが読み込むことができる媒体に記憶されてよく、一実施形態において、プロセッサ100またはグラフィックプロセッサ112により実行されてよい。図1から図3は、フローチャートである。いくつかの実施形態において、これらのフローチャートに記載されたシーケンスが、ハードウエア、ソフトウエアまたはファームウエアにおいて実行されてよい。ソフトウエアの実施形態において、半導体メモリ、磁気メモリまたは光学メモリのようなコンピュータ可読媒体を用いて命令が記憶されてよく、プロセッサにより実行されて、図1から図3に記載されたフローチャートの1以上に示されるシーケンスが実行されてよい。本明細書に記載される画像処理技術は、様々なハードウエアアーキテクチャにおいて実現されてよい。例えば、グラフィック機能が1つのチップセットに統合されてよい。他には、独立したdiscreteグラフィックプロセッサが用いられてよい。さらに他の実施形態において、グラフィック機能が、マルチコアプロセッサを含む、汎用のプロセッサにより実現されてもよい。本明細書を通して、一実施形態またはある実施形態という表現は、その実施形態に関連して記載される特定の特徴、構造または特性が、本発明の範囲内に含まれる少なくとも1つの実現手段の中に含まれることを意味する。例えば、一実施形態またはある実施形態中という用語が出現しても、必ずしも、同一の実施形態を参照しているとは限らない。さらに、特定の特徴、構造または特性は、説明された特定の態様以外にも、その他の適切な実施形態の中で用いられてよく、そのような態様は、すべて、本出願の特許請求の範囲の範囲内に含まれてよい。本発明は、限られた数の実施形態に関連して説明されているけれども、当業者は、それらから、多数の改造および変更variationを認識することができるであろう。添付の特許請求の範囲は、本発明の真の精神および範囲内に含まれるように、そのような改造および変更をカバーすることが意図されている。