(58)【調査した分野】(Int.Cl.,DB名)
スクリーン領域へマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法であって、前記スクリーン領域が複数のゾーンを含み、前記ゾーンの各々がレンダリング・パラメータの異なるセットを有し、前記方法が、
メモリ内に前記ゾーンの各々に対するレンダリング・パラメータ・コンテクストを設定すること、
前記ゾーンの各々にゾーン・インデックスを割り当てること、
前記メモリ内にオブジェクトを設定することであって、この場合の前記オブジェクトが、前記スクリーン領域の前記ゾーンの少なくとも二つを覆い、前記少なくとも二つのゾーンが、各々、前記ゾーン・インデックスの少なくとも二つに割り当てられ、前記オブジェクトの前記設定が、前記オブジェクトに対して前記少なくとも二つのゾーン・インデックスを設定することを含む前記メモリ内に前記オブジェクトを設定すること、及び
前記オブジェクトに対するドロー・コールを発することを含む、前記方法。
前記複数のゾーンが、中央ゾーン及び少なくとも一つのエッジ・ゾーンを含み、前記エッジ・ゾーンのレンダリング・パラメータが、前記中央ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項5に記載のシステム。
前記複数のゾーンが、前記凝視トラッカーから確定された着目点ゾーンを含み、前記複数のゾーンが、少なくとも一つの周辺ゾーンを含み、エッジ周辺のレンダリング・パラメータが、前記着目点ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項7に記載のシステム。
前記ゾーンの各々が、異なる同次座標空間によって定義された異なる視認方向を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なる視認方向を含む、請求項4に記載のシステム。
前記ゾーンの各々が、異なるセットのスクリーン空間変換パラメータを有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるセットのスクリーン空間変換パラメータを含む、請求項4に記載のシステム。
前記ゾーンの各々が、異なるピクセル形式を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるピクセル形式を含む、請求項4に記載のシステム。
前記ゾーンの各々が、異なるピクセル密度を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるピクセル密度を含む、請求項4に記載のシステム。
前記ゾーンの各々が、異なるサンプル密度を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるサンプル密度を含む、請求項4に記載のシステム。
前記複数のゾーンが、中央ゾーン及び少なくとも一つのエッジ・ゾーンを含み、前記エッジ・ゾーンのレンダリング・パラメータが、前記中央ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項4に記載のシステム。
前記複数のゾーンが、凝視トラッカーから確定された着目点ゾーン及び少なくとも一つの周辺ゾーンを含み、前記周辺ゾーンのレンダリング・パラメータが、前記着目点ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項4に記載のシステム。
プロセッサ実行命令を記憶した非一時的コンピュータ可読媒体であって、プロセッサによる前記命令の実行は、前記プロセッサに、スクリーン領域にマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法を遂行させ、前記スクリーン領域が複数のゾーンを含み、前記ゾーンの各々が、レンダリング・パラメータの異なるセットを有し、前記方法が、
メモリ内に前記ゾーンの各々に対するレンダリング・パラメータ・コンテクストを設定すること、
前記ゾーンの各々にゾーン・インデックスを割り当てること、
前記メモリ内にオブジェクトを設定することであって、前記オブジェクトが、前記スクリーン領域の前記ゾーンの少なくとも二つを覆い、前記少なくとも二つのゾーンが、各々、前記ゾーン・インデックスの少なくとも二つに割り当てられ、前記オブジェクトの前記設定が、前記オブジェクトに対して前記少なくとも二つのゾーン・インデックスを設定することを含む前記メモリ内に前記オブジェクトを設定すること、及び
前記オブジェクトに対するドロー・コールを発することを含む、前記非一時的コンピュータ可読媒体。
スクリーン領域にマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法であって、前記スクリーン領域が複数のゾーンを含み、前記ゾーンの各々が、レンダリング・パラメータの異なるセットを有し、前記方法が、
前記スクリーン領域の前記ゾーンの少なくとも二つを覆うオブジェクトに属するプリミティブのバッチを受けること、
プリミティブ・アセンブラで前記プリミティブの各々をスクリーン空間へアセンブルすることを含み、
前記プリミティブの各々をアセンブルすることが、各イテレーションで前記ゾーンの各々の前記異なるセットのレンダリング・パラメータを使用して、前記プリミティブ・アセンブラで少なくとも2回(前記少なくとも二つのゾーンの各々に対して一度)各プリミティブの演算を繰り返すことを含む、前記方法。
プリミティブ毎のゾーン・インデックスが、オブジェクト・メッシュのプリミティブ連結性を定義する頂点インデックス・データ内に埋め込まれる、または、別個のバッファとして供給される、請求項17に記載の方法。
GPUへ供給されるプリミティブの前記バッチの各特定のプリミティブに対する頂点インデックス・データ及びゾーン・インデックスが、前記特定のプリミティブがカバーする可能性のあるプリミティブ毎のゾーン・インデックスのみを含むよう間引かれる、請求項17に記載の方法。
前記複数のゾーンが、中央ゾーン及び少なくとも一つのエッジ・ゾーンを含み、前記エッジ・ゾーンのレンダリング・パラメータが、前記中央ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項22に記載のシステム。
前記複数のゾーンが、前記凝視トラッカーから確定された着目点ゾーンを含み、前記複数のゾーンが少なくとも一つの周辺ゾーンを含み、前記周辺ゾーンのレンダリング・パラメータが、前記着目点ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項24に記載のシステム。
前記ゾーンの各々が、異なる同次座標空間によって定義された異なる視認方向を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なる視認方向を含む、請求項21に記載のシステム。
前記ゾーンの各々が、異なるセットのスクリーン空間変換パラメータを有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるセットのスクリーン空間変換パラメータを含む、請求項21に記載のシステム。
前記ゾーンの各々が、異なるピクセル形式を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるピクセル形式を含む、請求項21に記載のシステム。
前記ゾーンの各々が、異なるピクセル密度を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるピクセル密度を含む、請求項21に記載のシステム。
前記ゾーンの各々が、異なるサンプル密度を有するよう、レンダリング・パラメータの前記異なるセットの各々が、異なるサンプル密度を含む、請求項21に記載のシステム。
前記複数のゾーンが、中央ゾーン及び少なくとも一つのエッジ・ゾーンを含み、前記エッジ・ゾーンのレンダリング・パラメータが、前記中央ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項21に記載のシステム。
前記複数のゾーンが、凝視トラッカーから確定された着目点ゾーン及び少なくとも一つの周辺ゾーンを含み、前記周辺ゾーンのレンダリング・パラメータが、前記着目点ゾーンに対してグラフィクス・レンダリング・リソースを保つように選択される、請求項21に記載のシステム。
プロセッサ実行命令を記憶した非一時的コンピュータ可読媒体であって、プロセッサによる前記命令の実行は、前記プロセッサに、スクリーン領域にマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法を遂行させ、前記スクリーン領域が複数のゾーンを含み、前記ゾーンの各々が、レンダリング・パラメータの異なるセットを有し、前記方法が、
前記スクリーン領域の前記ゾーンの少なくとも二つを覆うオブジェクトに属するプリミティブのバッチを受けること、
プリミティブ・アセンブラで前記プリミティブの各々をスクリーン空間へアセンブルすることを含み、
前記プリミティブの各々をアセンブルすることが、各イテレーションで前記ゾーンの各々の前記異なるセットのレンダリング・パラメータを使用して、少なくとも2回(前記少なくとも二つのゾーンの各々に対して一度)各プリミティブの演算を繰り返すことを含む、前記非一時的コンピュータ可読媒体。
【発明を実施するための形態】
【0022】
以下の詳細説明は、解説のために特定の詳細を多く含むが、同業者には、以下の詳細への多くの変形及び変更が本発明の範囲内にあることが明らかである。したがって、以下に示す本発明の例示的実施形態は、請求項の発明への普遍性を損なうことなく、且つ制限を課すことなく述べられる。
【0023】
本開示の態様は、スクリーン空間を複数の異なるゾーン(例えば、二つ以上のゾーン)へ分割し、且つ異なるゾーン内で異なる特定の処理操作を実行することによって、グラフィクス・パイプラインにおけるレンダリング効率を向上させるように設計されたグラフィクス・レンダリング技術に関する。スクリーン空間内の各々の異なるゾーンは、最終画像内の一つ以上のピクセルに対応してもよく、各々の異なるゾーンは、レンダリング効率を向上させるための最適化として、レンダリング・パイプライン内で、異なるレンダリング・パラメータを有してレンダリングされてもよい。例えば、より重要とされるゾーンのためにグラフィック処理リソースを保存するために、一つ以上のゾーンが、視聴者のための画質に関して相対的重要度が低いと決定されてもよく、そのレンダリング・パラメータの一つ以上が、結果としてより重要とみなされるもう一つのゾーンとは異なってもよい。
【0024】
本開示の追加の態様によれば、このことは、スクリーンのエッジ及びスクリーンのコーナに近位の各ピクセル(またはピクセルのセット)によって形成される立体角が、スクリーン中央のピクセルまたはピクセルのセットによって形成される立体角よりも小さいという事実を利用することによって、頭部装着ディスプレイ(HMD)のためのグラフィクスをレンダリングする場合に有益である。例えば、レンダリング・パラメータは、スクリーン空間内の中央ピクセルに対応する一つ以上のゾーンのためにレンダリング・リソースを保存するよう選択されてもよく、また、スクリーン空間内のエッジ及び/またはコーナにあるゾーンのパラメータは、効率を優先して選択されていてもよい。
【0025】
本開示のさらにもう一つの態様によれば、このことは、中心窩レンダリングが用いられる場合に有益である。また、異なるゾーンの位置は、視聴者の確定着目点に基づいてもよい。特定のインプリメンテーションでは、したがって、例えば、凝視追跡システムによって検出される眼(または一対の眼)の着目点の変化の検出に応じて、一つ以上のスクリーン・ゾーンの位置が経時的に動的に変化することが有益である。
【0026】
本開示の更なる態様によれば、中心窩イメージングが、頭部装着ディスプレイに組み合わされてもよい。この場合、頭部装着ディスプレイ・デバイスは、一つ以上の光源及び一つ以上のカメラを含むもの等の凝視追跡システムを含むように構成されてもよい。
【0027】
本開示の追加の態様によれば、オブジェクトは、複数の異なるゾーンに重なる場合、再レンダリングされてもよく、オブジェクトが重なる各ゾーンに対して再レンダリングされてもよい。特定のインプリメンテーションでは、これは、各ゾーンに対してレンダリング・パラメータ・コンテクスト及び各コンテクストに関連するゾーン・インデックスを設定するコマンド・バッファを介して達成されてもよい。オブジェクトのための単数または複数のゾーン・インデックスが、オブジェクトが重なる各々のゾーンに対して設定されてもよい。他のインプリメンテーションでは、オブジェクトがスクリーン空間内で複数のゾーンに重なる場合、オブジェクトが重なる各々のゾーンに対して、オブジェクトのプリミティブの各々が、プリミティブ・アセンブラによってユニークにアセンブルされてもよい。
【0028】
図1A−1Cは、大きなFOVディスプレイに関する、以前に認識されていなかった問題を表す。
図1Aは90°FOVディスプレイを表し、
図1Bは114°FOVディスプレイを表す。従来の大きなFOVディスプレイにおける三次元ジオメトリーは、視認平面101への平面投影を利用してレンダリングされる。しかし、高FOV視認平面上へのジオメトリーのレンダリングは、非常に非効率である。
図1Cから分かるように、視認平面101のエッジ領域112及び中央領域114は同じ面積ではあるが、視聴者103が見た場合、非常に異なる立体角を表す。したがって、スクリーンのエッジ近くのピクセルが保持する情報は、中央近くのピクセルに比べ、有意性が低い。シーンを従来通りレンダリングすると、これらの領域は同数のピクセルを有し、スクリーン上で等しい大きさの領域をレンダリングするのに費やされる時間は、ほぼ同じである。
【0029】
図2A−2Cは、異なる大きさの視野に対する二次元の大きなFOVディスプレイの異なる部分の相対的重要度を表す。
図2Aは、チェッカーボードが角度114°を形成する場合の、視認方向に対して直角な平面チェッカーボードの各正方形に対する立体角の相違を表す。言い換えれば、これは、114°FOVディスプレイへの従来の平面投影レンダリングの非効率性を表す。
図2Bは、90°FOVディスプレイに関する同じ情報を表す。そのような平面投影レンダリングでは、投影が、中央にあるタイル204に比べ、エッジにある画像201内のタイル202、及びコーナにあるタイル203を、より小さな立体角へ圧縮してしまう。この圧縮、及び画像201内の各タイルが、スクリーン空間内で同数のピクセルを有するという事実のため、エッジ・タイル202をレンダリングする非効率係数は、中央タイル204に比べ、およそ4倍である。このことは、エッジ・タイル202の従来のレンダリングは、中央タイル204に対するよりも、立体角単位につき4倍多くの処理を伴う。コーナ・タイル203に対する非効率係数は、およそ8倍である。全画像201に渡って平均した場合、非効率係数はおよそ2.5倍である。
【0030】
非効率性は、FOVの大きさに依存する。例えば、
図2Bに示す90°FOVディスプレイに対する非効率係数は、エッジ・タイル202をレンダリングするのに、およそ2倍であり、コーナ・タイル203をレンダリングするのに、およそ3倍、また、画像201をレンダリングする全体で、およそ1.7倍である。
【0031】
この状況に対するもう一つの見方を、
図2Cに示す。ここでは、スクリーン102が、形成立体角単位毎のピクセルに関してほぼ等しい「重要度」の長方形へ分割されている。各長方形は、ディスプレイを介して見た場合、最終画像に対してほぼ同程度に貢献する。平面投影が、いかにエッジ長方形202及びコーナ長方形203の重要度を歪めるかが分かる。立体角に関する要因に加えて、コーナ長方形203は、(立体角単位のピクセル数として表される)視覚ピクセル密度を、ディスプレイの中央に向けてより高く設けるように選択された場合、このディスプレイ光学系が原因で、中央の長方形に比べ、貢献がより少ないことも起こる。
【0032】
前述の観察に基づけば、広FOVディスプレイのための画像210は、
図2Dに示すように、中央領域215に比べ、エッジ領域212、214、216、218でより少ない、且つエッジ領域212、214、216、218よりも、コーナ領域211、213、217及び219でより小さなピクセル密度を有することが有利である。基本グラフィカルな画像データまたはデータ形式またはデータ処理を著しく修正する必要なしに、スクリーンを横切ってピクセル密度を変化させるのと同じ効果を得る様式で、広FOVディスプレイのスクリーン上に従来のグラフィカル画像をレンダリングすることも有利である。
【0033】
中心窩レンダリングが利用される場合、ピクセルの所定重要度に関する
図2Cに示す中央204は、視聴者の確定着目点に対応すると解釈されてもよく、着目点に対して、レンダリング・リソースが保存されることも有利である。
【0034】
さて、
図3A−3Cを参照する。コンピュータ・グラフィクス・レンダリングのための視界フラスタムの例示的実施例が、従来の原理に従って描写されている。
図3Aは、そのフラスタムの斜視図であり、
図3Bは、
図3Bの同じフラスタムを平面図で描写する。
図3Cは、生じる対応スクリーン空間を表す。
【0035】
図3A及び3Bに示すように、フラスタムは、投影316の中心によって定義される先端を切った角錐であると解釈してもよい。投影316の中心は、シーンが見られている視点を定義する眼または仮想カメラに対応すると解釈されてもよい。フラスタムは、グラフィクスがレンダリングされるべき視界ボリュームを定義する近クリップ面310及び遠クリップ面312を含む。すなわち、フラスタム内のボリュームは、視界ボリュームを定義する。図面内に別個に標識していないが、フラスタムの左面、右面、頂面及び底面によって定義される視界フラスタム平面は、廃棄面であると解釈されてもよい。なぜなら、この面を越えてレンダリングされたオブジェクトは、スクリーンの外に位置するので破棄してもよいからである。左、右、頂及び底クリップ平面は、この図に示していないが、側面に対してのクリップの必要を最小化するようクリッピング保護帯域を設けるために、典型的に、非常に広い視野を有するように構成される。
図3A−3Bは、また、視認平面320を示す。その上へ、ワールド空間の三次元シーンが、レンダリング中に演算されるスクリーン空間変換を介して投影される。視認平面320は、ディスプレイ上への提示のためにグラフィックスがレンダリングされるスクリーン空間を定義する二次元平面に対応する。一つの態様による視認方向は、視認平面垂直線329によって定義されてもよく、投影316の中心からシーンが見られる方向に類似することになる。
図3A及び3Bでは、視認平面320が視界ボリューム314内に位置するように表されているが、近クリップ面310及び遠クリップ面312に平行な方位で、シーン内のどこに位置してもよく、また、シーンをワールド空間からスクリーン空間へ変換する原理は同じである。
【0036】
視界ボリューム314内に位置する視認平面320のウィンドウ、すなわち長方形状のウィンドウ322は、グラフィックスがレンダリングされるスクリーン空間を定義する。このウィンドウ322は、シーンの、複数のスクリーン空間ピクセルからなる「表示ウィンドウ」または「ビューポート」に対応する。視界ボリューム内に位置する一つ以上のオブジェクト318は、スクリーン空間表示ウィンドウ322に投影されるが、視界ボリュームの外側にあるオブジェクトまたはオブジェクトの一部分、例えばオブジェクトの三角形プリミティブ、例えばオブジェクト319は、変換後のオブジェクトの各々が、更なるピクセル毎処理のためのラスタライゼーション中にスキャン変換される前に、映らないようクリップされることになる。
【0037】
視認平面320及びスクリーン空間表示ウィンドウ322に対しては、同次座標が使用される。その概念は、
図3Bの投影線324によって明確に示されている。
図3Bの投影線324は、また、視認平面320の位置が問題にならない理由を明確に示しており、フラスタム内に、またはそれの外に存在可能なことを概念的に理解できる。オブジェクト318の頂点の同次座標は、視聴者の意図した視点316から見た場合の、それら頂点のスクリーン空間322位置に直線的に対応する。ワールド空間と任意の視界に対する同次座標空間との間の変換は、Z軸に関わる視認方向とX及びY座標軸に関わるビューポート方位とを位置合わせする線形行列変換、その後の、しばしば「パースペクティブ・デバイド」と呼ばれるX及びYに対するZでの除算を含む。
【0038】
図3A−3Cに表す従来の実施例では、レンダリングのパラメータは、スクリーン空間322全域に渡って同じである。例えば、特に、フラスタムは同じであり、クリップ面はすべて同じであり、スクリーン322の視認方向及び同次座標空間はすべて同じである。
図3A−3Cに示す従来の実施例が立体画像のために使用された場合、
図3A−3Cに示す同じシーンに対して、異なる投影316の中心に位置する各々の眼に関する左右眼の視界に対応する異なる2セットの視界を得ることは可能だろう。このケースでは、異なる左右眼画像がレンダリングされるであろうが、それでも、左眼及び右眼画像の各々に対するレンダリング・パラメータは、スクリーン空間出力画像の全域に渡って同一である。
【0039】
さて、本開示の二つの例示的実施例を描写する
図4A及び4Bを参照する。例示実施例においては、出力画像に対応するスクリーン空間領域が、異なるゾーン(すなわち、Z1、Z2、Z3等)へ分割され、スクリーンの各ゾーンが、異なるパラメータを使用してレンダリングされる。
【0040】
図1A−1Cに関して先に説明した原理を参照すると、特定のインプリメンテーションにおいては、スクリーン空間422が、平坦ではないように、例えば、HMD等のための広FOVディスプレイに対応する(湾曲スクリーンを有する)図示の表示システム425に対してレンダリングされるのが有利であろう。
図4Bは、
図4Aに表す実施例に類似しているが、スクリーン空間420が、より多数のゾーンZへ分けられている。各例示実施例における各ゾーンZは、同じ視界位置で、しかし異なる視認方向429(例えば、図に示すような異なる視認平面垂直線)、及び、各々に対応する異なるビューポートを使用してレンダリングされてもよい。この場合のすべてのゾーン・ビューポートの集合は、ピクセル毎の立体角の相違が集約的に最小となるよう、また、ゾーン同士の重なりまたは全視野を超える投影が最小な視野全体をカバーするように選択される。各ゾーンは、別個のレンダリング目標(または複数のレンダリング目標の別個セット)にラスタライズされてもよく、また、結果として生じた複数の画像は、後処理ステップとして、単一広FOVディスプレイ画像を生成するよう合成されてもよい。これは、平坦でない「スクリーン」422へ、シーン内のオブジェクトを変形させることを近似する。
【0041】
図4Cに示すように、点416は、すべての図示ゾーン・フラスタムの共通視点である。線分410及び412は、各々、ゾーンZ6内のオブジェクトに対する視界ボリューム414を定義するゾーンZ6に対して、近クリップ面及び遠クリップ面に対応する。類似の各視界ボリューム及び近クリップ面及び遠クリップ面が、各々の視界フラスタムに対するゾーンZ4及びZ5についても図示されている。各ゾーンは、異なる視認方向429を有し、そのため、異なる同次座標空間を有するが、すべてが共通視点416を共有するため、各ゾーン・フラスタムの視認平面と全視野平面422との間には、単純な射影変換がある。したがって、シーンを、各ゾーンに対する別個のスクリーン空間画像へレンダリングした後、出力を表示する前の最終ステップとして単一全視野出力画像を合成するために、シーンの各ゾーン画像に対して射影変換を適用することが可能である。上記
図1及び2を参照し、特定の大きさを有するラスター・タイルを利用するスキャン変換プロセスを考察することによって、その利点は認識できる。中心から離れたゾーンに関しては、同じシーン・ジオメトリーが、より小さなピクセル領域を有する平面へ投影されるが、それでも、角度のある空間内には目標最小ピクセル密度が維持される。したがって、レンダリングされる全ピクセル領域が縮小され、このことは、ピクセル・シェーディング及びハードウェア・ピクセル処理の負担への相応な減少、及び、出力品質に有意な損失を生じさせることなくレンダリング効率の相応な増加をもたらす。
【0042】
さて、本開示のもう一つの例示的実施例を表す
図5A及び5Bを参照する。この実施例は、異なるゾーン内で異なるレンダリング・パラメータを使用する。
図5A及び5Bは、シーン・ジオメトリーを投影するために使用されるスクリーン空間522の画像を描写する。この例示的実施例におけるスクリーン空間は、九つのゾーン(Z1、Z2等)へ分割されており、スクリーン空間522の異なるゾーンは、同じ同次座標及び同じ視界フラスタムに関して演算されてもよいが、同次座標からスクリーン空間ピクセルへは、異なる線形変換で演算される。シーン・レンダリング中、オブジェクトまたはプリミティブの、それらが交差しないゾーンへのレンダリングを破棄するために、視点及びゾーン境界によって定義される平面に対するテストが用いられてもよい。任意のプリミティブがレンダリングされるべきゾーンを決定するのに使用される平面を生成するために、ゾーン間の分割が利用されてもよい。この場合、プリミティブがピクセル座標へラスタライズされる点に到達するときにプリミティブを「インターセプトする」ために、異なるスクリーン空間変換パラメータが使用され、各ゾーン内に、そのゾーン内のピクセル密度を変化させるよう異なるスケールが適用される。この実施例では、例えば、
図5Aの異なるゾーンZ4、Z5及びZ6に対して示すように、各ゾーンの視認方向529は同じであるが、例えば、平坦でない「スクリーン」へのレンダリングを近似するために、スクリーン空間変換は、ワールド空間ジオメトリー内の頂点を、それらが視認平面522に到達する前に「インターセプトする」よう演算される。
【0043】
これをより良く表すために、
図5Bは、また、ワールド・ジオメトリー内のプリミティブ527について例示的実施例、より具体的には三角形プリミティブを示す。この実施例では、三角形527は、スクリーン空間内の二つの異なるゾーン、すなわちゾーンZ5及びZ6に重なる。
図5Bは、また、異なるゾーンが、異なるスクリーン空間変換パラメータを有するため、三角形527がどのように同次座標からスクリーン空間ピクセル座標へ、異なるゾーンで異なって変換されるのかを示す。ゾーンZ6内の水平方向の「潰れ」に注目する。この実施例においては、一つのスクリーン軸に沿って任意のスクリーン空間領域内のプリミティブを「潰す」レンダリング・パラメータが、一つ以上のエッジ・ゾーン、例えばゾーンZ2、Z4、Z6及びZ8に対して選択されてもよい(例えば、ゾーンZ4及びZ6についてはスクリーンの水平方向X軸、またはゾーンZ2及びZ8についてはスクリーンの垂直方向Y軸に沿って押し潰される)。さらに、一つ以上のコーナ・ゾーンについて両スクリーン軸に沿ってジオメトリーを更に押し潰すよう、異なるゾーンが選択されてもよい(例えば、ゾーンZ1、Z3、Z7及びZ9については、水平及び垂直軸の両方に沿った潰れとなる)。中心から離れたゾーンに対しては、同じシーン・ジオメトリーが、より小さなピクセル領域へレンダリングされるが、それでも、角度のある空間内には目標最小ピクセル密度が維持される。したがって、レンダリングされる全ピクセル領域が縮小され、このことは、ピクセル・シェーディング及びハードウェア・ピクセル処理の負担への相応な減少、及び、出力品質に有意な損失を生じさせることなくレンダリング効率の相応な増加をもたらす。
【0044】
図4A−4Cと
図5A及び5Bのレンダリング・パラメータ間の違いは、シーン・ジオメトリーをスクリーン空間へ変換する全体的なプロセスを参照することで理解できる。
【0045】
図4A−4Cの実施例におけるシーンの頂点位置は、異なる視認方向に対応する異なる同次座標空間を使用して演算されてもよい。特定のインプリメンテーションにおいては、異なる同次座標空間内のこれら頂点位置は、頂点シェーダから出力されてもよい。その後、同次座標空間からスクリーン空間へ頂点を投影するために、各ゾーンに対してスクリーン空間変換パラメータが使用されてもよい(例えば、シーン・ジオメトリーを視認平面へ投影してもよい)。これは、異なる視認方向に対応する異なるビューポートへプリミティブ頂点を投影することに類似している。
【0046】
図5A及び5Bの実施例においては、プリミティブの頂点位置は、同じ視認方向に対応する各ゾーン内の同じ同次座標空間を使用して演算されてもよく、頂点シェーダから単一共用同次座標空間内にプリミティブ頂点の位置を出力することが可能になる。その後、プリミティブ・アセンブリ中に、プリミティブが、ラスタライゼーションのために同次座標空間からスクリーン空間ピクセルへ変換されてもよいが、この際に、各ゾーンに対して、異なるスクリーン空間変換パラメータを利用してもよい。
【0047】
頂点シェーダから単一共用同次座標空間内にプリミティブ頂点の位置を出力することは可能であるが、そうすることは必須ではなく、また他の点を考慮すると、望ましい場合も、または望ましくない場合もある。例えば、すべての出力ゾーン間で単一の頂点シェーディングの再使用を可能にするためのハードウェアが存在するならば、単一の頂点シェーディングがすべてのゾーンに適用可能なよう、同じ同次座標空間を共有することが要求されるであろう。しかし、そのようなハードウェアが存在しないならば、各ゾーンが、異なる同次空間を有する場合にのみ、既存の三角形カリング・ハードウェアがゾーン境界を間引くことになるため、同じ空間を共有することは、他の手段によって処理されるべき内部ゾーン境界での間引きの必要を導入することになるであろう。
【0048】
いくつかのインプリメンテーションでは、プリミティブ毎のゾーン・インデックスが、オブジェクト・メッシュのプリミティブ連結性を定義する頂点インデックス・データに埋め込まれてもよい、または、別個のバッファとして供給されてもよい。
【0049】
いくつかのインプリメンテーションにおいては、GPUに供給される頂点インデックス・データ及びゾーン・インデックスは、プリミティブがカバーする可能性のあるプリミティブ毎のゾーン・インデックスのみを含むよう、ライタによって更に間引かれてもよい。
【0050】
いくつかのインプリメンテーションでは、GPUに供給される頂点インデックス・データ及びゾーン・インデックスは、ハードウェアのプリミティブ・アセンブリ・ユニットがプリミティブを間引くであろうことが判定できるプリミティブを取り除くよう更に間引かれてもよい。
【0051】
いくつかのインプリメンテーションにおいては、プリミティブ毎のゾーン・インデックス及び、可能なら、間引かれた頂点インデックス・データが、CPUによって、またはGPU上で稼働中の計算シェーダによって、GPUへ供給されてもよい。
【0052】
さて、本開示のもう一つの例示的実施例を示す
図6を参照する。これは、スクリーン空間622内の異なるゾーンに対して異なるレンダリング・パラメータを使用する。この実施例では、二つの異なるゾーンが描写される。例えば、スクリーン空間の中央、または中心窩レンダリングのためのスクリーン空間内の着目点、または両方に相当するゾーンZ1、及び、スクリーン空間のエッジ及び境界領域、または中心窩レンダリングのための着目点の外側、または両方に相当するゾーンZ2。この実施例では、同じ同次座標空間及び視認方向が、同じフラスタム及びスクリーン空間変換パラメータと共に、複数のゾーンに渡って使用される。しかし、この実施例における異なるゾーン(スクリーンの異なる領域)は、例えば、異なるピクセル密度、サンプル密度、異なるピクセル形式、それらの組み合わせを有してもよい。または、異なるゾーンに対して異なる忠実度を生じる可能性を秘めた他の異なるレンダリング・パラメータを有してもよい。例えば、この実施例におけるゾーンZ2は、グラフィクス・レンダリング・リソースの割り当てに関して、ゾーンZ1に比べ重要度が低いと決定されてもよい。したがって、ゾーンZ2は、低ピクセル密度または低忠実度レンダリング・パラメータを使用してレンダリングされてもよい。シーン・レンダリング中、交差しないゾーンへのオブジェクトまたはプリミティブのレンダリングを破棄するために、視点及びゾーン境界によって定義される平面に対するテストが行われてもよい。
【0053】
本開示の態様によれば、異なるゾーンは、複数のレンダリング・パラメータが異なってもよいことに注意すべきである。すなわち、異なるゾーンは、二つ以上のレンダリング・パラメータが異なる。また、異なるゾーンが、本文で説明するレンダリング・パラメータの組み合わせにおいて異なることも可能である。例えば、異なるゾーンは、上述のレンダリング・パラメータの組み合わせにおいて異なってもよい。さらに、特定のインプリメンテーションでは、異なるゾーンが、
図4−6を参照して上述したパラメータを超えて、またはそれらの代わりに、他のレンダリング・パラメータにおいて異なることも可能である。例えば、特定の態様によれば、異なるゾーンは、相互に異なるピクセル形式を利用してもよい。追加の態様によれば、異なるゾーン内に、異なる複数のレンダリング目標(MRT)パラメータが使用されてもよい。実施例として、限定することなく、一つのゾーンは、他のゾーンのためにレンダリング・リソースを保存するよう、他のゾーンに比べ、レンダリング目標位置毎に、より少ない複数のレンダリング目標をサポートしてもよい。
【0054】
特定の事例では、シーンのオブジェクトが、そのジオメトリーがスクリーンに対する出力画像としてレンダリングされる際に、単一フレーム内で複数のゾーンに重なる、または「覆う」ことに注意すべきである。結果として、特定のインプリメンテーションでは、パイプライン内の一つ以上のステージで、オブジェクトが重なる異なるゾーンの異なるレンダリング・パラメータを使用して、同じオブジェクトを再レンダリングすることが必要な場合も起こる。
図7A−7Cは、スクリーン空間表示ウィンドウ722を表し、各々が、異なるレンダリング・パラメータを有する複数の異なるゾーンを含む。実施例の各々において、画像内のオブジェクト718の少なくとも一つは、複数のゾーン(Z1、Z2等)に重なり、
図7A−7Cに図示の各オブジェクトに対する数字は、そのオブジェクトが例示実施例内で覆う異なるゾーンの数に対応する。
【0055】
図7Aに示すインプリメンテーションにおけるゾーンZ1は、ユーザーの凝視に対する着目点に対応し、ゾーンZ2は、着目点の外側の周辺ゾーンに対応してもよい。この場合、後者は、視聴者の視力が最大となる着目点Z1に対してレンダリング・リソースを保存するよう、一つ以上の異なるレンダリング・パラメータでレンダリングされてもよい。特定のインプリメンテーションにおけるゾーンZ1に対する着目点は、凝視追跡システムから動的にリアルタイムで判定されてもよい。このことは、スクリーン上のゾーンZ1及びZ2の位置が、経時的に動的に変化可能であることを意味し、視聴者の凝視方向の変化に応じ、例えば、異なるフレームを覆うよう変化し、グラフィクスは、検出変化に応じて、リアルタイムにレンダリングされてもよい。
図7Aに示す実施例におけるゾーンZ1は、高解像度領域であってもよく、スクリーンの同次座標が、異なるゾーンに対して同じであっても、ユニークなMRT、フラスタム、スクリーン空間変換及びピクセル形式を有してもよい。ゾーンZ1に重なるオブジェクトは、オブジェクトが重なる異なるゾーンの数に対応して、ピクセル処理の前に2回リプレイされる必要があることに注意すべきである。
【0056】
図7Bは、本開示のもう一つの例示的インプリメンテーションを表す。
図7Bに示す実施例におけるゾーンは、ユニークなMRT、スクリーン空間変換及びピクセル形式を有してもよい。この実施例におけるゾーンは、同じ同次座標を有してもよく、フラスタムを共有してもよい。
図7Bに表す実施例に同様にゾーンが配置された場合、左右のエッジ・ゾーン、例えばZ4及びZ6、及び、恐らく、頂部及び底部のエッジ・ゾーン、例えばZ2及びZ8が、他のゾーンとは異なる相互に同じレンダリング・パラメータを有することが可能であることに留意すべきである。同様に、コーナ・ゾーン、例えばZ1、Z3、Z7及びZ9は、他のゾーンとは異なる相互に同じレンダリング・パラメータを有することが可能である。換言すると、各ゾーンは、レンダリング・パラメータのユニークなセットを有するスクリーン画像の異なるセクションと見なしてもよく、特定のインプリメンテーションにおけるスクリーン画像は、Z1、Z3、Z7及びZ9の位置に対応するビューポートのコーナ領域が同一ゾーンに属し、同様に、Z4及びZ6またはZ2及びZ8に対応するエッジ領域が同一ゾーンに属するように分割されてもよい。これは、例えば、異なるゾーンの唯一異なるレンダリング・パラメータが、ピクセル形式またはサンプル密度である場合、真になり得る。しかし、異なる視認方向が利用される場合は、異なるゾーンである。特定のインプリメンテーションにおけるゾーンのパラメータは、ピクセルの所定の相対的重要度に基づいて、例えば
図1及び2に関する上述の原理に従って選択されてもよい。
【0057】
図7Cは、本開示のもう一つの例示的インプリメンテーションを表す。この実施例における異なるゾーンは、MRT及びピクセル形式を共有しながら、異なるゾーンに対するユニークな同次座標空間に定義される頂点位置を有してもよく、また、異なるフラスタム及びスクリーン空間変換を使用してもよい。注目すべきことは、
図7A−7Cに示すインプリメンテーションは、実施例であり、本開示の態様に従う多数の異なる様式で、ゾーン・レイアウト及びゾーンのレンダリング・パラメータの違いを変更または組み合わせることが可能であることである。
【0058】
特定のインプリメンテーションでは、効率的なグラフィクス・レンダリング・プロセスは、レンダリング・パイプラインの一つ以上のステージに対して別個に、オブジェクト全体をレンダリングする必要があってもよい。このことは、
図7A−7Cの例示実施例におけるオブジェクト718上の数字が、オブジェクトがレンダリングされる必要回数に対応することを意味する。より具体的には、スクリーン空間変換のパラメータが異なる、及び/または同次座標空間が、上述のものに類似の方式で、異なるゾーンに対して異なるもの等の、特定のインプリメンテーションにおけるオブジェクトは、スクリーン空間ピクセルにおけるスキャン変換が可能で、且つ更なるピクセル毎処理のためにフラグメントが生成される前に、オブジェクトが重なる各ゾーンに対してユニークに処理される必要があってもよい。したがって、本開示の態様は、グラフィクス・パイプラインにおけるピクセル処理ステージに到達する前の、オブジェクトの効率的再レンダリングのためのシステム及び方法を含む。
【0059】
概して、任意のオブジェクトに対してドロー・コールが発せられる前に、例えばコマンド・バッファを介して、特定の入力データが設定される必要がある。コマンド・バッファは、典型的に、フラスタムのパラメータ、MRT等のレンダリング・パラメータに対して設定されるレジスターを含んでもよい。複数のゾーンによってカバーされるオブジェクトに対して、このことは、オブジェクトが、それが重なるゾーンの各々からのパラメータで設定されるデータを必要とすることを意味する。一つのゾーンまたは他のゾーン内に入るオブジェクトの一部分に対してレンダリングが実行されると、異なる各々のレンダリング・パラメータに対して、新しいコンテクストが使用される必要があってもよい。通常、本質的にオブジェクト単位で、各頂点に対する頂点シェーディング演算が実行されるが、このことは、特定のゾーン及び対応するレンダリング・パラメータが、異なるゾーンに基づき、オブジェクトに対する頂点から頂点へ変化してもよいことを意味するので、これは、複数のゾーン内に頂点、例えばスクリーン領域の異なる複数のゾーンに位置する頂点を有するオブジェクトに対しては非効率になる可能性がある。
【0060】
したがって、
図8は、コマンド・バッファを介して、スクリーン空間内の異なるゾーンへ効率的にレンダリングする例示的インプリメンテーションを表す。
図8に示すように、オブジェクトに対するドロー・コールの前に、レンダリング・パラメータの各々の異なるセットが、メモリ内に設定され、830に示すように、ゾーン・インデックスを介して各々のゾーンに関連付けられてもよい。これは、オプションとして、各々の異なるゾーンに対するレジスター内にレンダリング・パラメータのセットを設定し、これらのレジスターの各々に、ゾーン・インデックスでインデックス付けを行うことを含んでもよい。830で設定されるレンダリング・パラメータ・コンテクストは、全フラスタム、MRT及び他のレンダリング・パラメータを含んでもよい。
【0061】
832に示すように、各オブジェクトに対するドロー・コールの前に、オブジェクトが重なる各ゾーンが、例えばアプリケーションによって確定され、そのオブジェクトに対して設定されてもよい。これは、スクリーン領域内でオブジェクトが覆う各ゾーンに対して、オブジェクト毎に、そのオブジェクトに対するゾーン・インデックスを設定することを含んでもよい。ゾーン・インデックスは、830で設定されたスクリーン領域のゾーンに対する適切なレンダリング・パラメータ・コンテクストに関連付けられてもよい。
【0062】
これは、複数のゾーンの異なる頂点に対応する可能性があるオブジェクトの異なる頂点での、頂点シェーディング操作のためのコンテクスト切り換えに関連する大きなオーバヘッドを回避する。その理由は、異なるゾーン・レンダリング・パラメータの異なるコンテクスト間での頻繁な切り替わりは、レンダリング効率を悪化させる可能性があるためである。そのかわりに、スクリーンの異なるゾーン内の同じオブジェクトの異なる頂点は、頂点処理中に陰影付けが行われるので、ゾーン・インデックス・コンテクストのみを切り換えてもよい。これは、ゾーン・インデックスが、本質的に単一数字のみでもよく、レンダリング・パラメータのコンテクスト全体に比べ、データの非常に小さなセットに相当するため、スクリーンの異なる部分を異なるレンダリング・パラメータでレンダリングする際に、効率を著しく向上させる可能性がある。
【0063】
図8に示すように、オブジェクトの各々、例えばフレームの各オブジェクトに対してドロー・コール834が発せられてもよい。ゾーン・インデックス/コンテクストを設定すること、及び、ドロー・コールを発することは、グラフィクスAPIを介して実行されてもよい。また、方法800は、ドロー・コール834に従ったオブジェクトの頂点に対する頂点シェーディング演算836を含んでもよい。この図示インプリメンテーションにおけるオブジェクトの各頂点は、832で設定されたゾーン・インデックスで示される各ゾーンのパラメータで、陰影付けが行われてもよい。換言すると、オブジェクトは、このステージで、オブジェクトが重なる各ゾーンに対して、例えば
図7の実施例に示す数に従って、再レンダリングされてもよい。したがって、各々異なる2セットのレンダリング・パラメータで、スクリーンの二つのゾーンを覆うオブジェクトに対しては、頂点シェーダが、各ゾーンに対するレンダリング・パラメータのユニークなセットで、オブジェクトの各頂点を処理するため、頂点シェーダの呼出し回数が2倍になる可能性がある。
図8に表すインプリメンテーションにおいては、オブジェクトが、関連ゾーン・インデックスに従って、頂点シェーダ内でスクリーン空間の異なるゾーンに対して再レンダリングされるため、スクリーンの異なるゾーンに対しては、異なる同次座標空間を利用することが可能である。そのとき、頂点シェーダは、各ゾーンに対するユニークな同次座標で、オブジェクトの頂点の位置を出力してもよい。
【0064】
例えば、テクスチャ・コーディネート、明暗値、色などの種々のパラメータ値の操作を介して、任意のオブジェクトに対してすべての頂点が陰影付けられた後、オブジェクトの頂点及びパラメータは、プリミティブ・アセンブリ838へ通過してもよく、そこで、プリミティブ、例えば三角形を定義するオブジェクトの頂点は、(しばしば「ビューポート」とも呼ぶ)スクリーン空間表示ウィンドウへマッピングされてもよい。このことは、投影及び座標空間変換を演算する、並びに、異なるゾーンのレンダリング・パラメータに従ってプリミティブを視界フラスタムへクリップする種々の操作を介して行われる。プリミティブ・アセンブリ・ユニットの出力は、840に示すように、スクリーン空間内の別個のピクセルへのスキャン変換のためのラスタライザーへ渡されてもよい。図示のインプリメンテーションにおいては、スクリーン空間内の異なるゾーンが、830で設定された異なるゾーンのレンダリング・パラメータに応じて、異なるクリップ平面、視認フラスタム、スクリーン空間変換パラメータ等の、プリミティブ・アセンブリ操作838のための異なるパラメータを有することが可能である。
【0065】
各プリミティブがラスタライズされた後、関連フラグメント及びピクセル値は、表示のために最終フレームが生成される前に、レンダリング・パイプラインの後のピクセル処理ステージで更に処理されてもよい。
【0066】
さて、本開示の追加の態様によるもう一つの方法900を表す
図9Aを参照する。概して、
図9Aに表す例示的な方法900においては、複数のゾーンに重なるオブジェクトのために、そのオブジェクトのプリミティブが受信される。各々の受信プリミティブに対して、オブジェクトが重なるスクリーン空間内の各ゾーンのために、各ゾーンのレンダリング・パラメータに従って、新しいプリミティブがアセンブルされてもよい。換言すると、複数のゾーンに重なるオブジェクトに対して、それのプリミティブの各々が、異なるゾーンの各々に対して再アセンブルされてもよく、プリミティブ・アセンブリ中に、異なる視界フラスタム、異なるクリップ平面、異なるスクリーン空間変換などの異なるパラメータを含んでもよい。
【0067】
933に示すように、プリミティブのバッチが、オブジェクトに属していてもよい。935に示すように、頂点シェーダが呼び出され、バッチ内の各頂点に対して、頂点シェーディング演算が実行されてもよい。この実施例では、頂点シェーダが、オブジェクトが重なる各々のゾーンに対してユニークに呼び出される必要はない。そのため、頂点シェーダ・オーバヘッドは、従来の方法に比べ増加しない。むしろ、このインプリメンテーションにおいては、後のプリミティブ・アセンブリ中に、異なるレンダリング・パラメータを初めて適用することが可能である。
【0068】
938に示すように、プリミティブ・アセンブラは、受信プリミティブのバッチから、ラスタライゼーションのためにスクリーン空間へプリミティブをアセンブルしてもよい。この実施例におけるプリミティブ・アセンブリは、939に示すように、オブジェクトが覆うスクリーンの各ゾーンに対して、反復的に実行されてもよい。したがって、プリミティブのオブジェクトが重なる各ゾーンに対するユニークなプリミティブ・アセンブリ・レンダリング・パラメータで、ゾーンの数に従って、オブジェクトのプリミティブのバッチ内の各プリミティブを再アセンブルしてもよい。940に示すように、生成されたプリミティブの各々は、それから、更なるピクセル処理のために、目標ゾーンのスクリーン空間へスキャン変換されてもよい。
【0069】
ゾーンに対する繰返し処理がプリミティブ・アセンブリ・ユニットによって提供されるケースに対しては、オブジェクト毎にゾーン・インデックスを付与する複数の方法がある。実施例として限定することなく、ゾーン・インデックスは、グラフィックス・メモリ内にアレイとして供給されてもよい。アレイは、例えば、コマンド・バッファ内に埋め込まれてもよい、またはコマンド・バッファ内のポインターを介してアクセスされてもよい。オブジェクト毎のゾーン・インデックスは、CPUによって、またはGPU上で実行中の演算シェーダによって、そのようなバッファを介してGPUへ供給されてもよい。
【0070】
図9Bは、
図9Aの方法による一つの方法の追加の態様を表す概略図である。
図9Bに示す実施例プロセスは、プリミティブ・アセンブリ(PA)ユニット938が、対応オブジェクトが重なる各ゾーンに対して反復的にプリミティブを再アセンブルするときに、プリミティブ演算の繰返しを保持するために、FIFO(第一の入力、第一の出力)バッファ941を利用してもよい。
【0071】
図9Bに示す実施例は、シーン内のオブジェクトの頂点のパラメータを処理するために頂点シェーダを呼び出すように構成された頂点シェーダ呼出しモジュール943を含む。同時発生的に、それら頂点に関連する連結性データが、プリミティブ・バッファ941へ送信されてもよい。プリミティブ・バッファは、プリミティブがどのように頂点のグループから構成されるのかに関する情報を含み、また、各プリミティブがレンダリングされるべきゾーンに関する情報を含む。
【0072】
頂点シェーダは、頂点の種々のパラメータを操作するために、頂点シェーダ演算を実行してもよく、頂点の位置は、頂点シェーダによって同次座標内に定義され、頂点シェーダから位置キャッシュ944へ出力されてもよい。プリミティブ・アセンブラ938は、プリミティブのバッチをプリミティブ・バッファから受信し、各々の指示されたゾーン、すなわちプリミティブを含むオブジェクトが重なる各ゾーンに対して反復的に実行してもよい。その結果のピクセルは、それから、更なるピクセル処理のために、スキャン・コンバータ(図示せず)へ送信されてもよい。
【0073】
図8に示すインプリメンテーションに比較した場合の、
図9A及び9Bのインプリメンテーションの利点は、異なる同次座標空間内の異なる頂点位置が、各ゾーンに対する異なるプリミティブ・アセンブリ操作に必要とされないため、頂点シェーダ・オーバヘッドが、異なるゾーンに重なるオブジェクトに対して増加しなくてもよいことである。しかしながら、
図9A及び9Bに示す技術のみを用いる場合は、異なる視認方向を有するゾーンを利用することは、頂点シェーダが典型的に、頂点の同次座標を演算するように構成されるため、困難な場合がある。
【0074】
しかし、特定のインプリメンテーションでは、
図8と
図9A及び9Bに示す技術の組み合わせを利用することが可能である。
【0075】
図10Aは、本開示の態様を実行するように構成された例示的グラフィクス・レンダリング・パイプライン1000aを表す。
図10Aに示す例示的レンダリング・パイプラインには、異なるレンダリング・パラメータで、複数の異なるゾーンを有するスクリーンへオブジェクトをレンダリングするために、
図8の方法800を統合させてもよい。
【0076】
レンダリング・パイプライン1000aは、(本文中、しばしば「ワールド空間」と称する)仮想空間内の三次元ジオメトリーであることが好ましいシーンを表す画像として、グラフィクスをレンダリングするように構成されてもよい。しかしながら、潜在的に二次元ジオメトリーであってもよい。レンダリング・パイプライン全体を通して、データは、図中にグラフィックス・メモリ1020として概記された一つ以上のメモリ・ユニットから読まれ、それらへ書き込まれてもよい。グラフィックス・メモリは、レンダリング・パイプライン内で利用される種々のバッファ及びグラフィクス・リソースを含むビデオ・メモリ及び/またはハードウェア状態メモリを含んでもよい。グラフィックス・メモリ1020の一つ以上の個々のメモリ・ユニットは、レンダリングの特定のステージにおけるデータの性質に応じて、一つ以上のビデオ・ランダムアクセス・メモリユニット、一つ以上のキャッシュ、一つ以上のプロセッサ・レジスター等として具現化されてもよい。したがって、グラフィックス・メモリ1020は、グラフィクス・レンダリング・パイプライン内で利用されるプロセッサ・アクセス可能メモリに言及する、と理解すべきである。特殊なGPU等の処理ユニットが、パイプライン内の種々の操作を実行し、それに応じてグラフィックス・メモリ1020への読み書きを行うように構成されてもよい。
【0077】
パイプラインの初期ステージは、ワールド空間内で実行される操作を含んでもよい。その後、シーンは、ラスタライズされ、ピクセル表示デバイス上の出力に適切な一セットの個別画素としてスクリーン空間へ変換される。パイプライン全体を通して、グラフィックス・メモリ1020内に含まれる種々のリソースが、パイプライン・ステージで利用されてもよく、ステージへの入力及び出力は、画像の最終値が決定されるまで、一時的に、グラフィックス・メモリ内に含まれるバッファ内に記憶されてもよい。
【0078】
パイプラインの初期ステージは、パイプライン内の種々のレンダリング・ステージのために特定の入力データ1022を設定するアプリケーション処理ステージ1061を含んでもよい。アプリケーション処理ステージ1061は、各々のユニークなゾーン・コンテクストに割り当てられた各々のゾーン・インデックス、例えば、レンダリング・パラメータ・データを含む各々のユニークなドロー・コンテクストに関連するゾーン・インデックスと一緒に、1062に示すように、スクリーン領域の各ゾーンに対してレンダリング・パラメータ・コンテクスト1063を設定することを含んでもよい。アプリケーション処理ステージ1061が、例えば仮想空間内の一セットの頂点によって定義されたポリゴン・メッシュとしてレンダリングするために、各オブジェクトを設定し、オブジェクトが覆うスクリーン空間の各々のユニークなゾーンに対してゾーン・インデックス1064を設定してもよい。1065に示すように、それから、各オブジェクトに対して、そのオブジェクトが覆う一つ以上のゾーンのレンダリング・パラメータに従ってレンダリングされるよう、ドロー・コールが発せられてもよい。特定のインプリメンテーションにおけるプロセス1000aは、異なるCPU及びGPU間で調整されてもよい。
【0079】
入力データ1022は、ゾーン・インデックス1064とそれらインデックスに関連する対応レンダリング・コンテクスト1063に応じて、一つ以上のレンダリング・パラメータに従ってオブジェクトをレンダリングするために、種々のレンダリング操作を実行するようアクセスされ、利用されてもよい。レンダリング・パイプラインは入力データ1022を操作してもよく、その入力データは、ワールド空間内に設定された一セットの頂点によって定義された一つ以上の仮想オブジェクトを含んで、シーン内の座標に対して定義されたジオメトリーを有してもよい。レンダリング・パイプライン1000a内で利用される入力データ1022は、本開示の態様に従ってレンダリング・パイプライン内で処理されるプリミティブに対応する頂点で構成されるシーン・ジオメトリーのポリゴン・メッシュ・モデルを含んでもよい。また、初期頂点ジオメトリーは、CPUによって実行されるアプリケーション・ステージ中に、グラフィックス・メモリ内に設定されてもよい。パイプラインの初期ステージは、図中、頂点処理ステージ1024として概ね分類されるものを含んでもよく、これは、ワールド空間ジオメトリー内のオブジェクトの頂点を処理するための、種々の演算を含んでもよい。これは、頂点シェーディング演算1026を含んでもよく、その演算は、シーン内の頂点の種々のパラメータ値、位置値(例えば、X−Y座標及びZ深度値)、色値、明暗値、テクスチャ・コーディネート等を操作してもよい。頂点シェーディング演算1026は、一つ以上のプログラム可能な頂点シェーダによって実行されることが好ましい。頂点シェーディング演算は、オブジェクトが重なる各ゾーンに対してユニークに実行されてもよく、オブジェクト・ゾーン・インデックス1064は、頂点シェーディング1026中、使用すべきレンダリング・コンテクスト及びオブジェクト関連パラメータを決定し、それに応じて、後のラスタライゼーションのために頂点値がどのように操作されるべきかを決定するために利用されてもよい。
【0080】
頂点処理ステージは、モザイク化とジオメトリー・シェーダ演算1028などの、追加の頂点処理演算をオプションとして含んでもよく、その演算は、プリミティブを下位区分し、ワールド空間内に新しい頂点及び新しいジオメトリーを生成するために使用されてもよい。頂点処理1024と呼ばれるステージが完了したら、パイプライン内のこのステージで、一セットの頂点パラメータ値1046を各々有する頂点のセットによって、シーンが定義される。この場合の頂点パラメータ値は、グラフィックス・メモリ内に記憶されてもよい。特定のインプリメンテーションにおいては、頂点シェーダから出力される頂点パラメータ値1046は、オブジェクトのゾーン・インデックス1064に従って、異なるゾーンに対する異なる同次座標で定義された位置を含んでもよい。
【0081】
それから、パイプライン1000aは、シーン・ジオメトリーをスクリーン空間、及び、一セットの個別画素、すなわちレンダリング・パイプライン中に使用されるピクセルへ変換することに関わるラスタライゼーション処理ステージ1030へ進行してもよい。注意すべきは、用語ピクセルが必ずしも、最終表示バッファ画像におけるディスプレイ・ピクセル値に対応することを意味しないことである。仮想空間ジオメトリーは、オブジェクト及び頂点の投影をワールド空間から、ラスタライザーによってサンプリングされた複数の個別スクリーン空間ピクセルで構成されるシーンの表示ウィンドウ(または「ビューポート」)へ本質的に演算する操作を介して、スクリーン空間ジオメトリーへ変換されてもよい。本開示の態様によれば、スクリーン領域は、異なるレンダリング・パラメータを有する複数の異なるゾーンを含んでもよく、これらパラメータは、異なるゾーンに対して異なるラスタライゼーション・パラメータを含んでもよい。図示のラスタライゼーション処理ステージ1030は、シーン内の頂点の各セットによって定義されたプリミティブを設定するプリミティブ・アセンブリ操作1032を含んでもよい。各頂点は、頂点インデックスによって定義され、各プリミティブは、これら頂点インデックスに対して定義されてもよい。また、頂点インデックスは、グラフィックス・メモリ1020内のインデックス・バッファ内に記憶されてもよい。プリミティブは、各々三つの頂点によって定義される三角形を少なくとも含まなければならないが、点プリミティブ、線分プリミティブ及び他の多角形形状を含んでもよい。プリミティブ・アセンブリ・ステージ1032中に、特定のプリミティブが、オプションとして間引かれてもよい。例えば、頂点インデックス及び同次座標空間位置が特定の湾曲状態を示すプリミティブは、後ろ向きであると見なしてもよく、シーンから間引かれてもよい。プリミティブ・アセンブリ1032は、プリミティブ頂点に対するスクリーン空間変換を含んでもよく、この変換は、スクリーン領域の異なるゾーンに対して異なるスクリーン空間変換パラメータをオプションとして含んでもよい。
【0082】
プリミティブがアセンブルされた後、ラスタライゼーション処理ステージは、スキャン変換操作1034を含んでもよく、この操作は、各々の個別ピクセルにおけるプリミティブをサンプリングし、サンプルがプリミティブによってカバーされる場合、更なる処理のために、それらプリミティブからフラグメントを生成してもよい。本開示のいくつかのインプリメンテーションでは、スキャン変換1034は、各々のスクリーン空間ピクセル内の複数のサンプルに対して、サンプル・カバレージを決定してもよい。
【0083】
スキャン変換1034中にプリミティブから生成されるフラグメント(または「ピクセル」)は、生成に関与したプリミティブの頂点の頂点パラメータ値1046からピクセルの位置へ内挿されるパラメータ値を有してもよい。ラスタライゼーション・ステージ1030は、これら内挿フラグメント・パラメータ値1048を演算するパラメータ補間操作1036を含んでもよい。これらパラメータ値は、パイプラインの後期ステージにおける更なる処理のための入力として使用されてもよく、パラメータ補間は、深度サンプルをカバーするプリミティブの頂点深度値からの、深度値の補間を含んでもよい。これらパラメータ値は、構成に応じて、ピクセル・シェーダへの入力フラグメント値として使用されても、または使用されなくてもよい。
【0084】
方法1000aは、図中1040に概略を示す、内挿パラメータ値1048を更に操作する更なるピクセル処理操作を含んでもよく、また、フラグメント及び/または内挿値が、表示すべき最終ピクセル値にどのように寄与するのかを決定する更なる操作を実行してもよい。これらピクセル処理タスクのいくつかは、フラグメントの内挿パラメータ値1048を更に操作するために使用されるピクセル・シェーディング演算1042を含んでもよい。ピクセル・シェーディング演算は、プログラム可能なピクセル・シェーダによって実行されてもよく、ピクセル・シェーダ呼出し1038は、ラスタライゼーション処理ステージ1030中のプリミティブのサンプリングに基づいて始動されてもよい。
【0085】
ピクセル・シェーディング演算1042は、しばしばレンダリング目標1049と呼ばれるグラフィックス・メモリ1020内の一つ以上のバッファへ値を出力してもよい。いくつかのインプリメンテーションでは、複数のレンダリング目標(MRT)が使用されてもよい。このケースにおけるピクセル・シェーダは、各々のピクセル毎の、またはサンプル毎の出力に対して、複数の独立値を出力することが可能であってもよい。本開示の特定のインプリメンテーションでは、スクリーンの異なるゾーンに対する異なるMRTパラメータを使用することが可能である。ピクセル処理1040は、レンダリング出力操作1044を含んでもよい。この出力操作は、しばしばラスタ演算(ROP)として既知であるものを含んでもよい。レンダリング出力操作1044は、ピクセル・シェーダによって処理されたフラグメント値、及び、多分、ピクセル・シェーダによって処理されない内挿深度値が、色バッファ及び/または深度バッファへ書き込まれるべきかどうかを判定するために、深度テスト、ステンシル・テスト及び/または他の操作を含んでもよい。また、レンダリング出力操作のいくつかは、ピクセル・シェーディング演算1042の後、または、最適化としてのピクセル・シェーディング演算1042の前に実行されてもよい。レンダリング目標1049のサンプル毎の最終色値及び深度値は、レンダリング出力操作1044に従って決定されてもよく、完結フレームを構築する最終表示ピクセル値が決定される前に、(しばしば「フレーム・バッファ」として既知である)表示バッファへ一つ以上のバック・バッファとして記憶されてもよい。
【0086】
完結フレームは、上述のパイプライン操作に従う複数の異なるドロー・コールの結果であってよい。さらに、本開示のインプリメンテーションは、また、異なるレンダリング・パラメータで、複数の異なるゾーンを有する出力表示画像へ演算された異なるスクリーン空間画像を合成してもよい。オプションとして、出力表示画像のゾーン間の継ぎ目を隠すために、追加の後処理が使用されてもよい。この後処理は、例えば、複数の異なるドロー・コールからのピクセル処理の後、オプションとして行われてもよいことにも注意すべきである。
【0087】
また、パイプラインのどのステージも、ハードウェア・モジュール、ソフトウェア・モジュール(例えば、一つ以上の個々の、または統一されたシェーダ・プログラム)、または、それらのいくつかの組み合わせで実行されてもよい。
【0088】
さて、もう一つの例示的実施例を表す
図10Bを参照する。
図10Bに示すインプリメンテーションにおけるレンダリング方法1000bは、
図9に示す再レンダリング方法の態様を実行するように構成されてもよい。この実施例における方法1000bは、
図10Aに示す実施例に共通の多くの特徴を含んでもよい。しかしながら、この実施例におけるプリミティブ・アセンブラ1032は、
図9に示す実施例に従って、対応オブジェクトが覆う各ゾーンに対するビューポートへ、各プリミティブを反復的にマッピングするように構成されてもよい。その結果、異なるゾーンを覆うオブジェクトに対する各々の異なるスクリーン空間ゾーンへユニークにアセンブルされたアセンブル済プリミティブ1066のバッチが生成されてもよい。
【0089】
さて、
図11を参照する。これは、本開示の態様に従ってグラフィクスをレンダリングするように構成されたコンピューティング・システム1100の例示的実施例を表す。システム1100は、上述の態様に従って、アプリケーション1165のためにグラフィクスをレンダリングするように構成されてもよい。本開示の態様によれば、システム1100は、組み込みシステム、携帯電話、パーソナル・コンピュータ、タブレット型コンピュータ、携帯用ゲーム・デバイス、ワークステーション、ゲーム機などであってもよい。
【0090】
システムは概して、例えば、
図8及び/または9の方法に共通な特徴を有する方法を実行することによって、本開示の態様を実行するように構成されたプロセッサ及びメモリを含んでもよい。例示実施例におけるプロセッサは、中央処理ユニット(CPU)1170、グラフィクス処理ユニット(GPU)1171及びメモリ1172を含む。メモリ1172は、CPU及びGPUの両方がアクセス可能なメイン・メモリ・ユニットをオプションとして含んでもよく、メイン・メモリの一部が、グラフィックス・メモリ1150の一部をオプションとして含んでもよい。CPU1170及びGPU1171は、各々、例えば、単一のコア、二つのコア、四つのコア、八つのコアまたはそれを超える、一つ以上のプロセッサ・コアを含んでもよい。CPU1170及びGPU1171は、データ・バス1176を使用して、一つ以上のメモリ・ユニットにアクセスするよう構成されてもよく、いくつかのインプリメンテーションでは、システム1100が二つ以上の異なるバスを含むことが有利である。
【0091】
メモリ1172は、例えばRAM、DRAM等のアドレス指定可能メモリを提供する集積回路の形態で、一つ以上のメモリ・ユニットを含んでもよい。グラフィックス・メモリ1150は、グラフィクス・レンダリング・パイプラインのために、グラフィクス・リソース、グラフィクス・バッファ及び他のグラフィクス・データを一時的に記憶してもよい。グラフィクス・バッファは、本開示の態様に従って、レンダリング・コンテクスト・データ及びゾーン・インデックスを保持するように構成されたコマンド・バッファ1159を含んでもよい。グラフィクス・バッファは、例えば、頂点パラメータ値を記憶するための一つ以上の頂点バッファ、及び、頂点インデックスを記憶するための一つ以上のインデックス・バッファを含んでもよい。グラフィクス・バッファは、また、一つ以上のレンダリング目標を含んでもよく、これらは、本開示の態様に従って演算されたピクセル/サンプル値を保持する色バッファ及び深度バッファの両方を含んでもよい。バッファの値は、本開示の態様に従って、スクリーンの異なるゾーンに対応する異なるレンダリング・パラメータを使用してレンダリングされたピクセルに対応してもよい。特定のインプリメンテーションにおけるGPU1171は、ディスプレイ1186上への提示のために表示バッファ1193からグラフィクス・フレームをスキャン出力するように構成されてもよく、表示バッファは、本開示の態様に従って複数の異なるゾーンを有する出力表示画像を含んでもよい。
【0092】
CPUは、CPUコードを実行するように構成されてもよい。CPUコードは、(ビデオゲーム等の)描写グラフィクスを利用するアプリケーション1165、及び、アプリケーション1165の状態に基づきGPU1171によって実行されるプログラムへドロー・コマンドまたはドロー・コールを発するための対応グラフィクスAPI1167を含んでもよい。CPUコードは、また、物理学的シミュレーション及び他の関数を実行してもよい。
【0093】
GPUは、本開示の例示的インプリメンテーションに関して上記に考察したように稼働するよう構成されてもよい。グラフィクスのレンダリングをサポートするために、GPUはシェーダ1173を実行してもよい。また、頂点シェーダ及びピクセル・シェーダを含んでもよい。GPUは、また、他のシェーダ・プログラム、例えばジオメトリー・シェーダ、モザイク化シェーダ、演算シェーダ等を実行してもよい。GPUは特殊なハードウェア・モジュール1198を含んでもよく、それらは、
図10A及び10Bに示すパイプラインに類似のグラフィクス・パイプラインの一つ以上のステージで、操作を実行するように構成された一つ以上のテクスチャ・マッピング・ユニット及び/または他のハードウェア・モジュールを含んでもよい。それらは固定関数演算であってもよい。シェーダ1173及びハードウェア・モジュール1198は、最終ピクセル値がディスプレイへ出力される前に、パイプライン内の種々のステージで、メモリ1150及びバッファ内のデータを入出力してもよい。本文に説明のグラフィック処理技術の態様を実行するためにシステム1100のプロセッサによって実行されるよう構成されたシェーダ1173及び/または他のプログラムは、非一時的コンピュータ可読媒体内に命令として記憶されてもよい。GPUは、オプションとしてGPUのハードウェア・モジュール1198内に具現化されてもよいプリミティブ・アセンブリ・モジュール1138、シェーダ1173、またはそれらの組み合わせを含んでもよい。プリミティブ・アセンブリ・モジュール1138は、本開示の態様に従って、スクリーン空間内の複数の異なるゾーンに対して受信プリミティブの演算を繰り返すように構成されてもよい。
【0094】
システム1100は、また、例えば、バス1176を介してシステムの他の構成部品と通信を行う周知のサポート機能1177を含んでもよい。そのようなサポート機能は、入出力(I/O)素子1179、電源(P/S)1180、クロック(CLK)1181及びキャッシュ1182を含むが、これらに限定されるものではない。装置1100は、オプションとして、プログラム及び/またはデータを記憶するために、ディスク・ドライブ、CD−ROMドライブ、フラッシュメモリ、テープ装置、Blu−ray(登録商標)ドライブ等の大容量記憶デバイス1184を含んでもよい。デバイス1100は、ユーザーへ描写グラフィクス1187を提示するためのディスプレイ・ユニット1186、及び、装置1100及びユーザー間の相互作用を促進するユーザー・インターフェイス・ユニット1188を含んでもよい。ディスプレイ・ユニット1186は、フラットパネルディスプレイ、ブラウン管(CRT)スクリーン、タッチスクリーンの形態であっても、または、テキスト、数字、グラフィックシンボルまたは画像を表示可能な他のデバイスの形態であってもよい。ディスプレイ1186は、本文で説明の種々の技術に従って処理された描写グラフィクス1187を表示可能である。特定のインプリメンテーションにおける表示デバイス1186は、頭部装着ディスプレイ(HMD)または他の大きなFOVディスプレイであってもよく、システム1100は、大きなFOVディスプレイに対するレンダリング効率が最適化されるように構成されてもよい。ユーザー・インターフェイス1188は、例えばキーボード、マウス、ジョイスティック、ライトペン、ゲーム・コントローラ、タッチスクリーン、及び/またはグラフィカル・ユーザー・インターフェイス(GUI)と併せて使用可能な他のデバイス等の、一つ以上の周辺機器であってもよい。特定のインプリメンテーションにおいては、例えば、アプリケーション1165がビデオゲームを含むビデオ・ゲーム・インプリメンテーションでは、アプリケーション1165の状態及びグラフィクスの基調をなすコンテンツが、ユーザー・インターフェイス1188を介したユーザー入力によって少なくとも部分的に決定されてもよい。システム1100は、例えば、中心窩レンダリングを実行するために、ディスプレイ上の、視聴者の着目点を検出するように構成された凝視トラッカー1199を含んでもよい。また、システム1100は、応答してビューポート上の一つ以上のゾーンの位置を調節するように構成されてもよい。凝視追跡ユニット1199は、カメラから検出されるユーザーの凝視方向に基づきスクリーン上の着目点を検出するために、赤外線LEDまたは他の赤外線光源などの一つ以上の光源、及び、赤外線カメラ等の一つ以上のカメラを含んでもよい。
【0095】
システム1100は、また、デバイスがネットワークを介して他のデバイスと通信可能なよう、ネットワーク・インターフェイス1190を含んでもよい。ネットワークは、例えば、ローカル・エリア・ネットワーク(LAN)、インターネット等のワイド・エリア・ネットワーク、Bluetooth(登録商標)ネットワークまたは他のタイプのネットワーク等のパーソナル・エリア・ネットワークであってもよい。図示及び説明の、種々の構成部品は、ハードウェア、ソフトウェアまたはファームウェア、または、これらの二つ以上のいくつかの組み合わせで実行されてもよい。
【0096】
追加の態様
本開示の追加の態様は、スクリーン領域にマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法を含む。スクリーン領域は複数のゾーンを含み、各々のゾーンは、レンダリング・パラメータの異なるセットを有する。この方法は、メモリ内に各ゾーンに対するレンダリング・パラメータ・コンテクストを設定すること、各ゾーンに対してゾーン・インデックスを割り当てること、メモリ内にオブジェクトを設定することを含む。この方法におけるオブジェクトは、スクリーン領域の少なくとも二つのゾーンを覆い、少なくとも二つのゾーンは、各々、少なくとも二つのゾーン・インデックスに割り当てられる。また、上記オブジェクトの設定は、オブジェクトに対して少なくとも二つのゾーン・インデックスを設定することを含み、上記方法は、さらに、オブジェクトに対するドロー・コールを発することを含む。
【0097】
もう一つの追加の態様は、実行されると前述の方法を遂行するコンピュータ実行命令を記憶したコンピュータ可読媒体である。
【0098】
更なる態様は、前述の方法を実行するための電磁または通信コンピュータ可読命令である。
【0099】
さらにもう一つの態様は、通信ネットワークからダウンロード可能な、及び/またはコンピュータ可読媒体及び/またはマイクロプロセッサ実行可能媒体に記憶されたコンピュータ・プログラムであり、前述の方法を実行するためのプログラム・コード命令を含むことを特徴とする。
【0100】
本開示の追加の態様は、スクリーン領域にマッピングすべき一つ以上のオブジェクトを描写するグラフィクスの処理方法を含む。スクリーン領域は複数のゾーンを含み、各々のゾーンは、レンダリング・パラメータの異なるセットを有する。この方法は、スクリーン領域の少なくとも二つのゾーンを覆うオブジェクトに属するプリミティブのバッチを受けること、プリミティブ・アセンブラでスクリーン空間へプリミティブの各々をアセンブルすることを含む。この方法において、プリミティブの各々をアセンブルすることは、各イテレーションで各々のゾーンの異なるセットのレンダリング・パラメータを使用して、プリミティブ・アセンブラで少なくとも2回(少なくとも二つのゾーンの各々に対して一度)各プリミティブの演算を繰り返すことを含む。
【0101】
もう一つの追加の態様は、実行されると前述の方法を遂行するコンピュータ実行命令が記憶されたコンピュータ可読媒体である。
【0102】
更なる態様は、前述の方法を実行するための電磁または通信コンピュータ可読命令である。
【0103】
さらにもう一つの態様は、通信ネットワークからダウンロード可能な、及び/またはコンピュータ可読媒体及び/またはマイクロプロセッサ実行可能媒体に記憶されたコンピュータ・プログラムであり、前述の方法を実行するためのプログラム・コード命令を含むことを特徴とする。
【0104】
上記説明は本発明の好適実施例の詳細であるが、種々の変更、修正及び同等代替を適用することが可能である。したがって、本発明の範囲は、上記説明の参照によってではなく、その代わりに、添付の請求項及び同等代替の範囲を参照して決定すべきである。本明細書で説明の特徴は、好適かどうかに関わらず、本明細書で説明の他の特徴と組み合わされてもよい。以下の請求項における不定冠詞「a」または「an」は、明確に否定されていない限り、不定冠詞に続く品目の一つ以上の数量を表す。添付の請求項は、「のための手段」と請求項内に明確に制限が記述されていない限り、手段及び機能制限を含むと解釈すべきではない。