JP2015506017A - オーバドロー・トラッカを用いたグラフィック処理におけるダイレクト・レンダリングとビニングとの切替 - Google Patents

Abstract

本開示は、レンダリング・モード（例えば、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モード）を決定するための技法および構成のみならず、このようなレンダリング・モード間の切り替えのための技法および構成を表す。レンダリング・モードは、レンダリング特性を分析することによって決定されうる。レンダリング・モードはまた、ビンにおけるオーバドローをトラックすることによって決定されうる。レンダリング・モードは、グラフィック・メモリ・アドレスを用いるコマンドを、システム・メモリ・アドレスを用いるようにパッチすることによって、ビニング・レンダリング・モードからダイレクト・レンダリング・モードへ切り替えられうる。パッチは、ＣＰＵによって取り扱われうるか、または、ＧＰＵによって実行可能な第２の書込コマンド・バッファによって取り扱われうる。

Description

優先権主張

本願は、その全体が参照によって本明細書に組み込まれている２０１１年１１月３０日出願の米国仮出願６１／５６５，３９７の利益を要求する。

本開示は、グラフィック処理のための技法に関し、さらに詳しくは、グラフィック処理におけるダイレクト・レンダリングとビニングとの切替のための技法に関する。

例えば、グラフィック・ユーザ・インタフェースおよびビデオ・ゲームのためのコンテンツのような、ディスプレイのためのビジュアル・コンテンツは、グラフィック処理ユニット（ＧＰＵ）によって生成されうる。ＧＰＵは、２次元（２Ｄ）または３次元（３Ｄ）のオブジェクトを、表示されうる２次元ピクセル表現に変換しうる。３Ｄオブジェクトに関する情報を、表示されるビット・マップへ変換することは、ピクセル・レンダリングとして知られており、かなりのメモリおよび処理電力を必要とする。過去においては、３Ｄグラフィック機能は、強力なワークステーションにおいてのみ利用可能であった。しかしながら、今や、一般に、例えばスマート・フォン、タブレット・コンピュータ、ポータブル・メディア・プレーヤ、ポータブル・ビデオ・ゲーム・コンソール等のような組み込みデバイスと同様に、パーソナル・コンピュータ（ＰＣ）においても３Ｄグラフィック・アクセラレータが見受けられる。一般に、組み込みデバイスは、従来のＰＣと比較して、計算能力もメモリ容量も少ない。そのため、このような技法を、組み込みシステムにおいて実施する場合、３Ｄグラフィック・レンダリング技法の複雑さが増すので、困難を呈する。

一般に、本開示は、グラフィック処理におけるダイレクト・レンダリングとビニングとの切替のための技法と、レンダリング・モードを決定するための技法と、を記載している。

本開示の１つの例において、グラフィック処理のための方法は、フレームをレンダリングするためのレンダリング・コマンドを生成することと、ここで、レンダリング・コマンドは、ビニング・レンダリング・モードのためのものである；グラフィック・メモリ・アドレスを用いるレンダリング・コマンドをトラックすることと；レンダリング特性に基づいて、フレームのための複数のレンダリング・モードのうちの１つを決定することと、ここで、複数のレンダリング・モードは、ビニング・レンダリング・モードとダイレクト・レンダリング・モードを含む；決定されたレンダリング・モードがダイレクト・レンダリング・モードである場合、グラフィック・メモリ・アドレスを用いるレンダリング・コマンドを、システム・メモリ・アドレスを用いることに変更することと；を備える。

本開示の別の例では、グラフィック処理の方法は、シーンのプリミティブにビニング演算を実行することと、ここで、プリミティブは、ビンに分割される；シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと；計算されたスコアに基づいて、レンダリング・モードを決定することと；を備える。

本開示の別の例では、グラフィック処理の方法は、グラフィック演算を実行するための演算コマンドを第１のバッファに格納することと；書込コマンドを第２のバッファに格納することと；を備え、ここで、書込コマンドは、実行された場合、第１のバッファにおける演算コマンドを変更し、変更された演算コマンドを生成する。

本開示の技法はまた、これら技法をプロセッサに対して実行させるための命令群を格納したコンピュータ読取可能な媒体および装置の観点で記載される。１または複数の例の詳細が、添付図面および以下の説明において記載されている。他の特徴、目的、および利点が、説明と図面から、および特許請求の範囲から明らかになるだろう。

図１は、本開示の技法を用いるように構成されたコンピューティング・デバイスの例を示すブロック図である。 図２は、本開示の技法を用いるように構成された処理ユニットの例を示すブロック図である。 図３は、ビニング・レンダリング・モードにおいて使用されるようなフレームのビンを例示する概念図である。 図４は、ビニング・レンダリング・モードにおいて使用されるようなフレームのビンをより詳細に例示する概念図である。 図５は、「ソフトウェア」ビニングを用いるビニング・レンダリング・モードのためのコマンド・バッファを例示する概念図である。 図６は、「ハードウェア」ビニングを用いるビニング・レンダリング・モードのためのコマンド・バッファを例示する概念図である。 図７は、ダイレクト・レンダリング・モードのためのコマンド・バッファを例示する概念図である。 図８は、本開示の１つの例にしたがうレンダリング・コマンド・パッチを例示する概念図である。 図９は、本開示の１つの例にしたがうオーバドロー・トラッキングを例示する概念図である。 図１０は、本開示の１つの例にしたがう４つのビンにおけるオーバドローを例示する概念図である。 図１１は、本開示の１つの例にしたがうレンダリング・モード選択を例示する概念図である。 図１２は、本開示の別の例にしたがうレンダリング・コマンド・パッチを例示する概念図である。 図１３は、本開示の１つの例にしたがう方法を例示するフローチャートである。 図１４は、本開示の別の例にしたがう方法を例示するフローチャートである。 図１５は、本開示の別の例にしたがう方法を例示するフローチャートである。 図１６は、本開示の別の例にしたがう方法を例示するフローチャートである。

本開示は、グラフィック処理のための技法に関し、さらに詳しくは、レンダリング・モードを決定し、グラフィック処理システムにおけるレンダリング・モードを切り替えるための技法に関する。

現在のグラフィック・レンダリング・システムは、一般に、シーンをレンダリングするために、（しばしば、タイル・ベースのレンダリングと称される）ビニング・レンダリング・モードまたはダイレクト・レンダリング・モードを利用する。ビニング・レンダリングでは、２Ｄシーンまたは３Ｄシーンの１つのフレームが、より小さなパーツ（例えば、長方形のビンまたはタイル）に分解することと、これらビンのおのおのを個別にレンダリングすることと、によってレンダリングされる。ビニング・レンダリングは、例えば、モバイル・アプリケーションのためのように、小型の専用の高速グラフィック・メモリ（ＧＭＥＭ）が利用可能であるアプリケーションのために有益である。タイルのサイズは、ＧＭＥＭにおいて利用可能なデータの量を示すように構成されうる。例えば、ＧＭＥＭが５１２ｋＢを格納することができるのであれば、タイルのサイズは、そのタイルに含まれるピクセル・データが５１２ｋＢ以下になるように構成されうる。

一方、ダイレクト・レンダリング・モードにおけるグラフィック処理は、フレームを、より小さなビンに分解することはない。その代わり、フレームの全体は、一度にレンダリングされる。いくつかのグラフィック処理システム（例えば、モバイル・デバイス上のグラフィック処理システム）では、ピクセル・データのフレーム全体を保持するために十分なＧＭＥＭはない。そうではなく、ダイレクト・レンダリング・モードの場合、フレームをレンダリングするために、より低速のシステム・メモリしか使用されない。

本開示は、（例えば、ビニング・レンダリング・モードやダイレクト・レンダリング・モードのような）レンダリング・モードを決定するための技法および構成のみならず、このようなレンダリング・モードの切り替えを行うための技法および構成を表す。

本開示の１つの例では、グラフィック処理の方法は、フレームをレンダリングするためのレンダリング・コマンドを生成することと、ここで、レンダリング・コマンドは、ビニング・レンダリング・モードのためのものである；グラフィック・メモリ・アドレスを用いるレンダリング・コマンドをトラックすることと；レンダリング特性に基づいて、フレームのための複数のレンダリング・モードのうちの１つを決定することと、ここで、複数のレンダリング・モードは、ビニング・レンダリング・モードとダイレクト・レンダリング・モードを含む；決定されたレンダリング・モードがダイレクト・レンダリング・モードである場合、グラフィック・メモリ・アドレスを用いるレンダリング・コマンドを、システム・メモリ・アドレスを用いることに変更することと；を備える。

本開示の別の例では、グラフィック処理の方法は、シーンのプリミティブにビニング演算を実行することと、ここで、プリミティブは、ビンに分割される；シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと；計算されたスコアに基づいて、レンダリング・モードを決定することと；を備える。

開示の別の例では、グラフィック処理の方法は、グラフィック演算を実行するための演算コマンドを第１のバッファに格納することと；書込コマンドを第２のバッファに格納することと；を備え、ここで、書込コマンドは、第１のバッファにおける演算コマンドを変更し、変更された演算コマンドを生成する。

図１は、レンダリング・モードを決定することと、レンダリング・モードの切り替え（例えば、ビニング・レンダリング・モードとダイレクト・レンダリング・モードとの間の切り替え）を行うことと、のための、本開示の技法を実施するために使用されうるコンピューティング・デバイス２の例を例示するブロック図である。コンピューティング・デバイス２は、例えば、パーソナル・コンピュータ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、コンピュータ・ワークステーション、ビデオ・ゲーム・プラットフォームまたはコンソール、例えばセルラ電話または衛星電話のようなモバイル電話、陸線電話、インターネット電話、ポータブル・ビデオ・ゲーム・デバイスまたは携帯情報端末（ＰＤＡ）のようなハンドヘルド・デバイス、パーソナル音楽プレーヤ、ビデオ・プレーヤ、ディスプレイ・デバイス、テレビ、テレビジョン・セット・トップ・ボックス、サーバ、中間ネットワーク・デバイス、メインフレーム・コンピュータ、任意のモバイル・デバイス、または、グラフィック・データを処理および／または表示するその他のタイプのデバイスを備えうる。

図１の例で例示されるように、コンピューティング・デバイス２は、ユーザ入力インタフェース４、中央処理装置（ＣＰＵ）６、メモリ・コントローラ８、システム・メモリ１０、グラフィック処理ユニット（ＧＰＵ）１２、グラフィック・メモリ１４、ディスプレイ・インタフェース１６、ディスプレイ１８、およびバス２０，２２を含みうる。いくつかの例において、グラフィック・メモリ１４は、ＧＰＵ１２とともに「オン・チップ」されうることに注目されたい。いくつかのケースでは、図１に示されるすべてのハードウェア要素は、例えば、システム・オン・チップ（ＳｏＣ）設計されたシステム上にオン・チップされうる。ユーザ入力インタフェース４、ＣＰＵ６、メモリ・コントローラ８、ＧＰＵ１２、およびディスプレイ・インタフェース１６は、バス２０を用いて互いに通信しうる。メモリ・コントローラ８およびシステム・メモリ１０はまた、バス２２を用いて互いに通信しうる。バス２０，２２は、例えば、第３世代バス（例えば、ハイパ・トランスポート・バスまたはインフィニ・バンド・バス）、第２世代バス（例えば、アドバンスト・グラフィック・ポート・バス、ペリフェラル・コンポーネント・インタコネクト（ＰＣＩ）エクスプレス・バス、または、アドバンスト・エクステンシブル・インタフェース（ＡＸＩ）バス）または、その他のタイプのバスまたはデバイス・インタコネクト、のようなさまざまなバス構成のうちの何れかでありうる。図１に図示される異なる構成要素間の通信インタフェースおよびバスの具体的な構成は、単なる典型例であり、本開示の技法を実現するために、同じ構成要素または異なる構成要素を持つコンピューティング・デバイスおよび／またはその他のグラフィック処理システムのその他の構成も使用されうることが注目されるべきである。

ＣＰＵ６は、コンピューティング・デバイス２の動作を制御する汎用または専用のプロセッサを備えうる。ユーザは、ＣＰＵ６に対して、１または複数のソフトウェア・アプリケーションを実行させるために、コンピューティング・デバイス２へ入力を提供しうる。ＣＰＵ６において動作するソフトウェア・アプリケーションは、例えば、オペレーティング・システム、ワード・プロセッサ・アプリケーション、電子メール・アプリケーション、スプレッド・シート・アプリケーション、メディア・プレイヤ・アプリケーション、ビデオ・ゲーム・アプリケーション、グラフィック・ユーザ・インタフェース・アプリケーション、またはその他のプログラムを含みうる。さらに、ＣＰＵ６は、ＧＰＵ１２の動作を制御するために、ＧＰＵドライバ７を実行しうる。ユーザは、例えば、キーボード、マウス、マイクロホン、タッチ・パッドまたは、ユーザ入力インタフェース４を経由してコンピューティング・デバイス２に接続されるその他の入力デバイス、のような１または複数の入力デバイス（図示せず）によって、コンピューティング・デバイス２へ入力を提供しうる。

ＣＰＵ６において動作するソフトウェア・アプリケーションは、グラフィック・データのディスプレイ１８へのレンダリングを行わせるようにＣＰＵ６に指示する１または複数のグラフィック・レンダリング命令群を含みうる。いくつかの例において、ソフトウェア命令群は、例えば、オープン・グラフィック・ライブラリ（ＯｐｅｎＧＬ（登録商標））、オープン・グラフィック・ライブラリ・エンベデッド・システム（ＯｐｅｎＧＬ ＥＳ）ＡＰＩ、ダイレクト３Ｄ ＡＰＩ、Ｘ３Ｄ ＡＰＩ、レンダマンＡＰＩ、ＷｅｂＧＬ ＡＰＩ、または、その他任意の公開または独自規格のグラフィックＡＰＩ、のようなグラフィック・アプリケーション・プログラミング・インタフェース（ＡＰＩ）に準拠しうる。グラフィック・レンダリング命令群を処理するために、ＣＰＵ６は、（例えば、ＧＰＵドライバ７によって）１または複数のグラフィック・レンダリング・コマンドをＧＰＵ１２へ発行し、ＧＰＵ１２に対して、グラフィック・データのレンダリングのうちのいくつかまたはすべてを実行させる。いくつかの例において、レンダリングされるべきグラフィック・データは、例えば、点、線、三角形、四角形、三角形ストリップ等のようなグラフィック・プリミティブのリストを含みうる。

メモリ・コントローラ８は、システム・メモリ１０との間のデータの移動を容易にする。例えば、メモリ・コントローラ８は、メモリ読取コマンドおよびメモリ書込コマンドを受け取りうる。そして、コンピューティング・デバイス２内の構成要素のためにメモリ・サービスを提供するために、メモリ・システム１０に関するこれらコマンドをサービスしうる。メモリ・コントローラ８は、メモリ・バス２２を介してシステム・メモリ１０に通信可能に接続される。メモリ・コントローラ８は、図１において、ＣＰＵ６とシステム・メモリ１０との両方と離れている処理モジュールであると例示されているが、別の例では、メモリ・コントローラ８の機能のうちのいくつかまたはすべてが、ＣＰＵ６とシステム・メモリ１０のうちの１つまたは両方で実現されうる。

システム・メモリ１０は、ＣＰＵ６による実行のためにアクセス可能であるプログラム・モジュールおよび／または命令群、および／または、ＣＰＵ６で動作するプログラムによって使用されるデータ、を格納しうる。例えば、システム・メモリ１０は、ディスプレイ１８上にグラフィック・ユーザ・インタフェース（ＧＵＩ）を表示するためにＣＰＵ６によって使用されるウィンドウ・マネジャ・アプリケーションを格納しうる。さらに、システム・メモリ１０は、ユーザ・アプリケーションと、このアプリケーションに関連付けられたアプリケーション・サーフェス・データとを格納しうる。システム・メモリ１０はさらに、コンピューティング・デバイス２のその他の構成要素によって使用される、および／または、生成された情報を格納しうる。例えば、システム・メモリ１０は、ＧＰＵ１２のためのデバイス・メモリとして動作し、ＧＰＵ１２によって演算されるべきデータのみならず、ＧＰＵ１２によって実行された演算の結果得られたデータをも格納しうる。例えば、システム・メモリ１０は、テクスチャ・バッファ、デプス・バッファ、ステンシル・バッファ、頂点バッファ、フレーム・バッファ等の任意の組み合わせを格納しうる。システム・メモリ１０は、例えば、ランダム・アクセス・メモリ（ＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能なプログラマブルＲＯＭ（ＥＰＲＯＭ）、電子的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、磁気データ媒体、または、光学記憶媒体、のような１または複数の揮発性または不揮発性のメモリまたは記憶デバイスを含みうる。

ＧＰＵ１２は、ディスプレイ１８に１または複数のグラフィック・プリミティブをレンダリングするためのグラフィック演算を実行するように構成されうる。したがって、ＣＰＵ６において動作するソフトウェア・アプリケーションのうちの１つが、グラフィック処理を必要とする場合、ＣＰＵ６は、ディスプレイ１８にレンダリングするために、グラフィック・コマンドおよびグラフィック・データをＧＰＵ１２へ提供しうる。グラフィック・データは、例えば、ドロー・コマンド、状態情報、プリミティブ情報、テクスチャ情報等を含みうる。ＧＰＵ１２は、いくつかの事例では、複雑なグラフィック関連演算の、ＣＰＵ６よりもより効率的な処理を提供する高度な並列構造で構築されうる。例えば、ＧＰＵ１２は、複数の頂点またはピクセルにおいて並列方式で動作するように構成された複数の処理要素を含みうる。いくつかの事例では、ＧＰＵ１２の高度な並列特性によって、ＧＰＵ１２は、ＣＰＵ６を用いてディスプレイ１８にダイレクトにシーンを描画するよりも、より迅速にディスプレイ１８にグラフィック・イメージ（例えば、ＧＵＩおよび２次元（２Ｄ）および／または３次元（３Ｄ）のグラフィック・シーン）を描画できるようになる。

ＧＰＵ１２は、いくつかの事例では、コンピューティング・デバイス２のマザーボードへ組み込まれうる。その他の事例では、ＧＰＵ１２は、コンピューティング・デバイス２のマザーボードのポートに搭載されたグラフィック・カード上に存在しうるか、または、コンピューティング・デバイス２と協働するように構成された周辺デバイス内に組み込まれうる。ＧＰＵ１２は、例えば、１または複数のマイクロプロセッサ、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラム可能なゲート・アレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、または他の等価な統合されたまたは個別のロジック回路のような１または複数のプロセッサを含みうる。

ＧＰＵ１２は、グラフィック・メモリ１４にダイレクトに接続されうる。したがって、ＧＰＵ１２は、バス２０を用いることなく、グラフィック・メモリ１４からのデータの読み取り、および、グラフィック・メモリ１４へのデータの書き込みを実施しうる。言い換えれば、ＧＰＵ１２は、オフ・チップ・メモリの代わりに、ローカル記憶装置を用いて、データをローカルに処理しうる。これによって、ＧＰＵ１２は、高いバス・トラフィックを経験しうるバス２０を経由してのデータの読取および書込のためにＧＰＵ１２を必要とすることを不要とすることによって、より効率的な方式で動作できるようになる。しかしながら、いくつかの事例では、ＧＰＵ１２は、個別のメモリを含みうるが、代わりに、バス２０を経由してシステム・メモリ１０を利用しうる。グラフィック・メモリ１４は、例えば、ランダム・アクセス・メモリ（ＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、消去可能なプログラマブルＲＯＭ（ＥＰＲＯＭ）、電子的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、磁気データ媒体、または光学記憶媒体のような１または複数の揮発性または不揮発性のメモリまたは記憶デバイスを含みうる。

ＣＰＵ６および／またはＧＰＵ１２は、レンダリングされたイメージ・データを、フレーム・バッファ１５に格納しうる。フレーム・バッファ１５は、独立したメモリでありうるか、または、システム・メモリ１０内に割り当てられうる。ディスプレイ・インタフェース１６は、フレーム・バッファ１５からデータを取得し、レンダリングされたイメージ・データによって表現されるイメージを表示するようにディスプレイ１８を構成しうる。いくつかの例において、ディスプレイ・インタフェース１６は、フレーム・バッファから取得されたデジタル値を、ディスプレイ１８によって使用されるアナログ信号へ変換するように構成されたデジタル・アナログ変換器（ＤＡＣ）を含みうる。その他の例では、ディスプレイ・インタフェース１６は、処理のために、デジタル値を、ディスプレイ１８へダイレクトに渡しうる。ディスプレイ１８は、モニタ、テレビ、映写デバイス、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ・パネル、例えば有機ＬＥＤ（ＯＬＥＤ）ディスプレイのような発光ダイオード（ＬＥＤ）アレイ、陰極管（ＣＲＴ）ディスプレイ、電子ペーパ、表面電界ディスプレイ（ＳＥＤ）、レーザ・テレビ・ディスプレイ、ナノ結晶ディスプレイ、またはその他のタイプのディスプレイ・ユニットを含みうる。ディスプレイ１８は、コンピューティング・デバイス２に組み込まれうる。例えば、ディスプレイ１８は、モバイル電話のスクリーンでありうる。あるいは、ディスプレイ１８は、有線または無線の通信リンクによってコンピューティング・デバイス２へ接続されたスタンド・アロンのデバイスでありうる。例えば、ディスプレイ１８は、ケーブルまたは無線リンクによってパーソナル・コンピュータに接続されたコンピュータ・モニタまたはフラット・パネル・ディスプレイでありうる。

本開示の１つの例によれば、ＣＰＵ６および／またはＧＰＵ７は、フレームをレンダリングするためのレンダリング・コマンドを生成することと、ここで、レンダリング・コマンドは、ビニング・レンダリング・モードのためのものである；グラフィック・メモリ・アドレスを用いるレンダリング・コマンドをトラックすることと；レンダリング特性に基づいて、フレームのための複数のレンダリング・モードのうちの１つを決定することと、ここで、複数のレンダリング・モードは、ビニング・レンダリング・モードとダイレクト・レンダリング・モードを含む；決定されたレンダリング・モードがダイレクト・レンダリング・モードである場合、グラフィック・メモリ・アドレスを用いるレンダリング・コマンドを、システム・メモリ・アドレスを用いることに変更することと；を実行するように構成されうる。

本開示の別の例によれば、ＣＰＵ６および／またはグラフィック・ドライバ７は、シーンのプリミティブにビニング演算を実行することと、ここで、プリミティブは、ビンに分割される；シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと；計算されたスコアに基づいて、レンダリング・モードを決定することと；を実行するように構成されうる。

本開示の別の例によれば、ＣＰＵ６および／またはグラフィック・ドライバ７は、グラフィック演算を実行するための演算コマンドを第１のバッファに格納することと；書込コマンドを第２のバッファに格納することと；を備え、ここで、書込コマンドは、第１のバッファにおける演算コマンドを変更し、変更された演算コマンドを生成する。

図２は、図１のＣＰＵ６、ＧＰＵ１２、およびシステム・メモリ１０の実施の例をさらに詳細に例示するブロック図である。ＣＰＵ６は、少なくとも１つのソフトウェア・アプリケーション２４、グラフィックＡＰＩ２６、およびＧＰＵドライバ７を含みうる。これらのおのおのは、ＣＰＵ６上で動作する１または複数のソフトウェア・アプリケーションまたはサービスでありうる。ＧＰＵ１２は、グラフィック処理コマンドを実行するためのともに動作する複数のグラフィック処理ステージを含むグラフィック処理パイプライン３０を含みうる。ＧＰＵ１２は、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードを含むさまざまなレンダリング・モードでグラフィック処理パイプライン３０を実行するように構成されうる。図２に図示されるように、グラフィック処理パイプライン３０は、コマンド・エンジン３２、幾何学処理ステージ３４、ラスタライゼーション・ステージ３６、およびピクセル処理パイプライン３８を含みうる。グラフィック処理パイプライン３０における構成要素のおのおのは、固定機能構成要素、（例えば、プログラマブル・シェダー・ユニットにおいて動作するシェダー・プログラムの一部としての）プログラマブル構成要素、または、固定機能構成要素とプログラマブル構成要素の組み合わせとして実現されうる。ＣＰＵ６およびＧＰＵ１２に利用可能なメモリは、システム・メモリ１０およびフレーム・バッファ１５を含みうる。フレーム・バッファ１５は、システム・メモリ１０の一部でありうるか、または、システム・メモリ１０から分離しうる。フレーム・バッファ１５は、レンダリングされたイメージ・データを格納しうる。

ソフトウェア・アプリケーション２４は、ＧＰＵ１２の機能を利用する任意のアプリケーションでありうる。例えば、ソフトウェア・アプリケーション２４は、ＧＵＩアプリケーション、オペレーティング・システム、ポータブル・マッピング・アプリケーション、エンジニアリング・アプリケーションまたはアーティスティック・アプリケーションのためのコンピュータ支援設計プログラム、ビデオ・ゲーム・アプリケーション、または、２Ｄまたは３Ｄグラフィックを用いるその他のタイプのソフトウェア・アプリケーション、でありうる。

ソフトウェア・アプリケーション２４は、グラフィック・ユーザ・インタフェース（ＧＵＩ）および／またはグラフィック・シーンをレンダリングするようにＧＰＵ１２に指示する１または複数のドローイング命令群を含みうる。例えば、ドローイング命令群は、ＧＰＵ１２によってレンダリングされるべき１または複数のグラフィック・プリミティブのセットを定義する命令群を含みうる。いくつかの例において、ドローイング命令群は、集合的に、ＧＵＩにおいて使用される複数のウィンドゥイング・サーフェスのうちのすべてまたは一部を定義しうる。さらなる例では、ドローイング命令群は、集合的に、アプリケーションによって定義されるワールド空間またはモデル空間内の１または複数のグラフィック・オブジェクトを含むグラフィック・シーンのすべてまたは一部を定義しうる。

ソフトウェア・アプリケーション２４は、グラフィックＡＰＩ２６を介してＧＰＵドライバ７を起動し、１または複数のグラフィック・プリミティブを表示可能なグラフィック・イメージにレンダリングするための１または複数のコマンドをＧＰＵ１２へ発行させる。例えば、ソフトウェア・アプリケーション２４は、グラフィックＡＰＩ２６を介してＧＰＵドライバ７を起動し、ＧＰＵ１２へプリミティブ定義を提供する。いくつかの事例では、プリミティブ定義が、例えば、三角形、長方形、三角形ファン、三角形ストリップ等のようなドローイング・プリミティブのリストの形態でＧＰＵ１２へ提供されうる。プリミティブ定義は、レンダリングされるべきプリミティブに関連付けられた１または複数の頂点を指定する頂点仕様を含みうる。頂点仕様は、おのおのの頂点の位置座標と、さらには、いくつかの事例においては、例えば、色座標、法線ベクトル、およびテクスチャ座標のように、頂点に関連付けられたその他の属性とを含みうる。プリミティブ定義はまた、プリミティブ・タイプ情報（例えば三角形、長方形、三角形ファン、三角形ストリップ等）、スケーリング情報、回転情報等を含みうる。ＧＰＵドライバ７は、プリミティブをレンダリングするために、ソフトウェア・アプリケーション２４によってＧＰＵドライバ７へ発行された命令群に基づいて、ＧＰＵ１２が実行するための１または複数の動作を指定する１または複数のコマンドを定式化しうる。ＧＰＵ１２がＣＰＵ６からコマンドを受け取った場合、グラフィック処理パイプライン３０は、このコマンドを復号し、グラフィック処理パイプライン３０内の１または複数の処理要素を、このコマンドにおいて指定された動作を実行するように設定する。グラフィック処理パイプライン３０は、指定された動作を実行した後、レンダリングされたデータを、ディスプレイ・デバイスに関連付けれたフレーム・バッファ４０へ出力する。グラフィック・パイプライン３０は、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードを含む複数の異なるレンダリング・モードのうちの１つを実行するように構成されうる。ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードの動作が、以下にさらに詳細に記載される。

ＧＰＵドライバ７はさらに、１または複数のシェダー・プログラムをコンパイルし、コンパイルされたシェダー・プログラムを、ＧＰＵ１２内に含まれた１または複数のプログラマブル・シェダー・ユニットにダウンロードするように構成されうる。シェダー・プログラムは、例えば、ＯｐｅｎＧＬシェーディング言語（ＧＬＳＬ）、高レベル・シェーディング言語（ＨＬＳＬ）、Ｃフォー・グラフィック（Ｃｇ）シェーディング言語等のような高レベル・シェーディング言語で記述されうる。コンパイルされたシェダー・プログラムは、ＧＰＵ１２内のプログラマブル・シェダー・ユニットの動作を制御する１または複数の命令群を含みうる。例えば、シェダー・プログラムは、頂点シェダー・プログラムおよび／またはピクセル・シェダー・プログラムを含みうる。頂点シェダー・プログラムは、プログラマブル頂点シェダー・ユニットまたは統一されたシェダー・ユニットの実行を制御しうる。また、１または複数の頂点毎の動作を指定する命令群を含みうる。ピクセル・シェダー・プログラムは、プログラマブル・ピクセル・シェダー・ユニットまたは統一されたシェダー・ユニットの実行を制御するピクセル・シェダー・プログラムを含みうる。また、１または複数のピクセル毎の動作を指定する命令群を含みうる。本開示のいくつかの実施形態の例によれば、ピクセル・シェダー・プログラムはまた、ソース・ピクセルの対応する目標アルファ値に基づいて、ソース・ピクセルのためにテクスチャ値が選択的に取得されるようにする命令群をも含みうる。

本開示の技法によれば、ＧＰＵドライバ７はまた、ＧＭＥＮアドレスを利用するビニング・レンダリング・モードにおけるレンダリングのために生成されたコマンドをトラックするように構成されうる。ＧＭＥＭアドレスを利用するおのおののコマンドについて、ＧＰＵドライバ７は、ダイレクト・レンダリング・モードのために使用されるであろう対応するシステム・メモリ・アドレスを格納しうる。レンダリング・モードがビニング・レンダリング・モードからダイレクト・レンダリング・モードへ切り替わったのであれば、ＧＰＵドライバ７は、ＧＭＥＭアドレスをシステム・メモリ・アドレスと交換するためにレンダリング・コマンドをパッチ（すなわち、変更）しうる。ＧＭＥＭアドレスをシステム・メモリ・アドレスでパッチするためのさらなる技法が、以下にさらに詳しく記載される。

グラフィック処理パイプライン３０は、グラフィック・ドライバ２８を経由してＣＰＵ６から１または複数のグラフィック処理コマンドを受け取り、表示可能なグラフィック・イメージを生成するために、このグラフィック処理コマンドを実行する、ように構成されうる。前述したように、グラフィック処理パイプライン３０は、グラフィック処理コマンドを実行するためにともに動作する複数のステージを含んでいる。しかしながら、このようなステージは、個別のハードウェア・ブロックで必ずしも実施される必要はないことが注目されるべきである。例えば、幾何学処理ステージ３４およびピクセル処理パイプライン３８の一部が、統一されたシェダー・ユニットの一部として実現されうる。繰り返すが、グラフィック・パイプライン３０は、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードを含む複数の異なるレンダリング・モードのうちの１つで実行するように構成されうる。

コマンド・エンジン３２は、グラフィック処理コマンドを受け取りうる。そして、グラフィック処理コマンドを実行するためのさまざまな動作を実行するように、グラフィック処理パイプライン３０内の残りの処理ステージを構成しうる。グラフィック処理コマンドは例えば、ドローイング・コマンドおよびグラフィック状態コマンドを含みうる。ドローイング・コマンドは、１または複数の頂点の位置座標を指定する頂点仕様コマンドと、さらに、いくつかの事例においては、例えば色座標、法線ベクトル、テクスチャ座標、およびフォグ座標のような頂点のおのおのに関連付けられたその他の属性値とを含みうる。グラフィック状態コマンドは、プリミティブ・タイプ・コマンド、変換コマンド、照明コマンド等を含みうる。プリミティブ・タイプ・コマンドは、レンダリングされるべきプリミティブのタイプ、および／または、プリミティブを生成するために頂点がどのように組み合わされるのか、を指定しうる。変換コマンドは、頂点に対して実行する変換のタイプを指定しうる。照明コマンドは、グラフィック・シーン内の異なる光のタイプ、方向、および／または、位置を指定しうる。コマンド・エンジン３２は、受け取られた１または複数のコマンドに関連付けられたプリミティブおよび／または頂点に関する幾何学処理を、幾何学処理ステージ３４に対して実行させうる。

幾何学処理ステージ３４は、ラスタライゼーション・ステージ３６のためのプリミティブ・データを生成するために、１または複数の頂点に対するプリミティブ設定演算および／または頂点毎の演算を実行しうる。おのおのの頂点は、例えば、位置座標、明度、法線ベクトル、およびテクスチャ座標のような属性のセットに関連付けられうる。幾何学処理ステージ３４は、頂点毎のさまざまな演算にしたがって、これら属性のうちの１または複数を修正する。例えば、幾何学処理ステージ３４は、修正された頂点位置座標を生成するために、頂点位置座標において１または複数の変換を実行しうる。幾何学処理ステージ３４は、例えば、修正された頂点位置座標を生成するために、モデリング変換、ビューイング変換、プロジェクション変換、モデル・ビュー変換、モデル・ビュー・プロジェクション変換、ビューポート変換、およびデプス範囲スケーリング変換のうちの１または複数を頂点位置座標に適用しうる。いくつかの事例では、頂点位置座標は、モデル空間座標でありうる。そして、修正された頂点位置座標は、スクリーン空間座標でありうる。スクリーン空間座標は、モデリング変換、ビユーイング変換、プロジェクション変換、およびビューポート変換が適用された後に取得されうる。いくつかの事例では、幾何学処理ステージ３４はまた、頂点のために修正された色座標を生成するために、頂点に対して頂点毎の照明演算を実行しうる。幾何学処理ステージ３４はまた、例えば、正規変換、正規規格化演算、ビュー・ボリューム・クリッピング、ホモジニアス分割、および／または、バックフェース間引き演算を含むその他の演算をも実行しうる。

幾何学処理ステージ３４は、ラスタライズされるべきプリミティブを定義する１または複数の修正された頂点からなるセットのみならず、プリミティブを生成するために頂点がどのように結合するのかを示すデータを生成しうる。修正された頂点のおのおのは、例えば、修正された頂点位置座標と、頂点に関連付けられた処理された頂点属性値とを含みうる。プリミティブ・データは、集合的に、グラフィック処理パイプライン３０のさらなるステージによってラスタライズされるべきプリミティブに対応しうる。概念的に、おのおのの頂点は、プリミティブの２つのエッジが出会うプリミティブのコーナに対応しうる。幾何学処理ステージ３４は、さらなる処理のために、プリミティブ・データを、ラスタライゼーション・ステージ３６へ提供しうる。

いくつかの例において、幾何学処理ステージ３４のすべてまたは一部は、１または複数のシェダー・ユニットにおいて動作する１または複数のシェダー・プログラムによって実施されうる。例えば、幾何学処理ステージ３４は、例えば、頂点シェダー、幾何学シェダー、またはこれらの任意の組み合わせによって実施されうる。他の例において、幾何学処理ステージ３４は、固定機能ハードウェア処理パイプラインとして、または、固定機能ハードウェアと、１または複数のシェダー・ユニットで動作する１または複数のシェダー・プログラムとの組み合わせとして実施されうる。

ラスタライゼーション・ステージ３６は、ラスタライズされるべきプリミティブ示すプリミティブ・データを、幾何学処理ステージ３４から受け取り、プリミティブをラスタライズし、ラスタライズされたプリミティブに対応する複数のソース・ピクセルを生成する、ように構成される。いくつかの例において、ラスタライゼーション・ステージ３６は、ラスタライズされるべきプリミティブによって、どのスクリーン・ピクセル位置がカバーされているのかを判定し、プリミティブによってカバーされるべきであると判定されたおのおののスクリーン・ピクセル位置のソース・ピクセルを生成しうる。ラスタライゼーション・ステージ３６は、例えば、エッジ・ウォーキング技法や、評価エッジ式等のような当業者に周知の技法を用いることによって、どのスクリーン・ピクセル位置が、プリミティブによってカバーされているのかを判定しうる。ラスタライゼーション・ステージ３６は、結果として得られたソース・ピクセルを、さらなる処理のために、ピクセル処理パイプライン３８に提供しうる。

ラスタライゼーション・ステージ３６によって生成されたソース・ピクセルは、例えば目標ピクセルのようなスクリーン・ピクセル位置に相当し、１または複数の色属性に関連付けられうる。ラスタライズされた特定のプリミティブのために生成されたソース・ピクセルのすべては、ラスタライズされたプリミティブに関連付けられていると言われうる。プリミティブによってカバーされるべきと、ラスタライゼーション・ステージ３６によって判定されたピクセルは、概念的には、プリミティブの頂点を表すピクセルと、プリミティブのエッジを表すピクセルと、プリミティブの内部を表すピクセルとを含みうる。

ピクセル処理パイプライン３８は、ラスタライズされたプリミティブに関連付けられたソース・ピクセルを受け取り、ソース・ピクセルに対して１または複数のピクセル毎の演算を実行するように構成される。ピクセル処理パイプライン３８によって実行されるべきピクセル毎の演算は、例えば、アルファ・テスト、テクスチャ・マッピング、色計算、ピクセル・シェーディング、ピクセル毎の照明、フォグ処理、ブレンディング、ピクセル・オーナシップ・テキスト、ソース・アルファ・テスト、ステンシル・テスト、デプス・テスト、シザース・テスト、および／または、ストリッピング演算、を含む。さらに、ピクセル処理パイプライン３８は、１または複数のピクセル毎の演算を実行するために、１または複数のピクセル・シェダー・プログラムを実行しうる。ピクセル処理パイプライン３８による生成の結果得られるデータは、本明細書において目標ピクセル・データと称され、フレーム・バッファ１５内に格納されうる。目標ピクセル・データは、処理されたソース・ピクセルと同じ表示位置を有する、フレーム・バッファ１５内の目標ピクセルに関連付けられうる。目標ピクセル・データは、例えば、色値、目標アルファ値、デプス値等のようなデータを含みうる。

フレーム・バッファ１５は、ＧＰＵ１２のための目標ピクセルを格納する。おのおのの目標ピクセルは、ユニークなスクリーン・ピクセル位置に関連付けられうる。いくつかの例において、フレーム・バッファ１５は、おのおのの目標ピクセルのための目標アルファ値および色成分を格納しうる。例えば、フレーム・バッファ１５は、おのおののピクセルの赤、緑、青、アルファ（ＲＧＢＡ）成分を格納しうる。ここで、“ＲＧＢ”成分は、色値に対応し、“Ａ”成分は、目標アルファ値に対応する。フレーム・バッファ１５およびシステム・メモリ１０は、個別のメモリ・ユニットであるとして例示されているが、別の例では、フレーム・バッファ１５は、システム・メモリ１０の一部でありうる。

前述したように、グラフィック処理パイプライン３０は、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードを含む特定のレンダリング・モードにしたがってグラフィック・イメージをレンダリングしうる。ビニング・レンダリング・モードにしたがってレンダリングする場合、グラフィック処理パイプライン３０は、結果として得られるグラフィック・イメージにレンダリングするために、プリミティブ（すなわち、１または複数のプリミティブ）のバッチを受け取りうる。プリミティブのバッチをレンダリングするために、結果として得られたグラフィック・イメージは、複数のより小さな部分（例えば、ビンまたはピクセルのタイル）に細分割されうる。そして、グラフィック処理パイプライン３０は、グラフィック・イメージのおのおのの部分を、個別のレンダリング・パスとしてレンダリングしうる。

図３は、ビニング・レンダリング・モードのために、ビンに分割されたフレームを例示する概念図である。フレーム４０は、例えばビン４２のような複数のビンに分割されうる。一般に、グラフィック・ハードウェアは、データの少なくとも１つのビンを保持するのに十分なサイズからなる高速メモリ（例えば、図２のグラフィック・メモリ１４）を含むだろう。フレームの特定の部分のための単一のレンダリング・パスの一部として、グラフィック処理パイプライン３０は、フレームの目標ピクセル（例えば、目標ピクセルの特定のビン）の特定のサブセットに関するプリミティブのバッチのすべてまたはサブセットをレンダリングしうる。第１のビンに関して第１のレンダリング・パスを実行した後、グラフィック処理パイプライン３０は、第２のビンに関して第２のレンダリング・パスを実行するという具合である。グラフィック処理パイプライン３０は、すべてのビンに関連付けられたプリミティブがレンダリングされるまで、ビンを漸増的にトラバースしうる。

図４は、ビニング・レンダリング・モードにおいて使用されるビンをより詳細に示す概念図である。ビン４４，４６，４８および５０は、複数のピクセル５２を含むようにレンダリング／ラスタライズされる。１または複数のグラフィック・プリミティブが、各ビンにおいて見えうる。例えば、三角形Ａ（Ｔｒｉ Ａ）の一部は、ビン４４およびビン４８の両方において見える。三角形Ｂ（Ｔｒｉ Ｂ）の一部は、ビン４４，ビン４６，ビン４８およびビン５０のおのおのにおいて見える。三角形Ｃ（Ｔｒｉ Ｃ）は、ビン４６においてのみ見える。ビニング・レンダリング・モードの１つの例では、レンダリング・パスの間、シーンが、ビンに分割され、このビンにあるすべての三角形がレンダリングされる（これは、しばしば、ソフトウェア・ビニングと呼ばれる）。ビニング・レンダリング・モードの別の例では、最終的にレンダリングされたシーンにおいて、ビン内のどの三角形が実際に見えるのかを判定するための追加のステップが、レンダリング前に行われる（これは、しばしば、ハードウェア・ビニングと呼ばれる）。例えば、いくつかの三角形は、１または複数のその他の三角形の後ろにあるかもしれず、最終的にレンダリングされたシーンにおいて見えないであろう。このように、見えない三角形は、そのビンのためにレンダリングされる必要はない。

特定のレンダリング・パスを実行している間、その特定のレンダリング・パスに関連付けられたビンのピクセル・データが、（しばしば、ビン・バッファと呼ばれる）グラフィック・メモリ１４に格納されうる。レンダリング・パスが実行された後、グラフィック処理パイプライン３０は、グラフィック・メモリ１４のコンテンツを、フレーム・バッファ１５へ転送しうる。いくつかのケースでは、グラフィック処理パイプライン３０が、グラフィック・メモリ１４に格納されたデータを用いて、フレーム・バッファ１５内のデータの一部を上書きしうる。別のケースでは、グラフィック処理パイプライン３０は、フレーム・バッファ１５内のデータを、グラフィック・メモリ１４に格納されたデータと合成または結合しうる。グラフィック・メモリ１４のコンテンツがフレーム・バッファ１５へ転送された後、グラフィック処理パイプライン３０は、グラフィック・メモリ１４をデフォルト値に初期化し、別のビンに関して、後続するレンダリング・パスを開始しうる。

図５は、「ソフトウェア」ビニングを用いるビニング・レンダリング・モードを用いてシーンをレンダリングするためのコマンド構造の例を示す概念図である。レベル１インダイレクト・バッファ（ＩＢ１）６０は、グラフィック・メモリ・パイプライン３０のさまざまなステップを実行するようにＧＰＵ１２を指示するための一連の実行コマンドを含む。ＩＢ１６０におけるおのおのの実行コマンドは、実質的に、レンダリング・パイプラインのさまざまな態様のためのコマンドを含む１または複数のレベル２インダイレクト・バッファ（ＩＢ２）へのポインタである。このようにして、グラフィック・レンダリング・パイプラインを実行するための２またはそれ以上のレベル構造が確立される。ＧＰＵ１２は、ＩＢ１ ６０におけるおのおのの実行コマンドをシーケンシャルにステップしうる。ここでは、ＩＢ１ ６０におけるおのおのの実行は、ＩＢ２に格納されたコマンドの特定のスタックを指す。ＩＢ１およびＩＢ２は、内蔵型のＣＰＵ１２であるメモリでありうる。または、例えばシステム・メモリ１０のように、ＧＰＵ１２の外部のメモリでありうる。

ＩＢ１ ６０におけるプリアンブル実行コマンドは、ＧＰＵ１２によって実行されることが可能なプリアンブル・コマンドを含むプリアンブルＩＢ２ ６２を指す。例えば、プリアンブルＩＢ２ ６２は、ＧＰＵ１２のスタティック状態を初期化し、ＧＰＵ１２の初期レンダリング状態を設定するコマンドを含みうる。ＧＰＵのスタティック状態は、特定のアプリケーションに基づいて変わらない設定を含んでいる。一方、レンダリング状態は、特定のアプリケーション（例えば、ＯｐｅｎＧＬ．アプリケーション対ダイレクトＸアプリケーション）に基づいて変わりうるＧＰＵ設定を含む。プリアンブルＩＢ２におけるコマンドが完了した後、制御は、次の実行コマンドを行うために、ＩＢ１ ６０に戻る。

ＩＢ１ ６０における次の実行コマンドは、使用されているレンダリング・モードのレンダリング・パスを設定する。再び、図５の例に示すように、レンダリング・モードは、ソフトウェア・ビニングを用いるビニング・レンダリング・モードである。次に、ＩＢ１ ６０におけるロード・ビン実行コマンドは、ロードＩＢ２ ６６におけるコマンドを指す。ソフトウェア・ビニングの場合、特定のビンのデータが、ＧＭＥＭ１４にロードされる（ロード２ＧＭＥＭ）。その後、制御は、ＩＢ１ ６０に戻り、レンダリング・ビン実行コマンドは、レンダリングＩＢ２におけるコマンドを指す。ＩＢ２ ６８をレンダリングすることは、一連の状態コマンドと、ロードされたビンにおいて三角形を描画するためのドロー・コマンドとからなる。おのおののドロー・コマンドは、ＧＰＵ１２に対して、コマンドおよび／またはＧＰＵハードウェアによって確立された（例えば、幾何学処理ステージ３４、ラスタライゼーション・ステージ３６、および／または、ピクセル処理パイプライン３８のような）グラフィック処理パイプライン３０にしたがって三角形を描画するように指示する。レンダリングＩＢ２ ６８に示されるように、ドロー・コマンドのおのおのは、特定の三角形が実際にビンにおいて見えるか否かを判定するために、ビジビリティ（visibility）ストリームが使用されないことを示す。ビジビリティ・ストリームは、「ハードウェア」ビニングを用いるビニング・レンダリング・モードにおいて生成され、図６を参照してさらに詳細に説明される。レンダリングＩＢ２ ６８における状態コマンドは、ＧＰＵ１２によって実行されるグラフィック処理パイプラインの挙動に影響を与える。例えば、状態コマンドは、色、ポリゴン・モード（例えば、固体または線ではなく点）、ブレンディング（オン／オフ）、デプス・テスト（オン／オフ）、テクスチャリング（オン／オフ）、間引き、クリッピング、およびその他の論理演算を変更しうる。レンダリングＩＢ２ ６８において示されているように、状態コマンドが、三角形毎（または、プリミティブ毎）ベースで発行されうる。すなわち、コマンド“Ｓｔａｔｅ Ｔｒｉ Ａ”は、三角形Ａを描画している場合、ＧＰＵ１２の挙動に影響を与えうる一方、“Ｓｔａｔｅ Ｔｒｉ Ｂ１”コマンドおよび“Ｓｔａｔｅ Ｔｒｉ Ｂ２”コマンドは、三角形Ｂを描画している場合、ＧＰＵ１２の挙動に影響を与えうる。“Ｓｔａｔｅ Ｔｒｉ Ｂ１”コマンドおよび“Ｓｔａｔｅ Ｔｒｉ Ｂ２”コマンドは、単に、複数の状態コマンドが、おのおのの三角形について実行されうることを示しうる。

レンダリングＩＢ２ ６８においてすべてのコマンドが実行された後（例えば、すべての三角形が描画された後）、制御は、ＩＢ１ ６０に戻る。格納ビン実行コマンドは、ＧＭＥＭ１４からレンダリングされたビンをメモリ（例えば、フレーム・バッファ１５）へ格納するためのコマンドを含む、ストアＩＢ２ ７０へのポインタを含みうる。その後、レンダリング・パス（例えば、ＩＢ１ ６０に図示されるように、ビンを格納するための、設定レンダリング・パスからの実行コマンド）が、１または複数のフレームについて、おのおののビン７２について繰り返される。

図６は、「ハードウェア」ビニングを用いたビニング・レンダリング・モードを用いてシーンをレンダリングするためのコマンド構造の例を図示する概念図である。ＩＢ１ ６１における実行コマンドは、「ビニング」パスに関連するコマンドを除いて、図６のＩＢ１ ６０のものに類似している。「ビニング」パスは、ビン内の特定の三角形が、最終的にレンダリングされたシーンにおいて実際に見えるか否かを示すビジビリティ・ストリームを生成するために使用される。例えば、いくつかの三角形は、シーン内の別の三角形の後ろに存在しうるので、いくつかのシナリオ（例えば、正面の三角形が不透明である場合、または、ブレンディングが使用されていない場合）では、見えないだろう。ビン７２をレンダリングする前に、ＩＢ１ ６１は、ビニングＩＢ２ ７４におけるコマンドを指すビニング・パス実行コマンドを含みうる。ビニングＩＢ２ ７４は、ＧＰＵ１２に対して、グラフィック・パイプラインの簡略バージョン（例えば、レンダリングＩＢ２ ６９の簡略バージョン）を実行させるコマンドを含むが、最終的にレンダリングされたシーンにおいて三角形が見えるか否かを判定するデプス・テスト（Ｚテスト）に基づいて、ビンにおけるおのおのの三角形のビジビリティ・ストリームを更新するステップを加える。

ビニング・パスの目的は、現在のビンと交差する三角形を特定することである。そのため、三角形が特定のビンと交差するか否かを特定するために、三角形の頂点の位置しか判定される必要がない。ビニング・パスは、頂点の位置に影響を与える命令群のみを含む簡略化された頂点シェダーを利用する。例えば、三角形の頂点の位置に影響を与えない色命令群、テクスチャ座標、およびその他の命令群は、ビニング・パスのために使用される簡略化された頂点シェダーから除去されうる。ビニング・パスはまた、おのおのの三角形の適切なデプスを決定するために、精細なラスタライゼーションではなく、粗いラスタライゼーションを利用する。粗いラスタライゼーションは、精細なラスタライゼーションよりも低い精度で（例えば、低位のビットを用いて）デプス値を計算する。ビンにおいて三角形が見えるか否かを判定するために、適切なデプス値のみが必要とされる。ピクセル・シェダーは、ビニング・パスにおいて使用されない。

ビニング・パスは、その後、ビンにおける三角形が、そのビンにおける他の三角形に対して見えるか否かを判定するために、この粗いデプス・テストを利用する。このデプス・テストに基づいて、ビジビリティ・ストリームが更新される。ビジビリティ・ストリームは、レンダリングされたビンにおける特定の三角形が見えるか否かを示す一連のビットでありうる（例えば、１は、三角形が見えることを示し、０は、三角形が見えないことを示す）。

レンダリングＩＢ２ ６９におけるコマンドは、ビジビリティ・ストリームを用いることを除いて、図５におけるレンダリングＩＢ ６８のものと類似している。レンダリングＩＢ２ ６９におけるドロー・コマンド（例えば、Ｄｒａｗ Ｔｒｉ Ａ、Ｄｒａｗ Ｔｒｉ Ｂ、Ｄｒａｗ Ｔｒｉ Ｃ等）は、特定の三角形を描画する必要があるか否かを判定するために、ビニング・パスによって生成されたビジビリティ・ストリームを使用しうる。例えば、ドローイングは、ビジビリティ・ストリームによって、見えないと示された三角形についてはスキップされうる。

ダイレクト・レンダリングは、ビニング・レンダリング・モードにおけるように、ビン毎にフレームをレンダリングするのではなく、グラフィック・パイプラインによって、１つのパスで、フレーム全体をレンダリングする。制限された容量のグラフィック・メモリしか有さないビニング・ベースのアーキテクチャで実行された場合、ダイレクト・レンダリングは、一般に、より低速のシステム・メモリを利用する。

図７は、ダイレクト・レンダリング・モードを用いてシーンをレンダリングするためのコマンド構造の例を図示する概念図である。ダイレクト・レンダリング・モードのコマンドは、図５におけるソフトウェア・ビニングのものに類似しているが、ビン毎ベースでレンダリングするのではなく、フレーム全体が、１つのパスでレンダリングされる。例えば、ＩＢ１ ８０における実行コマンドは、ビンをロードすること、レンダリングすること、および格納することを除いて、ＩＢ１ ６０におけるものに類似しており、ＩＢ１ ８０における実行コマンドは、フレームをロードし、レンダリングし、格納するそれぞれのＩＢ２におけるコマンドを指す。さらに詳しくは、ＩＢ１ ８０におけるロード・フレーム実行コマンドは、フレームのデータをシステム・メモリ（ロード２システム・メモリ）にロードするためのコマンドを含むロードＩＢ２ ８６を指す。ＩＢ１ ８０におけるコマンドは、プリアンブル、プリアンブル／リストア、レンダリング・パス設定、フレーム・ロード、フレーム・レンダリング、およびフレーム格納を含みうる。ＩＢ１ ８０におけるレンダリング・フレーム実行コマンドは、ＧＰＵ１２に対して、フレーム内にプリミティブを描画させる命令群を含むレンダリングＩＢ２ ８８を指す。ソフトウェア・ビニングのように、ダイレクト・レンダリング・モードにおけるレンダリングは、ハードウェア・ビニング・パスもビジビリティ・ストリームも利用しない。レンダリングＩＢ２ ８８における何れかのドロー・コマンド（例えば、Ｄｒａｗ Ｔｒｉ Ａ、Ｄｒａｗ Ｔｒｉ Ｂ、Ｄｒａｗ Ｔｒｉ Ｃ）は、レンダリングされた三角形を格納するためにシステム・メモリを利用するだろう。ストア・フレーム実行コマンドは、システム・メモリからレンダリングされたフレームを別のメモリ（例えば、フレーム・バッファ１５）に格納するための命令群（システム・メモリから格納）を含むストアＩＢ２ ９０を指す。

ＩＢ１ ８０におけるプリアンブル実行コマンドは、ＧＰＵ１２の定常状態と初期レンダリング状態を確立するための命令群を含むプリアンブルＩＢ２ ８２を指す。これらのコマンドは、図６のプリアンブルＩＢ２ ６２におけるコマンドと同様に動作するが、ビニング・レンダリング・モードのためではなく、ダイレクト・レンダリング・モードのためのレンダリング状態を設定する。

本開示の技法によれば、アプリケーション（例えば、図２のソフトウェア・アプリケーション２４）が、シーンのレンダリングを開始する前に、１または複数のプロセッサ（例えば、ＣＰＵ ６）で動作するグラフィック・ドライバ（例えば、グラフィック・ドライバ７）は、所望のレンダリング・パスに関するヒューリスティック・データに基づいてレンダリング・モードを決定する（例えば、ビニング・レンダリングかダイレクト・レンダリングかを決定する）。いくつかの技法では、現在のレンダリング・パスに関するヒューリスティック・データは、以前のレンダリング・パスから収集されうる。しかしながら、このアプリケーションは、新たなシーンをレンダリングする前に、レンダリング技法を切り替えるので、この技法は、レンダリング・モードを決定するための常に最適な手法という訳ではない。そのため、この技法は、適切なレンダリング・モードに切り替えるための新たなデータが十分に蓄積されるまで、非効率的なレンダリングに至りうる。

さらに、現在のシーンが、以前のシーンと異なるのであれば、過去のレンダリングに関するヒューリスティック・データは、現在のシーンのために最も適したレンダリング・モードを常に提供する訳ではない。例えば、迅速に変化するレンダリング・モードを最適に用いるであろうアプリケーションは、このようなヒューリスティックな分析を用いた多くの誤予測をもたらしうる。理想的には、グラフィック・ドライバは、所与のレンダリング・ターゲットのためのレンダリング・ロードを決定し、レンダリング・モード決定を直ちに行いうる。本開示は、レンダリング・モードのより適した決定のための技法と、レンダリング・モード間の切り替えのための技法とを提案する。

以下の技法は、任意のグラフィック・アプリケーション・プログラム・インタフェース（ＡＰＩ）を用いたグラフィック処理システムのために適用可能であり、特に、ビニング・レンダリングを利用するグラフィックＡＰＩのために適切である。このようなＡＰＩの例は、マイクロソフトのＤｉｒｅｃｔＸ９（ＤＸ９）、ＤＸ１０、およびＤＸ１１のみならず、例えばＯｐｅｎＧＬおよびＯｐｅｎＧＬ ＥＳのようなオープン・ソース・グラフィックＡＰＩを含む。

図８は、本開示の１つの例にしたがうレンダリング・コマンド・パッチを例示する概念図である。先ず、グラフィック処理システム（例えば、図１のコンピューティング・デバイス２）は、ビニング・モードにおいて、特定のアプリケーションが、現在のレンダリング・ターゲット（例えば、１または複数のフレーム）へより最適にレンダリングすると仮定する。この特定のレンダリング・モードの選択（例えば、ビニング・レンダリングまたはダイレクト・レンダリング）は、グラフィック・ドライバ７によって取り扱われうる。ビニングがイネーブルされた場合、グラフィック・ドライバ７は、所与のレンダリング・ターゲットのためのロード・コマンド、格納コマンド、レンダリング・コマンド、およびブロック転送（ＢＬＴ）コマンドのすべてを、これらがフラッシュすることが必要になるまでバッチする。このコンテキストでは、フラッシュは、ドライバによってバッチされた何れかのレンダリング・コマンドをハードウェア（例えば、ＧＰＵ１２）へ送ることを意味する。ロード、格納、レンダリング、およびＢＬＴのためのコマンドは、個別のバッファ（例えば、個別のＩＢ２バッファ）に格納されうる。例えば、レンダリング・コマンドは、ビニング・レンダリング・モードＩＢ２ ６８に格納されうる。

ビニング・レンダリング・モードにおけるレンダリング・コマンドは、あるレジスタに書き込まれた特別のアドレスを用い、これによって、高速グラフィック・メモリ（ＧＭＥＭ）がアクセスされるようになる。グラフィック・ドライバ７は、先ず、すべてのレンダリングのためにビニングがイネーブルされていると仮定するので、ＧＭＥＭかシステム・メモリかの選択を行うすべてのレジスタは、ＧＭＥＭアドレスを用いるだろう。図８におけるビニング・レンダリング・モードＩＢ２ ６８は、三角形を描画することに関連付けられた一連のコマンド（Ｄｒａｗ Ｔｒｉ）を示す。ここで、コマンド１，４，５は、ＧＭＥＭアドレスを利用する。

レンダリングがフラッシュされるべきである場合、グラフィック・ドライバは、間もなく実行されるべきすべてのレンダリング・コマンドへのアクセスを有する。本開示の技法によれば、グラフィック・ドライバ７は、レンダリング・コマンドを分析するように構成されうる。そして、１または複数のレンダリング特性（例えば、レンダリング・パスに関するヒューリスティック・データ）を考慮しうる。そのようなレンダリング特性は、レンダリング・ターゲットのサイズおよびタイプ、デプス・テストがイネーブルされているか否かを示すインジケーション、使用されるシェダーの複雑さ、描画されたプリミティブの数、テクスチャ読取の数、読み取られた任意のテクスチャのサイズ、および／または、使用されているすべての表面のマイクロ・タイル・モードを含みうる。

例えば、ＧＰＵドライバ７は、レンダリング・ターゲットのサイズに基づいて、ビニングのオーバヘッド（例えば、ＧＭＥＭに対するロード／格納サイクルとビニング・パスを実行するための時間）が、ビニングの正の効果によってオフセットされるか否かを判定しうる。例えば、小さなレンダリング・ターゲット（例えば、１６×１６）は、システム・メモリに保存している場合であっても、ダイレクト・レンダリング・モードにおいてより高速に動作しうる。

別の例として、デプス・テストを利用しないグラフィック・パイプラインは、ビニング・レンダリング・モードの利点を利用しない場合がありうる。一般に、ビニングが使用されない場合、既存のデプス値を読み取り、テストを実行し、新たなデプス値をシステム・メモリ内のバッファに書き戻すために、デプス・テストが適用される必要がある。デプス・テスト処理は、ビニングを用いて、ＧＭＥＭにおいてなされる。これは、ＧＭＥＭを「フリー」（すなわち、最小のオーバヘッド時間を用いて非常に高速）にする。そのため、特定のグラフィック・パイプラインのためにデプス・テストがイネーブルされていない場合、ビニング・レンダリング・モードは、デプス・テストに関連するどのようなメモリ帯域節約も与えないだろう。そのため、デプス・テストがディセーブルされているか、または使用されていない場合、ＧＰＵドライバ７は、ダイレクト・レンダリング・モードが好適であると判定しうる。

別の例として、デプス複雑さがあり（例えば、さまざまなデプスにおいてプリミティブがあり）、複数の三角形間にオーバラップがある場合、ビニング・レンダリング・モードは、最大の利点を提供する。描画されたプリミティブの数が少ない場合、ビニング・レンダリング・モードからの利点もまた少ないことがありうる。そのため、ＧＰＵドライバ７は、少ない数のプリミティブしか描画されるべきではない場合、ダイレクト・レンダリング・モードが好適であると判定しうる。同様に、ＧＰＵドライバ７は、多くの数のプリミティブが描画されるべきである場合、ビニング・レンダリング・モードが好適であると判定しうる。

別の例として、テクスチャが実行される場合、システム・メモリへの追加の格納およびシステム・メモリからの追加の読み取りは、システム・メモリ帯域幅に対して負の効果を有する。そのため、テクスチャする場合、ビニング・レンダリング・モードは、メモリに対するより迅速なアクセスを提供する（すなわち、ほとんどの格納および読取は、より高速なＧＭＥＭで実行される）。描画するシーンにおけるテクスチャ動作の数および頻度は、ビニング・レンダリング・モードからの利益を無効にしうる。すなわち、より少ないテクスチャ動作は、ビニング・レンダリング・モードがより少ない利益しか与えず、代わりにダイレクト・レンダリング・モードが使用されるべきであることを示唆しうる。

レンダリング・コマンドの分析の結果は、「スコア」として計算されうる。これは、前述したさまざまな特定のうちの１または複数を、例えば、重み付けベースまたは非重み付けベースで考慮しうる。このスコアが、所与のしきい値未満である場合、ダイレクト・レンダリング・モードが使用される。このスコアが、所与のしきい値よりも高い場合、ビニング・レンダリング・モードが使用される。そのため、この技法は、現在のレンダリング・モードを決定するための、現在のレンダリング・ターゲットのジャスト・イン・タイム（ＪＩＴ）分析を提供する。過去のレンダリング・パスのヒューリスティック分析は必要ではない。しかしながら、過去のレンダリング・パスのヒューリスティック分析は、現在のレンダリング・ターゲットの分析の代わりに、または、それと連携して使用されうる。例えば、現在のレンダリング・モードのＪＩＴ分析は、過去のレンダリングの、蓄積された統計のヒューリスティック分析から決定されたレンダリング・モードが無効であることを示すインジケータとして使用されうる。

本開示の別の例によれば、レンダリング・モードの決定（例えば、ビニング・レンダリング・モードかダイレクト・レンダリング・モードかの決定）は、「ハードウェア」ビニングを用いるグラフィック処理システムにおけるオーバドロー・トラッカを用いてなされうる。

図９は、本開示の１つの例にしたがうオーバドロー・トラッキングを例示する概念図である。オーバドローの量が多い場合、ビニング・レンダリング・モードは、ダイレクト・レンダリング・モードに比べて、最も効率的である。オーバドローは、オーバラップするいくつかのグラフィック・プリミティブがある場合に生じる。このようなプリミティブのすべてを描画することは、効率的ではないだろう。なぜなら、いくつかのプリミティブの一部は、最終的なシーンにおいて見えない（例えば、別の不透明なプリミティブの背後にある）ことがありうるからである。「ハードウェア」ビニングは、（例えば、前述したようなビジビリティ・ストリームを生成することによって）フレームのうちのいくつかのタイルにおけるオーバドローを低減するために使用されうる。

ビニングを利用するグラフィック・アーキテクチャでは、一般に２つのフェーズがある。それらは、１）変換された頂点位置に基づいて、プリミティブを、ビットの揃ったスクリーンにソートするビニング・フェーズと、２）ビンのおのおの（すなわち、ビンにおけるプリミティブ）がレンダリングされるレンダリング・フェーズと、である。いくつかのグラフィック処理アーキテクチャはまた、ソート・ステップに加えて、プリミティブ毎のビジビリティ・ストリームと、（例えば、いわゆる、「ハードウェア」ビニングにおける）領域に関連付けられた粗いグレイン・デプス（Ｚ）値とを生成しうる。しかしながら、この「ハードウェア」ビニングは、ビンにおけるプリミティブの分布と、関連付けられたオーバドローに関するダイレクトな情報を生成しない場合がありうることに注目されたい。本開示は、粗いグレインＺラスタライザのものと同じグラニュラリティでオーバドロー・トラッカ（すなわち、ビニングＩＢ２ ９４におけるコマンド）を追加することを提案する。例えば、ＧＰＵ１２に対して、おのおののビンのオーバドローの量の計算、および、計算されたオーバドローの量に基づくオーバドロー・トラッカの更新を実行させるためのコマンド（例えば、「オーバドロー計算」および「オーバドロー・トラッカ更新」）が、ビニングＩＢ２ ９４に追加されうる。

この「オーバドロー」は、領域においてラスタライズされたプリミティブ間のオーバラップと、ビニング・レンダリングを用いることの利益とを表す、領域毎の整数値でありうる（ここで、領域は、ピクセル、ビンの一部、ビン、または複数のビンでありうる）。グラフィック・ドライバ７は、オーバドロー数に対するアクセスを有し、レンダリング・モード決定を行うために、オーバドロー数を用いうる。この技法は、その後、この値をビン内のすべての領域に、さらには、シーン内のすべてのビンにアグリゲートするために拡張されうる。これによって、ソフトウェア・アプリケーションおよび／またはドライバ（例えば、グラフィック・ドライバ７）は、他のヒューリスティックと比較された場合に、ビニング・レンダリングが有益であるか否かを迅速に判定できるようになる。さらに、これらの技法はまた、複雑なレンダリング・シナリオにおける動作の領域を視覚化するためのデバック・ツールとしても使用されうる。

図１０は、４つの１６×１６ビンにおけるオーバドローを計算する１つの例を例示する。この例において、「オーバラップ」は、おのおののピクセルについて最初に計算される。オーバラップは、ピクセルに触れる１より多くのプリミティブの数として定義される。ビン９５およびビン９９におけるピクセルはすべて、ゼロであるオーバラップ・スコアを有するであろう一方、例えば、ビン１０１のピクセル９６は、１であるオーバラップ・スコアを有するであろう。なぜなら、そのピクセルには２つの三角形があるからである。この「オーバドロー」数は、ビン内のピクセルの総数によって除された、ビンのオーバラップ・スコアの総和（例えば、オーバドロー＝ピクセル毎のオーバラップの総数／ピクセル数）として定義されうる。図１０において図示される例では、ビン１０１は、３０／１６のオーバドロー数を有するであろう一方、ビン９５とビン９９との両方は、０であるオーバドロー・スコアを有するであろう。あるしきい値よりも高いオーバドロー数は、このオーバドロー数に関連付けられた領域のためにビニング・レンダリング・モードが使用されるべきであることを示しうる一方、あるしきい値未満のオーバドロー数は、このオーバドロー数に関連付けられた領域のためにダイレクト・レンダリング・モードが使用されるべきであることを示しうる。

図８に戻って、グラフィック・ドライバ７は、スコアに基づいて（レンダリング・コマンドおよび／またはオーバドロー・トラッカの分析に基づいて）最適のモードを決定する。グラフィック・ドライバ７はまた、より最適なレンダリング・モードを決定することと連携して、ＧＭＥＭアドレスを利用するすべてのビニング・レンダリング・コマンド（図８の例におけるコマンド１，４，５）をトラックするように構成されうる。グラフィック・ドライバ７は、これらコマンドのおのおのの対応するシステム・メモリ・アドレスを（例えば、システム・メモリ１０に）格納し、これによって、ＧＭＥＭアドレスを用いるビニング・レンダリング・コマンドが、システム・メモリ・アドレスを使用するように変更されうる。ダイレクト・レンダリングが、より最適なモードであると判定されると、グラフィック・ドライバ７は、ＧＭＥＭアドレスをシステム・メモリ・アドレスと置き換えるようにビニング・レンダリング・モードＩＢ２ ６８をパッチし、これによって、ダイレクト・レンダリング・モードＩＢ２ ８８を生成しうる。このようにして、ダイレクト・レンダリングのためのレンダリング・コマンドは、ダイレクト・レンダリング・モードＩＢ２のための全体的なコマンド構造を再生成することなく生成されうる。最後に、グラフィック・ドライバ７は、フラッシュ時において、ＢＬＴ ＩＢ２およびレンダリングＩＢ２を実行せよ（この場合、レンダリングＩＢ２は、システム・メモリ・アドレスを使用するように変更される）とのコマンドをＩＢ１（例えば、図７のＩＢ１ ８０）に追加し、ＧＰＵ７は、ＩＢ１の実行を開始するようにシグナルされる。

本開示の別の例では、レンダリングのために使用されるおのおののレジスタは、ハードウェアで実現されうる。図１１は、本開示のこの例にしたがうレンダリング・モード選択を例示する概念図である。所与のレンダリング・モードのためにどのセットのレジスタ（例えば、ビニング・レンダリング・モード・レジスタ１０４またはダイレクト・レンダリング・モード・レジスタ１０６）が使用されるのかを制御するために、グローバル制御レジスタ１０２が使用されうる。ビニング・レンダリング・モード・レジスタ１０４は、目標サーフェス情報（すなわち、ビン）、ＧＭＥＭのアドレス・レジスタ、および、（ハードウェア・ベースのビニング・レンダリングのための）ビジビリティ・ストリーム利用を取り扱いうる。ダイレクト・レンダリング・モード・レジスタ１０６は、システム・メモリへのアドレスを含むだろう。グローバル制御レジスタ１０２は、前述したように、レンダリング・モードのＪＩＴ分析に基づいて、例えば、前述したレジスタのうちのどのバージョンが、レンダリングＩＢ２ １１８にコマンドをポピュレートするために使用されるのかを制御する。グラフィック・ドライバ７は、ビニング・レンダリング・モード・レジスタ１０４またはダイレクト・レンダリング・モード・レジスタ１０６を選択するために、グローバル制御レジスタ１０２を制御しうる。前述したように、本技法は、ソフトウェアを用いてＩＢ２をパッチするのではなく、ハードウェア・レジスタを用いる。グローバル制御レジスタ１０２は、ＩＢ１にありうる。

本開示の別の例では、コマンド・バッファをパッチするための技法が提案される。図１２は、本開示のこの例にしたがうレンダリング・コマンド・パッチングを例示する概念図である。この提案された例の技法は、ビニング・レンダリング・モードからダイレクト・レンダリング・モードに切り替わる場合に、コマンド・バッファをパッチするために使用されうる。しかしながら、以下の技法は、コマンド・バッファをパッチすることが所望される任意の状況において利用されうる。例えば、コマンドは、グラフィック・メモリの仮想化をサポートするため、リソース・レベル・オブ・ディテール（ＬＯＤ）のＭＩＰレベルを、より低いＭＩＰに変更するため、または、コマンド・バッファの実行前に修正スキャナを実行するため、にパッチされうる。ビニング・レンダリング・モードからダイレクト・レンダリング・モードへ切り替えるようにコマンド・バッファをパッチするために必要とされるＣＰＵサイクルは、いくつかのシナリオでは、費用が嵩みうる。この例は、ＣＰＵオーバヘッドを低減することを目的とする。

一般に、この技法は、グラフィック・ドライバ７が、コマンド・バッファをパッチするために（ＧＰＵドライバ７の代わりに）ＧＰＵ１２を用いる手法を提供する。これによって、ＣＰＵオーバヘッドが最小化される。図８の例では、グラフィック・ドライバ７が、ビニング・レンダリングとダイレクト・レンダリングとの切り替えを行うのであれば、グラフィック・ドライバ７は、ＩＢ１へ実行コマンドを追加する前に、ＩＢ２コマンドのすべてのトラックして、パッチする。この例は、パッチ・リスト（例えば、図８のシステム・メモリに図示されるパッチ・リスト）を構築する代わりに、別のＩＢ２におけるコマンド（例えば、任意の一般的な動作コマンド）を変更する書込コマンドを含む個別のパッチＩＢ２ ９８を、グラフィック・ドライバ７が構築することを提案する。例えば、書込コマンドの宛先は、ダイレクト・レンダリング・モードがグラフィック・ドライバ７によって選択された場合に、システム・メモリ・アドレスを使用するために変更される必要のあるビニング・レンダリング・モードＩＢ２ ６８における位置でありうる。グラフィック・ドライバ７は、コマンドをフラッシュする準備ができた場合、ダイレクト・レンダリング・モード入るために、「パッチングＩＢ２」におけるコマンドを実行するオプション、または、パッチングＩＢ２をスキップして、ビニング・モードで継続するオプション、を有する。グラフィック・ドライバ７は、ＩＢ１における実行コマンドに実行コマンド（パッチ・レンダリングＩＢ２）を追加することによって実行されうるパッチングＩＢ２ ９８に影響を与えうる。このようにして、ＧＰＵ１２は、ＩＢ２ ９８においてレンダリング・コマンドを実行する前に、ＩＢ２ ９８においてパッチング・コマンドを実行するだろう。そのため、レンダリング・モード切替を達成するために、ＣＰＵ６にパッチをさせるのではなく、ＧＰＵ１２自身がレンダリングＩＢ２ ６８にパッチをする。

図１３は、本開示の１つの例にしたがう方法を例示するフローチャートである。図１３の方法は、コンピューティング・デバイス２に常駐するＣＰＵ６、ＧＰＵ１２、および／または、その他任意のハードウェア、ファームウェア、ソフトウェア要素、またはこれらの組み合わせによって実行されうる。ＣＰＵ６は、フレームをレンダリングするためのレンダリング・コマンドを生成するように構成されうる（１３０２）。ここで、レンダリング・コマンドは、ビニング・レンダリング・モード用である。ＣＰＵ６はさらに、グラフィック・メモリ・アドレスを用いるレンダリング・コマンドをトラックするように構成されうる（１３０４）。

その後、ＣＰＵ６は、レンダリング特性に基づいて、フレームのために、複数のレンダリング・モードのうちの１つのレンダリング・モードを決定しうる（１３０６）。ここで、複数のレンダリング・モードは、ビニング・レンダリング・モードとダイレクト・レンダリング・モードを含む。レンダリング特性は、マイクロ・タイル・モード、テクスチャのサイズ、テクスチャ読取の数、描画されたプリミティブの数、シェダーの複雑さ、デプス・テスト・ステータス、レンダリング・ターゲットのサイズおよびタイプのうちの１つを含む。複数のレンダリング・モードのうちの１つのレンダリング・モードを決定することは、複数のレンダリング・モードのうちの１つのレンダリング・モードを、現在のフレームのレンダリング特性に基づいて決定することを含みうる。別の例では、複数のレンダリング・モードのうちの１つのレンダリング・モードを決定することは、複数のレンダリング・モードのうちの１つのレンダリング・モードを、現在のフレーム、および、以前にレンダリングされたフレームのレンダリング特性に基づいて決定することを含みうる。

その後、ＣＰＵ６は、決定されたレンダリング・モードがダイレクト・レンダリング・モードである場合、グラフィック・メモリ・アドレスを用いるレンダリング・コマンドを、システム・メモリ・アドレスを使用するように変更しうる（１３０８）。決定されたレンダリング・モードが、ビニング・レンダリング・モードである場合、ＣＰＵ６は、レンダリング・コマンドを変更しないだろう。

ＣＰＵ６はさらに、実行コマンドを第１のバッファに格納することと、レンダリング・コマンドを第２のバッファに格納することと、を実行するように構成されうる。これら実行コマンドは、レンダング・コマンドを指す。レンダリング・コマンドの変更は、グラフィック・メモリ・アドレスを、システム・メモリ・アドレスに置き換えるように第２のバッファをパッチすることを含みうる（１３０８）。ＣＰＵ６はさらに、第２のバッファにおけるレンダリング・コマンドを指す実行コマンドを第１のバッファに追加しうる。その後、ＧＰＵ１２が、第１のバッファにおける実行コマンドを実行しうる。

別の例において、ＣＰＵ６は、ビニング・モード特有情報を第１のレジスタに格納することと、ダイレクト・レンダリング・モード特有情報を第２のレジスタに格納することと、決定されたレンダリング・モードに基づいて第１のレジスタか第２のレジスタかを選択するために、グローバル・レジスタを利用することと、を実行するように構成されうる。ビニング・モード特有情報は、目標サーフェス情報を取り扱うレジスタ・アドレス、グラッフィク・メモリ・アドレス、および、ビジビリティ・ストリーム利用のうちの少なくとも１つを含む。ここで、ダイレクト・レンダリグ・モード特有情報は、システム・メモリ・アドレスを含む。

図１４は、本開示の１つの例にしたがう方法を例示するフローチャートである。図１４の方法は、コンピューティング・デバイス２に常駐するＣＰＵ６、ＧＰＵ１２、および／または、その他任意のハードウェア、ファームウェア、ソフトウェア要素、またはこれらの組み合わせによって実行されうる。ＣＰＵ６は、シーンのプリミティブにビニング演算を実行するように構成されうる（１４０２）。これらプリミティブは、ビンに分割される。ＣＰＵ６はさらに、シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算すること（１４０４）と、計算されたオーバドロー数に基づいてレンダリング・モードを決定すること（１４０６）と、を実行するように構成されうる。オーバドロー数があるしきい値よりも大きいのであれば、ビニング・レンダリング・モードが、レンダリング・モードとして決定されうる。オーバドロー数があるしきい値未満であれば、ダイレクト・レンダリング・モードが、レンダリング・モードとして決定されうる。その後、ＧＰＵ１２は、決定されたレンダリング・モードにしたがってシーンをレンダリングしうる（１４０８）。

オーバドロー数は、ビンの領域のために、複数のビンにわたって、および／または、シーン全体のために計算されうる。ビンのオーバドロー数を計算する（１４０４）ための１つの技法の例は、ビン内のおのおののピクセルのオーバラップ値を計算することと、ビン内のおのおののピクセルの計算された各オーバラップ値を総和して、合計オーバラップ値を生成することと、合計オーバラップ値を、ビン内のピクセル数によって除することによって、オーバドロー数を生成することと、を含みうる。オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される。

図１５は、本開示の１つの例にしたがう方法を例示するフローチャートである。図１５の方法は、コンピューティング・デバイス２に常駐するＣＰＵ６、ＧＰＵ１２、および／または、その他任意のハードウェア、ファームウェア、ソフトウェア要素、またはこれらの組み合わせによって実行されうる。ＣＰＵ６は、グラフィック演算を実行するための演算コマンドを第１のバッファに格納すること（１５０２）と、書込コマンドを第２のバッファに格納すること（１５０４）と、を実行するように構成されうる。ここで、書込コマンドは、第１のバッファにおける演算コマンドを変更して、変更された演算コマンドを生成する。演算コマンドおよび書込コマンドは、グラフィック・プロセッサによる実行が可能である。ＣＰＵ６はさらに、第２のバッファにおける書込コマンドを実行させ（１５０６）、第２のバッファにおける書込コマンドを実行させた後、第１のバッファにおける変更された演算コマンドを実行させる（１５０８）、ように構成されうる。一例では、演算コマンドは、ビニング・レンダリング・モードのためのレンダリング・コマンドを含み、書込コマンドは、ビニング・レンダリング・モードのレンダリング・コマンドを、ダイレクト・レンダリング・モードのレンダリング・コマンドに変更する。

図１６は、図１５に図示される一般的な技法を利用する方法の例を例示するフローチャートである。図１６の方法は、コンピューティング・デバイス２に常駐するＣＰＵ６、ＧＰＵ１２、および／または、その他任意のハードウェア、ファームウェア、ソフトウェア要素、またはこれらの組み合わせによって実行されうる。ＣＰＵ６は、フレームをレンダリングするための演算コマンドを生成する（１６０２）ように構成されうる。ここで、演算コマンドは、ビニング・レンダリング・モード用である。ＣＰＵ６はさらに、グラフィック・メモリ・アドレスを用いる演算コマンドをトラックする（１６０４）ように構成されうる。ＣＰＵ６はさらに、書込コマンドを生成する（１６０６）ように構成されうる。書込コマンドは、グラフィック・メモリ・アドレスを用いる演算コマンドを、システム・メモリ・アドレスを用いる演算コマンドになるように変更する。ＣＰＵ６は、演算コマンドを第１のバッファに格納し（１６０８）、書込コマンドを第２のバッファに格納する（１６１０）。

ＣＰＵはさらに、レンダリング特性に基づいて、フレームのために、複数のレンダリング・モードのうちの１つのレンダリング・モードを決定する（１６１２）ように構成されうる。ここで、複数のレンダリング・モードは、ビニング・レンダリング・モードおよびダイレクト・レンダリング・モードを含む。レンダリング特性は、マイクロ・タイル・モード、テクスチャのサイズ、テクスチャ読取の数、描画されたプリミティブの数、シェダーの複雑さ、デプス・テスト・ステータス、レンダリング・ターゲットのサイズおよびタイプのうちの１つを含む。複数のレンダリング・モードのうちの１つのレンダリング・モードを決定することは、複数のレンダリング・モードのうちの１つのレンダリング・モードを、現在のフレームのレンダリング特性に基づいて決定することを含みうる。別の例では、複数のレンダリング・モードのうちの１つのレンダリング・モードを決定することは、複数のレンダリング・モードのうちの１つのレンダリング・モードを、現在のフレーム、および、以前にレンダリングされたフレームのレンダリング特性に基づいて決定することを含みうる。

その後、ＣＰＵ６は、決定されたレンダリング・モードがダイレクト・レンダリング・モードである場合、（例えば、ＧＰＵ１２によって）第２のバッファにおける書込コマンドを実行させる（１６１４）ように構成されうる。

１または複数の例では、前述された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれら任意の組み合わせで実現されうる。ソフトウェアで実現される場合、これら機能は、非一時的なコンピュータ読取可能な媒体を備える製造物品における１または複数の命令群またはコードとして格納されうる。コンピュータ読取可能な媒体は、コンピュータ・データ記憶媒体を含みうる。データ記憶媒体は、本開示において記述された技術を実施するための命令群、コード、および／または、データ構造を検索するために１または複数のコンピュータまたは１または複数のプロセッサによってアクセスされうる任意の利用可能な媒体でありうる。限定するのではなく、例として、このようなコンピュータ読取可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、フラッシュ・メモリ、または、命令群またはデータ構造の形態で所望のプログラム・コードを搬送または格納するように使用され、かつプロセッサによってアクセスされうるその他任意の媒体、を備えうる。本明細書で使用されるようにディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクト・ディスク（ｄｉｓｃ）（ＣＤ）、レーザ・ディスク（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、Ｂｌｕ−ｒａｙ（登録商標）ディスク（ｄｉｓｃ）を含む。ここで、ｄｉｓｋは通常、データを磁気的に再生し、ｄｉｓｃは、レーザを用いてデータを光学的に再生する。前述した組み合わせもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。

例えば、１または複数のＤＳＰ、汎用マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、またはその他等価な統合論理回路またはディスクリート論理回路のような１または複数のプロセッサによって実行されうる。さらに、いくつかの態様では、本明細書に記載された機能は、専用のハードウェア・モジュールおよび／またはソフトウェア・モジュール内に提供されうる。さらに、これら技術は、１または複数の回路または論理要素で完全に実現されうる。

本開示の技術は、無線ハンドセット、集積回路（ＩＣ）、またはＩＣのセット（例えば、チップセット）を含む種々さまざまなデバイスまたは装置において実現されうる。さまざまな構成要素、モジュール、またはユニットは、本開示では、開示された技術を実行するように構成されたデバイスの機能態様を強調するように記載されているが、異なるハードウェア・ユニットによる実現を必ずしも必要とする訳ではない。むしろ、前述されたように、さまざまなユニットは、適切なソフトウェアおよび／またはハードウェアと連携する、前述されたような１または複数のプロセッサを含む共通のハードウェア・ユニットの集合によって提供されうるか、コーデック・ハードウェア・ユニットに結合されうる。

さまざまな例が記載された。これらの例およびその他の例は、以下の特許請求の範囲のスコープ内である。

さまざまな例が記載された。これらの例およびその他の例は、以下の特許請求の範囲のスコープ内である。
以下に、出願時の特許請求の範囲に記載された発明を付記する。
［発明１］
グラフィック処理の方法であって、
シーンのプリミティブにビニング演算を実行することと、
前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと、
前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択することと、
を備える方法。
［発明２］
決定されたレンダリング・モードにしたがって、前記シーンをレンダリングすること、をさらに備える発明１に記載の方法。
［発明３］
前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択すること、をさらに備える発明１に記載の方法。
［発明４］
前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択すること、をさらに備える発明１に記載の方法。
［発明５］
ビンの領域について、前記オーバドロー数を計算すること、をさらに備える発明１に記載の方法。
［発明６］
複数のビンにわたる、前記オーバドロー数を計算すること、をさらに備える発明１に記載の方法。
［発明７］
前記シーン全体のための、前記オーバドロー数を計算すること、をさらに備える発明１に記載の方法。
［発明８］
前記オーバドローの量を示すオーバドロー数を計算することは、
ビン内のおのおののピクセルのオーバラップ値を計算することと、
前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成することと、
前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成することと
を備える、発明１に記載の方法。
［発明９］
前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、発明８に記載の方法。
［発明１０］
前記プリミティブは、三角形である、発明９に記載の方法。
［発明１１］
グラフィック処理のために構成された装置であって、
シーンのプリミティブにビニング演算を実行する手段と、
前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算する手段と、
前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択する手段と、
を備える装置。
［発明１２］
決定されたレンダリング・モードにしたがって、前記シーンをレンダリングする手段、をさらに備える発明１１に記載の装置。
［発明１３］
前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択する手段、をさらに備える発明１１に記載の装置。
［発明１４］
前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択する手段、をさらに備える発明１１に記載の装置。
［発明１５］
ビンの領域について、前記オーバドロー数を計算する手段、をさらに備える発明１１に記載の装置。
［発明１６］
複数のビンにわたる、前記オーバドロー数を計算する手段、をさらに備える発明１１に記載の装置。
［発明１７］
前記シーン全体のための、前記オーバドロー数を計算する手段、をさらに備える発明１１に記載の装置。
［発明１８］
前記オーバドローの量を示すオーバドロー数を計算する手段は、
ビン内のおのおののピクセルのオーバラップ値を計算する手段と、
前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成する手段と、
前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成する手段と
を備える、発明１１に記載の装置。
［発明１９］
前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、発明１８に記載の装置。
［発明２０］
前記プリミティブは、三角形である、発明１９に記載の装置。
［発明２１］
グラフィック処理のために構成された装置であって、
シーンのプリミティブにビニング演算を実行することと、
前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと、
を実行するように構成されたグラフィック・プロセッサと、
前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択することを実行するように構成されたプロセッサと、
を備える装置。
［発明２２］
前記グラフィック・プロセッサはさらに、決定されたレンダリング・モードにしたがって、前記シーンをレンダリングすることを実行するように構成された、発明２１に記載の装置。
［発明２３］
前記グラフィック・プロセッサはさらに、前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択することを実行するように構成された、発明２１に記載の装置。
［発明２４］
前記グラフィック・プロセッサはさらに、前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択することを実行するように構成された、発明２１に記載の装置。
［発明２５］
前記グラフィック・プロセッサはさらに、ビンの領域について、前記オーバドロー数を計算することを実行するように構成された、発明２１に記載の装置。
［発明２６］
前記グラフィック・プロセッサはさらに、複数のビンにわたる、前記オーバドロー数を計算することを実行するように構成された、発明２１に記載の装置。
［発明２７］
前記グラフィック・プロセッサはさらに、前記シーン全体のための、前記オーバドロー数を計算することを実行するように構成された、発明２１に記載の装置。
［発明２８］
前記グラフィック・プロセッサはさらに、
ビン内のおのおののピクセルのオーバラップ値を計算することと、
前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成することと、
前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成することと
を実行するように構成された、発明２１に記載の装置。
［発明２９］
前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、発明２８に記載の装置。
［発明３０］
前記プリミティブは、三角形である、発明２９に記載の装置。
［発明３１］
前記グラフィック・プロセッサは、モバイル・デバイスにある、発明２１に記載の装置。

Claims (31)

1. グラフィック処理の方法であって、
   シーンのプリミティブにビニング演算を実行することと、
   前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと、
   前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択することと、
   を備える方法。
2. 決定されたレンダリング・モードにしたがって、前記シーンをレンダリングすること、をさらに備える請求項１に記載の方法。
3. 前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択すること、をさらに備える請求項１に記載の方法。
4. 前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択すること、をさらに備える請求項１に記載の方法。
5. ビンの領域について、前記オーバドロー数を計算すること、をさらに備える請求項１に記載の方法。
6. 複数のビンにわたる、前記オーバドロー数を計算すること、をさらに備える請求項１に記載の方法。
7. 前記シーン全体のための、前記オーバドロー数を計算すること、をさらに備える請求項１に記載の方法。
8. 前記オーバドローの量を示すオーバドロー数を計算することは、
   ビン内のおのおののピクセルのオーバラップ値を計算することと、
   前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成することと、
   前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成することと
   を備える、請求項１に記載の方法。
9. 前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、請求項８に記載の方法。
10. 前記プリミティブは、三角形である、請求項９に記載の方法。
11. グラフィック処理のために構成された装置であって、
    シーンのプリミティブにビニング演算を実行する手段と、
    前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算する手段と、
    前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択する手段と、
    を備える装置。
12. 決定されたレンダリング・モードにしたがって、前記シーンをレンダリングする手段、をさらに備える請求項１１に記載の装置。
13. 前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択する手段、をさらに備える請求項１１に記載の装置。
14. 前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択する手段、をさらに備える請求項１１に記載の装置。
15. ビンの領域について、前記オーバドロー数を計算する手段、をさらに備える請求項１１に記載の装置。
16. 複数のビンにわたる、前記オーバドロー数を計算する手段、をさらに備える請求項１１に記載の装置。
17. 前記シーン全体のための、前記オーバドロー数を計算する手段、をさらに備える請求項１１に記載の装置。
18. 前記オーバドローの量を示すオーバドロー数を計算する手段は、
    ビン内のおのおののピクセルのオーバラップ値を計算する手段と、
    前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成する手段と、
    前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成する手段と
    を備える、請求項１１に記載の装置。
19. 前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、請求項１８に記載の装置。
20. 前記プリミティブは、三角形である、請求項１９に記載の装置。
21. グラフィック処理のために構成された装置であって、
    シーンのプリミティブにビニング演算を実行することと、
    前記シーンの領域におけるプリミティブのオーバドローの量を示すオーバドロー数を計算することと、
    を実行するように構成されたグラフィック・プロセッサと、
    前記計算されたオーバドロー数に基づいて、レンダリング・モードを選択することを実行するように構成されたプロセッサと、
    を備える装置。
22. 前記グラフィック・プロセッサはさらに、決定されたレンダリング・モードにしたがって、前記シーンをレンダリングすることを実行するように構成された、請求項２１に記載の装置。
23. 前記グラフィック・プロセッサはさらに、前記オーバドロー数が、あるしきい値よりも大きいのであれば、ビニング・レンダリグ・モードを選択することを実行するように構成された、請求項２１に記載の装置。
24. 前記グラフィック・プロセッサはさらに、前記オーバドロー数が、あるしきい値未満であれば、ダイレクト・レンダリグ・モードを選択することを実行するように構成された、請求項２１に記載の装置。
25. 前記グラフィック・プロセッサはさらに、ビンの領域について、前記オーバドロー数を計算することを実行するように構成された、請求項２１に記載の装置。
26. 前記グラフィック・プロセッサはさらに、複数のビンにわたる、前記オーバドロー数を計算することを実行するように構成された、請求項２１に記載の装置。
27. 前記グラフィック・プロセッサはさらに、前記シーン全体のための、前記オーバドロー数を計算することを実行するように構成された、請求項２１に記載の装置。
28. 前記グラフィック・プロセッサはさらに、
    ビン内のおのおののピクセルのオーバラップ値を計算することと、
    前記ビン内のおのおののピクセルの、計算された各オーバラップ値を総和して、合計オーバラップ値を生成することと、
    前記合計オーバラップ値を、前記ビン内のピクセル数によって除することによって、前記オーバドロー数を生成することと
    を実行するように構成された、請求項２１に記載の装置。
29. 前記オーバラップ値は、ピクセルに触れる、１つよりも多くのプリミティブの数として定義される、請求項２８に記載の装置。
30. 前記プリミティブは、三角形である、請求項２９に記載の装置。
31. 前記グラフィック・プロセッサは、モバイル・デバイスにある、請求項２１に記載の装置。

Images