JP3453088B2 - 圧縮テクスチャ・データ構造 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ・グ
ラフィックス・システムにおけるテクスチャ・マッピン
グに関するもので、特に、メモリ・システムから圧縮テ
クスチャ・データを効率的に取り出すことを可能にする
データ構造に関するものである。

【０００２】

【従来の技術】コンピュータ・グラフィックスの分野に
おいて、テクスチャ・マッピングは、オブジェクトの表
面のあらゆる細部を実際にモデル化することを必要とす
ることなく、レンダリングされたオブジェクトの表面上
に複雑な様相を作成するため使用される周知の技術であ
る。この技術は、典型的には、２次元の関数またはアレ
イ(すなわちテクスチャ)を３次元オブジェクト空間にお
けるオブジェクトにマップし、その結果生成された画像
を表示するため２次元画面空間に戻すように投影する動
作を伴う。"テクスチャ・マップ"という用語は、テクス
チャ・マッピング・プロセスにおいて使用される関数ま
たはアレイを意味する。一般的２次元テクスチャ・マッ
プは、例えば、木材または大理石のような材質を表現す
るための反復可能パターンから構成される。また、３次
元テクスチャ・マップも頻繁ではないが使用される。３
次元テクスチャ・マップは、通常、２次元テクスチャ・
マップより大きい。テクスチャ・マップは、テクセル(t
exel)と呼ばれる複数の数値から構成される。テクセル
の数値は、通常、ＲＧＢカラー値に対応し、また、アル
ファ透明度値に対応する場合もある(ＲＧＢカラー値お
よびアルファ透明度値に加えて、あるいは、それらに代
えて、その他のパラメータがテクスチャ・マップに含め
られることもある)。テクスチャ・マップの範囲内のテ
クセルの位置は、ｓ,ｔ座標を使用して指定されること
ができる。

【０００３】また、ＭＩＰマッピングとして知られる技
術がテクスチャ・マッピングにおいて使用される。ＭＩ
Ｐマッピングは、基底テクスチャ・マップを多数回縮小
サンプリングして、一連の一層小さいテクスチャ・マッ
プを開発するもので、それら一連の一層小さいテクスチ
ャ・マップの各々はあらかじめ決められた一層低レベル
の解像度で基底マップを表現する。典型的には、マップ
番号が各マップに割り当てられる。例えば、２つのテク
スチャが記憶されるシステムの場合、テクスチャ・マッ
プを個別に参照するため、４つの異なるレベルでの解像
度において各々２つ計８つのユニークなマップ番号が必
要とされる。ＭＩＰマッピングを使用するシステムにお
いては、各テクスチャに関する基底マップがメモリに記
憶される必要があるだけではなく、各テクスチャに関す
る縮小サンプルされたマップの各々も記憶されなければ
ならない。このように、テクスチャ・マップは、複雑な
画像をレンダリングするため重要な効率を生み出す一方
で、それらの記憶のため必要とされるメモリ量という観
点から負担となる場合もある。実際、画像のレンダリン
グのため使用されるテクスチャ・マップのサイズは、レ
ンダリングされた画像自体より大きい場合もある。

【０００４】テクスチャ・マップに関連するメモリ問題
に対処するため現在使用されている１つの技術は、グラ
フィックス・サブシステムの範囲内に位置する専用テク
スチャ・メモリではなく、ホスト・コンピュータ・シス
テムのメモリにテクスチャ・マップを記憶するというも
のである。この新しい技術は、グラフィックス・サブシ
ステムにおける大きい専用テクスチャ・メモリの必要性
を除去または減少させるという範囲において、有益であ
る。一方、この新しい技術は、ソフトウェア・レンダリ
ングに代わってハードウェア・レンダリングを利用する
という新しい問題をシステムにもたらす。グラフィック
ス・サブシステムのレンダリング・ハードウェアは、シ
ステム・メモリに記憶されている大量のテクスチャ・デ
ータにアクセスするため、システム・バスを頻繁に使用
しなければならない。これは、システム・バスおよびシ
ステム・メモリの両方に大幅なバンド幅需要を生じさせ
る。

【０００５】テクスチャ・マッピングに関連するこれら
メモリ空間ならびにバンド幅の問題のため、記憶される
テクスチャ・マップを多数の等サイズのブロックに論理
的に分割することが普及した。この方法は、システム・
メモリから１度に１テクセルを取り出すのではなくテク
スチャ・データのブロック全体を取り出すというもの
で、バスならびにメモリ利用度の観点からみて一般的に
効率的である。

【０００６】同じ理由のため、テクスチャ・マップを圧
縮した形式で記憶することも普及している。この目的の
ため、ＪＰＥＧ、ラン長符号化、Huffman符号化、ベク
トル量子化およびLampel-Ziv圧縮法を含む種々の圧縮ア
ルゴリズムが使用されている。これらのアルゴリズムの
各々は次のような多数の異なる方法で分類することがで
きる。第１に、アルゴリズムは有損失または無損失か？
有損失アルゴリズムは、無損失よりすぐれた圧縮率を
生むが、画像品質を犠牲にする。第２に、アルゴリズム
が生成する圧縮比率は固定的か可変的か？言い換える
と、アルゴリズムは画像のあらゆる部分を同程度に圧縮
するのか、あるいは、画像の非常に詳細な部分を他の画
像部分より小さい圧縮比率で圧縮するのか？ 無損失、
可変圧縮率アルゴリズムがテクスチャ・マッピングの用
途にとって最も利益のあることが判明している。なぜな
らば、無損失アルゴリズムだけが、圧縮／伸張プロセス
を通して、画像品質を保持することができるからであ
る。圧縮比率の可変性によって、無損失を維持しなが
ら、可能な限り最大の全般的圧縮効率が可能とされる。
圧縮アルゴリズムを選択する第３の重要な因子は、当該
アルゴリズムによって生成された圧縮テクスチャ・デー
タを容易にランダムにアクセスすることができる否かと
いう点である。所与のレンダリング・ルーチンがテクス
チャをどのようにアクセスするかを事前に決定すること
が難しいことが多い。従って、圧縮テクスチャー・デー
タをランダムにアクセスすることができる機能は非常に
有益である。

【０００７】現在普及している更に別の技法は、上述の
方法の組み合せである。すなわち、テクスチャ・マップ
が論理的にブロックに分割され、次に１度に１ブロック
が圧縮される。圧縮されたテクスチャ・マップが個々の
圧縮された複数ブロックからなる１つのセットとしてシ
ステム・メモリに記憶されるとすれば、テクスチャ・デ
ータの所望の部分は、所望のデータを内包する個々の圧
縮されたブロックだけを取り出すことによって、システ
ム・メモリから取り出すことができる。この技法を使用
すれば、圧縮されたテクスチャ・マップ全体をシステム
・メモリから取り出す必要はなく、システム・メモリに
おけるテクスチャ・データの個々の部分にだけアクセス
すればよい。更に、ブロックが圧縮形式で取り出される
ので、バスならびにメモリ・バンド幅の更なる節約が実
現する。

【０００８】

【発明が解決しようとする課題】従って、圧縮されたテ
クスチャ・データをメモリから効率的に取り出すことを
可能にするデータ構造が必要とされている。また、特に
取り出すべき圧縮テクスチャ・データが可変圧縮比率を
使用して生成されたものである場合の効率を高めるデー
タ構造が求められている。

【０００９】

【課題を解決するための手段】本発明は、コンピュータ
読み取り可能記憶媒体に記憶されている圧縮テクスチャ
・データ構造を含む。本発明の圧縮テクスチャ・データ
構造は、コンピュータ読み取り可能記憶媒体からのコン
ピュータ・グラフィックス表示システムによる圧縮テク
スチャ・データの効率的取り出しを可能にする。圧縮テ
クスチャ・データ構造は、少くとも第１および第２の圧
縮テクスチャ・データ・セグメントを含む。第１の圧縮
テクスチャ・データ・セグメントは、第１セグメント開
始メモリ位置から始まって第１セグメント終了メモリ位
置で終了し、第１セグメント長を有し、第１圧縮テクス
チャ・データ・ブロック長を持つ第１圧縮テクスチャ・
データ・ブロックを内包する。第２の圧縮テクスチャ・
データ・セグメントは、第２セグメント開始メモリ位置
から始まって第２セグメント終了メモリ位置で終了し、
第２セグメント長を有し、第２圧縮テクスチャ・データ
・ブロック長を持つ第２圧縮テクスチャ・データ・ブロ
ックを内包する。第２セグメント開始メモリ位置は、第
１セグメント終了メモリ位置に連続して配置される。第
１および第２セグメント長は等しいが、第１および第２
圧縮テクスチャ・データ・ブロック長は等しくない。第
１圧縮テクスチャ・データ・ブロックは第１セグメント
開始メモリ位置から開始し、第２圧縮テクスチャ・デー
タ・ブロックは第２セグメント開始メモリ位置から開始
する。

【００１０】本発明の別の１つの局面において、第１圧
縮テクスチャ・データ・セグメントは第１の長さインジ
ケータを含む。第１の長さインジケータは、第１の圧縮
テクスチャ・データ・ブロック長を決定するためコンピ
ュータ・グラフィックス・システムによって使用される
ことができる。第１の長さインジケータは、第１ヘッダ
の内部に含まれる。第１ヘッダは第１セグメント開始メ
モリ位置から始まることができる。その場合、第１圧縮
テクスチャ・データ・ブロックは、第１ヘッダの終了メ
モリ位置に隣接するメモリ位置から始まる。第１および
第２の圧縮テクスチャ・データ・ブロックは、非圧縮テ
クスチャ・マップの第１および第２の非圧縮ブロックの
圧縮表現を含む。

【００１１】本発明の更に別の局面において、第１圧縮
テクスチャ・データ・セグメントは、第１圧縮／伸張タ
イプ・インディケータを含む。第１圧縮／伸張タイプ・
インディケータは、第１圧縮テクスチャ・データ・ブロ
ックを伸張する際に使用する伸張アルゴリズムを選択す
るため、コンピュータ・グラフィックス・システムによ
って使用されることができる。第１圧縮／伸張タイプ・
インディケータも第１ヘッダの内部に含められる。

【００１２】

【発明の実施の形態】１. 代表的ホスト・コンピュータ
・システム 図１は、本発明の好ましい実施形態の実施に適するコン
ピュータ・システム１００を示す。コンピュータ・シス
テム１００は、少くとも１台のＣＰＵ１０２、システム
・メモリ１０４、メモリならびにＩ／Ｏコントローラ１
０６、プリンタ、スキャナ、ネットワーク・インタフェ
ースなどのようないくつかのＩ／Ｏ装置１０８を含む
(キーボードならびにマウスも通常Ｉ／Ｏ装置として含
まれるが、コンピュータ・システム１００へのインタフ
ェースとしてそれら自身のインタフェース・タイプを持
つ可能性がある)。典型的には、メモリならびにＩ／Ｏ
コントローラ１０６は、システム・バス１１０、およ
び、ＡＧＰバス・ブリッジ１１２ならびにＰＣＩバス・
ブリッジ１１４のようなと少くとも１つのバス・インタ
フェースを含む。ＰＣＩバス・ブリッジ１１４は、Ｉ／
Ｏ装置１０８をシステム・バス１１０へインタフェース
するため使用され、一方、ＡＧＰバス・ブリッジ１１２
は、例えばグラフィックス・サブシステム１１６をシス
テム・バス１１０へインタフェースするため使用され
る。図１に示されているバスの特定タイプは、コンピュ
ータ・システム１００のアーキテクチャと共に、例示の
目的のため提示されているにすぎず、本発明を実施する
ため、図示以外のバス・タイプおよびアーキテクチャを
使用することは可能である。

【００１３】グラフィックス・サブシステム１１６は、
典型的には、グラフィックス・レンダリング・ハードウ
ェア１１８、フレーム・バッファ・コントローラ１２０
およびフレーム・バッファ・メモリ１２２を含む。フレ
ーム・バッファ・コントローラ１２０は表示モニタ１２
６を駆動するため(例えばＲＡＭＤＡＣおよび同期発生
回路のような)ビデオ・コントローラ１２４とインタフ
ェースされる。グラフィックス・レンダリング・ハード
ウェア１１８は、典型的には、ＡＧＰバス１１３にイン
タフェースされた２Ｄまたは３Ｄジオメトリ加速ハード
ウェア、および、テクスチャ・メモリ１２８ならびにフ
レーム・バッファ・コントローラ１２０とインタフェー
スされたラスター化／テクスチャ・マッピング・ハード
ウェアを含む。

【００１４】テクスチャ・データは、コンピュータ・シ
ステム１００の範囲内の多数の異なる位置に記憶される
可能性がある。例えば、専用のテクスチャ・メモリ１２
８がグラフィックス・サブシステム１１６の内部に備え
られる(テクスチャ・メモリ１２８は、小規模のオンチ
ップ・キャッシュまたは比較的大きいオフチップ・テク
スチャ・メモリとして、あるいはそれらの組み合わせと
して、実施される場合がある)。テクスチャ・データ
が、テクスチャ・メモリ１２８の範囲内のテクスチャ記
憶域１３０に記憶されることもある。この場合、この記
憶域は、グラフィックス・レンダリング・ハードウェア
１１８のラスター化／テクスチャ・マッピング・ハード
ウェアにとって即座に利用できる。または、テクスチャ
・データは、フレーム・バッファ・メモリ１３２の範囲
内のテクスチャ記憶域１３２に記憶されることもでき
る。また、テクスチャ・データはシステム・メモリ１０
４の範囲内のテクスチャ記憶域１３４に記憶されること
もできる。テクスチャ記憶域１３０には、典型的には、
利用できるメモリは比較的小量しか存在しないが、ラス
ター化／テクスチャ・マッピング・ハードウェアがそこ
に記憶されているテクスチャ・データにアクセスする際
に発生する遅延は非常に小さい。テクスチャ記憶域１３
２の利用可能メモリ量は若干大きいが、そこに記憶され
ているテクスチャ・データにアクセスする際に発生する
遅延も若干大きい。これは、フレーム・バッファ・コン
トローラ１２０を経由してフレーム・バッファ・メモリ
１２２にアクセスすることに関わるバンド幅の制約によ
るものである。テクスチャ記憶域１３４の利用可能メモ
リ量は相対的に大きいが、そこに記憶されているテクス
チャ・データにアクセスする際に発生する遅延は非常に
大きい。これは、メモリならびにＩ／Ｏコントローラ１
０６、システム・バス１１０およびシステム・メモリ１
０４が、コンピュータ・システム１００のコンポーネン
トのすべてによって共有されなければならないからであ
る。従って、テクスチャ・マッピングに関して、テクス
チャ記憶域１３２をテクスチャ記憶域１３４のキャッシ
ュとして使用し、テクスチャ記憶域１３０をテクスチャ
記憶域１３２のキャッシュとして使用することが適切で
ある。

【００１５】２. 可変長圧縮ブロックの連続的記憶 図２は、圧縮(された)テクスチャ・データの可変長ブロ
ックをメモリ・システムに記憶するための第１の技法を
示している。データ構造２００は、多数の圧縮テクスチ
ャ・データ・ブロック０−ｎを含む。圧縮ブロック０−
ｎは共通のブロック長を持たないが、システム・メモリ
に連続的に記憶される。データ構造２００における非圧
縮ブロック０−ｎと圧縮ブロック０−ｎの対応関係を示
すように、非圧縮テクスチャ・マップ２０２が図２に示
されている(通常、テクスチャ・マップ２０２が一旦圧
縮されたならば、圧縮されたバージョンだけがメモリに
記憶される)。非圧縮ブロック０−ｎの各々は同じブロ
ック長を持つ。データ構造２００は、システム・メモリ
１０４におけるメモリ空間を節約するという利点を持つ
けれども、圧縮ブロック０−ｎの各々に関する開始アド
レスを決定する何らかの付加的方式がなければ、それを
使用することはできない。

【００１６】図３はそのような方式を示している。非圧
縮テクスチャ・マップのどの非圧縮ブロックが当該テク
セルを含むかを決定するマッピング機能３００に対して
ｓ,ｔ座標が使用される。マッピング機能３００のよう
なマッピング機能は、照合テーブルまたは組合せの論理
を用いて実施することができる。次に、当該テクセルに
関してマッピング機能３０２に対して非圧縮ブロック番
号およびマップ番号を使用して、(1)テクセルの圧縮表
現を含む実際の圧縮ブロックに関するシステム・メモリ
の開始アドレスおよび(2)圧縮ブロック長を決定する。
好ましくは、マッピング機能３０２のようなマッピング
機能を実施するため照合テーブルが使用される。別の実
施形態において、マッピング機能３００および３０２
は、全体として１つの大きい照合テーブル３０４に包含
されることもできる。マッピング機能の実施様態がどの
ようなものであろうと、マッピング機能は、システム・
メモリ１０４ではなくグラフィックス・サブシステム１
１６の範囲内に物理的に配置されることが好ましい。マ
ッピング機能がシステム・メモリ１０４の範囲内に配置
されるとすれば、システム・メモリ１０４に記憶されて
いる圧縮テクスチャ・データのブロックにアクセスする
時、システム・バスが少くとも２回使用されなければな
らない。すなわち、最初は圧縮ブロックに関する開始ア
ドレスおよびブロック長を決定するため、２回目はその
ブロック自体をアクセスするためである。そのような技
法は、システム・バスおよびシステム・メモリ・バンド
幅の観点から非効率である。

【００１７】３.可変長圧縮ブロックの等サイズ・セグ
メントへの記憶 図４は、可変長圧縮テクスチャ・データ・ブロックを等
サイズのセグメントに記憶する技法を示す。データ構造
４００は、基底アドレス４０２から始まるシステム・メ
モリ１０４に記憶される。データ構造４００は、各々等
しいセグメント・サイズを持つセグメント０−ｎから成
る。各セグメント０−ｎの範囲内に圧縮ブロック０−ｎ
がそれぞれある。各セグメントのサイズは同じである
が、圧縮されたブロックの各々のサイズは潜在的に異な
るので、セグメント０−ｎの大部分は、図４において例
えば４０４、４０６および４０８という符号で示されて
いるように、未使用のメモリ部分を含む。このように、
データ構造４００は、データ構造２００と比較してなに
がしかのメモリを浪費する。しかしながら、等サイズの
セグメントへの可変長ブロックの記憶は、各ブロック
(すなわちセグメント)の開始アドレスの計算を単純化す
る。

【００１８】好ましくは、データ構造４００が作成され
る時、最初にテクスチャ・マップ２０２がブロック毎に
完全に圧縮される。次に、データ構造４００に関するセ
グメント・サイズは、圧縮されたブロック０−ｎのうち
の最大のもの(すなわち最悪ケースの圧縮比率を持つブ
ロック)に等しく設定される。このようにして、部分４
０４、４０６および４０８のような未使用部分によって
無駄となるシステム・メモリの量が最小限度にとどめら
れる。また、セグメント・サイズを最も近い２の累乗値
に丸めれば、セグメント開始アドレスの計算が更に簡略
化されるので、都合がよい(セグメント・サイズが２の
累乗であれば、アドレス計算の間に必要な乗算は単純な
シフト動作を使用して実行できる)。代替的に、セグメ
ント・サイズをキャッシュ行境界のような別の便利な値
まで丸めることもできる。

【００１９】図５は、図４の方式の１つのバリエーショ
ンを示す。データ構造５００の代表部分(すなわち１つ
のセグメント)がシステム・メモリ１０４に記憶されて
いるように示されている。ヘッダ５０２が各セグメント
の開始部分に加えられた点を除けば、データ構造５００
はすべての点でデータ構造４００と同じものである。好
ましくは、ヘッダ５０２は、そのセグメントに含まれる
圧縮ブロック(例えば図５における圧縮ブロックｘ)の長
さを表示するため、ブロック長フィールド５０４を含
む。オプションとして、別の１つのフィールド５０６を
ヘッダ５０２に含めることもできる。圧縮／伸張タイプ
・フィールド５０６を使用して、そのセグメントに含ま
れる圧縮ブロックを生成するために使用された圧縮アル
ゴリズムのタイプを標示することができる(同じことで
はあるが、フィールド５０６はブロックを伸張するため
に使用されなければならない伸張アルゴリズムを標示す
る)。圧縮／伸張タイプ・フィールド５０６を使用する
利点は、データ構造５００に圧縮ブロックの各々を作成
するため異なるアルゴリズムを使用することができる点
である。このようにして、データ構造５００の全体サイ
ズを最小限度にとどめることができる。

【００２０】４. 圧縮テクスチャ・データ・セグメント
の開始アドレスの決定 対象テクセルのｓ,ｔ座標およびマップ番号を所与とし
て、図６は、テクセルの圧縮表現を含む(図４および図
５に示されているような)圧縮テクスチャ・データ・セ
グメントの開始アドレスを決定する方法を示す。本明細
書における記述の目的から、対象テクセルの圧縮された
表現を含む圧縮されたテクスチャ・データ・セグメント
を、目標圧縮テクスチャ・データ・セグメントと呼ぶ。
テクセルのｓ,ｔ座標を使用して、マッピング機能６０
０によって、非圧縮テクスチャ・マップのどの非圧縮ブ
ロックが当該テクセルを含むか決定される(このマッピ
ング機能は上述されたマッピング機能３００と同等のも
のである)。マッピング機能６００は、次に、当該テク
セルに対応する非圧縮ブロック番号６０２を生成する
(マッピング機能６０３は、また、非圧縮ブロックの開
始位置に対するテクセル位置を示すオフセット６０３を
生成する)。一般的ケースにおいては、非圧縮ブロック
番号６０２を使用して、マッピング機能６０４によって
セグメント番号６０６が決定される。セグメント番号６
０６は、データ構造４００または５００のようなデータ
構造におけるどの圧縮テクスチャ・データ・セグメント
が目標セグメントであるか標示する。好ましい実施形態
において、非圧縮ブロック番号はセグメント番号として
０からｎまで番号をつけられているので、マッピング機
能６０４は単に同一性関数である(言い換えると、好ま
しい実施形態において、セグメント番号６０６は、単
に、非圧縮ブロック番号６０２と等しい)。

【００２１】当該テクセルに対応するマップ番号を使用
して、マッピング機能６０８によって、目標セグメント
を含むデータ構造に対応するセグメント長６１０が決定
される。(好ましい実施形態において、圧縮テクスチャ
・セグメント長は、コンピュータ・システム１００に記
憶されるすべての圧縮テクスチャ・マップについて同じ
ものである。その場合、マッピング機能６０８は省略す
ることができる。実際、データ構造４００および５００
の特性からこのマッピング機能は省略されることが可能
とされている。しかし、一般的ケースにおいては、各マ
ップ番号は異なるセグメント長に対応する)。マッピン
グ機能６０８は、また、目標セグメントを含むデータ構
造に関する基底アドレス６１２を生成する。次に、セグ
メント番号６０６がセグメント長６１０に乗算され(ブ
ロック６１４)、乗算結果が基底アドレスに加算されて
(ブロック６１６)、目標圧縮テクスチャ・データ・セグ
メントに関する開始アドレス６１８が生成される(上述
のように、セグメント長が２の累乗であれば、乗算６１
４は、シフト・レジスタで実施されることができる)。

【００２２】最悪ケース圧縮比率６２０は、目標セグメ
ントを含むデータ構造に対応する。それは、マッピング
機能６０８によって生成されることができる。代替実施
形態において、セグメント長および非圧縮テクスチャ・
データ・ブロックのサイズの関数として、それは決定さ
れる。(非圧縮テクスチャ・データ・ブロックのサイズ
は前もって知られていると仮定される。好ましくは、サ
イズは各テクスチャ・マップについて同じものであっ
て、使用される圧縮アルゴリズムと無関係である。）

【００２３】５. バッファおよびデータ経路 好ましいデータ取り出し方法を記述する前に、図７を参
照してバッファおよびデータ経路を考察する。圧縮テク
スチャ・データがグラフィックス・サブシステム１１６
によってシステム・メモリ１０４から読み取られる時、
圧縮テクスチャ・データは経路７００を経由して到着し
て、圧縮テクスチャ・データ・バッファ７０２に記憶さ
れる。データ構造５００の場合のようにヘッダが利用さ
れている時、経路７０６上でアクセスできるようなヘッ
ダ・バッファ７０４が提供される。好ましくは、(状態
マシンのような)伸張プロセス７０８が、圧縮テクスチ
ャ・データ・バッファ７０２にアクセスして、伸張テク
スチャ・データ・バッファ７１０にファイルする。目標
データ７１２は、オフセット６０３を使用して伸張テク
スチャ・データ・バッファ７１０から取り出すことがで
きる。

【００２４】６. 圧縮テクスチャ・データの効率的取り
出し 図８は、アクセスされている圧縮ブロックの長さが前も
って知られていない場合に圧縮テクスチャ・データをメ
モリ・システムから取り出す効率的な方法を示す。ステ
ップ８００において、目標テクセルに関するｓ,ｔ座標
およびマップ番号を使用して、目標圧縮テクスチャ・デ
ータ・セグメントのシステム・メモリ１０４における開
始アドレスが決定される。ステップ８０２において、目
標圧縮セグメントを含むデータ構造に関する最悪ケース
圧縮比率が決定される。（以下の記述において、最悪ケ
ース圧縮比率をその英語表現"worst case compression
ratio"の頭文字をとって"ＷＣＣＲ"と略称する)。この
目的のため、図６に関連して上述された方法を使用する
ことができる。(本明細書の記述の目的から、圧縮比率
は、オブジェクトの圧縮前サイズの圧縮後サイズに対す
る比率として定義される。例えば、ある圧縮アルゴリズ
ムが４０Ｋバイトのオブジェクトを１０Ｋバイト・オブ
ジェクトに圧縮することができるならば、この圧縮アル
ゴリズムはこのオブジェクトに対して４対１の圧縮比率
を達成したといわれる)。ステップ８０４において、カ
ウントが０に初期化される。このカウントは、システム
・メモリ１０４に対して発信された読み取り要求の総数
に関する情報を追跡するために使用される。ステップ８
０６において、読み取りアドレスは、ステップ８００で
決定された目標セグメントに関する開始アドレスに初期
化される。

【００２５】ステップ８０８において、読み取り要求発
信動作が開始される。この動作の間に、データ読み取り
要求は、ステップ８００において決定された開始アドレ
スから始めて、目標圧縮セグメントの範囲内のアドレス
に順に向けられる。ステップ８０８において発信される
１つの読み取り要求は読み取りアドレスに記憶されてい
る１つのアドレスに向けられる(各読み取り要求は、好
ましくは、複数バイトのデータを取り出す。説明の目的
から、各読み取り要求はｘバイトのデータを取り出すと
仮定する)。ステップ８１０において、カウントが増分
される。ステップ８１２および８１４において、読み取
り要求発信動作が停止されたか否か検査される。ステッ
プ８１２において、それまでに要求されたデータの最小
非圧縮サイズに対応する最小非圧縮サイズが決定され
る。このサイズを決定するため、カウントに各読み取り
要求が取り出すバイト数(この例では"ｘ")が乗算され
る。乗算の結果にＷＣＣＲが乗算される。ステップ８１
４において、そのように決定された最小非圧縮サイズが
予想非圧縮サイズと比較される。この比較において使用
される予想非圧縮サイズは、当該ブロックの(事前に知
られている)非圧縮サイズであるか、あるいは、オフセ
ット値６０３に基づく場合もある(例えば目標テクセル
だけを取り出そうとする場合、予想非圧縮サイズは"オ
フセット＋１"として設定される)。最小非圧縮サイズが
予想非圧縮サイズより小さい場合、ステップ８１６にお
いて読み取りアドレスが適切に増分され、ステップ８０
８において別の１つの読み取り要求が発信される。しか
し、最小非圧縮サイズが予想非圧縮サイズと少なくとも
同じであれば、ステップ８１８において読み取り要求発
信動作が停止される。

【００２６】図９は、図８の方法に対する修正を示す。
図９において、ステップ８２０が、図８のステップ８１
２を置き換え、ステップ８２２が図８のステップ８１４
を置き換えている。ステップ８２０において、要求され
たデータに関する実際の圧縮サイズが計算される。実際
の圧縮サイズは単純にｘとカウントの乗算結果である。
ステップ８２２において、この実際の圧縮サイズが予想
圧縮サイズと比較される。予想圧縮サイズを単にセグメ
ント・サイズとすることができる。実際の圧縮サイズが
少くとも予想圧縮サイズと同じ大きさであれば、ステッ
プ８２４において読み取り要求発信動作が停止される。
しかし、実際の圧縮サイズが予想圧縮サイズより小さけ
れば、動作は図８のステップ８１６へ進む。注：セグメ
ント・サイズが最大ブロックのサイズに等しく設定され
ているデータ構造を伴う特別のケースの場合、図９の予
想非圧縮サイズが非圧縮ブロックのサイズに設定さてい
れば、図９の方法は、図８の方法と同じ結果を生む(す
なわち、たとえその範囲内の圧縮テクスチャ・データ・
ブロックがセグメントと同じ大きさでないとしても圧縮
テクスチャ・データ・セグメントの全体が読み取られる
という結果を生む)。

【００２７】７. 取り出したデータの非圧縮サイズを迅
速に決定することができる場合の方法改善 図１０は、非圧縮データのサイズが受け取り次第迅速に
かつ漸増的に決定されることができる場合の符号化アル
ゴリズムの１つの一般的クラスを示している。そのよう
な符号化アルゴリズムの１例は、ランレングス(run-len
gth)符号化法である。ランレングス符号化法のような符
号化技法によって生成されるデータストリームは、先ず
反復数９００が送られ、次に、反復されるべきデータの
サイズに対応するサイズ・フィールド９０２が続き、そ
の後に、反復されるべき実際のデータ９０４(またはデ
ータを参照するために使用されるインジケータ)が続
く。注：ランレングス符号化においてサイズ・フィール
ド９０２がオプションで、サイズが暗黙的に定まってい
る場合もある。反復数にデータのサイズを乗算すること
によって、非圧縮サイズが決定され、符号化されたデー
タが受け取られる都度累積される。

【００２８】図１１は、非圧縮データのサイズが受け取
り次第迅速にかつ漸増的に決定されることができる場合
のテクスチャ・データ取り出し方法を示す。ステップ１
０００において、第２の最小非圧縮サイズ値が０に初期
化される。この値は、受け取ったデータの非圧縮サイズ
を蓄積するために使用される。ステップ１００２におい
て、その他の値が初期化される。すなわち、目標圧縮テ
クスチャ・データ・セグメントの開始アドレスおよび該
セグメントのデータ構造に関するＷＣＣＲが決定され
る。カウント値がゼロに初期化される。このカウント値
は、(要求は出されたがそのデータがいまだに受け取ら
れていない)仕掛り中読み取り要求を追跡するために使
用される。最後に、読み取りアドレス値が目標セグメン
トの開始アドレスに初期化される。ステップ１００４に
おいて、読み取り要求発信動作が開始される。読み取り
要求は読み取りアドレスに記憶されているｘバイトのデ
ータに対して発信され、カウントが増分される。ステッ
プ１００６、１００８および１０１０において、読み取
り要求に応じるデータ量が受け取られ、バッファ７０２
のような圧縮テクスチャ・データ・バッファに受け取ら
れたデータが記憶され、データがｘバイト受け取られる
毎にカウントが減分される(このようにして、カウント
は、要求されたがまだデータが受け取られていない読み
取り要求の数を常に反映する)。

【００２９】ステップ１０１２において、第１の非圧縮
サイズが決定される。このサイズは、要求されたがまだ
受け取られていないデータのサイズに対応する。この値
は、ｘにカウントを乗算し、更に、ＷＣＣＲを乗算する
ことによって決定される。ステップ１０１４および１０
１６は、上述の第２の非圧縮サイズを蓄積するプロセス
を表す。未処理反復インジケータがバッファ７０２に存
在する限り、反復数に反復されるべきデータのサイズを
乗算して、その結果を蓄積された合計に加えることによ
って、第２の最小非圧縮サイズが更新される。

【００３０】ステップ１０１８において、第１および第
２の最小非圧縮サイズが加算される。この合計が予想非
圧縮サイズ(例えば、非圧縮ブロックのサイズまたはオ
フセット６０３から決定されるサイズ)と少なくとも同
じ大きさであれば、ステップ１０２２において、読み取
り要求発信動作は停止される。しかし、この合計が予想
非圧縮サイズ未満であれば、ステップ１０２０において
読み取りアドレスが適切に増分され、動作はステップ１
００４へ進む。

【００３１】本明細書に示されている動作流れ図におけ
るすべてのステップの順序は例示の目的にすぎない点は
注意されるべきである。これらステップは、本発明の理
念を逸脱することなく、異なる順序で実行することがで
きるし、あるいは、異なるプロセスまたは異なる状態マ
シンによって同時に実行することも可能である。

【００３２】８. 圧縮テクスチャ・データ・セグメント
の内部におけるヘッダの使用 図１２は、データ構造５００のようなデータ構造が使用
される場合にメモリ・システムから圧縮テクスチャ・デ
ータを取り出すために使用される方法を示す。ステップ
１１００において初期化が実行される。すなわち、目標
圧縮セグメントの開始アドレスが決定され、カウントが
０にセットされ、読み取りアドレス値が目標セグメント
の開始アドレスに等しくセットされる。ステップ１１０
２において、読み取り要求発信動作が開始する。すなわ
ち、読み取りアドレスに記憶されているデータのｘバイ
トを取り出すように読み取り要求が出され、カウントが
増分される。注：図１２の方法におけるカウントは、仕
掛かり中読み取り要求の数ではなく発信された読み取り
要求の総数を追跡する。

【００３３】ステップ１１０４乃至１１１６において、
データが受け取られ、記憶される。データが受け取られ
ると(ステップ１１０４)、ヘッダが既に受け取られてい
るか否か調べられる(ステップ１１０６)。まだ受け取ら
れていないとすれば、ステップ１１０８においてカウン
トが減分され(ヘッダはデータとしてカウントしない)、
ヘッダがバッファ７０４に記憶される(ステップ１１１
０)。次に、圧縮ブロック長ヘッダ・フィールド５０４
に従って、予想圧縮ブロック長値がセットされる。圧縮
／伸張ヘッダ・フィールド５０６を使用する実施形態に
おいては、ステップ１１１４にいて、ヘッダ・フィール
ド５０６の情報を使用して伸張タイプ値がセットされ
る。この伸張タイプ値は、データを伸張するため後刻使
用される。ステップ１１０６において、ヘッダがすでに
受け取られていると判断されると、到来データがバッフ
ァ７０２に記憶される(ステップ１１１６)。

【００３４】ステップ１１１８において、ｘにカウント
を乗算することによって要求されたデータ長値が計算さ
れる。ステップ１１２０において、この値が、ステップ
１１１２でセットされた予想圧縮ブロック長値と比較さ
れる。要求されたデータ長が予想圧縮ブロック長と少な
くとも同じ大きさであれば、ステップ１１２４において
読み取り要求発信動作が停止され、受け取られたデータ
が伸張される。オプションとして、圧縮／伸張タイプ・
フィールド５０６を使用する実施形態においては、ステ
ップ１１１４においてセットされる圧縮／伸張タイプを
使用してステップ１１２２において伸張を実行すること
が可能である。

【００３５】９. 並列伸張 読み取り要求発信動作がまだ進行している間に、それぞ
れのジョブを実行する別のプロセスまたは別の状態マシ
ンを使用することによって、バッファ７０２の内容を伸
張することも可能である。そのような実施形態において
は、図１３乃至図１６に示さているような方法を使用す
ることができる。図１３の方法は、図１４乃至図１６に
比較して基本的なものである。ステップ１２００におい
て初期化が実行される。すなわち、目標圧縮セグメント
の開始アドレスが決定され、カウントが０にセットさ
れ、読み取りアドレス値が目標セグメントの開始アドレ
スに等しくセットされる。ステップ１２０２において、
読み取り要求発信動作がプロセス１として開始される。
ステップ１２０４において、当該読み取り要求発信動作
に応答してなんらかのデータが受け取られたと判断され
ると、ステップ１２０６において、伸張動作７０８がプ
ロセス２として開始される。プロセス２は、その進捗を
示すため現在時非圧縮データ・サイズを維持する。プロ
セス１および２が進む間に、ステップ１２０８が、現在
時非圧縮データ・サイズを予想非圧縮データ・サイズと
比較する。現在時非圧縮データ・サイズが予想非圧縮デ
ータ・サイズと少なくとも同じ大きさであれば、プロセ
ス１および２が共に停止される(ステップ１２１０)。

【００３６】図１４乃至図１６の方法は、図１３の方法
より効果的である。図１４の場合、ステップ１３００に
おいて、ＷＣＣＲが決定されること以外は、ステップ１
２００の場合と同じ初期化が実行される。ステップ１３
０２において、読み取り要求発信動作がプロセス１とし
て開始される。このプロセス１は図１５に示されてい
る。ステップ１４００において、読み取りアドレスに記
憶されているｘバイトを取り出す読み取り要求が発信さ
れ、カウントが増分される。ステップ１４０２において
データのｘバイトが受けられたと判断されれば、ステッ
プ１４０４においてカウントが減分される(このケース
では、カウントは読み取り要求総数ではなく仕掛かり中
読み取り要求を追跡する)。ステップ１４０６において
伸張プロセスがまだ始まっていないと判断されると、伸
張プロセスがプロセス２として開始される。このプロセ
ス２は図１６を参照して後述される。ステップ１４１０
において、受け取られたデータがバッファ７０２に記憶
される。

【００３７】ステップ１４１２において、第１の非圧縮
サイズが決定される。この第１のサイズは、要求は出さ
れたがまだ受け取られていないデータの最小非圧縮サイ
ズに対応する。それは、ｘにカウントを乗算し、さらに
ＷＣＣＲを乗算することによって決定される、ステップ
１４１４において、第２の非圧縮サイズが決定される。
この第２のサイズは、プロセス２によって進捗インジケ
ータとして維持されている実際の非圧縮サイズ値に対応
する。ステップ１４１６において、第１および第２のサ
イズが加算される。その合計が予想非圧縮サイズと少な
くとも同じ大きさであれば、(プロセス１の)読み取り要
求発信動作は、ステップ１４１８において、停止され
る。さもなければ、プロセス１はステップ１４００に戻
る。

【００３８】プロセス２の伸張活動が図１６に示されて
いる。未処理データがバッファ７０２に存在すれば(ス
テップ１５００)、その少くとも一部分が伸張される(ス
テップ１５０２)。ステップ１５０４において、非圧縮
サイズ進捗インジケータが更新されなければならない。
ステップ１５０６において、更新された非圧縮サイズ値
が予想非圧縮サイズと比較される。実際の非圧縮サイズ
が予想非圧縮サイズと少なくとも同じ大きさであれば、
ステップ１５０８において伸張プロセスは停止される。
さもなければ、伸張プロセスはステップ１５００に戻
る。

【００３９】１０. システム・メモリから圧縮テクスチ
ャ・データを取り出す効率的方法 図１７は、圧縮テクスチャ・データをシステム・メモリ
１０４から取り出す別の方法を示す。図１７の方法は、
グラフィックス・サブシステム１１６に配置される照合
テーブルまたはハードウェア・マッピング機能(図３参
照)を利用する。ステップ１６００において、目標テク
セルに対応するｓ,ｔ座標およびマップ番号が、グラフ
ィックス・サブシステム１１６の照合テーブルまたはハ
ードウェア・マッピング機能に適用される。ステップ１
６０２において、照合テーブルまたはハードウェア・マ
ッピング機能の出力に基づいて、システム・メモリ１０
４に記憶されている目標圧縮テクスチャ・データ・ブロ
ックの開始アドレスと長さが決定される(注：図１７の
方法では、開始アドレスは、圧縮テクスチャ・データ・
ブロックを含むセグメントではなくそのようなブロック
の開始アドレスを直接指す)。ステップ１６０４におい
て、カウントが０に初期化され、読み取りアドレス値が
ステップ１６０２で決定された開始アドレスに初期化さ
れる。

【００４０】ステップ１６０６、１６０８、１６１０お
よび１６１２は、目標テクセルの圧縮表現を含む(シス
テム・メモリ１０４に記憶されている)圧縮テクスチャ
・データ・ブロックにアクセスするプロセスを表す。ス
テップ１６０６において、読み取りアドレスに記憶され
ているデータのｘバイトを取り出す読み取り要求が発信
され、カウントが増分される。ステップ１６０８におい
て、ｘにカウントを乗算することによって要求されたデ
ータ長値が計算される。ステップ１６１０において、要
求されたデータ長値が、ステップ１６０２で決定された
圧縮ブロック長と比較される。要求されたデータ長値が
圧縮ブロック長と少なくとも同じ大きさであれば、ステ
ップ１６１４において読み取り要求発信動作は停止され
る。さもなければ、ステップ１６１２において読み取り
アドレスが適切に増分され、プロセスはステップ１６０
６に進む。図１７の方法は、アクセスに先立って目標圧
縮テクスチャ・データ・ブロックの開始アドレスおよび
その長さを決定するためシステム・バス１１０の使用を
必要としないので、システム・バスのバンド幅の効率が
高い方法である。

【００４１】以上、好ましい実施形態を参照して本発明
を記述したが、上記参照の実施形態は例示のためのもの
にすぎず、本発明をそのような特定の実施形態に制約す
るために提示されたものではない。本発明の理念を逸脱
することなく、上記実施形態に種々の変更を加えること
が可能な点は当業者に認められることであろう。例え
ば、上述された技法のすべては、３次元のテクスチャ・
マップに適用することが可能である。それら技法を３次
元テクスチャ・マップに関して使用するため、ｓ,ｔ座
標の代わりにｒ,ｓ,ｔ座標を使用することができる。

【００４２】本発明には、例として次のような実施様態
が含まれる。 （１）コンピュータ・グラフィックス表示システムによ
るコンピュータ読み取り可能記憶媒体からの圧縮テクス
チャ・データの効率的取り出しのためコンピュータ読み
取り可能記憶媒体に記憶される圧縮テクスチャ・データ
構造であって、該圧縮テクスチャ・データ構造が少くと
も第１および第２の圧縮テクスチャ・データ・セグメン
トを備え、上記第１圧縮テクスチャ・データ・セグメン
トは、第１セグメント開始メモリ位置から始まって第１
セグメント終了メモリ位置で終了し、第１セグメント長
を有し、第１圧縮テクスチャ・データ・ブロック長を持
つ第１圧縮テクスチャ・データ・ブロックを内包し、上
記第２圧縮テクスチャ・データ・セグメントは、第２セ
グメント開始メモリ位置から始まって第２セグメント終
了メモリ位置で終了し、第２セグメント長を有し、第２
圧縮テクスチャ・データ・ブロック長を持つ第２圧縮テ
クスチャ・データ・ブロックを内包し、上記第２セグメ
ント開始メモリ位置は上記第１セグメント終了メモリ位
置に連続して配置され、上記第１および第２セグメント
長は等しく、上記第１および第２圧縮テクスチャ・デー
タ・ブロック長は等しくない、圧縮テクスチャ・データ
構造。

【００４３】（２）上記第１圧縮テクスチャ・データ・
ブロックは上記第１セグメント開始メモリ位置から開始
し、上記第２圧縮テクスチャ・データ・ブロックは上記
第２セグメント開始メモリ位置から開始する、上記
（１）に記載の圧縮テクスチャ・データ構造。 （３）上記第１圧縮テクスチャ・データ・セグメントが
第１の長さインジケータを含み、該第１の長さインジケ
ータは上記第１圧縮テクスチャ・データ・ブロック長を
決定するためコンピュータ・グラフィックス・システム
によって使用される、上記（１）に記載の圧縮テクスチ
ャ・データ構造。 （４）上記第１の長さインジケータが第１ヘッダの内部
に含まれ、該第１ヘッダは上記第１セグメント開始メモ
リ位置から始まる、上記（３）に記載の圧縮テクスチャ
・データ構造。

【００４４】（５）上記第１圧縮テクスチャ・データ・
ブロックが第１圧縮ブロック開始メモリ位置から始ま
り、上記第１ヘッダが第１ヘッダ終了メモリ位置で終了
し、上記第１圧縮ブロック開始メモリ位置が上記第１ヘ
ッダ終了メモリ位置に隣接するメモリ位置から始まる、
上記（４）に記載の圧縮テクスチャ・データ構造。
（８）上記第１および第２の圧縮テクスチャ・データ・
ブロックが、非圧縮テクスチャ・マップの第１および第
２の非圧縮ブロックの圧縮表現を含む、上記（１）に記
載の圧縮テクスチャ・データ構造。 （６）上記第１圧縮テクスチャ・データ・セグメントが
第１圧縮／伸張タイプ・インディケータを含み、該第１
圧縮／伸張タイプ・インディケータは、上記第１圧縮テ
クスチャ・データ・ブロックを伸張する際に使用する伸
張アルゴリズムを選択するため、上記コンピュータ・グ
ラフィックス・システムによって使用される、上記
（１）に記載の圧縮テクスチャ・データ構造。 （７）上記第１圧縮／伸張タイプ・インディケータが、
上記第１セグメント開始メモリ位置から始まる上記第１
ヘッダの内部に含められる、上記（６）に記載の圧縮テ
クスチャ・データ構造。

【００４５】

【発明の効果】本発明によって、圧縮されたテクスチャ
・データをメモリから効率的に取り出すことができるデ
ータ構造が利用可能となる。特に、取り出すべき圧縮テ
クスチャ・データが可変圧縮比率を使用して生成された
ものである場合、データ取り出しの効率が大幅に改善さ
れる。

【図面の簡単な説明】

【図１】本発明の１つの実施形態に適するコンピュータ
・システムのブロック図である。

【図２】圧縮テクスチャ・データの可変長ブロックをメ
モリ・システムに記憶する第１の技法を示すブロック図
である。

【図３】図２の圧縮テクスチャ・データ・ブロックの開
始アドレスおよびブロック・サイズを決定する方法を示
すブロック図である。

【図４】圧縮テクスチャ・データの可変長ブロックをメ
モリ・システムに記憶する第２の技法を示すブロック図
である。

【図５】圧縮テクスチャ・データの可変長ブロックをメ
モリ・システムに記憶する第３の技法を示すブロック図
である。

【図６】図４および図５の圧縮テクスチャ・データ・セ
グメントの開始アドレスを決定する方法を示すブロック
図である。

【図７】図５のデータ構造から圧縮テクスチャ・データ
を取り出す時使用できるバッファおよびデータ経路のブ
ロック図である。

【図８】本発明の１つの好ましい実施形態に従ってメモ
リ・システムから圧縮テクスチャ・データを取り出す第
１の方法を示す流れ図である。

【図９】図８の方法に対する修正部分を示す流れ図であ
る。

【図１０】テクスチャ・データを圧縮するために使用す
ることができる符号化の従来技術の１つのタイプを示す
ブロック図である。

【図１１】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第２の方法を示す流れ図である。

【図１２】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第３の方法を示す流れ図である。

【図１３】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第４の方法を示す流れ図である。

【図１４】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第５の方法を示す流れ図である。

【図１５】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第５の方法を示す流れ図である。

【図１６】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第５の方法を示す流れ図である。

【図１７】本発明の１つの好ましい実施形態に従ってメ
モリ・システムから圧縮テクスチャ・データを取り出す
第６の方法を示す流れ図である。

【符号の説明】

１０４ システム・メモリ ２０２ 非圧縮テクスチャ・マップ ４００ データ構造 ４０２ 基底アドレス ４０４、４０６、４０８ 未使用部分

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平10−307925（ＪＰ，Ａ) 特開 平10−98719（ＪＰ，Ａ) 特開 平10−11594（ＪＰ，Ａ) 特開 平９−326041（ＪＰ，Ａ) 特開 平９−16785（ＪＰ，Ａ) 特開 平８−339267（ＪＰ，Ａ) 特開 平８−339262（ＪＰ，Ａ) 特開 平８−314798（ＪＰ，Ａ) 特開 平８−314689（ＪＰ，Ａ) 特開 平８−221249（ＪＰ，Ａ) 特開 平８−163560（ＪＰ，Ａ) 特開 平８−102141（ＪＰ，Ａ) 特開 平８−87398（ＪＰ，Ａ) 特開 平５−37790（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06T 15/00 300 G06F 5/00 G06F 12/04 530 H03M 7/30 ＪＩＣＳＴファイル（ＪＯＩＳ)

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】ホスト・コンピュータ・システムのフレー
   ム・バッファ・メモリから独立した、該ホスト・コンピ
   ュータ・システムのシステム・メモリに記憶される圧縮
   テクスチャ・データ構造であって、 第１セグメント開始メモリ位置から始まって第１セグメ
   ント終了メモリ位置で終了し、第１セグメント長を有
   し、可変の、第１圧縮テクスチャ・データ・ブロック長
   を持つ第１圧縮テクスチャ・データ・ブロックを内包す
   る第１圧縮テクスチャ・データ・セグメントと、 第２セグメント開始メモリ位置から始まって第２セグメ
   ント終了メモリ位置で終了し、第２セグメント長を有
   し、可変の、第２圧縮テクスチャ・データ・ブロック長
   を持つ第２圧縮テクスチャ・データ・ブロックを内包す
   る第２圧縮テクスチャ・データ・セグメントとを備え、 前記第２セグメント開始メモリ位置は前記第１セグメン
   ト終了メモリ位置に連続して配置され、 前記第１および第２セグメント長は等しく前記等しいセ
   グメント長は、未使用部分によって無駄となるシステム
   ・メモリの量を最小限度にとどめるように、最大の圧縮
   テクスチャ・データ・ブロックに基づいて定められる圧
   縮テクスチャ・データ構造。
2. 【請求項２】前記第１圧縮テクスチャ・データ・ブロッ
   クは前記第１セグメント開始メモリ位置から開始し、前
   記第２圧縮テクスチャ・データ・ブロックは前記第２セ
   グメント開始メモリ位置から開始する、請求項１に記載
   の圧縮テクスチャ・データ構造。
3. 【請求項３】前記第１圧縮テクスチャ・データ・セグメ
   ントが第１の長さインジケータを含み、該第１の長さイ
   ンジケータは前記第１圧縮テクスチャ・データ・ブロッ
   ク長を決定するためコンピュータ・グラフィックス・シ
   ステムによって使用される、請求項１に記載の圧縮テク
   スチャ・データ構造。
4. 【請求項４】前記第１の長さインジケータが第１ヘッダ
   の内部に含まれ、該第１ヘッダは前記第１セグメント開
   始メモリ位置から始まる、請求項３に記載の圧縮テクス
   チャ・データ構造。
5. 【請求項５】前記第１圧縮テクスチャ・データ・ブロッ
   クが第１圧縮ブロック開始メモリ位置から始まり、前記
   第１ヘッダが第１ヘッダ終了メモリ位置で終了し、前記
   第１圧縮ブロック開始メモリ位置が前記第１ヘッダ終了
   メモリ位置に隣接する、請求項４に記載の圧縮テクスチ
   ャ・データ構造。
6. 【請求項６】前記第１圧縮テクスチャ・データ・セグメ
   ントが第１圧縮／伸張タイプ・インディケータを含み、
   該第１圧縮／伸張タイプ・インディケータは、前記第１
   圧縮テクスチャ・データ・ブロックを伸張する際に使用
   する伸張アルゴリズムを選択するため、コンピュータ・
   グラフィックス・システムによって使用される、請求項
   １に記載の圧縮テクスチャ・データ構造。
7. 【請求項７】前記第１圧縮／伸張タイプ・インディケー
   タが、前記第１セグメント開始メモリ位置から始まる前
   記第１ヘッダの内部に含められる、請求項６に記載の圧
   縮テクスチャ・データ構造。
8. 【請求項８】前記第１および第２の圧縮テクスチャ・デ
   ータ・ブロックが、非圧縮テクスチャ・マップの第１お
   よび第２の非圧縮ブロックの圧縮表現を含む、請求項１
   に記載の圧縮テクスチャ・データ構造。