特許 5928914 グラフィックス処理装置およびグラフィックス処理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5928914

(24)【登録日】2016年5月13日

(45)【発行日】2016年6月1日

(54)【発明の名称】グラフィックス処理装置およびグラフィックス処理方法

(51)【国際特許分類】

   G06T 15/04 20110101AFI20160519BHJP

   H04N 1/41 20060101ALI20160519BHJP

   H04N 19/93 20140101ALI20160519BHJP

【ＦＩ】

   G06T15/04

   H04N1/41 Z

   H04N19/93

【請求項の数】5

【全頁数】16

(21)【出願番号】特願2014-54021(P2014-54021)

(22)【出願日】2014年3月17日

(65)【公開番号】特開2015-176492(P2015-176492A)

(43)【公開日】2015年10月5日

【審査請求日】2015年3月18日

(73)【特許権者】

【識別番号】310021766

【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(74)【代理人】

【識別番号】100109047

【弁理士】

【氏名又は名称】村田 雄祐

(74)【代理人】

【識別番号】100109081

【弁理士】

【氏名又は名称】三木 友由

(74)【代理人】

【識別番号】100134256

【弁理士】

【氏名又は名称】青木 武司

(72)【発明者】

【氏名】佐藤 仁

(72)【発明者】

【氏名】冨永 丈博

(72)【発明者】

【氏名】鹿子木 朋睦

【審査官】 千葉 久博

(56)【参考文献】

【文献】 特開２００６−２２１４１８（ＪＰ，Ａ）

【文献】 特開２００４−１１０８５０（ＪＰ，Ａ）

【文献】 特開２０００−５７３６９（ＪＰ，Ａ）

【文献】 特開平１０−２４７１３８（ＪＰ，Ａ）

【文献】 特開平１０−５６３８７（ＪＰ，Ａ）

【文献】 特開平８−１６３５６０（ＪＰ，Ａ）

【文献】 特開平５−１７６１８７（ＪＰ，Ａ）

【文献】 特表２０１２−５０４９１８（ＪＰ，Ａ）

【文献】 米国特許第０７０５００６３（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｔ １５／００−１５／８７

Ｈ０４Ｎ １／４１−１／４１９

Ｈ０４Ｎ １９／００−１９／９８

Ｇ０６Ｔ １／００，１９／００−１９／２０

Ｇ０９Ｇ ５／００−５／４２

(57)【特許請求の範囲】

【請求項1】

メインメモリとグラフィックスプロセッシングユニットとを含むグラフィックス処理装置であって、
前記グラフィックスプロセッシングユニットは、圧縮テクスチャのランレングス伸張を実行するランレングス伸張部と、ランレングス伸張されたテクスチャを逆空間周波数変換することによりテクスチャを復元する逆空間周波数変換部とを含み、
前記メインメモリは、復元されたテクスチャを部分的にキャッシュするテクスチャプールを含み、
前記ランレングス伸張部は、コンピュートシェーダの複数のスレッドによって実行され、各スレッドが前記圧縮テクスチャの空間周波数変換ブロック内で相対的に同じ位置の空間周波数変換係数のランレングス伸張を行うことを特徴とするグラフィックス処理装置。

【請求項2】

前記圧縮テクスチャは前記メインメモリに格納され、前記ランレングス伸張部は前記メインメモリから前記圧縮テクスチャを読み出すことを特徴とする請求項１に記載のグラフィックス処理装置。

【請求項3】

前記グラフィックスプロセッシングユニットによりランレングス伸張の前に、前記圧縮テクスチャを伸張する伸張回路をさらに備え、
前記ランレングス伸張部は、前記伸張回路により伸張されたテクスチャのランレングス伸張を実行することを特徴とする請求項１または２に記載のグラフィックス処理装置。

【請求項4】

メインメモリとグラフィックスプロセッシングユニットとを含むグラフィックス処理装置におけるグラフィックス処理方法であって、
グラフィックスプロセッシングユニットが、コンピュートシェーダによって、圧縮テクスチャのランレングス伸張を実行し、ランレングス伸張されたテクスチャを逆空間周波数変換することによりテクスチャを復元し、テクスチャを部分的にキャッシュする前記メインメモリ内のテクスチャプールに復元されたテクスチャを格納し、
前記ランレングス伸張は、コンピュートシェーダの複数のスレッドによって実行され、各スレッドが前記圧縮テクスチャの空間周波数変換ブロック内で相対的に同じ位置の空間周波数変換係数のランレングス伸張を行うことを特徴とするグラフィックス処理方法。

【請求項5】

圧縮テクスチャのランレングス伸張を実行するステップと、ランレングス伸張されたテクスチャを逆空間周波数変換することによりテクスチャを復元し、テクスチャを部分的にキャッシュするテクスチャプールに復元されたテクスチャを格納するステップとをグラフィックスプロセッシングユニットのコンピュートシェーダに実行させ、
前記ランレングス伸張は、コンピュートシェーダの複数のスレッドによって実行され、各スレッドが前記圧縮テクスチャの空間周波数変換ブロック内で相対的に同じ位置の空間周波数変換係数のランレングス伸張を行うことを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、圧縮テクスチャを伸張するグラフィックス処理技術に関する。

【背景技術】

【0002】

パーソナルコンピュータやゲーム専用機において、高品質な３次元コンピュータグラフィックスを用いたゲームやシミュレーションなどのアプリケーションを実行したり、実写とコンピュータグラフィックスを融合させた映像コンテンツの再生を行うなど、高画質のグラフィックスの利用が広がっている。

【0003】

一般に、グラフィックス処理は、ＣＰＵとグラフィックスプロセッシングユニット（ＧＰＵ）が連携することで実行される。ＣＰＵが汎用的な演算を行う汎用プロセッサであるのに対して、ＧＰＵは高度なグラフィックス演算を行うための専用プロセッサである。ＣＰＵはオブジェクトの３次元モデルにもとづいて投影変換などのジオメトリ演算を行い、ＧＰＵはＣＰＵから頂点データなどを受け取ってレンダリングを実行する。ＧＰＵはラスタライザやピクセルシェーダなどの専用ハードウェアから構成され、パイプライン処理でグラフィックス処理を実行する。最近のＧＰＵには、プログラマブルシェーダと呼ばれるように、シェーダ機能がプログラム可能なものもあり、シェーダプログラミングをサポートするために、一般にグラフィックスライブラリが提供されている。

【発明の概要】

【発明が解決しようとする課題】

【0004】

グラフィックス処理では、オブジェクトの表面の質感を表現するためにテクスチャをオブジェクトの表面に貼り付けるテクスチャマッピングが行われる。ゲームなどのアプリケーションで利用される画像の高精細化にともない、テクスチャも高解像度のデータが利用されるようになり、テクスチャデータは大容量化している。たとえば、ゲームで利用されるテクスチャはＧｉＢ（ギビバイト）のオーダーであり、必要なテクスチャデータをすべてメモリ上に格納することは困難である。

【0005】

そこで非圧縮テクスチャまたはＧＰＵが直接扱える低圧縮テクスチャをハードディスクなどの記憶装置に格納しておき、必要に応じてメモリ上のテクスチャバッファにロードして描画に用いることが行われている。ハードディスクからテクスチャをロードするのに要する時間は通常数十ミリ秒から時には数秒になることもあり、安定しない。そのため、ハードディスクからのテクスチャのロードが間に合わなかった場合、本来表示したいテクスチャが利用できないという問題が生じる。

【0006】

一方、高圧縮テクスチャであれば、メインメモリ容量を上回るテクスチャであってもメモリに保持することができ、ハードディスクからのロードなしにテクスチャを扱うことができるようになる。しかし、この場合、高圧縮テクスチャは一般にＧＰＵが直接扱えるものでないため、高圧縮テクスチャをリアルタイムで伸張するための専用ハードウェアが必要になる。専用ハードウェアが利用できなければ、ＣＰＵで圧縮テクスチャを伸張してテクスチャバッファに展開することになるが、この場合は伸張に時間がかかり、描画をリアルタイムで行うことが難しくなる。

【0007】

本発明はこうした課題に鑑みてなされたものであり、その目的は、圧縮テクスチャを効率良く伸張することのできるグラフィックス処理技術を提供することにある。

【課題を解決するための手段】

【0008】

上記課題を解決するために、本発明のある態様のグラフィックス処理装置は、メインメモリとグラフィックスプロセッシングユニットとを含むグラフィックス処理装置であって、前記グラフィックスプロセッシングユニットは、圧縮テクスチャのランレングス伸張を実行するランレングス伸張部と、ランレングス伸張されたテクスチャを逆空間周波数変換することによりテクスチャを復元する逆空間周波数変換部とを含む。前記メインメモリは、復元されたテクスチャを部分的にキャッシュするテクスチャプールを含む。

【0009】

本発明の別の態様は、グラフィックス処理方法である。この方法は、メインメモリとグラフィックスプロセッシングユニットとを含むグラフィックス処理装置におけるグラフィックス処理方法であって、グラフィックスプロセッシングユニットが、コンピュートシェーダによって、圧縮テクスチャのランレングス伸張を実行し、ランレングス伸張されたテクスチャを逆空間周波数変換することによりテクスチャを復元し、テクスチャを部分的にキャッシュする前記メインメモリ内のテクスチャプールに復元されたテクスチャを格納する。

【0010】

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。

【発明の効果】

【0011】

本発明によれば、圧縮テクスチャを効率良く伸張することができる。

【図面の簡単な説明】

【0012】

【図1】ある実施の形態に係るグラフィックス処理装置の構成図である。

【図2】図２（ａ）〜図２（ｃ）は、ミップマップテクスチャを説明する図である。

【図3】本実施の形態のＰＲＴの仕組みを説明する図である。

【図4】図４（ａ）〜図４（ｅ）は、ランレングス圧縮されたテクスチャのデータ量を説明する図である。

【図5】図５（ａ）〜図５（ｃ）は、本実施の形態のランレングス圧縮および伸張を説明する図である。

【図6】本実施の形態のランレングス伸張の流れを説明するフローチャートである。

【図7】比較のため、分岐先に偏りがない場合のスレッドの実行過程を説明する図である。

【図8】分岐先に偏りがある場合のスレッドの実行過程を説明する図である。

【図9】別の実施の形態に係るグラフィックス処理装置の構成図である。

【図10】図１０（ａ）〜図１０（ｆ）は、Ｚｌｉｂ圧縮されたテクスチャのデータ量を説明する図である。

【図11】図１１（ａ）および図１１（ｂ）は、本実施の形態においてテクスチャをランレングス圧縮する利点を説明する図である。

【図12】本実施の形態のグラフィックス処理装置による圧縮テクスチャの伸張処理の性能を説明する図である。

【発明を実施するための形態】

【0013】

（第１の実施の形態）
図１は、第１の実施の形態に係るグラフィックス処理装置の構成図である。グラフィックス処理装置は、メインプロセッサ１００、グラフィックスプロセッシングユニット（ＧＰＵ）２００、およびメインメモリ３００を含む。

【0014】

メインプロセッサ１００は、単一のメインプロセッサであってもよく、複数のプロセッサを含むマルチプロセッサシステムであってもよく、あるいは、複数のプロセッサコアを１個のパッケージに集積したマルチコアプロセッサであってもよい。メインプロセッサ１００はバスを介してメインメモリ３００に対してデータを読み書きすることができる。

【0015】

ＧＰＵ２００は、グラフィックプロセッサコアを搭載したグラフィックチップであり、バスを介してメインメモリ３００に対してデータを読み書きすることができる。

【0016】

メインプロセッサ１００とＧＰＵ２００は、バスで接続されており、メインプロセッサ１００とＧＰＵ２００は互いにバスを介してデータをやりとりすることができる。

【0017】

同図は、グラフィックス処理の中で特にテクスチャ処理に関する構成を図示しており、それ以外の処理に関する構成は省略している。

【0018】

メインメモリ３００のメモリ領域はＧＰＵ２００からアクセスできるようにＧＰＵ２００が参照するアドレス空間にメモリマッピングされており、ＧＰＵ２００は、メインメモリ３００からテクスチャデータを読み取ることができる。テクスチャデータは、ＰＲＴ（Partially Resident Textures）と呼ばれる方法を用いて、部分的にメインメモリ３００にキャッシュされる。

【0019】

メインプロセッサ１００は、グラフィックス演算部２０およびＰＲＴ制御部１０を含む。グラフィックス演算部２０は、ＧＰＵ２００のグラフィックス処理部５０からテクスチャの詳細度を示すＬＯＤ（level of detail）値を受け取り、ＰＲＴ制御部１０にＬＯＤ値を渡す。ＰＲＴ制御部１０は、グラフィックス処理部５０から受け取ったＬＯＤ値にもとづいて、今後必要となるであろうミップマップテクスチャを算出し、テクスチャプールであるＰＲＴキャッシュ３２０への展開を指示したり、使わなくなったページをはがしたりすることでＰＲＴのマッピングを更新する。

【0020】

図２（ａ）〜図２（ｃ）は、ミップマップテクスチャを説明する図である。ミップマップテクスチャは、詳細度（ＬＯＤ）に応じて解像度を異ならせた複数のテクスチャである。図２（ａ）のミップマップテクスチャ３４０は、高解像度のテクスチャである。図２（ｂ）のミップマップテクスチャ３４２は、図２（ａ）の高解像度のミップマップテクスチャ３４０の縦、横のサイズをそれぞれ１／２にした、中解像度のテクスチャである。図２（ｃ）のミップマップテクスチャ３４４は、図２（ｂ）の中解像度のミップマップテクスチャ３４２の縦、横のサイズをそれぞれ１／２にした、低解像度のテクスチャである。

【0021】

図１に戻り、ＰＲＴ制御部１０は、グラフィックス演算部２０に指定された詳細度のミップマップテクスチャを読み出すようにＧＰＵ２００に指示する。より具体的には、ＰＲＴ制御部１０は、ＧＰＵ２００のランレングス伸張部３０および逆離散コサイン変換部４０を制御し、また、メインメモリ３００に格納されたＰＲＴキャッシュ３２０のスワップイン、スワップアウトを制御する。

【0022】

ＧＰＵ２００は、ランレングス伸張部３０、ＩＤＣＴ部４０、およびグラフィックス処理部５０を含む。

【0023】

ランレングス伸張部３０は、ＰＲＴ制御部１０から指定された詳細度に対応する圧縮テクスチャ３１０をメインメモリ３００から読み出し、圧縮テクスチャ３１０をランレングス伸張し、ＤＣＴブロックリングバッファ８０に格納する。

【0024】

ＩＤＣＴ部４０は、ＤＣＴブロックリングバッファ８０に格納されたランレングス伸張後のテクスチャのＤＣＴブロックを逆離散コサイン変換し、ＰＲＴキャッシュ３２０に格納する。

【0025】

グラフィックス処理部５０は、ＰＲＴキャッシュ３２０から必要なミップマップテクスチャを読み出す。ＰＲＴキャッシュ３２０は、テクスチャを部分的にキャッシュするテクスチャタイルプールであり、必要なテクスチャをスワップインし、不要なものはスワップアウトする。

【0026】

図３は、本実施の形態のＰＲＴの仕組みを説明する図である。

【0027】

仮想メモリ上にはミップマップテクスチャ３４０、３４２、３４４の領域が配置される。テクスチャの領域を一定のサイズのチャンクに分け、ページテーブル３３０を用いて、必要なテクスチャ領域だけをテクスチャタイルプール３６０に格納する。ここで、テクスチャは圧縮テクスチャ３１０としてメインメモリ３００に存在しているため、テクスチャタイルプール３６０にテクスチャ領域をキャッシュする際、圧縮テクスチャ３１０を伸張する処理が必要になる。ＰＲＴ制御部１０は、グラフィックス処理部５０からの要求に従い、ランレングス伸張部３０およびＩＤＣＴ部４０を制御して、必要に応じて圧縮テクスチャ３１０を伸張させる。

【0028】

同図の例では、高解像度のミップマップテクスチャ３４０のチャンク３５２、中解像度のミップマップテクスチャ３４２のチャンク３５８は、それぞれページテーブル３３０のページ３３２、３３８に対応づけられており、物理メモリがテクスチャタイルプール３６０からマップされている。

【0029】

他方、高解像度のミップマップテクスチャ３４０のチャンク３５４、中解像度のミップマップテクスチャ３４２のチャンク３５６は、それぞれページテーブル３３０のページ３３４、３３６に対応づけられているが、いずれも物理メモリがまだテクスチャタイルプール３６０からマップされていない。この場合、前述のように、ＰＲＴ制御部１０は、グラフィックス処理部５０から受け取ったＬＯＤ値にもとづいて必要なテクスチャがテクスチャタイルプール３６０にあるように制御し、テクスチャタイルプール３６０の物理メモリが割り当てられ、圧縮テクスチャ３１０から必要なテクスチャデータが伸張されてテクスチャタイルプール３６０に格納される。一方、グラフィックス処理部５０は、メインプロセッサ１００を介することなく、自分自身が計算したＬＯＤ値を使ってミップマップテクスチャをテクスチャタイルプール３６０から読み出す。このとき、もし計算したＬＯＤ値に対応するミップマップテクスチャがテクスチャタイルプール３６０に存在しない場合は、グラフィックス処理部５０はフォールバックして、要求する詳細度を下げ、解像度の低いミップマップテクスチャをテクスチャタイルプール３６０から読み出し、描画する。

【0030】

図４（ａ）〜図４（ｅ）は、ランレングス圧縮されたテクスチャのデータ量を説明する図である。図４（ａ）に示すように、元のテクスチャデータがＲＧＢ３２ビットフォーマットで、たとえば１６Ｍｉｂ（メビバイト）あるとする。図４（ｂ）は、ＢＣ５またはＢＣ７と呼ばれるテクスチャ圧縮方式により圧縮されたテクスチャであり、元のテクスチャデータに比べておよそ１／４の圧縮率であり、品質を比較的良好に保ったまま、４ＭｉＢまでデータ量を削減できる。品質が比較的低くなってもよいのであれば、図４（ｃ）のように、ＢＣ１またはＤＸＴ１と呼ばれるテクスチャ圧縮方式により圧縮されたテクスチャを利用してもよく、この場合、元のテクスチャデータに比べておよそ１／８の圧縮率であり、２ＭｉＢまでデータ量を削減できる。図４（ａ）〜図４（ｃ）はいずれもＧＰＵ２００が直接扱うことのできるテクスチャフォーマットである。

【0031】

他方、ＧＰＵ２００が直接扱えなくなるが、図４（ｄ）のようにＪＰＥＧにより圧縮されたテクスチャを利用すれば、元のテクスチャデータに比べておよそ１／２０の圧縮率が得られ、０．５〜１ＭｉＢまでデータ量を削減できる。この場合、ＧＰＵ２００のコンピュートシェーダではＪＰＥＧ伸張のような複雑なアルゴリズムを実行することは非効率であり、ＪＰＥＧ伸張を行うことのできる専用ハードウェアがなければ、リアルタイムで圧縮テクスチャを伸張してグラフィックス処理に利用することは難しい。

【0032】

それに対して、図４（ｅ）に示すように、離散コサイン変換（ＤＣＴ）とランレングス（Run Length）圧縮を行えば、およそ１／１０の圧縮率が得られ、１〜２ＭｉＢまでデータ量を削減できる。ここまで高圧縮されると、圧縮テクスチャ３１０はメインメモリ３００に常駐させることが可能になる。ＧＰＵ２００は、メインメモリ３００から圧縮テクスチャ３１０を読み出し、コンピュートシェーダによって、リアルタイムでランレングス伸張および逆離散コサイン変換（ＩＤＣＴ）を実行してテクスチャを復元することが可能である。

【0033】

ＪＰＥＧ圧縮されたテクスチャは、ＧＰＵ２００が直接利用することができないため、ＪＰＥＧデコーダによっていったん復号する必要がある。ＪＰＥＧのコーデックが搭載されたグラフィックス装置であれば、ＪＰＥＧ圧縮されたテクスチャにも対応可能であるが、一般にはＪＰＥＧのコーデックを利用可能ではない。ＪＰＥＧ圧縮は、画像を離散コサイン変換し、量子化した後、ハフマン符号化を行うものである。ハフマン符号化は複雑な圧縮アルゴリズムであるから、仮にＧＰＵ２００のコンピュートシェーダがＪＰＥＧ圧縮されたテクスチャのハフマン復号を行ったとすると、計算量が膨大なものになってしまう。

【0034】

それに対して、ランレングス伸張のような単純な計算はＧＰＵ２００のコンピュートシェーダによって効率的に実行することができる。図５〜図８を参照して、ＧＰＵ２００のコンピュートシェーダがランレングス伸張を効率良く実行できることを説明する。

【0035】

図５（ａ）〜図５（ｃ）は、本実施の形態のランレングス圧縮および伸張を説明する図である。図５（ａ）はオリジナルデータ列、図５（ｂ）はランレングス圧縮されたデータ列、図５（ｃ）はランレングス伸張されたデータ列を示す。

【0036】

本実施の形態のランレングス圧縮では、バイト単位で圧縮を行い、１６進数で「００」および「ｆｆ」以外の入力値をそのまま出力する。図５（ａ）の符号４１０で示す、最初の６バイトの入力値「３ｆ」、「４ｄ」、「ｅ８」、「０２」、「ａ５」、「０１」は、「００」でも「ｆｆ」でもないため、図５（ｂ）のように、そのまま６バイトの出力値「３ｆ」、「４ｄ」、「ｅ８」、「０２」、「ａ５」、「０１」として符号化される。

【0037】

本実施の形態のランレングス圧縮では、入力値「００」がｎ個連続して並ぶ場合、２バイトの出力値「ｆｆ」、「ｎ−１」として符号化する。たとえば、図５（ａ）の符号４２０で示すように「００」が７個連続して並ぶ場合、図５（ｂ）の符号４２２で示すように２バイトの出力値「ｆｆ０６」として符号化する。

【0038】

本実施の形態のランレングス圧縮は、実値の「ｆｆ」が入力された場合、実値の「ｆｆ」であることを識別するために２バイトの「ｆｆ００」に変換する。図５（ａ）の符号４３０で示す入力値「ｆｆ」は、図５（ｂ）の符号４３２で示すように２バイトの出力値「ｆｆ００」として符号化される。

【0039】

本実施の形態のランレングス伸張は、ランレングス圧縮の逆の変換を行えばよい。図５（ｂ）の最初の６バイトの入力値「３ｆ」、「４ｄ」、「ｅ８」、「０２」、「ａ５」、「０１」は、図５（ｃ）に示すようにそのまま出力される。図５（ｂ）の符号４２２で示す「ｆｆ０６」に対しては、図５（ｃ）の符号４２４で示すように、最初の「ｆｆ」を「００」に変換した後、６個の「００」を出力する。図５（ｃ）の符号４３２で示す「ｆｆ００」に対しては、これは実値の「ｆｆ」であることを示しているから、図５（ｃ）の符号４３４で示すように、１バイトの「ｆｆ」を出力する。

【0040】

図６は、本実施の形態のランレングス伸張の流れを説明するフローチャートである。

【0041】

変数ＲＬは「００」の出力を繰り返す回数（ｎ−１）を示すものであり、初期値としてＲＬ＝０であるから（Ｓ１０のＮｏ）、入力データ列から１バイトの読み出しが行われる（Ｓ２０）。ステップＳ２０で読み出したデータが「ｆｆ」でない場合（Ｓ２２のＹｅｓ）、読み出したデータをそのまま出力し（Ｓ２４）、ステップＳ１０に戻る。ステップＳ２０で読み出したデータが「ｆｆ」である場合（Ｓ２２のＮｏ）、さらに次の１バイトを読み出す（Ｓ３０）。

【0042】

ステップＳ３０で読み出されたデータが「００」である場合（Ｓ３２のＹｅｓ）、その一つ前に読み出された「ｆｆ」が実値であることを意味するから、「ｆｆ」を出力し（Ｓ３４）、ステップＳ１０に戻る。

【0043】

ステップＳ３０で読み出されたデータが「００」でない場合（Ｓ３２のＮｏ）、変数ＲＬに読み出されたデータを代入する（Ｓ４０）。これによりＲＬには、「００」の出力を繰り返す回数（ｎ−１）が代入される。その後、最初の「００」を出力し（Ｓ４２）、ステップＳ１０に戻る。

【0044】

ステップＳ２４およびステップＳ３４からステップＳ１０に戻った場合、変数ＲＬ＝０であるから（ステップＳ１０のＮｏ）、ステップＳ２０に進み、それ以降のステップを繰り返す。

【0045】

ステップＳ４２からステップＳ１０に戻った場合、変数ＲＬ＝ｎ−１であるから（ステップＳ１０のＹｅｓ）、変数ＲＬから１を引き（Ｓ１２）、「００」を出力し（Ｓ１４）、ステップＳ１０に戻る。変数ＲＬが０になるまで、ステップＳ１２およびステップＳ１４が繰り返され、「００」が（ｎ−１）回出力される。

【0046】

本実施の形態のテクスチャ圧縮では、画像のブロックに対して離散コサイン変換（ＤＣＴ）がなされた後、量子化され、ランレングス圧縮される。自然画を離散コサイン変換すると、周波数成分のほとんどが低周波領域に集中し、高周波成分は無視できるほど小さくなる。特に量子化により、高周波成分のＤＣＴ係数はほとんどゼロになる。このことから、ランレングス圧縮の入力データはゼロが多数連続することが多くなる。

【0047】

図６のステップＳ１０、Ｓ１２、Ｓ１４を分岐Ａ、ステップＳ２０、Ｓ２２、Ｓ２４を分岐Ｂ、ステップＳ３０、Ｓ３２、Ｓ３４を分岐Ｃ、ステップＳ４０、Ｓ４２を分岐Ｄとすると、離散コサイン変換後のテクスチャデータはゼロが多数連続することが多いため、ランレングス伸張を行うと、分岐Ａを通ることがきわめて多くなる。一般的な自然画のテクスチャの場合、およそ８割以上が分岐Ａを通ることが実験的に確かめられている。このランレングス伸張の性質によって、ＧＰＵ２００のコンピュートシェーダが効率良くランレングス伸張を行うことができる。なぜなら、ＧＰＵ２００は、ＳＩＭＤ（Single Instruction Multiple Data）アーキテクチャであり、複数のスレッドが異なるデータに対して同じインストラクションを同時に実行するため、分岐条件に偏りがあれば、並列度が高まり、実行効率が上がる。

【0048】

ＧＰＵ２００は、一つのプログラムカウンタ（ＰＣ）がインストラクションキャッシュに格納されたインストラクションを参照し、たとえば１６個のＡＬＵ（Arithmetic Logic Unit）が同時にＰＣが参照するインストラクションを実行する。ｉｆ−ｔｈｅｎ−ｅｌｓｅループの分岐毎に異なる命令を１６個のスレッドにセットして同時に実行することになる。１６個のスレッドに対して、ｉｆ分岐では、ｉｆ条件が成立する場合（Ｔｒｕｅ）のピクセルを担当するスレッドを有効にして並列に実行し、ｅｌｓｅ分岐では、ｅｌｓｅ条件が成立する場合（Ｆａｌｓｅ）のピクセルを担当するスレッドを有効にして並列に実行する。ｉｆ条件が成立する場合とｅｌｓｅ条件が成立する場合がほぼ同数である場合、Ｔｒｕｅの場合とＦａｌｓｅの場合で有効化するスレッドの入れ替えを頻繁に行うことになるが、ｉｆ条件成立が８割、ｅｌｓｅ条件成立が２割のように偏っていれば、Ｔｒｕｅの場合に有効化するスレッドの集合を繰り返し使えるため、実行効率が高まる。図７および図８を参照してこの点をより詳しく説明する。

【0049】

図７は、比較のため、分岐先に偏りがない場合のスレッドの実行過程を説明する図である。

【0050】

ＧＰＵ２００は複数の計算ユニット（Computing Unit）を含む。ＧＰＵ２００の１つの計算ユニットで同時に実行されるスレッドの数は計算ユニット内の演算器の数によって決まるが、ここではこれを１６個とする。１つの計算ユニットに同時に投入可能な最大１６スレッドの集まりを「スレッドセット」と呼ぶ。スレッドセットに含まれる各スレッドは、同じシェーダプログラムを実行するが、処理するデータはそれぞれ異なり、プログラム内に分岐がある場合は、それぞれ別の分岐先をもつことがある。１つの計算ユニットはあるサイクルでは、１つのスレッドセット（ここでは最大１６スレッド）を並列に実行する。

【0051】

たとえば、各分岐先での必要な命令数が数個であっても、プラグラムカウンタが１個であり、計算ユニット内のすべての演算器は同一の命令を実行するＳＩＭＤ構造であるため、スレッドマスクによって実行するスレッドを変えながら各分岐の一つ一つの命令を実行することになる。

【0052】

一例として、図６のフローチャートの分岐Ａは３命令、分岐Ｂは４命令、分岐Ｃは２命令、分岐Ｄは５命令で実行されるとする。図７の例では、スレッドセット４５０内の１６個のスレッドの分岐先が順にＡ、Ａ、Ｃ、Ａ、Ａ、Ａ、Ｃ、Ｂ、Ｃ、Ａ、Ｃ、Ａ、Ｃ、Ａ、Ｃ、Ｄである場合を説明している。

【0053】

サイクル１において、分岐Ａを実行するスレッドのみ（この場合、８個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ａの３命令Ａ−１、Ａ−２、Ａ−３を実行する。

【0054】

サイクル３において、分岐Ｂを実行するスレッドのみ（この場合、１個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ｂの４命令Ｂ−１、Ｂ−２、Ｂ−３、Ｂ−４を実行する。

【0055】

サイクル８において、分岐Ｃを実行するスレッドのみ（この場合、６個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ｃの２命令Ｃ−１、Ｃ−２を実行する。

【0056】

サイクル１０において、分岐Ｄを実行するスレッドのみ（この場合、１個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ｄの５命令Ｄ−１、Ｄ−２、Ｄ−３、Ｄ−４、Ｄ−５を実行する。

【0057】

このように、図７の例では、スレッドセットに含まれる１６個のスレッドが４つの分岐Ａ〜Ｄのすべての命令を実行するために、１４サイクルが必要となる。

【0058】

図８は、分岐先に偏りがある場合のスレッドの実行過程を説明する図である。図８の例では、スレッドセット４５２内の１６個のスレッドの分岐先が順にＡ、Ａ、Ｃ、Ａ、Ａ、Ａ、Ｃ、Ｃ、Ｃ、Ａ、Ｃ、Ａ、Ｃ、Ａ、Ｃ、Ａである場合を説明している。この例では、シェーダプログラム上は分岐先が４種類あるが、分岐条件が成立するピクセルが偏っており、分岐先が分岐Ａと分岐Ｃの２種類しかない。スレッドセットに含まれる１６個のスレッドはこの２種類の分岐だけを実行すればよい。

【0059】

サイクル１において、分岐Ａを実行するスレッドのみ（この場合、９個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ａの３命令Ａ−１、Ａ−２、Ａ−３を実行する。

【0060】

サイクル４において、分岐Ｃを実行するスレッドのみ（この場合、７個のスレッド）を有効にし、プログラムカウンタを１つずつ進めながら、分岐Ｃの２命令Ｃ−１、Ｃ−２を実行する。

【0061】

このように、図８の例では、スレッドセットに含まれる１６個のスレッドが２つの分岐Ａ、Ｃのすべての命令を実行すればよく、必要サイクル数は５サイクルに減る。

【0062】

このように入力されるデータの性質によってプログラムの分岐先に偏りが生じる場合は、同じスレッドマスクをそのまま使って繰り返し命令を実行することができ、実行効率が向上する。分岐先にばらつきがあると、分岐毎にスレッドマスクを切り替えることになり、実行効率が低下する。

【0063】

テクスチャを離散コサイン変換した後、ランレングス圧縮することの利点はここになる。自然画由来のＤＣＴ係数の特性から、ＤＣＴ係数行列の左上の低周波成分に０以外の値が集中し、ＤＣＴ係数行列の右下の高周波成分に０が連続するようになる。したがって、離散コサイン変換後の画像ブロックをジグザグパターンにより１次元配列にすると、どのブロックのＤＣＴ係数も最初は非ゼロの値が続き、後半に０が連続するデータ列となる傾向がある。

【0064】

このＤＣＴ係数の傾向を踏まえて、スレッドセットの各スレッドには、異なるＤＣＴブロックのＤＣＴ係数を処理するようにランレングス圧縮データを割り当て、各スレッドがＤＣＴブロック内で相対的に同じ位置のＤＣＴ係数のランレングス伸張を行うようにスレッドセットを構成する。ＤＣＴ係数の値が「００」か、「ｆｆ」か、それ以外かによって、分岐先が分岐Ａ〜Ｄのいずれかになる。スレッドセットの構成から、ＤＣＴブロック内の相対的に同じ位置ではＤＣＴ係数の傾向が似るため、スレッドセット内の各スレッドの分岐先は同じものに偏るようになる。これにより、図７のように分岐先がばらつくのではなく、図８のように分岐先が偏るようになり、スレッドセットの効率的な実行状態を長く続けることができる。その結果、スレッドセットによってランレングス伸張は効率良く実行される。

【0065】

本実施の形態のグラフィックス処理装置によれば、離散コサイン変換後にランレングス圧縮されたテクスチャを用いるため、テクスチャ容量を大きく削減することができる。ＧＰＵ２００のコンピュートシェーダが圧縮テクスチャをランレングス伸張し、逆離散コサイン変換するため、高速に圧縮テクスチャを伸張してグラフィックス処理に投入することができる。高圧縮されたテクスチャはメモリに常駐させることができるため、大容量のテクスチャをハードディスクなどの記憶装置から読み出す必要がなく、オンメモリでＰＲＴを実行することが可能である。圧縮テクスチャがオンメモリ化されているため、必要に応じて圧縮テクスチャを読み出し、伸張してＰＲＴキャッシュにスワップインする構成にしても、レイテンシは短く、リアルタイムでテクスチャ処理を実行することができる。

【0066】

（第２の実施の形態）
図９は、第２の実施の形態に係るグラフィックス処理装置の構成図である。第２の実施の形態に係るグラフィックス処理装置は、Ｚｌｉｂエンジン６０を備える点が第１の実施の形態とは異なる。第１の実施の形態と共通する構成については適宜説明を省略し、主に第１の実施の形態と相違する構成について詳しく説明する。

【0067】

Ｚｌｉｂエンジン６０は、Ｚｌｉｂ伸張を実行する専用回路である。Ｚｌｉｂとは、Ｄｅｆｌａｔｅと呼ばれる可逆圧縮アルゴリズムを実装した、データの圧縮・伸張を行うライブラリである。

【0068】

本実施の形態では、圧縮テクスチャ３１０として、離散コサイン変換され、ランレングス圧縮された後、Ｚｌｉｂにより可逆圧縮されたテクスチャを利用する。圧縮テクスチャ３１０はメインメモリ３００に格納される。

【0069】

Ｚｌｉｂエンジン６０は、メインメモリ３００に格納された圧縮テクスチャ３１０をＺｌｉｂ伸張し、ランレングスブロックリングバッファ７０に格納する。

【0070】

ランレングス伸張部３０は、ランレングスブロックリングバッファ７０に格納されたＺｌｉｂ伸張後の圧縮テクスチャをランレングス伸張してＤＣＴブロックリングバッファ８０に格納する。それ以降の処理は第１の実施の形態と同じである。

【0071】

図１０（ａ）〜図１０（ｆ）は、Ｚｌｉｂ圧縮されたテクスチャのデータ量を説明する図である。図１０（ａ）〜図１０（ｃ）のＧＰＵ２００により扱うことのできる圧縮テクスチャは、図４（ａ）〜図４（ｃ）と同じであるから説明を省略する。

【0072】

図１０（ｄ）〜図１０（ｆ）は、ＧＰＵ２００が直接扱えない圧縮テクスチャである。図１０（ｅ）の離散コサイン変換およびＺｌｉｂ圧縮されたテクスチャは、図１０（ｄ）のＪＰＥＧ圧縮されたテクスチャと同様におよそ１／２０の圧縮率が得られる。しかしながら、後述するようにＤＣＴ係数をそのままＺｌｉｂ圧縮すると、伸張時にＺｌｉｂエンジン６０に通常のハードウェア性能を超える負荷を課すことになり、効率が悪い。そこで、本実施の形態では、図１０（ｆ）に示すように、離散コサイン変換およびランレングス圧縮後にＺｌｉｂ圧縮されたテクスチャを用いる。

【0073】

図１１（ａ）および図１１（ｂ）は、本実施の形態においてテクスチャをランレングス圧縮する利点を説明する図である。

【0074】

図１１（ａ）は、比較のため、ランレングス圧縮していないテクスチャをＺｌｉｂエンジン６０でＺｌｉｂ伸張する場合を示す。圧縮テクスチャの圧縮率が１／２０である場合、Ｚｌｉｂエンジン６０が５０ＭＢ／ｓ（メガバイト／秒）の転送速度で圧縮テクスチャの入力を受けた場合、１３３３ＭＢ／ｓの転送速度でＺｌｉｂ伸張されたテクスチャを出力する必要がある。Ｚｌｉｂ伸張されたテクスチャはＩＤＣＴ部４０により逆離散コサイン変換され、１０００ＭＢ／ｓの転送速度で復元されたテクスチャが出力される。

【0075】

Ｚｌｉｂエンジン６０の通常の入出力比は２〜４倍である。それに対して、ランレングス圧縮していないテクスチャの場合は、約２０倍の出力性能を要求されることになるが、Ｚｌｉｂエンジン６０の通常のハードウェア制限を超えるため、実装するのは現実的ではない。通常の出力性能のＺｌｉｂエンジン６０を用いると、要求される出力性能が出せないために、Ｚｌｉｂエンジン６０の出力がボトルネックとなり、テクスチャの復元にかかる時間が極端に長くなってしまう。

【0076】

図１１（ｂ）は、ランレングス圧縮されたテクスチャをＺｌｉｂエンジン６０でＺｌｉｂ伸張する場合を示す。この場合、Ｚｌｉｂエンジン６０が５０ＭＢ／ｓ（メガバイト／秒）の転送速度で圧縮テクスチャの入力を受けた場合、１２５ＭＢ／ｓの転送速度でＺｌｉｂ伸張されたテクスチャを出力すればよい。なぜなら、その後、ランレングス伸張部３０がＺｌｉｂ伸張されたテクスチャをランレングス伸張し、１３３３Ｍｂ／ｓの転送速度で出力することができるからである。ランレングス伸張されたテクスチャはＩＤＣＴ部４０により逆離散コサイン変換され、１０００ＭＢ／ｓの転送速度で復元されたテクスチャが出力される。

【0077】

ランレングス伸張部３０とＩＤＣＴ部４０は、ともにＧＰＵ２００のコンピュートシェーダにより実行されるから、データ転送の帯域幅は十分に大きく、ランレングス伸張部３０からＩＤＣＴ部４０のデータの受け渡しは、１３３３Ｍｂ／ｓの転送速度を実現可能である。この場合、Ｚｌｉｂエンジン６０の出力性能は２倍程度で済むから、通常のハードウェア制限の範囲で実装することができる。

【0078】

図１２は、本実施の形態のグラフィックス処理装置による圧縮テクスチャの伸張処理の性能を説明する図である。一例として、縦６４０画素、横６４０画素の圧縮テクスチャを伸張する場合を説明する。ここではＧＰＵ２００は一例として１８個の計算ユニット（ＣＵ）をもつ。Ｚｌｉｂエンジン６０は、テクスチャ伸張以外の用途にも用いられるため、ここでは、出力性能が２００Ｍｉｂ／ｓのＺｌｉｂエンジン６０のリソースの一部を用いて、２６Ｍｉｂ／ｓで圧縮テクスチャをＺｌｉｂ伸張する。これには６．２ｍｓ（ミリ秒）かかる。その後、１つのＣＵを用いてランレングス伸張を行うが、これは１．３ｍｓかかる。その後、逆離散コサイン変換は１８個のＣＵを用いて行うが、これは０．３ｍｓかかる。合計でメインメモリ３００上の圧縮テクスチャを伸張するのに８ｍｓのレイテンシとなり、リアルタイムで圧縮テクスチャを伸張してグラフィックス処理に投入することができる。

【0079】

仮にランレングス圧縮しないテクスチャを用いると、通常の出力性能のＺｌｉｂエンジン６０では、圧縮テクスチャをＺｌｉｂ伸張するのに約１０倍の６２ｍｓがかかることになり、実用に耐えなくなる。ランレングス圧縮されたテクスチャを利用することで、Ｚｌｉｂエンジン６０に与える負荷を軽くし、ランレングス伸張をコンピュートシェーダで高速に行うことで、圧縮テクスチャの伸張処理によるレイテンシを短くすることができる。

【0080】

第２の実施の形態のグラフィックス処理装置によれば、離散コサイン変換およびランレングス圧縮後にＺｌｉｂ圧縮されたテクスチャを用いるため、ＪＰＥＧ圧縮と同様にテクスチャ容量を大きく削減することができる。このように高圧縮されたテクスチャはメモリに常駐させることができ、オンメモリでＰＲＴを実行することが可能である。

【0081】

Ｚｌｉｂデコーダを備えるグラフィックス処理装置において、Ｚｌｉｂ圧縮の前にランレングス圧縮されたテクスチャを利用することで、圧縮テクスチャの伸張時にＺｌｉｂデコーダにかかる負荷を抑えることができる。

【0082】

また、第１の実施の形態と同様、ＧＰＵ２００のコンピュートシェーダが圧縮テクスチャをランレングス伸張し、逆離散コサイン変換するため、高圧縮されたテクスチャをリアルタイムで伸張してグラフィックス処理に投入することができる。

【0083】

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【0084】

上記の実施の形態では、圧縮テクスチャをメモリに格納したが、圧縮テクスチャをハードディスクや光ディスクなどの記録媒体に格納してもよい。テクスチャは高圧縮されているため、記憶容量を抑えることができ、また、オンメモリの場合のレイテンシにはかなわないが、記録媒体からの読み出しのレイテンシをある程度抑えることもできる。

【0085】

上記の実施の形態では、画像の空間領域を空間周波数領域に変換する空間周波数変換の一例として、離散コサイン変換を用いたが、これ以外の空間周波数変換、たとえば離散フーリエ変換を用いてもよい。

【0086】

上記の実施の形態では、ランレングス圧縮の一例として、「００」が連続した場合に、特定の符号「ｆｆ」と「００」が連続した長さの組み合わせで符号化したが、ランレングス圧縮はこれ以外の方法を用いてもよい。たとえば、「００」以外の値が連続した場合に特定の符号と連続した長さで符号化してもよい。

【0087】

上記の実施の形態では、Ｚｌｉｂデコーダがハードウェアとして利用できる場合を説明したが、Ｚｌｉｂ以外の圧縮アルゴリズムで圧縮されたデータを伸張するデコーダがハードウェアとして実装されている場合にも、本発明の実施の形態を適用することができる。

【符号の説明】

【0088】

１０ ＰＲＴ制御部、 ２０ グラフィックス演算部、 ３０ ランレングス伸張部、 ４０ 逆離散コサイン変換部、 ５０ グラフィックス処理部、 ６０ Ｚｌｉｂエンジン、 ７０ ランレングスブロックリングバッファ、 ８０ ＤＣＴブロックリングバッファ、 １００ メインプロセッサ、 ２００ ＧＰＵ、 ３００ メインメモリ、 ３１０ 圧縮テクスチャ、 ３２０ ＰＲＴキャッシュ、 ３３０ ページテーブル、 ３４０ ミップマップテクスチャ、 ３６０ テクスチャタイルプール。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】