高品質および高解像度のデジタル画像に対する需要は高まり続けている。高品質および高解像度のデジタル画像は、典型的には、大きいデータサイズを有するので、画像処理タスクを実行するためのハードウェア効率はより重要になる。1つのそのような画像処理タスクは、画像フィルタリングである。
1つの一般的なタイプの画像フィルタリングは、畳み込みフィルタリングである。畳み込みフィルタリングでは、2次元(2D)フィルタマスクが、中心ピクセルおよび周囲ピクセルのピクセル値(たとえば、色値)に適用される。すなわち、フィルタマスクはフィルタ重みの2D行列であり、フィルタマスクにおける各フィルタ重みは対応するピクセルに(たとえば、中心の現在フィルタリングされているピクセルとともに)適用される。典型的には、フィルタマスクは形が方形である。フィルタマスクのサイズは、カーネルサイズと呼ばれる。
畳み込みフィルタリングでは、各フィルタ重みは対応するピクセル色値で乗算され、これらの乗算の各々の結果は現在ピクセルのフィルタリングされた値として一緒に加えられる。いくつかの例では、フィルタリングされた値は除算され得るおよび/またはその値に加えられるバイアス値を有し得る。異なるタイプのフィルタリングは、フィルタマスクにおけるフィルタ重みの値を変化させることによって達成され得る。例示的なタイプのフィルタリングは、シャープ化、エッジファインディング(edge finding)、ぼかし、エンボス加工などを含む。
高次フィルタリング(HOF)は、大きいカーネルサイズに対して(たとえば、非線形であり得る)一般化されたフィルタリング公式を使用する畳み込みフィルタリングである。大きいカーネルサイズは、2×2よりも大きい(たとえば、4フィルタ係数よりも大きい)任意のフィルタカーネルとして定義され得る。したがって、HOFを実行することは、比較的多数のフィルタ重みならびに現在ピクセルを取り囲む多数のピクセルを必要とする。加えて、HOFは、サブピクセル解像度サポートを必要とする場合がある。HOFのためのこれらの要件を考慮すると、既存の解決策の主な問題はハードウェア性能および電力能力である。
本開示は、グラフィックス処理ユニット(GPU)において低コスト高次フィルタリング(LCHOF)を実行するためのデバイスおよび技法を提案する。本開示のLCHOFデバイスおよび技法は、単一のシェーダ命令によってHOFをサポートする。本開示の一例では、フィルタリングされるべきピクセルごとに、LCHOF修正GPUは、ローカルキャッシュからすべての関与するピクセルをフェッチし、プリロードされた重みとともにそれらのピクセルをブレンドするように構成される。この手法の利点は、必要とされる追加のハードウェア構成要素に関して、最小化されたシェーダリソース使用量、最小化されたメモリ圧力、柔軟性、および低コストを含む。
図1は、グラフィックス処理ユニット(GPU)上での高次フィルタリングのための本開示の技法を実装するために使用され得る例示的なコンピューティングデバイス2を示すブロック図である。コンピューティングデバイス2は、たとえば、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、コンピュータワークステーション、ビデオゲームプラットフォームもしくはコンソール、たとえば、セルラー電話もしくは衛星電話などの携帯電話、固定電話、インターネット電話、ポータブルビデオゲームデバイスもしくは携帯情報端末(PDA)などのハンドヘルドデバイス、パーソナル音楽プレーヤ、ビデオプレーヤ、ディスプレイデバイス、テレビジョン、テレビジョンセットトップボックス、サーバ、中間ネットワークデバイス、メインフレームコンピュータ、任意のモバイルデバイス、またはグラフィカルデータを処理および/もしくは表示する任意の他のタイプのデバイスを含み得る。
図1の例に示すように、コンピューティングデバイス2は、ユーザ入力インターフェース4と、中央処理ユニット(CPU)6と、メモリコントローラ8と、システムメモリ10と、GPU12と、グラフィックスメモリ14と、ディスプレイインターフェース16と、ディスプレイ18と、バス20および22とを含み得る。いくつかの例では、グラフィックスメモリ14はGPU12に「オンチップ」であってもよいことに留意されたい。いくつかの場合には、図1に示すCPU6、メモリコントローラ8、GPU12、およびグラフィックスメモリ14、ならびに場合によってはディスプレイインターフェース16は、たとえば、システムオンチップ(SoC)設計において、オンチップであってもよい。ユーザ入力インターフェース4、CPU6、メモリコントローラ8、GPU12およびディスプレイインターフェース16は、バス20を使用して互いと通信してもよい。メモリコントローラ8およびシステムメモリ10はまた、バス22を使用して互いと通信してもよい。バス20、22は、第3世代バス(たとえば、HyperTransportバスまたはInfiniBandバス)、第2世代バス(たとえば、アドバンストグラフィックスポートバス、ペリフェラルコンポーネントインターコネクト(PCI)エクスプレスバス、または高度拡張可能インターフェース(AXI)バス)または別のタイプのバスもしくはデバイス相互接続などの様々なバス構造のいずれかであってもよい。図1に示す異なる構成要素間のバスおよび通信インターフェースの特定の構成は例にすぎず、同じまたは異なる構成要素を有するコンピューティングデバイスおよび/または他のグラフィックス処理システムの他の構成が本開示の技法を実装するために使用され得ることに留意されたい。
CPU6は、コンピューティングデバイス2の動作を制御する汎用または専用プロセッサを備え得る。ユーザは、CPU6に1つまたは複数のソフトウェアアプリケーションを実行させるために、入力をコンピューティングデバイス2に与え得る。CPU6上で実行されるソフトウェアアプリケーションは、たとえば、オペレーティングシステム、ワードプロセッサアプリケーション、電子メールアプリケーション、スプレッドシートアプリケーション、メディアプレーヤアプリケーション、ビデオゲームアプリケーション、グラフィカルユーザインターフェースアプリケーションまたは別のプログラムを含み得る。加えて、CPU6は、GPU12の動作を制御するためのGPUドライバ7を実行し得る。ユーザは、ユーザ入力インターフェース4を介してコンピューティングデバイス2に結合されたキーボード、マウス、マイクロフォン、タッチパッドまたは別の入力デバイスなどの1つまたは複数の入力デバイス(図示せず)を介して、入力をコンピューティングデバイス2に与え得る。
CPU6上で実行されるソフトウェアアプリケーションは、ディスプレイ18へのグラフィックスデータのレンダリングを行わせるようCPU6に命令する1つまたは複数のグラフィックスレンダリング命令を含み得る。いくつかの例では、ソフトウェア命令は、たとえば、オープングラフィックスライブラリ(OpenGL(登録商標))API、オープングラフィックスライブラリ組込みシステム(OpenGL ES)API、Direct3D API、X3D API、RenderMan API、WebGL API、または任意の他の公的もしくはプロプライエタリ規格グラフィックスAPIなどのグラフィックスアプリケーションプログラミングインターフェース(API)に準拠し得る。グラフィックスレンダリング命令を処理するために、CPU6は、GPU12にグラフィックスデータのレンダリングの一部または全部を実行させるために、1つまたは複数のグラフィックスレンダリングコマンドをGPU12に(たとえば、GPUドライバ7を通じて)発行し得る。いくつかの例では、レンダリングされるべきグラフィックスデータは、グラフィックスプリミティブ、たとえば、点、線、三角形、四角形、三角形ストリップなどのリストを含み得る。
他の例では、CPU6上で実行されるソフトウェア命令は、GPU12に、GPUハードウェアの高度並列の性質によって実行されるように適用可能なより一般的な計算を実行するための汎用シェーダを実行させ得る。そのような汎用アプリケーションは、いわゆる汎用グラフィックス処理ユニット(GPGPU)であり得、OpenCLなどの汎用APIに準拠し得る。
メモリコントローラ8は、システムメモリ10を出入りするデータの転送を容易にする。たとえば、メモリコントローラ8は、メモリ読取りコマンドおよびメモリ書込みコマンドを受け取り、メモリサービスをコンピューティングデバイス2内の構成要素に提供するためにシステムメモリ10に対してそのようなコマンドをサービスし得る。メモリコントローラ8は、メモリバス22を介してシステムメモリ10に通信可能に結合される。メモリコントローラ8は、CPU6とシステムメモリ10の両方とは別の処理モジュールであるものとして図1に示されているが、他の例では、メモリコントローラ8の機能の一部または全部は、CPU6とシステムメモリ10の両方の上で実装され得る。
システムメモリ10は、CPU6が実行するためにアクセス可能なプログラムモジュールおよび/または命令ならびに/あるいはCPU6上で実行されるプログラムが使用するためのデータを記憶し得る。たとえば、システムメモリ10は、ディスプレイ18上にグラフィカルユーザインターフェース(GUI)を提示するためにCPU6によって使用されるウィンドウマネージャアプリケーションを記憶し得る。加えて、システムメモリ10は、ユーザアプリケーションと、アプリケーションに関連付けられたアプリケーションサーフェスデータとを記憶し得る。システムメモリ10は加えて、コンピューティングデバイス2の他の構成要素が使用するためのおよび/またはそれらの構成要素によって生成される情報を記憶し得る。たとえば、システムメモリ10は、GPU12用のデバイスメモリとして働くことができ、GPU12によって演算されるべきデータ、ならびにGPU12によって実行される演算から生じるデータを記憶し得る。たとえば、システムメモリ10は、テクスチャバッファ、深度バッファ、ステンシルバッファ、頂点バッファ、フレームバッファなどの任意の組合せを記憶し得る。システムメモリ10は、たとえば、ランダムアクセスメモリ(RAM)、スタティックRAM(SRAM)、ダイナミックRAM(DRAM)、読取り専用メモリ(ROM)、消去可能プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、フラッシュメモリ、磁気データ媒体または光学記憶媒体など、1つまたは複数の揮発性もしくは不揮発性メモリまたはストレージデバイスを含み得る。
GPU12は、1つまたは複数のグラフィックスプリミティブをディスプレイ18にレンダリングするためのグラフィックス動作を実行するように構成され得る。したがって、CPU6上で実行されるソフトウェアアプリケーションのうちの1つがグラフィックス処理を必要とするとき、CPU6は、ディスプレイ18にレンダリングするためにグラフィックスコマンドおよびグラフィックスデータをGPU12に与え得る。グラフィックスデータは、たとえば、描画コマンド、状態情報、プリミティブ情報、テクスチャ情報などを含み得る。GPU12は、ある事例では、CPU6よりも効率的な、複雑なグラフィック関連動作の処理を実現する高度並列構造で構築され得る。たとえば、GPU12は、複数の頂点またはピクセル上で並行して動作するように構成された複数の処理要素を含み得る。GPU12の高度並列の性質は、ある事例では、CPU6を使用してシーンを直接ディスプレイ18に描画するよりも速く、GPU12がグラフィックス画像(たとえば、GUIならびに2次元(2D)および/または3次元(3D)グラフィックスシーン)をディスプレイ18上で描画することを可能にし得る。
GPU12は、ある事例では、コンピューティングデバイス2のマザーボードに統合され得る。他の事例では、GPU12は、コンピューティングデバイス2のマザーボード内のポートにインストールされたグラフィックスカード上に存在してもよく、またはさもなければコンピューティングデバイス2と相互動作するように構成された周辺デバイス内に組み込まれてもよい。GPU12は、1つまたは複数のマイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、デジタル信号プロセッサ(DSP)、または他の等価の集積論理回路もしくは個別論理回路などの1つまたは複数のプロセッサを含み得る。
GPU12は、グラフィックスメモリ14に直接結合され得る。したがって、GPU12は、バス20を使用することなしに、グラフィックスメモリ14からデータを読み取り、グラフィックスメモリ14にデータを書き込んでもよい。言い換えれば、GPU12は、オフチップメモリの代わりに、ローカルストレージを使用してデータをローカルに処理してもよい。これは、GPU12がバス20を介してデータの読取りおよび書込みを行う(このことは、重いバストラフィックを経験する場合がある)必要をなくすことによって、GPU12がより効率的に動作することを可能にする。しかしながら、ある事例では、GPU12は別個のメモリを含まないが、代わりにバス20を介してシステムメモリ10を利用する場合がある。グラフィックスメモリ14は、たとえば、ランダムアクセスメモリ(RAM)、スタティックRAM(SRAM)、ダイナミックRAM(DRAM)、消去可能プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、フラッシュメモリ、磁気データ媒体または光学記憶媒体など、1つまたは複数の揮発性もしくは不揮発性メモリまたはストレージデバイスを含み得る。
CPU6および/またはGPU12は、レンダリングされた画像データをフレームバッファ15に記憶し得る。フレームバッファ15は、独立したメモリであってもよく、またはシステムメモリ10内で割り振られてもよい。ディスプレイインターフェース16は、フレームバッファ15からデータを取り出し、レンダリングされた画像データによって表される画像を表示するようにディスプレイ18を構成し得る。いくつかの例では、ディスプレイインターフェース16は、フレームバッファから取り出されたデジタル値をディスプレイ18によって消費可能なアナログ信号に変換するように構成されたデジタルアナログコンバータ(DAC)を含み得る。他の例では、ディスプレイインターフェース16は、処理のためにデジタル値を直接ディスプレイ18に渡してもよい。ディスプレイ18は、モニタ、テレビジョン、投影デバイス、液晶ディスプレイ(LCD)、プラズマディスプレイパネル、有機LED(OLED)ディスプレイなどの発光ダイオード(LED)アレイ、陰極線管(CRT)ディスプレイ、電子ペーパー、表面伝導電子放出ディスプレイ(SED)、レーザーテレビジョンディスプレイ、ナノ結晶ディスプレイまたは別のタイプのディスプレイユニットを含み得る。ディスプレイ18は、コンピューティングデバイス2内に統合され得る。たとえば、ディスプレイ18は、携帯電話のスクリーンであり得る。代替的に、ディスプレイ18は、ワイヤードまたはワイヤレス通信リンクを介してコンピューティングデバイス2に結合されたスタンドアロンデバイスであり得る。たとえば、ディスプレイ18は、ケーブルまたはワイヤレスリンクを介してパーソナルコンピュータに接続されたコンピュータモニタまたはフラットパネルディスプレイであり得る。
本開示の一例によれば、以下でより詳細に説明するように、GPU12は、シェーダ命令を使用してHOFを実行するように構成され得る。たとえば、GPU12は、ソースピクセルをフィルタリングするためのシェーダ命令を受け取り、シェーダ命令に応答してフィルタを決定し、決定されたフィルタに基づいて隣接ピクセルを取り出し、決定されたフィルタおよび取り出された隣接ピクセルを使用してソースピクセルをフィルタリングするように構成され得る。本開示の一例では、決定されたフィルタは、レジスタに記憶された事前計算されたフィルタ重みを含む。
図2は、図1のCPU6、GPU12、およびシステムメモリ10の例示的な実装形態をさらに詳細に示すブロック図である。CPU6は、少なくとも1つのソフトウェアアプリケーション24、グラフィックスAPI26、およびGPUドライバ7を含んでもよく、これらの各々は、CPU6上で実行される1つまたは複数のソフトウェアアプリケーションまたはサービスであってもよい。GPU12は、グラフィックス処理コマンドを実行するために一緒に動作する複数のグラフィックス処理段階を含むグラフィックス処理パイプライン30を含み得る。GPU12は、ビニングレンダリングモードおよび直接レンダリングモードを含む様々なレンダリングモードでグラフィックス処理パイプライン30を実行するように構成され得る。図2に示すように、グラフィックス処理パイプライン30は、コマンドエンジン32、ジオメトリ処理段階34、ラスタ化段階36、およびピクセル処理パイプライン38を含み得る。ピクセル処理パイプライン38は、テクスチャエンジン39を含み得る。グラフィックス処理パイプライン30内の構成要素の各々は、固定機能構成要素、(たとえば、プログラマブルシェーダユニット上で実行されるシェーダプログラムの一部としての)プログラマブル構成要素として、または固定機能構成要素とプログラマブル構成要素の組合せとして実装され得る。CPU6およびGPU12が利用可能なメモリは、システムメモリ10およびフレームバッファ15を含み得る。フレームバッファ15は、システムメモリ10の一部であってもよく、またはシステムメモリ10とは別であってもよい。フレームバッファ15は、レンダリングされた画像データを記憶し得る。
ソフトウェアアプリケーション24は、GPU12の機能を利用する任意のアプリケーションであり得る。たとえば、ソフトウェアアプリケーション24は、GUIアプリケーション、オペレーティングシステム、ポータブルマッピングアプリケーション、エンジニアリングもしくは美術アプリケーション用のコンピュータ支援設計プログラム、ビデオゲームアプリケーション、またはGPUを利用し得る別のタイプのソフトウェアアプリケーションであり得る。
ソフトウェアアプリケーション24は、グラフィカルユーザインターフェース(GUI)および/またはグラフィックスシーンをレンダリングするようGPU12に命令する1つまたは複数の描画命令を含み得る。たとえば、描画命令は、GPU12によってレンダリングされるべき1つまたは複数のグラフィックスプリミティブのセットを定義する命令を含み得る。いくつかの例では、描画命令は、GUIで使用される複数のウィンドウ処理サーフェスの全部または一部をまとめて定義してもよい。追加の例では、描画命令は、アプリケーションによって定義されたモデル空間またはワールド空間内に1つまたは複数のグラフィックスオブジェクトを含むグラフィックスシーンの全部または一部をまとめて定義してもよい。
ソフトウェアアプリケーション24は、1つまたは複数のグラフィックスプリミティブを表示可能なグラフィックス画像にレンダリングするための1つまたは複数のコマンドをGPU12に発行するために、グラフィックスAPI26を介してGPUドライバ7を呼び出し得る。たとえば、ソフトウェアアプリケーション24は、プリミティブ定義をGPU12に与えるために、グラフィックスAPI26を介してGPUドライバ7を呼び出し得る。ある事例では、プリミティブ定義は、描画プリミティブ、たとえば、三角形、長方形、三角形ファン、三角形ストリップなどのリストの形でGPU12に与えられ得る。プリミティブ定義は、レンダリングされるべきプリミティブに関連付けられた1つまたは複数の頂点を指定する頂点仕様を含み得る。頂点仕様は、頂点ごとの位置座標と、ある事例では、たとえば、色座標、法線ベクトル、およびテクスチャ座標など、頂点に関連付けられた他の属性とを含み得る。プリミティブ定義はまた、プリミティブタイプ情報(たとえば、三角形、長方形、三角形ファン、三角形ストリップなど)、スケーリング情報、回転情報などを含み得る。ソフトウェアアプリケーション24によってGPUドライバ7に発行された命令に基づいて、GPUドライバ7は、プリミティブをレンダリングするためにGPU12が実行する1つまたは複数の動作を指定する1つまたは複数のコマンドを公式化し得る。GPU12がCPU6からコマンドを受け取ると、グラフィックス処理パイプライン30は、コマンドを復号し、コマンドにおいて指定された動作を実行するようにグラフィックス処理パイプライン30内の1つまたは複数の処理要素を構成する。指定された動作を実行した後、グラフィックス処理パイプライン30は、レンダリングされたデータをディスプレイデバイスに関連付けられたフレームバッファ15に出力する。グラフィックス処理パイプライン30は、ビニングレンダリングモードおよび直接レンダリングモードを含む複数の異なるレンダリングモードのうちの1つで実行するように構成され得る。
GPUドライバ7は、1つまたは複数のシェーダプログラムをコンパイルし、コンパイルされたシェーダプログラムをGPU12内に含まれる1つまたは複数のプログラマブルシェーダユニットにダウンロードするようにさらに構成され得る。シェーダプログラムは、たとえば、OpenGL Shading Language(GLSL)、High Level Shading Language(HLSL)、C for Graphics(Cg) shading languageなどの高レベルシェーディング言語で書かれる場合がある。コンパイルされたシェーダプログラムは、GPU12内のプログラマブルシェーダユニットの動作を制御する1つまたは複数の命令を含み得る。たとえば、シェーダプログラムは、頂点シェーダプログラムおよび/またはピクセルシェーダプログラムを含み得る。頂点シェーダプログラムは、プログラマブル頂点シェーダユニットまたはユニファイドシェーダユニットの実行を制御し、1つまたは複数の頂点ごとの動作を指定する命令を含み得る。ピクセルシェーダプログラムは、プログラマブルピクセルシェーダユニットまたはユニファイドシェーダユニットの実行を制御し、1つまたは複数のピクセルごとの動作を指定する命令を含む、ピクセルシェーダプログラムを含み得る。
グラフィックス処理パイプライン30は、グラフィックスドライバ7を介してCPU6から1つまたは複数のグラフィックス処理コマンドを受け取り、表示可能なグラフィックス画像を生成するためのグラフィックス処理コマンドを実行するように構成され得る。上記で説明したように、グラフィックス処理パイプライン30は、グラフィックス処理コマンドを実行するために一緒に動作する複数の段階を含む。しかしながら、そのような段階は必ずしも別個のハードウェアブロックにおいて実装される必要はないことに留意されたい。たとえば、ジオメトリ処理段階34およびピクセル処理パイプライン38の部分は、ユニファイドシェーダユニットの一部として実装され得る。この場合も、グラフィックス処理パイプライン30は、ビニングレンダリングモードおよび直接レンダリングモードを含む複数の異なるレンダリングモードのうちの1つで実行するように構成され得る。
コマンドエンジン32は、グラフィックス処理コマンドを受け取り、グラフィックス処理コマンドを実施するための様々な動作を実行するようにグラフィックス処理パイプライン30内の残りの処理段階を構成し得る。グラフィックス処理コマンドは、たとえば、描画コマンドおよびグラフィックス状態コマンドを含み得る。描画コマンドは、1つまたは複数の頂点の位置座標を指定する頂点仕様コマンドと、ある事例では、たとえば、色座標、法線ベクトル、テクスチャ座標およびかぶり座標など、頂点の各々に関連付けられた他の属性値とを含み得る。グラフィックス状態コマンドは、プリミティブタイプコマンド、変換コマンド、照明コマンドなどを含み得る。プリミティブタイプコマンドは、レンダリングされるべきプリミティブのタイプおよび/またはプリミティブを形成するために頂点がどのように組み合わされるかを指定し得る。変換コマンドは、頂点に対して実行すべき変換のタイプを指定し得る。照明コマンドは、グラフィックスシーン内の異なる照明のタイプ、方向および/または配置を指定し得る。コマンドエンジン32は、ジオメトリ処理段階34に、1つまたは複数の受け取られたコマンドに関連付けられた頂点および/またはプリミティブに対してジオメトリ処理を実行させ得る。
ジオメトリ処理段階34は、ラスタ化段階36のためのプリミティブデータを生成するために、1つまたは複数の頂点に対して頂点ごとの動作および/またはプリミティブセットアップ動作を実行し得る。各頂点は、たとえば、位置座標、色値、法線ベクトル、およびテクスチャ座標などの属性のセットに関連付けられ得る。ジオメトリ処理段階34は、様々な頂点ごとの動作に従って、これらの属性のうちの1つまたは複数を修正する。たとえば、ジオメトリ処理段階34は、修正された頂点位置座標を生成するために、頂点位置座標に対して1つまたは複数の変換を実行し得る。ジオメトリ処理段階34は、修正された頂点位置座標を生成するために、たとえば、モデリング変換、ビューイング変換、投影変換、モデルビュー(ModelView)変換、モデルビュー投影(ModelViewProjection)変換、ビューポート変換および深度範囲スケーリング変換のうちの1つまたは複数を頂点位置座標に適用し得る。ある事例では、頂点位置座標はモデル空間座標であってもよく、修正された頂点位置座標はスクリーン空間座標であってもよい。スクリーン空間座標は、モデリング変換、ビューイング変換、投影変換およびビューポート変換の適用の後で取得され得る。ある事例では、ジオメトリ処理段階34はまた、頂点の修正された色座標を生成するために、頂点に対して頂点ごとの照明動作を実行し得る。ジオメトリ処理段階34はまた、たとえば、正規変換、ノーマル正規化(normal normalization)動作、ビューボリュームクリッピング、同次除算動作および/またはバックフェースカリング動作を含む他の動作を実行し得る。
ジオメトリ処理段階34は、ラスタ化されるべきプリミティブを定義する1つまたは複数の修正された頂点のセットを含むプリミティブデータ、ならびにプリミティブを形成するために頂点がどのように組み合わされるかを指定するデータを生成し得る。修正された頂点の各々は、たとえば、修正された頂点位置座標と、頂点に関連付けられた処理された頂点属性値とを含み得る。プリミティブデータはまとめて、グラフィックス処理パイプライン30のさらなる段階によってラスタ化されるべきプリミティブに対応し得る。概念的には、各頂点は、プリミティブの2つの辺がぶつかるプリミティブのコーナー(corner)に対応し得る。ジオメトリ処理段階34は、さらなる処理のために、プリミティブデータをラスタ化段階36に与え得る。
いくつかの例では、ジオメトリ処理段階34の全部または一部は、1つまたは複数のシェーダユニット上で実行される1つまたは複数のシェーダプログラムによって実装され得る。たとえば、ジオメトリ処理段階34は、そのような例では、頂点シェーダ、ジオメトリシェーダまたはそれらの任意の組合せによって実装され得る。他の例では、ジオメトリ処理段階34は、固定機能ハードウェア処理パイプラインとして、または固定機能ハードウェアと1つもしくは複数のシェーダユニット上で実行される1つもしくは複数のシェーダプログラムの組合せとして実装され得る。
ラスタ化段階36は、ジオメトリ処理段階34から、ラスタ化されるべきプリミティブを表すプリミティブデータを受け取り、プリミティブをラスタ化して、ラスタ化されたプリミティブに対応する複数のソースピクセルを生成するように構成される。いくつかの例では、ラスタ化段階36は、どのスクリーンピクセルロケーションがラスタ化されるべきプリミティブによってカバーされるかを決定し、プリミティブによってカバーされると決定されたスクリーンピクセルロケーションごとにソースピクセルを生成し得る。ラスタ化段階36は、たとえば、エッジウォーキング(edge-walking)技法、エッジ方程式評価(evaluating edge equations)などの、当業者に知られている技法を使用することによって、どのスクリーンピクセルロケーションがプリミティブによってカバーされるかを決定し得る。ラスタ化段階36は、さらなる処理のために、得られたソースピクセルをピクセル処理パイプライン38に与え得る。
ラスタ化段階36によって生成されたソースピクセルは、スクリーンピクセルロケーション、たとえば、宛先ピクセルに対応し、1つまたは複数の色属性に関連付けられ得る。特定のラスタ化されたプリミティブのために生成されたソースピクセルのすべては、ラスタ化されたプリミティブに関連付けられていると言える。プリミティブによってカバーされるべき、ラスタ化段階36によって決定されたピクセルは、概念的には、プリミティブの頂点を表すピクセル、プリミティブの辺を表すピクセル、およびプリミティブの内部を表すピクセルを含み得る。
ピクセル処理パイプライン38は、ラスタ化されたプリミティブに関連付けられたソースピクセルを受け取り、ソースピクセルに対して1つまたは複数のピクセルごとの動作を実行するように構成される。ピクセル処理パイプライン38によって実行され得るピクセルごとの動作は、たとえば、アルファテスト、テクスチャマッピング、色計算、ピクセルシェーディング、ピクセルごとの照明、かぶり処理、ブレンディング、ピクセルオーナーシップテスト、ソースアルファテスト、ステンシルテスト、深度テスト、シザーテストおよび/またはスティップリング動作を含む。加えて、ピクセル処理パイプライン38は、1つまたは複数のピクセルごとの動作を実行するための1つまたは複数のピクセルシェーダプログラムを実行し得る。ピクセル処理パイプライン38によって生成された得られたデータは、本明細書では宛先ピクセルデータと呼ばれ、フレームバッファ15に記憶され得る。宛先ピクセルデータは、処理されたソースピクセルと同じディスプレイロケーションを有する、フレームバッファ15内の宛先ピクセルに関連付けられ得る。宛先ピクセルデータは、たとえば、色値、宛先アルファ値、深度値などのデータを含み得る。
テクスチャエンジン39は、ピクセル処理パイプライン38の一部として含まれ得る。テクスチャエンジン39は、テクスチャ(テクセル)をピクセルに適用するように設計されたプログラマブルハードウェアと固定機能ハードウェアの両方を含み得る。テクスチャエンジン39は、テクスチャフィルタリングを実行するための専用ハードウェアを含み得、それによって、1つまたは複数のテクセル値は、最終的なテクスチャマッピングされたピクセルを生成するために、1つまたは複数のピクセル値で乗算され、累積される。以下でより詳細に説明するように、本開示は、テクスチャエンジン39が単一のシェーダ命令を使用してLCHOFを実行するために使用され得るように、テクスチャエンジン39に対する修正形態を提案する。
フレームバッファ15は、GPU12のための宛先ピクセルを記憶する。各宛先ピクセルは、一意のスクリーンピクセルロケーションに関連付けられ得る。いくつかの例では、フレームバッファ15は、宛先ピクセルごとの色成分および宛先アルファ値を記憶し得る。たとえば、フレームバッファ15は、ピクセルごとの赤(Red)、緑(Green)、青(Blue)、アルファ(Alpha)(RGBA)成分を記憶し得、ここで、「RGB」成分は色値に対応し、「A」成分は宛先アルファ値に対応する。フレームバッファ15およびシステムメモリ10は別個のメモリユニットであるものとして示されているが、他の例では、フレームバッファ15はシステムメモリ10の一部であってもよい。
以下では、単一のシェーダ命令を用いてHOFをサポートするように修正されたGPUによって実装されるLCHOF技法を含む、本開示のLCHOF技法について説明する。一例では、本開示は、GPUのテクスチャエンジン(たとえば、GPU12のテクスチャエンジン39)を修正し、すでに存在しているテクスチャエンジンハードウェア(たとえば、アドレス指定およびサンプルフェッチ乗算制御ユニットを有するローカルキャッシュ)を利用することによって、HOFを実装することを提案する。ピクセルに対してHOFを実行する場合、本開示の技法は、テクスチャエンジン39にすべての関与する周囲ピクセルを通ってループさせ、ローカルキャッシュから周囲ピクセルをフェッチさせ、プリロードされた/事前計算されたフィルタ重みとともに周囲ピクセルをブレンド(たとえば、乗算)させる単一のシェーダ命令の使用を提案する。
上記で説明したように、現在画像の処理タスクにおける高解像度および高品質の要望は、ハードウェアがサブピクセル解像度サポートおよび大きいフィルタリングカーネルを用いてフィルタリングを効率的に実行することを必要とする。様々な一般的に使用されるHOF技法は、以下の式によって表され得る。ピクセル(x,y)ごとに、フィルタリング結果f(x,y)は次のようになる。
変数m、nは、フィルタリングカーネルサイズである。フィルタリングに関与する合計サンプルは、m*nである。関数fu(i,x)およびfv(i,y)は、現在ピクセル(x,y)のフィルタリングに関与するサンプルピクセル(たとえば、周囲ピクセル)の座標を取得する。たとえば、単純な3×3カーネルの場合、fu(i,x)=x-(i/3)+1、fv(i,y)=y-(i/3)+1である。すなわち、中心(x,y)に対するオフセットは、両方の次元において(-1,0,1)である。
関数fweight(i,x,y)は、最もレガシーなフィルタリングアプリケーションの場合、fweight(i)に簡略化され得る。すなわち、各サンプルピクセルのフィルタ重みは、カーネル内部のその位置(i)のみによって決定される。より高度な一般的なfweight(i,x,y)マッピングは、ピクセルごとに異なる重みが指定されることを可能にし得る。たとえば、サブピクセル解像度サポートでは、現在ピクセルの座標(x,y)があらかじめ定義されたカーネル中心に位置していない場合、相対的なオフセットは、線形補間(または、ガウス曲線のような、フィルタリングを定義するより正確な公式/曲線)によって元のfweight(i)および(x-kernelcenter)、(y-kernelcenter)から導出され得る、現在ピクセルの新しい重みを決定する。異方性方向サポートでは、各ピクセルをフィルタリングするために異なるカーネルが使用され得る。たとえば、異なる重みは、現在ピクセルについての何らかの事前計算された方向情報に従って、選択され得る。
GPU(または他のハードウェア)上でのHOFのための以前の技法は、プログラマブル(たとえば、GPUシェーダ)実装形態および固定パイプライン実装形態を含む。両方とも欠点を有する。たとえば、GPUにおけるプログラマブルシェーダ実装形態は、低い効率性でHOFを処理する。大きいフィルタリングカーネルのための周囲ピクセルおよびフィルタ重みを取得することは、複数のシェーダ命令にブレークダウンする。フィルタリングに関与する各周囲ピクセルは、別個のデータロード命令を使用してフェッチされる。各周囲ピクセルのフィルタリング(すなわち、フィルタ重みによるピクセル値の乗算)は、1つまたは2つの命令(たとえば、乗算命令と加算命令を組み合わせるmuladd命令)によって実行される。この解決策の主な問題は、大量のソースデータ(すなわち、周囲ピクセル)およびHOFのために関与するフィルタ重みを考慮して必要とされるハードウェア性能/電力の量である。GPUシェーダ実行パス内部でのデータトランザクション(重みおよび中間結果の計算)を最小限に抑え、GPUからメモリデータパスへのデータトランザクションを最小限に抑えることが好ましい。
シェーダベースの解決策は、ソースデータごとにフィルタリングを実行し(すなわち、フィルタ重みによる周囲ピクセルの乗算が中間結果をもたらし)、次いで、他のシェーダ命令を使用してすべての中間結果をブレンドするためのシェーダ命令を使用する。この種類の解決策は、重みおよび中間結果を記憶/転送するために多くのシェーダリソースを必要とする。シェーダベースの解決策の別の問題は、GPU実行順序のせいで、ローカルキャッシュから削除される前にソースデータを完全に利用することができないということである。したがって、同じデータを複数回フェッチする必要があり得る。
シェーダベースの実装形態の非効率性を考慮すると、固定パイプライン実装形態は、HOFをサポートするための別の一般的な選択肢である。固定パイプライン実装形態では、HOFを実装するために、完全に新しい専用ハードウェアパイプラインが(たとえば、GPUに)追加され得る。しかしながら、そのような固定設計はフィルタリング動作に限定され、他の動作に柔軟に使用されない場合がある。さらに、固定フィルタリングパイプラインにおけるデータ帯域幅の設計は、良好な性能/電力トレードオフを得るように調整することが難しい。固定パイプライン実装形態に関する別の大きい懸念事項は、コストである。多くの使用事例では、HOFは、典型的には、大きいキャッシュおよび関連するメモリアクセス論理ユニット(たとえば、レイテンシ隠しFIFOバッファ)を必要とするので、HOFのための専用ハードウェアの必要性を正当化することが難しい。ラインバッファは、より良い電力およびメモリ効率を得るために、この種類の固定パイプライン実装形態において広く使用されているが、大きいフィルタリングカーネルがサポートされなければならない場合、そのようなラインバッファのコストはやはり大きい。
本開示は、複数のシェーダ命令を必要とするかまたはフィルタリングのための追加の専用の固定機能ハードウェアを必要とすることなしに、GPU12によって実装され得る低コスト高次フィルタリング(LCHOF)のための技法について説明する。本開示の例では、LCHOF技法は、シェーダプロセッサおよびテクスチャエンジン39を含む、GPU12の1つまたは複数のハードウェアユニットによって実装され得る。本開示の技法は、処理時間を増加させる複数の命令ではなく、単一のシェーダ命令を使用してGPU12上で実行される高次フィルタリングをサポートし得る。以下で説明するように、LCHOF技法は、既存のローカルキャッシュ、アドレス指定およびループ制御回路とともに働く少量の論理回路を追加することによって既存のGPUハードウェア(たとえば、テクスチャエンジン)を変更することによって、実装され得る。このようにして、本開示で説明するLCHOF技法は、フィルタリングのためのかなりの追加の専用ハードウェアを必要とせずに、GPU12の既存のハードウェアとともに機能する。以下でより詳細に説明する本開示の例では、GPU12は、フィルタリングされるべきピクセルを識別するシェーダ命令を受け取り、使用されるべきフィルタのタイプおよびサイズを決定し、フィルタのための事前計算されたフィルタ重みを取得し、決定されたフィルタのサイズに基づいて、必要とされる任意の周囲ピクセルをフェッチするように構成され得る。
図3は、本開示の技法に従ってHOFを実装するように構成されているGPU12およびテクスチャエンジン39の一例を示すブロック図である。図3に示すように、テクスチャエンジン39は、ループ制御およびアドレス指定ユニット40と、キャッシュ45と、フィルタリングユニット47と、アキュムレータ49とを含み得る。本開示の技法によれば、ループ制御およびアドレス指定ユニット40は、重みテーブルレジスタ41を含むおよび/または重みテーブルレジスタ41にアクセスするようにさらに修正され得る。すなわち、重みテーブルレジスタは、ループ制御およびアドレス指定ユニット40の内部または外部にあり得る。重みテーブルレジスタ41は、本開示のHOF技法を実装するために典型的な既存のテクスチャエンジンハードウェアに追加され得る、追加の論理回路の一部を表す。
図3に示すように、GPU12は、フィルタリング動作(たとえば、HOF動作)を実行するようGPU12に命令するシェーダ命令51を受け取り得る。シェーダ命令51は、フィルタリングされるべき現在ピクセル値(たとえば、ソースピクセル値)のインジケータ(たとえば、仮想アドレスまたは他のインジケータ)を含み得る。本開示はフィルタリングされるべき「ピクセル値」について概略的に説明することに留意されたい。フィルタリングされるべき「ピクセル値」は、表示されることになるピクセルの色を表す1つまたは複数の色成分であり得る。任意の色フォーマットが、色値を表すために使用され得る。
一例では、ピクセル値はRGBA色フォーマットによって表され得、ここで、Rはピクセル色の赤値を表し、Gはピクセル色の緑値を表し、Bはピクセル色の青値を表し、Aはピクセルのアルファ値(すなわち、深度値)を表す。他の例では、ピクセル色値は、ルーマ値(Y)および2つのクロミナンス値(たとえば、UおよびV、またはCrおよびCb)によって表され得る。いくつかのアプリケーションでは、色値の各々(たとえば、RGBAの各々)をフィルタリングすることが望ましい場合がある。他のアプリケーションでは、色値のうちの1つのみ(たとえば、YUV色フォーマットまたはYCrCb色フォーマットにおけるルミナンス値Yのみ)をフィルタリングすることが望ましい場合がある。
GPU12がシェーダ命令51を受け取ると、GPU12のシェーダプロセッサは、フィルタリングされるべき現在ピクセル(たとえば、ソースピクセル)のアドレスをテクスチャエンジン39のループ制御およびアドレス指定ユニット40に渡すことができる。ループ制御およびアドレス指定ユニット40は、重みテーブルレジスタ41から適用されるべきフィルタを決定するように構成され得る。重みテーブルレジスタ41は、フィルタタイプ、フィルタサイズ(たとえば、カーネルサイズ)および事前計算されたフィルタ重みを示すレジスタエントリを含み得る。重みテーブルレジスタ41において示されたカーネルサイズは、現在ピクセルをフィルタリングするために、現在ピクセルを取り囲むどのピクセルが使用されるべきかを、ループ制御およびアドレス指定ユニット40に示す。カーネルサイズに基づいて、ループ制御およびアドレス指定ユニット40は、ソースピクセルをフィルタリングする際に使用されるべきすべての周囲ピクセル値を1つずつフェッチし得る。周囲ピクセルは、グラフィックスメモリ14および/またはシステムメモリ10からフェッチされ得る。
ループ制御およびアドレス指定ユニット40は、フェッチされた周囲ピクセル値ならびにソースピクセルをキャッシュ45に記憶し得る。フィルタリングユニット47は、重みテーブルレジスタ41に記憶された対応するフィルタ重みでフィルタカーネル内のピクセル(すなわち、ソースピクセルおよび周囲ピクセル)を乗算するように構成される。乗算の結果は、アキュムレータ49において記憶される。対応するフィルタ重みでピクセル値を乗算した後続の結果は、キャッシュ45に記憶されたすべてのピクセル値がフィルタリングされるまで、現在アキュムレータ49に記憶されている結果に加えられる。アキュムレータ49内の累積された最終結果は次いで、ソースピクセルのフィルタリングされた値として(たとえば、グラフィックスメモリ14に)記憶され得る。
上述のように、図3のテクスチャエンジン39は、本開示のLCHOF技法を実装するように修正されたテクスチャエンジンを表す。1つのそのような修正は、フィルタタイプ、フィルタサイズ、および事前計算されたフィルタ重みを含む、適用されるべきフィルタに関する情報を記憶するように構成され得る重みテーブルレジスタ41の追加である。一例では、重みテーブルレジスタ41内のフィルタタイプ、フィルタサイズ、および事前計算されたフィルタ重みは、グラフィックスドライバ7および/またはソフトウェアアプリケーション24によって設定され得る。すなわち、適用されるべきフィルタリングは、制御ビットを設定し、フィルタ重みを重みテーブルレジスタ41に記憶することによって制御され得る。重みテーブルレジスタ41は、垂直次元および水平次元の2つの値(たとえば、M×N、ここで、Mは水平次元であり、Nは垂直次元である)としてのフィルタサイズ(たとえば、カーネルサイズ)を含み得る。他の例では、重みテーブルレジスタ41は、カーネル内のフィルタ重みの総数を示すフィルタサイズの単一の値を記憶(たとえば、M×Nの積の値を記憶)し得る。この例では、合計フィルタカーネルは方形であると見なされる。重みテーブルレジスタ41に記憶され得るフィルタタイプの制御ビットの一般的な例は、フィルタカーネルが(1)分離可能であるか非分離可能であるか、(2)等方性であるか非等方性であるか、および(3)対称的であるか非対称的であるかを示し得る制御ビットを含む。
分離可能フィルタは、カーネル内の位置ごとのフィルタ重み値が、N次元における重みで乗算されたM次元における重みに等しい、フィルタである。したがって、フィルタリングカーネルが分離可能であることを重みテーブルレジスタ41内の制御ビットが示す場合、より少ないフィルタリング重みが重みテーブルレジスタに記憶される必要がある。すなわち、サイズM*Nのフィルタカーネルの場合、フィルタリングカーネルが分離可能であるという指示は、非分離可能フィルタのためのM*N個の重みではなく、M+N個のフィルタ重みのみが記憶されることを意味する。
重みテーブルレジスタ41が、フィルタが分離可能フィルタであることを示す制御ビットを含む場合、追加の制御ビットは、フィルタが等方性か非等方性かを示すために使用され得る。等方性フィルタは、水平方向の重みおよび垂直方向の重みが分離可能であり、それらの重みが同じである、フィルタである。フィルタが分離可能かつ等方性である場合、重みテーブルレジスタに記憶される必要がある重みの数は、M+N個(分離可能だが、非等方性フィルタ)からM個の重み(分離可能および等方性)に削減され得る。
等方性フィルタと同様に、重みテーブルレジスタ41が、フィルタが分離可能フィルタであることを示す制御ビットを含む場合、追加の制御ビットは、フィルタが対称的であるか非対称的であるかを示すために使用され得る。対称的なフィルタは、中心軸のいずれかの側(水平方向または垂直方向のいずれか)で同じ重みを有する。対称的なフィルタは、等方性または非等方性であり得る。対称的なフィルタの場合、フィルタ重みの典型的な数の半分のみが重みテーブルレジスタ41に記憶される必要がある。たとえば、非等方性であり対称的である分離可能フィルタは、(M+N)/2個のフィルタ重みを記憶する必要がある。等方性であり対称的である分離可能フィルタは、M/2個のフィルタ重みを記憶する必要がある。
本開示における別のフィルタ重み記憶の最適化はサブピクセル解像度に関するものであり、この場合、重みテーブルレジスタ41は、重みセットの半分を記憶するだけでよい。サブピクセルオフセットを使用するときの重みの他方の半分は、記憶された半分から導出され得る。図4は、サブピクセルオフセットを用いたフィルタ重みの導出を示す概念図である。図4では、曲線の高さはフィルタ重みの値を表す。垂直線はテクセルの位置を表す。本質的にテクセルを重み曲線の異なる部分に移動するサブピクセルオフセット値(subpixoffset)が定義され得る。複数のサブピクセルオフセット値は、本質的にフィルタ重みの複数の異なるセットを与えるために、重みテーブルレジスタ41に記憶され得る。
上記で説明したように、いくつかのフィルタタイプの場合、すべてよりも少ない数の必要とされるフィルタ重みは、重みテーブルレジスタ41に記憶され得る。この場合、テクスチャエンジン39は、示されたフィルタタイプに基づいて、重みテーブルレジスタ41に記憶されたフィルタ重みから、追加の数の必要とされるフィルタ重みを導出するように構成され得る。図5は、対称的なフィルタのフィルタ重みをミラーリングするか、または大まかに導出するための技法を示す概念図である。たとえば、垂直軸に対して対称的なフィルタの場合、エリア102および104からのフィルタ重みは垂直軸に対してミラーリングされ得る。別の例として、水平軸に対して対称的なフィルタの場合、エリア106、108および110におけるフィルタ重みは水平軸に対してミラーリングされ得る。
本開示のHOF技法によれば、テクスチャエンジン39のループ制御およびアドレス指定ユニット40のアドレス指定ブロックは、ソースピクセルをフィルタリングするための必要なサンプル(たとえば、周囲ピクセル値)を生成および/またはフェッチするように構成され得る。上記で説明したように、ソースピクセル、またはソースピクセルのロケーションは、シェーダ命令51からテクスチャエンジン39に与えられ得る。ループ制御およびアドレス指定ユニット40は、フィルタタイプおよびフィルタサイズを決定するために、重みテーブルレジスタ41にアクセスするように構成される。ソースピクセルのロケーション、決定されたフィルタタイプ、および決定されたフィルタサイズに基づいて、ループ制御およびアドレス指定ユニット40は、フィルタリングを実行するために必要とされるすべてのサンプル(たとえば、周囲ピクセル)をフェッチする。各サンプルは、一例では4つのピクセルである基本処理ユニットにブレークダウンし得る。
決定されたフィルタおよびフィルタサイズに基づいて、ループ制御およびアドレス指定ユニット40は、決定されたカーネル中心と重みテーブルレジスタ41に示される任意の示されたサブピクセルサポートとに基づいて周囲ピクセルをフェッチする。(たとえば、重みテーブルレジスタ41内の制御ビットによって示される)サブピクセル解像度フィルタリングの場合、ループ制御およびアドレス指定ユニット40は、ピクセル位置に対するソースサンプルの距離がソースサンプル座標を整数座標にスナップすることに起因して変更されるとき、フィルタリング重みに対応するサンプルピクセルのロケーションを決定するように構成され得る。たとえば、図6Aは、1次元において偶数個の重みを有するフィルタカーネルを示す。この例では、ループ制御およびアドレス指定ユニット40は、フィルタ重み(w0〜w3)が(この場合はロケーション4.0における)カーネル中心の両側に均等に分散されるように、ピクセルPの位置を定義し得る。図6Aでは、対称的なフィルタは重みテーブルレジスタ41に示され、したがって、フィルタ重みw0〜w3はカーネル中心のいずれかの側にミラーリングされる。
別の対称的なフィルタの例が図6Bに示されている。この例では、カーネルサイズは、1次元において9個のフィルタ重みを含む。図6Bのカーネル中心は、一意のフィルタ重みw4に対応するロケーション4.5にある。フィルタ重みw0〜w3は、フィルタ中心のいずれかの側にミラーリングされる。サブピクセル解像度サポートの場合、オフセットはカーネル中心に対して定義され得る。この場合、フィルタ重みはカーネル中心の右側にミラーリングされ得る。
図7Aに示すように、ピクセルP'におけるカーネル中心は、サブピクセルオフセット値だけ、(ロケーション4.0における)カーネル中心の左側に移動される。図7Bでは、ピクセルP'は、サブピクセルオフセット値だけ、カーネル中心4の右側に移動される。ピクセルP'の位置はロケーション4.0におけるカーネル中心と対称であるので、図7Bの重みは図7Aの重みに対してミラーリングされる。
要約すると、本開示の技法に従って、GPU12において高次フィルタリングを実行するための方法について説明する。方法は、GPU12によって、ソースピクセルをフィルタリングするためのシェーダ命令51を受け取ることと、GPU12のテクスチャエンジン39によって、シェーダ命令に応答してフィルタを決定することとを含み得る。テクスチャエンジン39は、重みテーブルレジスタ41に記憶された制御ビットからフィルタを決定し得る。テクスチャエンジン39は、決定されたフィルタに基づいて隣接ピクセルを取り出し、決定されたフィルタ、ソースピクセル、および取り出された隣接ピクセルを使用してソースピクセルをフィルタリングするようにさらに構成され得る。
図3に戻って、次にテクスチャエンジン39の重みテーブルレジスタ41の特定の例示的なハードウェア実装形態について説明する。上記で説明したように、重みテーブルレジスタ41は、フィルタタイプ、フィルタサイズ(たとえば、カーネルサイズ)、およびフィルタ重み自体を示す制御ビットを含む複数のレジスタを含み得る。重みテーブルレジスタ41は、GPUドライバ7および/またはCPU6上で実行されるソフトウェアアプリケーション24によってポピュレートされ得る。いくつかの例では、重みテーブルレジスタ41は、GPU12上で実行されるシェーダプログラムによってポピュレートされ得る。
例示的な実装形態では、重みテーブルレジスタ41は、以下のレジスタを含み得る。
1)フィルタタイプレジスタ:フィルタタイプレジスタは、様々なタイプのフィルタを示す制御ビットを含む。たとえば、制御ビットは、フィルタが分離可能であるかどうか、等方性であるかどうか、または対称的であるかどうかを示し得る。フィルタタイプレジスタは、サブピクセルフィルタリングがサポートされるかどうかを示す制御ビットをさらに含み得る。上記で説明したように、あるフィルタタイプは、必要とされるフィルタ重みの一部分のみが必要とされる残りのフィルタ重みをミラーリングするかまたは大まかに導出するために使用され得るので、すべてよりも少ないフィルタ重みが記憶されることを可能にし得る。
2)フィルタサイズレジスタ:フィルタサイズレジスタは、フィルタカーネルのサイズを示す制御ビットを含む。フィルタカーネルのサイズは、(たとえば、UおよびVとして標識された)2つの方向で示され得る。したがって、フィルタカーネルは必ずしも方形ではないが、長方形であってもよい。加えて、いくつかのフィルタ重みをゼロ値にすることによって、他の形のフィルタカーネルが可能である。
3)フィルタ重みレジスタ:フィルタ重みレジスタは、フィルタ重み自体を含む。
ループ制御およびアドレス指定ユニット40は、次のように重みテーブルレジスタ41内の情報を利用するように構成され得る。最初に、ループ制御およびアドレス指定ユニット40は、重みテーブルレジスタ41内の示されたフィルタタイプおよびフィルタサイズを考慮して、テクスチャエンジン39を通る何個のパス(ループ)が必要とされるかを決定するように構成され得る。ループ制御およびアドレス指定ユニット40はまた、重みテーブルレジスタ41からのフィルタサイズおよびフィルタタイプ情報に従って、ループごとにどのピクセルがフェッチされるかを決定するように構成される。
一例では、テクスチャエンジン39は、各ループにおいて4つのピクセル(すなわち、4ピクセル基本処理ユニット)を処理するように構成され得る。他の例示的なテクスチャエンジンは、より多いまたはより少ないピクセルをループごとに処理するように構成され得る。4ピクセル基本処理ユニットの例では、重みテーブルレジスタ41によって示されたフィルタリング動作に関与するすべてのピクセルは、1つまたは複数の4ピクセルブロックにブレークダウンする。キャッシュフェッチの局所性および効率を改善するために、4ピクセルブロックは、図8に示すスキャン順序でフェッチされ得る。図8は、(dp4として標識された)4ピクセルブロックの例示的なフェッチ順序を示し、4ピクセルブロックの第1の行は、第1のdp4から始まってフェッチされる。図8の例では、カーネルサイズは、U方向において20ピクセル幅である。第5のdp4(すなわち、第5の4ピクセルブロック)がフェッチされた後、フェッチされるべき次の4ピクセルブロックは、第5のdp4の真下の行にある。ループ制御およびアドレス指定ユニット40は次いで、反対方向の次の行から(すなわち、右から左に)4ピクセルブロックをフェッチする。ループ制御およびアドレス指定ユニット40によってフェッチされた各4ピクセルブロックは、キャッシュ45に記憶される。キャッシュ45に記憶された4ピクセルブロックは、関連するフィルタ重みを適用するためにフィルタリングユニット47に送られ、次いで、アキュムレータ49は、4ピクセルブロックに適用された重みの結果を以前のフィルタリング結果の合計に加える。
上記で説明したように、(たとえば、4ピクセルブロックを処理する)テクスチャエンジン39のループごとの重みは、重みテーブルレジスタ41に記憶された重み値から導出され得る、あらかじめ定義された重みテーブルから選択される。ハードウェアコストを節約し、それらの重みをロードする効率を改善するために、重みテーブルレジスタ41に記憶された重み値は、フィルタタイプ(たとえば、対称的/分離可能/等方性/サブピクセル精度)に従って圧縮され得る。次いで、ループ制御およびアドレス指定ユニット40は、(たとえば、図5に関して上記で説明したような)特定のフィルタタイプに必要とされるすべてのフィルタ重みを導出し得る。
いくつかの例では、フィルタリングの品質を改善するために、重みテーブルレジスタ41に事前に記憶されたフィルタ重みは、フィルタリング前にアップスケールされ得る。フィルタリングの後、完全なフィルタリングされた値は次いでスケールダウンされ得る。たとえば、すべての関与するピクセルを平均化することによって結果を生成する16*16カーネルは、各ピクセルの重みを256で除算する(すなわち、1/(16*16)=1/256)。アップスケーリングを利用することによって、各重みは、中間結果に対するより高い精度を得るために、1に調整され得る。最終結果は、アキュムレータ49において1/256だけスケールダウンされる。
他の例では、本開示のHOF技法は、対称的なフィルタのわずかな定義上の変更を伴って、マルチサンプルアンチエイリアシング(MSAA:multi-sample anti-aliasing)サーフェスに適用され得る。MSAAサーフェスの場合、各ピクセル値は複数のサブサンプルから構成され得る。この例では、MSAAサーフェスに使用されるフィルタ重みは、非分離可能であり得るが、依然として対称的であり得る。MSAAサーフェス上でHOFを適用するとき、各フィルタ重みは、MSAAサーフェス内のサブサンプルのうちの1つに対応する。U次元重みは、MSAAサーフェス内のサンプルの数でカーネルサイズを乗算することによって拡張され得る。V次元重みは、非MSAAの場合と同じである。
図9は、高次フィルタリングを実行するために修正テクスチャエンジン39を使用するための本開示の技法の1つの利点を示す概念図である。図9に示すように、完全に専用の固定パイプラインを使用して高次フィルタリングを実行するために、ループ制御、アドレス指定、キャッシュ、フィルタリング、および累積のための完全に新しいハードウェアが必要とされる。代わりに、本開示の技法による既存の修正テクスチャエンジンを使用して、高次フィルタリングは最小の追加のハードウェア(すなわち、主に重みテーブルレジスタ41の追加)で達成され得る。
図10は、高次フィルタリングを実行するために単一のシェーダ命令および修正テクスチャエンジン39を使用するための本開示の技法の別の利点を示す概念図である。高次フィルタリングのための従来のシェーダベースの解決策(すなわち、本開示のHOF技法を用いない)では、各ピクセルフェッチ、重み決定、ピクセル/重み乗算、および蓄積を実行するために複数のシェーダ命令が必要とされた。したがって、中間結果(すなわち、ピクセル/重み乗算および累積)のフェッチおよび記憶のためのメモリアクセスは、広範囲のメモリロケーションにおいて大量のメモリを利用した。しかしながら、本開示のHOF技法を使用すると、メモリアクセスは隣接ピクセルをフェッチすることに限定され、隣接ピクセルはメモリ内で密接に記憶される可能性が高い。これは、フィルタリングのすべての中間最終結果がテクスチャエンジン39内のローカルキャッシュに記憶されるからである。したがって、本開示の技法は、より効率的なメモリ使用を実現する。
本開示の別の態様では、ピクセルのルーマ値を、RGBA(赤、緑、青、アルファ(深度))ピクセル値データ構造のすべての4つの値をフィルタリングするように構成されたフィルタフレームワークにパッキングすることによって、いくつかの使用事例についてフィルタリングスループットが改善され得る。
図11は、畳み込みフィルタリングの例(たとえば、高次畳み込みフィルタリング)を示す概念図であり、それによって、テクスチャエンジン(たとえば、テクスチャエンジン39)は、フィルタリングをピクセル値のR成分、G成分、B成分、およびA成分の各々に同時に適用するように構成される。すなわち、テクスチャエンジン39は、RGBA色フォーマットデータ構造を使用して高次フィルタリングを実行するように構成され得る。図11でわかるように、ピクセルP0〜P3はそれぞれ、R値、G値、B値、およびA値から構成され得る。2×2畳み込みを実行するためにフィルタ重み200(W0〜W3)をピクセルP0〜P3に適用するとき、重みW0〜W3の各々は、ピクセルごとのそれぞれのR値、G値、B値、およびA値の各々に等しく適用される。すなわち、R成分のフィルタリングされた値(RCONV)を生成するために、重みW0がピクセルP0のR0に適用され、重みW1がピクセルP1のR1に適用され、重みW2がピクセルP2のR2に適用され、重みW3がピクセルP3のR3に適用される。同様に、G成分のフィルタリングされた値(GCONV)を生成するために、重みW0がピクセルP0のG0に適用され、重みW1がピクセルP1のG1に適用され、重みW2がピクセルP2のG2に適用され、重みW3がピクセルP3のG3に適用される。このプロセスは、B(BCONV)成分およびA(ACONV)成分ごとのフィルタリングされた値を生成するために繰り返される。
図11に示す技法は、RGBAピクセルの各色成分の並列処理を実現する。そのような処理構造は、入力ピクセル値とフィルタリングされた出力ピクセル値の両方がRGBA色フォーマットであるときにうまく機能する。しかしながら、ビデオデータなどの何らかのアプリケーションでは、ピクセル値はRGBA色フォーマットに記憶されず、むしろ(たとえば、Yと指定された)ルーマ値および(たとえば、UおよびVと指定された、またはCrおよびCbと指定された)1つまたは複数のクロマ成分からなる色フォーマットに記憶される。ピクセル値がそのようなフォーマットに記憶されるとき、各ピクセルのルーマ成分のみをフィルタリングすることが望ましい場合がある。各ピクセルのルーマ成分のみがフィルタリングされる場合、テクスチャエンジン39の並列処理構造は、G成分、B成分およびA成分のフィルタリング用に指定されたハードウェアを利用しない(すなわち、R成分のフィルタリング用に指定されたハードウェアがルーマ成分に使用されると想定する)。
テクスチャエンジン39が4つの色成分(たとえば、RGBA)を同時にフィルタリングするように構成され得ると仮定すると、本開示は、4つのピクセルのルーマ成分を1つのRGBA色フォーマットデータ構造にパッキングすることによって、YUV色フォーマットまたはYCrCb色フォーマットに記憶されたピクセルのルーマ成分をフィルタリングするスループットを増加する技法を提案する。このようにして、4つのピクセルのルーマ成分は、同時にフィルタリングされ得る。いくつかの例では、フィルタリングされるべきピクセルは、ルーマ成分を含む色フォーマットにすでに記憶されている。他の例では、GPU12またはCPU6は、RGBAフォーマットからルーマ成分(たとえば、YUVまたはYCrCb)を含むフォーマットにピクセル値を変換するように構成され得る。本開示のパッキング技法は、上記で説明した(たとえば、フィルタタイプおよび重みが、単一のシェーダ命令に基づいて重みテーブルレジスタから取り出される)HOF技法とともに使用され得る。しかしながら、本開示のパッキング技法は、フィルタ重みがGPU12によって計算/導出されるフィルタリング技法を含む他のフィルタリング技法とともに使用され得る。
図12は、ルーマ値に対する畳み込みフィルタリング技法を示す概念図である。図12に示すように、2×2畳み込みフィルタリングは、フィルタ重みW0〜W3 200を使用してルーマ値Y0、Y1、Y2およびY3の各々に適用され得る。ルーマ値Y0〜Y3は、4つのそれぞれのソースピクセルのルーマ成分である。フィルタリングされた値Y0CONVを生成するために、ソースピクセルY0ならびに隣接ピクセルY1、Y8およびY9からなるブロック300が使用される。Y0ルーマ値のフィルタリングされた値(Y0CONV)を生成するために、重みW0がY0に適用され、重みW1がY1に適用され、重みW2がY8に適用され、重みW3がY9に適用される。同様に、フィルタリングされた値Y1CONVを生成するために、ソースピクセルY1ならびに隣接ピクセルY2、Y9およびY10からなるブロック302が使用される。Y1ルーマ値のフィルタリングされた値(Y1CONV)を生成するために、重みW0がY1に適用され、重みW1がY2に適用され、重みW2がY9に適用され、重みW3がY10に適用される。
図13は、本開示のルーマパッキング技法を示す概念図である。図13では、ルーマ値Y0〜Y15のブロック300は、RGBA色フォーマットデータ構造306、308、310、312にパッキングされる。データ構造の色フォーマットデータ構造306、308、310、312の例は、GPU12によって(たとえば、GPU12のテクスチャエンジン39によって)処理され得る。典型的には、RGBA色フォーマットデータ構造306、308、310、312は、4つのピクセルのRGBA成分値を含む。上記で説明した技法を使用して、テクスチャエンジン39は、1つのピクセルのすべてのRGBA色成分を同時にフィルタリングするように構成される。本開示のパッキング技法によれば、4つの異なるピクセルの4つのルーマ値は、4つの異なるピクセルのルーマ値がテクスチャエンジン39によって同時にフィルタリングされ得るように、単一のRGBA色フォーマットデータ構造にパッキングされ得る。
図13に示すように、ルーマ値Y0、Y1、Y8、およびY9からなるブロック300は、(図11のピクセルP0に対応する)RGBA色フォーマットデータ構造306および(図11のピクセルP2に対応する)RGBA色フォーマットデータ構造308にパッキングされる。より具体的には、ルーマ値Y0はRGBA色フォーマットデータ構造306のR0メモリロケーションにパッキングされ、ルーマ値Y1はRGBA色フォーマットデータ構造306のG0メモリロケーションにパッキングされ、ルーマ値Y8はRGBA色フォーマットデータ構造308のR2メモリロケーションにパッキングされ、ルーマ値Y9はRGBA色フォーマットデータ構造308のG2メモリロケーションにパッキングされる。
しかしながら、ルーマ値が図13に示すようにパッキングされた場合、不正確な畳み込みフィルタリングが生じ得る。たとえば、図13に示すように、R色成分に対応する4つのルーマ値(すなわち、Y0、Y4、Y8、Y12)が一緒にフィルタリングされる。代わりに、図12に示すように、ルーマ成分Y0、Y1、Y8およびY9が一緒にフィルタリングされるべきである。
正確なルーマ成分をフィルタリングするために、ルーマ値は、図14に示すように、さらに並べ替えられる(スウィズルされる(swizzled)とも呼ばれる)場合がある。図14に示すように、(図13の場合のように)行ごとにルーマ値をパッキングするのではなく、ルーマ値は2×2ブロックごとにパッキングされる。他のパッキングおよびスウィズリング(swizzling)構成は、所望のフィルタリングのタイプに応じて使用され得る。図14に示すように、ルーマ成分Y0、Y1、Y8、およびY9は、それぞれデータ構造356、360、358および362のR成分にパッキングされる。同様に、ルーマ成分Y1、Y2、Y9、およびY10は、それぞれデータ構造356、360、358および362のG成分にパッキングされる。ルーマ成分Y2、Y3、Y10、およびY11は、それぞれデータ構造356、360、358および362のB成分にパッキングされる。ルーマ成分Y3、Y4、Y11、およびY12は、それぞれデータ構造356、360、358および362のA成分にパッキングされる。
図14に示す技法に従ってルーマ値がパッキングされると、畳み込みフィルタリングは、図11で説明したのと同じ方法で、パッキングされたRGBA色フォーマットデータ構造356、358、360、および362に適用され得る。図15は、本開示のルーマパッキング技法を使用したルーマベースのピクセルフォーマットのための畳み込みフィルタリング技法を示す概念図である。たとえば、図15は図11と同様であるが、図11はRGBAを用いた例を示しており、図15はルーマ値を用いた例を示している。本開示のルーマパッキング技法を使用すると、ルーマ値をフィルタリングする4倍のスループットが達成され得る。
図16は、本開示の例示的な方法を示すフローチャートである。図16の方法は、テクスチャエンジン39を含む、GPU12の1つまたは複数のハードウェアユニットによって実施され得る。図16は、GPU(たとえば、GPU12)において高次フィルタリングを実行するための方法を示す。方法は、GPU12によって、ソースピクセルをフィルタリングするためのシェーダ命令を受け取ること(1500)を含む。本開示の一例では、シェーダ命令は、フィルタリングされるべきソースピクセルを識別する単一のシェーダ命令である。GPU12は次いで、シェーダ命令に応答してフィルタを決定し(1510)、決定されたフィルタに基づいて隣接ピクセルを取り出し(1520)得る。GPU12のテクスチャエンジン39は、隣接ピクセルを取り出すように構成され得る。テクスチャエンジン39は次いで、決定されたフィルタ、ソースピクセル、および取り出された隣接ピクセルを使用してソースピクセルをフィルタリングし(1530)得る。
本開示の一例では、GPU12は、重みテーブルレジスタからフィルタタイプを取り出し、重みテーブルレジスタからフィルタカーネルサイズを取り出し、フィルタタイプおよびフィルタカーネルサイズに基づいて重みテーブルレジスタから事前計算されたフィルタ重みを取り出すことによって、フィルタを決定するように構成され得る。本開示の別の例では、GPU12は、フィルタカーネルサイズに基づいて隣接ピクセルを取り出すように構成され得る。
本開示の一例では、重みテーブルレジスタ内のフィルタタイプは、分離可能フィルタの指示、等方性フィルタの指示、サブピクセルフィルタの指示、および対称的なフィルタの指示のうちの1つまたは複数を含み得る。本開示の別の例では、重みテーブルレジスタから取り出された事前計算されたフィルタ重みの総数は、分離可能フィルタの指示、等方性フィルタの指示、サブピクセルフィルタの指示、および対称的なフィルタの指示のうちの1つまたは複数に依存する。この点について、GPU12は、取り出された事前計算されたフィルタ重みの総数がカーネルサイズよりも小さい場合、取り出された事前計算されたフィルタ重みおよび決定されたフィルタタイプに基づいて追加のフィルタ重みを導出するようにさらに構成され得る。
本開示の別の例では、GPU12は、畳み込みフィルタリングをRGBA色フォーマットデータ構造におけるソースピクセルおよび取り出された隣接ピクセルに適用するように構成され得る。さらに、この点について、GPU12は、RGBA色フォーマットデータ構造においてソースピクセルおよび取り出された隣接ピクセルのルーマ値をパッキングするように構成され得、RGBA色フォーマットデータ構造ごとに4つのルーマ値がフィルタリングされる。本開示の別の例では、GPU12は、RGBA色フォーマットからルーマ値を使用する色フォーマットにソースピクセルおよび取り出された隣接ピクセルを変換するように構成され得る。
図17は、本開示の例示的な方法を示すフローチャートである。図17の方法は、テクスチャエンジン39を含む、GPU12の1つまたは複数のハードウェアユニットによって実施され得る。図17は、GPU(たとえば、GPU12)におけるフィルタリングの方法を示す。GPU12は、ソースピクセルをフィルタリングするための命令を受け取る(1600)ように構成され得る。本開示の一例では、命令は単一のシェーダ命令である。GPU12は、命令に基づいて隣接ピクセルを取り出し(1610)、RGBA色フォーマットデータ構造においてソースピクセルおよび取り出された隣接ピクセルのルーマ値をパッキングする(1620)ようにさらに構成され得る。(たとえば、テクスチャエンジン39を有する)GPU12は、RGBA色フォーマットデータ構造を使用してソースピクセルおよび取り出された隣接ピクセルのルーマ値に対してフィルタリングを実行する(1630)ようにさらに構成され得、RGBA色フォーマットデータ構造ごとに4つのルーマ値がフィルタリングされる。本開示の一例では、フィルタリングを実行することは、畳み込みフィルタリングを実行することを含む。
本開示の一例では、GPU12は、命令に基づいてフィルタ重みを取り出すようにさらに構成される。本開示の別の例では、GPU12は、命令に基づいてフィルタ重みを生成するように構成される。本開示の別の例では、GPU12は、RGBA色フォーマットからルーマ値を使用する色フォーマットにソースピクセルおよび取り出された隣接ピクセルを変換するように構成される。本開示の別の例では、GPU12は、単一のシェーダ命令に応答してフィルタを決定するように構成される。本開示の別の例では、GPU12は、重みテーブルレジスタからフィルタタイプを取り出し、重みテーブルレジスタからフィルタカーネルサイズを取り出し、フィルタタイプおよびフィルタカーネルサイズに基づいて重みテーブルレジスタから事前計算されたフィルタ重みを取り出すように構成される。
1つまたは複数の例では、上記で説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、非一時的コンピュータ可読媒体を備える製造品上の1つまたは複数の命令またはコードとして記憶され得る。コンピュータ可読媒体は、コンピュータデータ記憶媒体を含み得る。データ記憶媒体は、本開示で説明する技法を実装するための命令、コードおよび/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備えることができる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生するが、ディスク(disc)はレーザーを用いてデータを光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
コードは、1つまたは複数のDSP、汎用マイクロプロセッサ、ASIC、FPGA、または他の等価の集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサによって実行され得る。加えて、いくつかの態様では、本明細書で説明する機能は、専用ハードウェアモジュールおよび/またはソフトウェアモジュール内で提供され得る。また、技法は、1つまたは複数の回路または論理要素において完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。開示する技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットについて本開示で説明したが、これらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニットにおいて結合されてもよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、上記で説明したような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されてもよい。
様々な例について説明してきた。これらおよび他の例は、以下の特許請求の範囲内に入る。