JP4409956B2 - 集中型対話グラフィカルアプリケーションサーバ - Google Patents

Description

本発明は、ゲームソフトウェア等の対話型ソフトウェアの動作に関し、詳細には、集中型コンピュータプラットフォーム上のソフトウェアのホスト役を改善するための画像圧縮におけるオブジェクト識別および動き推定に関する。

ゲーム等の対話型ソフトウェアの分野では、普通には、対話型ソフトウェアつまりゲームを実行したい者は、ＰＣ（パーソナルコンピュータ）または任天堂^ＴＭゲームキューブ^ＴＭまたはソニー^ＴＭのプレイステーション２^ＴＭ等のゲームコンソールを使用して行うことがある。最新のゲームソフトウェアは、強力なプロセッサおよびグラフィックスレンダラを持つマシンを必要とする。ソフトウェアの新版がでるたびに、ハードウェアの能力を限界まで負荷をかけ、ハードウェアの所有者がそのハードウェアを定期的に更新または置換しなければならない出費を被ることを余儀なくさせる。

普通の状況での更なる問題は、数多くのハードウェアプラットフォームが存在することである。セガドリームキャスト^ＴＭ上で実行するゲームは、ＰＣまたはソニープレイステーション^ＴＭ上で実行するよう、おおむね書換える必要がある。従って、ゲーム開発者がゲームの市場潜在能力を十二分に活用し、その一方で消費者が特定のゲームを楽しむことができるのに先立ち適切なハードウェアを所有しなければならないことは費用がかかる。

さまざまな既知の関連技術があり、それを以下で説明する。

ゲームサーバは、Quake^TM等の多数プレーヤゲームを可能にし、所与のゲームに参加している全ての他のプレーヤの場所および動作と通信する中央ゲートウェイとして単に振舞う。それでも各プレーヤは、ゲームのローカルコピー、およびソフトウェアを処理しゲームに連係する全ての画像をレンダリングする能力のあるローカル装置を必要とすることになる。

ゲームストリーマ技術は、ゲームをチャンクに分割して、ゲームをダウンロードしたいユーザが全てのゲームをダウンロードする前にプレーを開始することを可能にする。ゲームがプレーされている間にダウンロードは継続する。これはソフトウェアを配布するより簡便な様式である。

グラフィックスストリーミング技術は、メッシュ（オブジェクトのワイヤーフレーム記述）およびテクスチャ（スキン）等のグラフィックス要素をストリーミングする。中でも、動画像およびオーディオデータを圧縮するための、およびビデオとオーディオデータストリームとを同期化するための標準であるＭＰＥＧ−４（Motion Picture Expert Group）は、遠隔のレンダラへの送信のためにメッシュおよびテクスチャを圧縮する方法を含む。この技術を利用するシステムは、ゲーム自体がクライアントまたはサーバマシン上で実行され得る一方で、それでも画像をレンダリングする能力のある強力なクライアントを必要とすることになる。

ウェブに基づくゲームは、Java^TMまたはShockwave^TM等の技術を使用して、ウェブページを介してゲームを提供する。しかし、サーバ上で処理されているのでなく、グラフィックス要素が圧縮されているかもしれないとはいえ、ソフトウェアは、それでもユーザのクライアントマシン上で実行され、グラフィックスはそれでもクライアントにおいてもレンダリングされる。

集中型ゲームサーバは、別の既知の技術であり、それは本発明の特定の分野である。中央サーバ上でゲームを処理し画像をレンダリングすることによって、ユーザは、デジタル加入者線（ＤＳＬ）等のブロードバンド通信ネットワーク、ケーブルまたは第３世代（３Ｇ）無線ネットワークへ接続されたゲームをプレーできる。

そのようなシステムは、専用の（そして高価な）ゲームコンソールを購入する、またはＰＣが最新のプロセッサおよびグラフィックスカードで常に更新される必要性を除去する。ゲームをプレーする希望の人々は、即座に彼らのケーブルＴＶ会社経由で彼らの既に据付のセットトップボックスを使用してゲームサービスへ加入できる。ケーブルＴＶ会社はこのように新規収入の路を見出し、ゲーム開発者は少ない配布コストで広い市場へのアクセスを有し、そして最終ユーザは高価な専用機器へ投資する必要なくゲームに手を出す機会を持つ。

これらのネットワークは通常の電話線と比較するとき比較的広い帯域幅を有するとはいえ、高級ゲームに対するグラフィックス画像は、それでも送信の前に高度に圧縮される必要がある。総体的なシステムの待ち時間がゲームのプレー体験を損なわないように、そのような圧縮は非常に速い必要がある。

それぞれのユーザが新型ゲームの複雑なグラフィックスをレンダリングする能力のある自分用の「インテリジェント」な装置を有する代りに、処理は中央サーバが引き受ける。ゲームに関する画像は、ハブで圧縮され、末端ユーザへブロードバンドネットワークの上で送信され、末端ユーザは、画像を見て、中央サーバ上で実行しているゲームソフトウェアと対話することに比較的「頭の鈍い」端末を使用する。

この中央サーバは、ゲームソフトウェアの多数のコピー、圧縮システム、および送信システムを実行することに十分に強力である必要があり、それによりサーバは異なるゲームを同時にプレーしているかもしれない大多数の同時ユーザに奉仕できる。

そのような集中型ゲームサーバの更なる利点は：
− ユーザは、最新のゲームをプレーすることに十分に強力な専用ハードウェアを所有する必要がない；
− 同じ機器を再利用することによって、サービスプロバイダ（普通にはケーブルＴＶ会社または通信会社）は、各顧客にゲームコンソールまたはＰＣを提供することによってよりはるかに費用効率良くこのサービスを供与できる；
− ゲーム開発者は、ユーザの所有する適切なハードウェアに依存することなく、ただ単に家庭、事務所等のブロードバンドネットワークへ、もしくは、例えば３Ｇまたは「WiFi」無線ネットワーク経由で携帯装置への接続だけで、広範囲の視聴者へのアクセスを有することができる；
− ゲーム更新およびバグフィックスは、即座にそして自動的に実行できる；そして
− オンライン、多数プレーヤの不正行為は、「不正モード」を遮断することによって削減できる。

しかし、そのようなシステムを動作させるために、克服されなければならない２つの技術的な問題がある。
− 圧縮の品質：画像は、ケーブルＴＶまたはＤＳＬ等の普通の国内のブロードバンドネットワークの上で送信できるように高度に圧縮されなければならない；および
− ネットワークの待ち時間：圧縮システムは非常に迅速に動作しなくてはならない。ユーザが制御を催促すること、連係するコマンドがサーバによって処理されること、新規シーンが計算され、圧縮され、送信され、そして次いで圧縮復元されることの間の遅延は、ユーザにとって無視できなければならない。

ニュージャージー州Murray HillのLucentへの米国特許第５，７４２，２８９号は、グラフィックスレンダリングおよび符号化を持つゲーム処理を集中型ゲームサーバ内にカプセル化するシステムを開示している。そのため、それは、合成画像をその画像のレンダリングと並列に圧縮できる。特許は、コンピュータグラフィックスシステムの特徴を持つシステムおよび方法を開示し、ＭＰＥＧ符号化を含む。システムは、動きベクトルを含む２Ｄ画像の詳細なモデルを使用し、そして圧縮援助データをエンコーダへ向けて回送し、それにより符号化処理を単純化する。完結したシステムは、３Ｄ画像の共有データベース、ハイブリッドレンダリングエンジン、および接続されたビデオエンコーダを含む。

一般的に、ゲームグラフィックスは、本明細書でグラフィックス演算処理装置（ＧＰＵ）と称される専用のグラフィックスプロセッサを使用してレンダリングされる。米国５，７４２，２８９のシステムでの問題は、標準的グラフィックスプロセッサの使用を許容せず、従って、大多数の汎用プロセッサだけでなく、グラフィックス処理を実行するよう特別に書かれたソフトウェアも必要とすることである。更に、ゲームソフトウェアは、この新規処理プラットフォーム上で実行するよう特別に書かれていなければならない。

論文「動的ポリゴンのシーンの高速化ＭＰＥＧ圧縮」で Dan S. Wallach, Sharma Kunapalli, and Michael F. Cohenは、Computer Graphics (Proc, SIGGRAPH 1994), July 1994 で、多くのグラフィックスワークステーションに存在するマトリクス−ベクトル乗算および走査転換を使用して、シーンにおける光の流れを急速に近似するための方法論を説明している。光の流れは、各画素の画面上の動きを記述する２Ｄのベクトルフィールドである。ＭＰＥＧ圧縮への光の流れの適用が説明されており、結果的に、最小限のオーバヘッドで圧縮を改善している。

システムは、２フレームからの変換マトリクスを格納し、シーンにある全てのオブジェクト上へそれが投影する「身元証明テクスチャ」を使用し、それによりそれはオブジェクトと画面との間の関係を見出すことができる。この手法での問題は、それがマトリクスでだけ動作することである。それは、例えば水のさざ波を模倣することに余弦を使用できるＧＰＵの頂点シェーダプログラムに対処していない。

総体的に、既知の手法での第１の問題は、頂点の変換は中央演算処理装置（ＣＰＵ）上で行われ、結果がローカルメモリに格納され、容易に抽出されることを手法が想定していることである。これは、ゲームがその中に取り込まれた、圧縮関連のタスクを実行するルーチンを持たねばならぬことを意味する。特別に書かれたゲームコードを有する必要がないことは有利であろう。

第２の問題は、ＧＰＵが使用される時、ＧＰＵは当然ながら頂点変換処理の結果を格納しないから、そのデータを抽出および格納することに特別の技法が必要とされる。

モジュール方式で標準的構成要素を使用して実現され、これらの問題に対する商業的に実行可能なソリューションを作成する能力のあるシステムを提供することが有利であろう。

本発明の目的は、ホスト役の対話グラフィカルシステムにおいて圧縮の品質を改善し、待ち時間を低減することである。

本発明の第１の局面に従えば、少なくとも１つのグラフィックスプロセッサモジュールを使用して圧縮ビデオデータ信号を生成する方法が提供され、方法は：
ａ）グラフィックスプロセッサモジュールのための第１セットの命令を受け取るステップ；
ｂ）前記第１のセットの命令を傍受し、グラフィックスプロセッサモジュールのための第２セットの命令を生成するステップ；
ｃ）第１のグラフィックスデータを生成するよう前記第１セットの命令または前記第２セットの命令をグラフィックスプロセッサモジュールにおいて処理するステップ；
ｄ）第２グラフィックスデータを生成するよう前記第２セットの命令を処理するステップ；
ｅ）圧縮援助データを生成するよう前記第２グラフィックスデータを処理するステップ；および
ｆ）圧縮ビデオデータ信号を生成するよう、前記圧縮援助データを使用して、前記第１のグラフィックスデータを処理するステップ；
を含む。

本発明の第２局面に従うと、圧縮されたビデオデータ信号を生成するための装置が提供され、装置は少なくとも１つのグラフィックスプロセッサモジュールを備え、装置は：
ａ）グラフィックスプロセッサモジュールのための第１セットの命令を受け取るため、そしてグラフィックスプロセッサモジュールのための第２セットの命令を生成するための命令傍受機能；
ｂ）第１のグラフィックスデータを生成するよう前記第１セットの命令または前記第２セットの命令をグラフィックスプロセッサモジュール内で処理するための処理機能；
ｃ）第２のグラフィックスデータを生成するよう前記第２セットの命令を処理するための処理機能；
ｄ）圧縮援助データを生成するよう前記第２のグラフィックスデータを処理するための処理機能；および
ｅ）圧縮ビデオデータ信号を生成するよう、前記圧縮援助データを使用して、前記第１のグラフィックスデータを処理するための符号化機能；
を備える。

本発明は、コンピュータ生成グラフィックスのための圧縮の品質を改善することに使用されてよい。数多くの圧縮技術が現今利用可能であり、その全てが常に進化している。柔軟性を最大限にするために、可能な限りモジュール式のシステムを有することがそれ故に重要であり、それにより完結したソリューションの完全性に影響を及ぼすことなく圧縮ステージ（段）が置換または更新できよう。

圧縮技術の１つの例は、業界標準のＭＰＥＧ−４である。それは画像の符号化の方法を定義せず、ビットストリームのプロトコルおよび復号化の方法だけであるのは異例である。それはまた、圧縮方法のツールキットも提供する。それを適用する時期と方法の決定プロセスは、実装ごとに変化して、大幅に異なる画像品質および圧縮比の結果となる。

ＭＰＥＧ−４エンコーダへ利用可能な１つのオプションは、画像の中で別体のグラフィックオブジェクトの符号化である。例えば、歩く像で、その人が歩いているフィールドの背景画像と区別できる。歩く人像を別体のオブジェクトとして符号化することはより高い圧縮比を引き出せるとはいえ、背景シーンからオブジェクトを隔離することは複雑でプロセッサ集約的な処理である。

コンピュータグラフィックスから等の合成ビデオで作業する利点は、その画像の個々の構成成分（オブジェクト）が既知であることである。自然のビデオの場合には、エンコーダは、最初に画像を分解しなければならない。ここでは、画像がレンダリングされる前にオブジェクトの定義を抽出することによって、処理負荷は軽減される。

本発明の好ましい実施形態に従うと、圧縮援助データは動きベクトルデータを含む。画像をＭＰＥＧ−４データ圧縮で符号化する時に提供され得る圧縮援助データの他の種類の幾つかの例は：
− 別体オブジェクトとして−あるとすれば−符号化するシーンの部分、（最大数があるので）
− オブジェクト上に使用する符号化の形式
− 形状の符号化で透明オブジェクトとするか実体とするか
− 単に前回画像からの変化ではなく全画像を送信する頻度（誤り訂正と帯域幅の間に交換代償があるので）
− 重なり合った動き推定の使用可否

これらの決定をすることに使用される判定基準は以下を含む：
− 解析をすることに必要とされる処理時間／労力
− 帯域幅「割付」の残り
− 最低画像品質の制約

本発明は、ネットワークの待ち時間を改善することにも使用されてよい。ネットワークの待ち時間は、符号化サブシステムの速度に依存し、それはそれ自体で圧縮の品質と所要処理能力との間の交換代償である。速度を改善するために、本発明は、圧縮されるべき画像のレンダリングと並行して幾つかの符号化ステップを処理することを探求する。更に、本発明は、自然ビデオ画像の場合に通常であろうように逆行分析する必要なく画像についての情報が容易に抽出できる様式を探求する。

本発明は、それ故に以下の設計制約の中で開発された：
− デバッギングおよび更新の容易さのためのモジュール方式（ゲームソフトウェアの処理、画像のレンダリング、画像の符号化の機能の分離）
− 最小限の（または更に良い無）変更で既存のゲームソフトウェアを実行する能力
− 例えばグラフィックスプロセッサで、可能な限り既製の構成要素を使用する能力

命令傍受機能はデバイスドライバであってよい。代替として、命令傍受機能は、DirectX^TMまたはOpenGL^TMのためのラッパー構成要素である。

命令傍受機能は、異なる命令を異なるグラフィックスプロセッサモジュールへ入力するように成されてもよい。

オプションで、複数の命令傍受機能は、それぞれが異なる命令を異なるグラフィックスプロセッサモジュールへ入力するように成されてもよい。

好ましくは、命令はグラフィカルデータを含む。オプションで、命令はプログラムコードを含んでもよい。好ましくは、命令はテクスチャを含む。

オプションで、異なる命令間の差分はライティング命令を含む。好ましくは、異なる命令間の差分はシェーディング命令を含む。

好ましくは、命令は、更に、３次元シーン情報を含む。同じ３次元シーン情報は各グラフィックスプロセッサモジュールへ供給されてもよい。

好ましくは、第１グラフィックスプロセッサモジュールへ供給される命令はテクスチャを含み、第２プロセッサモジュールへ供給される命令は異なる新規オブジェクトテクスチャを含む。一実施形態において、新規オブジェクトテクスチャのそれぞれは、画像フレームにおいて各オブジェクトに対する一意的なテクスチャである。好ましくは、新規オブジェクトテクスチャは、オブジェクトの隣り合ったポリゴンのテクスチャの２つが同じでないように特定される。新規オブジェクトテクスチャは、ビデオのその後のフレームで再配向されてもよい。一実施形態において、新規オブジェクトテクスチャは一様な色である。

代替として、少なくとも１つのグラフィックスプロセッサモジュールへ供給される命令は、それに新規オブジェクトテクスチャを生成させる。

一実施形態において、オブジェクトの部分（単数または複数）とその２Ｄ画面描写との間の関係は、２以上のフレーム間で比較するために一時記憶装置に収納される。好ましくは、それはテクスチャとして格納される。好ましくは、オブジェクト当りこれらのテクスチャの１つ、２つ以上、または全てのオブジェクトによって共有される１つがある。

一実施形態において、頂点マッピングへのテクスチャは、一定のオフセットを追加することによって「一意的なテクスチャ空間」を達成するよう再マップされる。好ましくは、頂点マッピングへのテクスチャは、オフセットを変化させることによって「一意的なテクスチャ空間」を達成するよう再マップされる。

代替として、「一意的なテクスチャ空間」は、同じサイズの新規テクスチャを作成し、元におけるように大多数のポリゴンにそれを分割し、そしてオブジェクト頂点を一意的なポリゴンへ新規テクスチャから再マップすることによって達成されてもよい。

一実施形態において、オブジェクトの各一部分がいずれかの時点で画面上に出現する場所を識別する目的で、画面の画素に対応する「基準」テクスチャが画面上へ投影される。好ましくは、少なくとも１つのグラフィックスプロセッサモジュールへ供給される命令は、画像フレームを作り上げるシーン全体を覆い、前記シーンに現存するオブジェクトの表面と結合する単一テクスチャをモジュールに生成させ、新規オブジェクトテクスチャを作成する。普通には、前記単一テクスチャはシーンの中のオブジェクト上へ投影される。好ましくは、単一テクスチャを生成するステップは、更に、オブジェクトの表面を初期値に設定すること、および次いでオブジェクトに対する新規表面テクスチャを作成および適用するように単一テクスチャを変更することを含む。好ましくは、初期値はオブジェクトが透明かどうかを指示し、好ましくは、初期値は画像フレーム内の各オブジェクトにとり一意的である。

一実施形態において、援助データ生成機能は、第２グラフィックスデータに応答してオブジェクトの形状を特定するように成される。

別の実施形態で、援助データ生成機能は、第２グラフィックスデータに応答して画像要素の位置を特定するように成される。

好ましくは、符号化機能は、圧縮援助データに応答して第１グラフィックスプロセッサモジュールによってレンダリングされた画像から個々の画像要素を選択するように成される。

オプションで、新規オブジェクトテクスチャは、オブジェクトが透明であることを符号化機能へ知らせることに使用されてもよい。

好ましくは、符号化機能は全面的シーン変更を検出するように成される。より好ましくは、符号化機能は、全面的シーン変更の検出に応答して異なる圧縮方法を使用するように成される。

好ましくは、各グラフィックスプロセッサモジュールは、普通にはグラフィックスチップの形式での専用のグラフィックスプロセッサを備える。オプションで、機能的に実質的に同一である２つ以上の専用グラフィックスプロセッサが使用される。

代替として、２つ以上のグラフィックスプロセッサモジュール、それの機能は、例えば多数タイムスライス処理方式を使用して単一の専用グラフィックスプロセッサ上に実装されてもよい。

グラフィックスプロセッサモジュールは、１つ以上の圧縮サブシステム間で共有されてもよい。単一の専用グラフィックスプロセッサは、フレームをレンダリングすることに最終ディスプレイレートより高い周波数でクロックされてもよい。

好ましくは、レンダリングされたフレームは、符号化機能が処理するようバッファメモリに格納される。

ハンドシェイク信号伝達が、処理を調製するよう符号化機能と命令傍受モジュールとの間で使用されてもよい。

好ましくは、新規オブジェクトテクスチャは、フレーム内の位置に対応して変化する数値を含んでもよい。

より好ましくは、新規オブジェクトテクスチャは、水平座標に対応して変化する１つの数値、および垂直座標に対応して変化する別の１つの数値を含む。

好ましくは、援助データ生成機能は、オブジェクトテクスチャを比較することによってフレーム間の動きを検出するように成される。

オプションで、援助データ生成機能は、前回に画像フレーム全体にわたり適用されたテクスチャにおけるものに対してオブジェクト上の画素を比較することによってフレーム間の動きを検出するように成される。

オプションで、援助データ生成機能は、オブジェクトの部分を形成するまたはそのオブジェクトの位置に関する１つ以上の頂点へ「タグ付き」された情報を比較することによってフレーム間の動きを検出するように成される。タグは、例えば明度であってよい。タグは、代替として、頂点に連係する他のデータを含んでもよい。

普通には、タグは、レンダリング処理に影響を与えることに使用され、それにより前記頂点の位置はそれが関連したオブジェクトがレンダリングされる時に容易に識別できる。レンダリングは、例えばレンダリングされた画像内の画素の色または輝度を変化させることにより影響を与えられてもよい。

オプションで、援助データ生成機能は、オブジェクトの部分（単数または複数）とその２Ｄ画面描写との間の関係を比較することによってフレーム間の動きを検出するように成され、ここでそのような関係は前回に一時記憶装置に収納された。記憶は、オブジェクト当り１つ以上のテクスチャ、または２つ以上のオブジェクトによって共有されたテクスチャであってもよい。

オプションで、オブジェクト上の画素の比較は、概念的な固定のグリッドつまり点に対するものであってもよい。普通には、比較は、少なくとも１つの画素座標で選択されたビットをマスクすることを含む。好ましくは、比較は少なくとも１つの減算を含む。好ましくは、減算は、前記テクスチャが同じオブジェクトの同じポリゴンに属する場合にだけ発生する。オプションで、比較は、更に、前記減算の結果を集計するステップを含む。普通には、集計は平均化することを含む。オプションで、集計することは平均を推測することを含む。

好ましくは、援助データ生成機能は、ブロック全体に対する動きベクトルを、そのブロックを占有するオブジェクトの部分の動きベクトルを集計することによって生成するように成される。普通には、集計することは平均化することを含む。オプションで、集計することは平均を推測することを含む。

好ましくは、援助データ生成機能は、オブジェクト全体に対する動きベクトルを、ブロックのそれぞれにある所与のオブジェクトに属する画素を検出し、これらの画素を別フレーム内の同じ場所にあるものと比較し、そして比較された画素を集計することによって生成するように成されて、そのオブジェクトの動きベクトルを推測する。普通には、検出された画素を集計することは平均化することを含む。普通には、比較は、少なくとも１つの座標で選択されたビットをマスクすることを含む。好ましくは、比較は、少なくとも１つの座標での減算を含み、ここで前記テクスチャは同じオブジェクトに属する。好ましくは、動きベクトルを適用するオブジェクト全体は、オブジェクトに連係すると見なされる全てのブロックを含む。

オプションで、第１グラフィックスプロセッサモジュールへ供給された命令からのパラメータは、格納され、次いで第２フレームからのパラメータで処理されて、それによって圧縮援助データの一部を形成するフレーム間の差分を特定する。

本発明の代替の実施形態では、第２セットの命令は、頂点シェーダプログラムまたは画素シェーダプログラム等のプログラム可能なパイプラインモジュールのための修正されたまたは新規セットのプログラムコードを含む。

方法は、第１パラメータを処理するようプログラム可能なパイプラインモジュール上のプログラムを実行すること、それによって第１変換結果を特定すること、および、第２パラメータを処理するようプログラム可能なパイプラインモジュール上のプログラムを実行すること、それによって第２変換結果を特定することを含んでよい。

普通には、変換結果は画面位置に直接的に関連し、特定されたフレーム間の差分値は動きベクトルの形式で特定されてよい。

オプションで、変換結果は色であり、特定されたフレーム間の差分値は色度または輝度における差分である。

好ましくは、方法は、更に、プログラム可能なパイプラインモジュールのための第１プログラムを解析すること、それで圧縮援助データのために使用されるフレーム内のオブジェクトの状態に影響を与えない命令を特定し、および特定された命令に応答してプログラム可能なパイプラインモジュールのための第２プログラムを作成することを含む。

好ましくは、プログラム可能なパイプラインモジュールのための第１プログラムを解析するステップは、オブジェクトの位置変換に影響を与えるパラメータを特定すること、および特定されたパラメータを格納することを含む。

オプションで、プログラム可能なパイプラインモジュールのための第１プログラムを解析するステップは、オブジェクトの色または輝度に影響を与えるパラメータを特定すること、および特定されたパラメータを格納することを含む。

好ましくは、プログラム可能なパイプラインモジュールのための第１プログラムおよびプログラム可能なパイプラインモジュールのための第２プログラムは、同じグラフィックス処理モジュール上で実行される。

代替として、プログラム可能なパイプラインモジュールのための第１プログラムおよびプログラム可能なパイプラインモジュールのための第２プログラムは、異なるグラフィックス処理モジュール上で実行される。

好ましくは、グラフィックス処理モジュールのためのグラフィックスのアプリケーション・プログラミング・インタフェース（ＡＰＩ）（時にはミドルウェアと称される）の周りのデバイスドライバまたはラッパーは、デバイスドライバの質問に利用可能なプログラム記憶スペースの低減された値を返答することによってグラフィックス処理モジュール上のプログラム可能なパイプラインモジュールのためのプログラム記憶スペースを用意しておくように成される。

より好ましくは、グラフィックス処理モジュールのためのグラフィックスＡＰＩの周りのデバイスドライバまたはラッパーは、デバイスドライバの質問に利用可能なデータ記憶スペースの低減された値を返答することによってグラフィックス処理モジュール上のプログラム可能なパイプラインモジュールのためのデータ記憶スペースを用意しておくよう成される。

本発明のより良い理解を提供するために、実施形態を以下に、単なる例として、添付図を参照して説明する。

本発明は、コンピュータ生成グラフィックスを含むビデオ画像を表す圧縮データストリームを生成するよう機能する対話型アプリケーションのためのシステムに関する。コンピュータ生成グラフィックスの分野に関する情報は、教科書「３Ｄコンピュータグラフィックス（3D Computer Graphics）」第３版, Alan Watt, Addison-Wesley, 2000 に見出すことができる。

普通には、コンピュータ生成３Ｄグラフィック図は、３Ｄオブジェクトの形状を定義するポリゴンのメッシュ、およびテクスチャマッピング処理を使用してメッシュ全体にあるテクスチャの形で生成される。本明細書中で、用語「グラフィックオブジェクト」は、グラフィック図、単一の頂点、頂点のグループ、「スプライト」（画素の集合）、もしくは「ベジェパッチ」または「ｎパッチ」機能オブジェクトに対するパラメータを称するであろう。多くの別体のグラフィックオブジェクトは、より少ない数の論理オブジェクトに結合されてもよく、例えば、壁および床は単一のオブジェクトであると定義され、従って同じテクスチャで被覆されてもよい。本明細書中で、用語「一様な色」は、その表面にわたり変化のない単一色を称する。

図１を参照すると、本発明に従う対話型アプリケーションのためのシステム１０は、命令傍受モジュール１１、メイングラフィックスプロセッサ１２、命令傍受モジュールに応答する補助グラフィックスプロセッサ１３、およびグラフィックスプロセッサに応答するエンコーダ１４を有する。この実施形態では、エンコーダはＤＳＰであり、代替としてエンコーダは、グラフィックスプロセッサ、いずれのＣＰＵ、または他の処理装置であってもよい。この実施形態では、命令傍受モジュールはデバイスドライバであり、代替として命令傍受モジュールは、DirectX^TMまたはOpenGL^TM等の既存のミドルウェアへの追加である。この実施形態では、１つの命令傍受モジュールが２つのグラフィックスプロセッサへ供給するが、別の実施形態では、２つ以上の命令傍受モジュール、例えばグラフィックスプロセッサ毎に１つあってもよい。メイングラフィックスプロセッサおよび補助グラフィックスプロセッサは、グラフィックスプロセッサモジュールである。それらは別々のハードウェアユニット、または１つのハードウェアユニット上で実行される別々の処理であってもよい。

図２は、ゲームソフトウェア２１、３Ｄグラフィックスミドルウェア２２、デバイスドライバ２３、専用グラフィックスプロセッサカード２４、レンダリング画像２５、および圧縮システムまたはエンコーダ２６を備えるゲームの処理のための代表的パイプラインを示す。点線ＡからＥは、圧縮サブシステムにおける符号化処理によって用いられてもよい情報の異なるソースを示す。

普通のゲームの複雑なシーンをレンダリングするため、莫大な処理能力を必要とするので、グラフィックスは、通常、専用グラフィックスプロセッサチップによってレンダリングされる。ＰＣではチップは通常別体のカードに搭載されており、コンソールでは、それはメインボックス内の別体のチップとなっている。

ゲームソフトウェア２１は、グラフィックスプロセッサ２４に、オブジェクトを記述する点の３Ｄ座標、３Ｄ空間におけるそれらの位置、それらの歪み方法（例えば、レーシングカーにおけるへこみ傷）、それを覆うべきスキン（「テクスチャ」）の種類、それらのライティングまたはシェード方法（これ故にテクスチャの更なる変更方法）を含む３Ｄシーン記述を供給する。大量の処理に続き、コンピュータモニタ等の装置上で観るために適した完全にレンダリングされた２Ｄ画像２５が作成される。

図３は、グラフィックスプロセッサによってシーンをレンダリングする代表的処理フローを示す。ステップには：形状の移動および歪みを含む変換３１；シーンのライティングおよびシェーディングを含むライティング３２；他のオブジェクトを隠すオブジェクトを処理することを伴う設定およびクリッピング３３；および、最終シーンの描画であるレンダリング３４がある。

図２を参照すると、グラフィックスプロセッサの前にオブジェクトの形状および位置についての情報を取得しようと試みる（経路ＣからＥの）困難は、オブジェクトの位置および形状がグラフィックスプロセッサの変換ステップ３１を通過するまで特定されていないことにある。オブジェクトが３Ｄ空間にあるので、他と重なり合うオブジェクトについての知識は、グラフィックスプロセッサによってレンダリングされるまで入手できない。

ソースＡから情報を得ることは、並列処理が実行できないことを意味するであろうし、ソースＢ、グラフィックスプロセッサから情報を得ることは、どの時点でも市場で既に入手できる最良のものを使用する代りに新規のグラフィックスチップを開発しなければならないことを意味するであろう。

図１を参照すると、本発明では、命令傍受モジュール１１は、補助グラフィックスプロセッサに供給する。

この接続形態では、メイングラフィックスプロセッサ１２は、普及しているコンピュータグラフィックスカードまたはゲームコンソールで用いられるような標準的デバイスであり、通常のように動作する。補助プロセッサは、並列に動作するが、エンコーダの要求事項に従い異なるセットの命令を供給される。

［オブジェクト識別（Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）］
個々のグラフィックスオブジェクトの形状および位置を特定するために、命令傍受モジュール１１は、同じ３Ｄシーン命令を補助グラフィックスプロセッサ１３へ供給するが、シーンにおけるテクスチャの変更を最小限に行うようにターンオフまたは変更されたライティングおよびシェーディング局面を持つように設計されている。テクスチャを適用する代りに、第２プロセッサは、一意的な一様な色を使用して各形状をレンダリングするよう命令される。代替として、それは、オブジェクトを一意的に識別するようテクスチャ／色の現在のビット範囲を使用することによって等、それを一意的にする色の局面を有してもよい。次いで、比較的簡単なタスクで、圧縮エンコーダ１４が、オブジェクトの形状および位置を特定し、この情報を使用して、メイングラフィックスプロセッサ１２によって作成された適正にレンダリングされた画像から個々のオブジェクトを選択する。

グラフィックスカードによって使用される論理では、ビット範囲は、色の例えば青色および赤色成分を記述することに用いられる範囲の境界を越えてもよく、全ての緑色範囲および一部の青色範囲は、自由に変更されてもよい。

エンコーダは、以下の２つの要素で構成できる：補助グラフィックスプロセッサユニット（ＧＰＵ）と共に動作して動きベクトル等の特定の詳細を抽出するプリプロセッサと；プリプロセッサから「ショートカット」を受取る「純粋な」エンコーダ。これは既製のＭＰＥＧ−４エンコーダの使用を可能にする。プリプロセッサは、エンコーダ、命令傍受モジュール、ゲームプロセッサ、または別体のプロセッサとして同じプロセッサ上で動作するソフトウェアであってもよい。

色、シェードまたは色コンテンツの所定範囲は、所与の形状が透明であることを知らせることに使用できる。（ＭＰＥＧ−４はオブジェクトが実体であるか、または透明度の２５５レベルの１つを有するかのいずれかを許容する）。

更に、命令傍受モジュールからエンコーダへの直接的フィードフォワード経路１５は、エンコーダが完全なシーン変更を検出できるように使用できる。そのような場合、そのシーンは、差分が過大になるため、前の画像からの差分として圧縮（時間的圧縮）されてはならない。

安価なチップは使用できるが、理想的には補助プロセッサは、レンダリング画像間のいずれの不整合も回避するように、実質的にメインプロセッサと厳密に同じであって、メインプロセッサと同じ解像度で動作する。

多くのこれら補助プロセッサが使用されてもよく、数は、使用されている符号化技術、コスト、スペースおよび電力の配慮による。エンコーダによって必要とされる情報の各要素に対して１つのプロセッサを有することに対する代替として、プロセッサおよびエンコーダが十分に高速な場合、より少ない、実際に潜在的にただ１つのグラフィックスプロセッサが使用されてもよい。従って、２つ以上のグラフィックスプロセッサ機能は、１ユニットの専用グラフィックスプロセッサのハードウェアで実装できる。この筋書きでは、グラフィックスプロセッサは、フレームをレンダリングすることに最終ディスプレイレートより高速にクロック設定でき、結果は、エンコーダが動作するための一連の隣接した重なり合わない場所でバッファメモリ内に格納される。エンコーダと命令傍受モジュールとの間のハンドシェイク信号伝達が、処理を調整する。

［動き推定（Ｍｏｔｉｏｎ Ｅｓｔｉｍａｔｉｏｎ）］
ＭＰＥＧ−４圧縮の最も演算集約的な要素は、「動き推定」であり、それは処理能力の５０％から８０％を消費する。

動画ビデオを圧縮する方法の１つは、ビデオの続くフレーム間の類似点を探索することである。フィールドを横切って歩いている人の例では、カメラが静止している場合、ビデオの各フレームに対してフィールドはほとんど同一であろう。主な変化は、１つのフレームで人がいた場所と一瞬の後にそれに続くフレームで彼が出現する場所との間に発生するであろう。

従来の動き推定では、画面はブロックに分割され、次いで前回フレームのブロックと比較されて、可能な限り近い整合を探索する。識別されると、ブロック全体を送信する代りに、前回送信されたフレームにある特定のブロックを新規フレームにおいてそれが出現する筈の場所から所与のオフセットで見出すことのできる信号が、デコーダへ送信できる。このオフセットは動きベクトルと呼ばれる。

これらのブロックのそれぞれは、ちょうど８ｘ８画素であり得る。検索を行うために、エンコーダは、最初に左へ１画素だけのオフセットを見なければならず、そのブロックの６４画素のそれぞれを試験ブロックのそれらから減算し、次いで左へ１画素および上へ１画素移動させ、再度全ての６４画素を減算し、そして結果を比較する。速い動画シーンでは、オフセットは、全方向において例えば１００画素離れていると言える。この処理は従って演算集約的である。

しかし、本発明のグラフィックスサーバの場合には、複雑さを低減するために、補助グラフィックスプロセッサが、３Ｄオブジェクトのそれぞれを新規テクスチャ（被膜、または「スキン」）で被覆することに使用される。これらのテクスチャは、水平位置で変化するそれらの色の１局面、および垂直位置で変化する別局面を有する。固定の点が画面上で取られ、オブジェクトのテクスチャの画素が２つの引き続くフレーム間でその位置で比較される場合、そのオブジェクトが移動した方向を特定できる。それにより、例えば、その画素が赤色成分でより高い明度を有する場合、それは右へ移動したことが検出される。その画素が青色成分でより高い明度を有する場合、それは下方へ移動したことが検出される。

本発明の１つの実施形態に従えば、３２ビットの画素が使用される（「ビット」は２進数であり、０または１に等しい）。以下は、これらのビットが各画素に割当てられる方法の例である：
uuuuuuuuu aaaaaaaa yyyyyyy xxxxxxx
10 x u （各オブジェクト／テクスチャ結合体に対するユニークコード）
8 x a （アルファ−透明性を示すことに使用される、２５５＝不透明）
7 x X （ｘ軸でのテクスチャの変化量）
7 x Y （ｙ軸でのテクスチャの変化量）

そのため、例を使用するが、理解を容易にするために十進法で、そしてｘとｙの桁だけを考慮する場合、以下のパターンが使用されてもよい：
11 12 13 14
21 22 23 24
31 32 33 34
41 42 43 44

上記のこの例のパターンで、１つ下で左から３番目に置かれた１つの画素を考えるとする。このフレームで、それは数２３を持つ。次のフレームでオブジェクトが左へ１画素だけ移動した場合、装置は画面上で同じ位置に数２４を検出することになろう。「ｘ」桁が３から４へ増大したので、移動は左へ１画素であると検出される。「ｙ」桁、すなわち「２」が１へ減少したとしたら、オブジェクトは１画素だけ下へ移動したであろう。

これらの数はグラフィックスカードによって色と解釈され、それにより３２ビット画素では、１２最上位画素が赤に、次の１０が青に、そして最後の１０が緑に予約されてもよい。

動きベクトルは、ＭＰＥＧ−４の現行版では、８ｘ８または１６ｘ１６のブロックごとの基準で計算される。そのような動きベクトルは、全てのｘ要素の平均および全てのｙ要素の平均を取ることによって計算されてもよい。

このブロックに基づく情報は、所与のオブジェクトに属するブロックのそれぞれにおける画素を検出すること、およびそれらを平均することによってオブジェクト全体（または１つのオブジェクトの部分）に対する動きベクトルを入手することに使用されてもよく、それによりそのオブジェクトの動きベクトルを推測する。（オブジェクトは１つ以上のベクトルを有してもよい、例えば、歩いている人は身体に対して異なって移動する手足を有するであろう）。

オブジェクトが別々に移動するかもしれない副要素を有しない場合、動きベクトルがそのオブジェクトに対して１つのブロックで計算された場合、装置は、そのオブジェクトが大部分の画素を占有する別のブロックの動きベクトルを即座に推測し得る。

動きベクトルは、ブロックまたはマクロブロック基準に適用される。エンコーダは、そのブロックを占有するオブジェクトの部分の動きベクトルを集計することによってブロック全体に対する動きベクトルを生成するように成される。一実施形態において、これは、ブロックにおける各オブジェクトに対する各画素の動きベクトルを計算すること、次いでそのブロックの中の各オブジェクトの動きベクトルを計算すること（それは全画面の上のオブジェクト全体とは異なることがある）、そして次いでそのブロックの動きベクトルをそのブロックの中のオブジェクトの加重平均化を使用して計算することを伴う。

普通には、オブジェクト全体は、これらのブロックの１つがそのオブジェクトに属する画素を実際に含有するか否かにかかわらず、エンコーダによってオブジェクトに連係すると見なされる全てのブロックを含む。動きベクトルは、従って、ブロックの全てへ適用される。

オブジェクトを符号化する場合（内部的に単にオブジェクトを使用するのでなく）、それらは、有界の長方形として、その長方形が１６ｘ１６画素のマクロブロックのグリッドに合致するように定義される。多くのブロックまたはマクロブロックは、まったく空かもしれないが、その「ビデオオブジェクト平面」と、従ってそのオブジェクトに属する。

一実施形態において、各オブジェクトを一意的なテクスチャでラッピングする代りに、方法は、単一の画面サイズのテクスチャをシーン上へ、スライド映写機そっくりに投影すること、次いでそのテクスチャをシーンにある全てのオブジェクトの空白表面と混合すること（すなわち、結び付けること）を伴う。オブジェクトの表面は、「クリーン」にされ、一様な一意的な色で置換されており、それにより個々のオブジェクトは識別できる。ブレンディング処理は、投影された「基準」テクスチャをオブジェクトの表面と結合して、一意的なテクスチャを各オブジェクト上に作成する。移動は、この投影された「布地」に「切り裂き」を生じ、それにより移動は容易に検出できる。基準グリッドは、視聴者と同じ位置に配置される。

この上記方法は、テクスチャをシーン全体上へ投影することを伴う。この処理は、テクスチャを後部平面（シーンで目に見える最遠の平面）上へマップする「投影マトリクス」を最初に特定することを含む。このマトリクスは次いで各オブジェクト上に使用され、それによりそのテクスチャマッピングを投影されたテクスチャへ設定する。内在するステップは、グラフィックスプログラミングに精通する者にとってよく知られているであろう。

投影されたテクスチャが以下のパターンを有する場合：
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

パターンの中央左にある３ｘ３画素正方形で、左へ１画素だけの移動の後に、以下のパターンが得られる：
1 2 3 4 5 6
8 9 10 0 11 12
14 15 16 0 17 18
20 21 22 0 23 24
25 26 27 28 29 30

１つの計算パスがテクスチャを投影することに使用され、シーンが移動され、そしてＧＰＵが変換計算を実行し、画面上の画素を移動させる−これは第２パスである。シーンは、投影されたテクスチャを移動させること、およびオブジェクトの表面をその初期状態にリセットすることによってリセットされて、テクスチャを再投影する。全ての処理は２パスを要する（リセットすることおよび投影することは１パスで生じる）。

オブジェクトのそれぞれは、一意的な一様な色で事前にカラーリングされてもよく、グリッドテクスチャを適用する時、テクスチャをこの色と結合して、各オブジェクトのための一意的なテクスチャを作成する（例えば、各オブジェクトのために一意的な色を作成することに赤チャネルが予約され、グリッドテクスチャを作成することに他のチャネルが予約される）。

一実施形態において、これらの方法は、補助グラフィックスプロセッサモジュールへそれに新規オブジェクトテクスチャを生成させる命令を供給する命令傍受機能によって実施される、これらの命令は、画像フレーム全体を覆い、前記画像フレームにあるオブジェクトの表面に結び付ける単一テクスチャをそれに生成させて、新規オブジェクトテクスチャを作成する。単一テクスチャは、画像フレーム上へ投影されるか、またはそれから反射される。単一テクスチャを生成するステップは、オブジェクトの表面を初期値に設定すること、および次いでオブジェクトに対して新規表面テクスチャを作成および適用するように単一テクスチャを変更することを含んでよい。初期値は、オブジェクトが透明かどうかを指示し、そして画像フレーム内の各オブジェクトにとり一意的である。エンコーダは、新規オブジェクトテクスチャに基づきオブジェクトの形状および位置を特定する。

本発明は、３Ｄオブジェクトをその２Ｄ画面描写と連係させ、動きのみならず動きの量および方向も識別する様式を提供する。好ましい実施形態は、基準グリッドをシーン上へ投射するよう投影のテクスチャを使用することである。テクスチャは、画面と同じ寸法を有し、それをカメラと同じ位置の点から投影すると定義される。効果は、シーン全体がテクスチャで覆われることとなる。

テクセルは、テクスチャ内部の単一の要素であり、画素が単一の画面要素であることに類似する。投影テクスチャの各テクセルは、本発明のこの実施形態では、テクスチャにおいてその位置を表す一意的なＸおよびＹ成分に分割される。種々のテクスチャフォーマットが選択されてこれを達成し得る。最も普及した３２ビットテクスチャフォーマットは、普通には赤、緑、青およびアルファ成分を有し、それぞれが８ビットを占有する。１０ビット色または浮動点色等でさえもより好適なフォーマットが存在するが、現在では広くサポートされていない。

そのようなグリッドをシーン上へ投影することによって、画面の画素位置と厳密に一致する基準グリッドが提供される。どんな移動も発生する前にこのテクスチャを投影すること、そして移動後に結果を元に対して比較することによって、移動が発生したことのみならず、その動きの画素の数ならびにｘおよびｙ成分の量も検出できる。

図４は、簡単な３Ｄシーン上へ投影されているテクスチャを示す。画面４２上の点線は、シーンの背景４８と共にシーンを構成する２個の３Ｄ立方体４６の２Ｄ表示の外形４４を示す。

動きを追跡するために、画面に対するオブジェクトの位置の現在の状態を格納する方法が提供され、それは比較的細かいレベルの解像度でそうすべきである。

使用できるデータは、オブジェクトの頂点、オブジェクトの表面を形成するテクセル、もしくは、ポリゴンまたはテクセルを作成または移動することに使用される変数である。

これを達成する１つの方法は、オブジェクトの表面にわたる画面位置を格納するようテクスチャを割当てる―「テクスチャキャッシュ」である。このテクスチャにおける各テクセルは、レンダリング中に基準テクスチャの投影によって特定されたその画面位置の表示を格納することになる。表面にわたり十分に高いサンプリング解像度を生じるためにテクスチャのサイズを選択することに注意すべきである。装置は元の画像で発生している画面上の画素の移動を追跡するので、一定のテクセル対画素の比が好ましい。従って、使用されるテクスチャキャッシュは、そのオブジェクトに割当てられた元のテクスチャと同じサイズである。元のゲームは、テクスチャがオブジェクトの表面にわたり並べて表示される（繰返される）場合、オブジェクトの種々の部分を覆うことに２つ以上のテクスチャを割当てたかもしれない。並べて表示する場合には、テクスチャキャッシュは、元のテクスチャがオブジェクトの表面にわたり繰返される回数と同じ倍数で大きくされる。

基準グリッドと共に投影テクスチャマッピングを投影されたテクスチャとして用いることにより、装置は、テクセルが「現実」の画像（すなわち、元のプログラマが意図したもの）にあったならばテクセルが出現したであろう画面上の場所をテクセルごとの基準で識別できる。

オブジェクトが移動する場合、テクスチャキャッシュのテクスチャマッピングも変化し、それによりそれは今やオブジェクトの新規位置に対応し、この事実はそれが今や異なるセットの基準グリッドテクセルを含有する事実によって確認される。本来のテクスチャは今や２Ｄ画面座標という観点でオブジェクトのテクセルがある場所を「知って」おり、記憶されたテクスチャは前回フレームでそれがあった場所を「知って」いる。

画面位置は、テクスチャ空間の中からサンプリングされ、それにより通常のレンダリングパイプラインは、それが画面空間という結果になるので、使用できない。換言すると、テクスチャを画面空間にレンダリングすること、すなわち、画像を画面上に作成することという通常の思考様式の代りに、画面空間位置はテクスチャにレンダリングされる。オブジェクトが移動する時、テクスチャキャッシュのテクスチャマッピングも変化することになり、それによりそれは今やオブジェクトの新規位置に対応する。キャッシュは、それ故に、画面に関してオブジェクトのテクセルの配向を「憶えている」ことになる。

２つのテクスチャキャッシュが、この実施形態では、保持される：前回フレームに対して１つ、および現行フレームに対して１つ。代替の実施形態では、オブジェクト当り１つだけが使用されてもよい、または全部のテクスチャの代りにテクスチャの一部分がオブジェクトに割当てられる場合、全てのオブジェクトに対して１つだけが使用されてもよい。

各フレームに対して、収納対象は、シーンの始まりで１回異なるテクスチャキャッシュへ交換されてもよく、現行の位置はそのキャッシュに収納される。他のキャッシュは、それでも前回フレームの画面位置を有することになる。テクセルごとの基準で、そこで、減算により前回フレームからこのフレームへのそのテクセルの正確な画面移動が分かる。プログラム可能なパイプラインハードウェアが、圧縮シーケンスの完了においての使用のためにビデオエンコーダによってアクセス可能な領域に現行のシーンのテクセル差分を収納することに使用され得る。この領域に格納されたデータは、各画素を表すテクセルの正確な動き、この故にその画素の動きである。

両方のテクスチャキャッシュはオブジェクト頂点へ同じ様式で結び付けられているので、それらは相互に対してシフトすることはない。この技法は、その故にｘ、ｙ、またはｚ軸での移動だけでなくモーフィングによる回転または歪みでも動作する。

半面のテクスチャが２回マップされる例のようにテクスチャの幾つかの部分はマッピングにおいて再使用されてもよいので、本発明は、「一意的なテクスチャ空間」が使用されること、すなわち、重なり合いがないものを確かにする方法を提供する。さもなければ、テクセルが画像に出現するたびに、その現行値が新規画面位置で上書きされることになり、装置は、テクセルの全ての場所と対照的に、（レンダリングされるべき最後の）テクセルの１個所だけを知ることになろう。この限定を克服することは、元のテクスチャを新規テクスチャへコピーすることによって頂点を新規テクスチャへ再マップせねばならぬことを意味する。この方法は、元のテクスチャのサイズを倍にし、前回マップされた領域を参照した一定のオフセットを頂点へ追加することによって実行され得る。

新規テクスチャは元のサイズへ圧縮されてもよく、従って元のポリゴンを縮小させる。代替として、元のポリゴン寸法は維持され得るが、再マッピングはそれ程多くの不使用スペースを有しないように再編成される。

更なる方法は、テクスチャキャッシュを元のテクスチャと同じサイズに保つことであろう。しかし、Ｎ個の三角形が元のテクスチャへマッピングされる場合、キャッシュはＮ個の長方形に分割される。これらの長方形は、次いで２個に分割され、それにより元の２倍の数の三角形がある。

システムは、次いで元へマップされる全ての三角形を介して動作し、それをテクスチャキャッシュのそれぞれにある三角形の１つへ割り当てる。再マップされる時に相対的位置が変化した事実は、テクスチャキャッシュがレンダリングすることに使用され、従って「一意的なテクスチャ空間」を必要とするだけなので、問題にはならない。

［実装の概観（Ｏｖｅｒｖｉｅｗ ｏｆ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）］
以下図５を参照し、本発明を実装するシステムのメイン構成要素を図示する。構成要素は、テレビ端末５２等の複数のユーザ局に提供する集中型ゲームサーバの列５０を含む。集中型サーバおよびユーザ局は、ケーブルまたは衛星放送ネットワークおよび／もしくは公衆電話ネットワーク等の１つまたはそれ以上のデータ通信ネットワーク５４経由で接続されている。セットトップボックス５６が、機能の中でもとりわけ、圧縮されたビデオデータを復号化するために備えられる。ジョイスティック等のユーザ入力装置５８が、ゲーム中にユーザ入力を検出するために備えられる。ネットワーク（単数または複数）５４が、集中型サーバ５０から、セットトップボックス５６が信号を圧縮復元されたビデオ信号６２へ変換するユーザ端末への圧縮されたビデオデータ６０の送信、および、反対方向へのユーザ入力６４の送信を提供する。

図６は、ゲームサーバの列５０にある単一のゲームサーバの実施形態の特徴を概略的に示す。ユーザ入力６４は、従来のパーソナルコンピュータ（ＰＣ）の中央演算処理装置（ＣＰＵ）７２にネットワークインタフェース７０を介して入って来る、ＰＣ上で従来のＰＣゲームプログラムが動作する。ゲームプログラムが、第１セットのグラフィックス命令を第１グラフィックス演算処理装置（ＧＰＵ）７６へ送り、命令は命令傍受モジュール７４によって傍受され、モジュールはソフトウェアラッパーまたはハードウェア形式で具現化されてもよい。第１セットの命令は、頂点データ、変換データおよびテクスチャデータを含み、ＧＰＵ１ ７６へ渡され、その一方で特別に操作されたバージョンの命令が生成され、第２グラフィックス演算処理装置（ＧＰＵ２）７８へ渡される。両ＧＰＵは、共通のグラフィックスカード上に備えられてもよい。ＧＰＵ１ ７６は、ゲームが意図するように画像データをレンダリングし、一方でＧＰＵ２ ７８は、圧縮のために使用される圧縮援助データ、例えば、動きベクトルが抽出される特別に適合されたグラフィックスデータをレンダリングすることに使用される。各画像フレームは画素のブロックに分割されることになり、次いで各ブロックに対して、可能な場合、画素のそのブロックのｘ、ｙ座標が前回画像フレーム内で見付け出される。デジタル信号処理装置（ＤＳＰ）８４が、ＧＰＵ２からの圧縮援助データを使用して、ＧＰＵ１からの画像データをＭＰＥＧ−４等の既知のビデオ圧縮アルゴリズムを使用して圧縮し、そして結果としての圧縮されたビデオストリーム８６をＣＰＵ７２へネットワーク５４にわたる送信のために回送する。ハンドシェイク信号伝達８８が、ネットワークが混雑している場合に品質制御のためにＤＳＰ８８とＣＰＵ７２との間で使用される。

上記に関連して、ＤＳＰ８８の機能は別のＣＰＵによってまたはＣＰＵ７２上の異なるタイムスライスによってさえも置換できることに注意されたい。さらに、ＧＰＵ２ ７８は、代替として、ＧＰＵ１ ７６上の別のタイムスライスを使用して具現化できる。

好ましい実施形態の方法は、オブジェクトの移動が、よって画素の移動が２Ｄ画面上で追跡されることを可能にする。「オブジェクト」の２Ｄ画面表示の形状および位置の知識は、動き推定のほかに別の圧縮技法のためにも有用である。ＭＰＥＧ−４は、任意に形状化されたオブジェクトを符号化する可能性を提供する。利点の中でもとりわけ、これは形状の周辺での「濃淡むら」が低減されることを可能にする。

このレベルでのタスクは現行フレームにある画素のブロックと前回フレームにあるブロックとの間の最良の整合を識別することであることに注目するのは重要である。それは厳密な整合である必要はない。エンコーダは、そこで、それがそのブロックをフレーム間モードで符号化するかまたはフレーム内技法を使用するかに整合が妥当であるかを決定する。

本発明の更なる実施形態を以下図７から１０を参照して説明する。最新のグラフィックスチップは、以前の固定グラフィックスパイプラインの代りに（そして、それだけでなく）、今やプログラム可能な変換およびライティングステージ（段）も有する。

これらは、多くの場合Microsoft（登録商標）によって「頂点シェーダ」（ＶＳ）および「画素シェーダ」（ＰＳ）と称される。それらは、時には他の団体によって「頂点プログラム」、「断片プログラム」、「頂点プロセッサ」、または「断片プロセッサ」とも称される。

ＶＳは、頂点（オブジェクトの構造を記述する３Ｄの点）の移動することおよび変換することだけでなく、ライティング、色、およびテクスチャマッピング座標も取扱う全ての機能を扱う。しかし、ＰＳは、テクスチャおよびそれをオブジェクトに適用する方法ならびに幾らかのライティングなどを取扱う。

以前には、ゲームプログラマは、固定パイプライン−すなわち、設定不可の処理を使用しなくてはならなかったのに対して、今やＶＳを使用して、グラフィックス演算処理装置（ＧＰＵ）上で実行することになる短いプログラム（プログラム可能なパイプラインモジュール）を書く能力を有する。

ゲームがＶＳと通信するには、最初にプログラムをロードし、次いでデータを数多くの「一定の」レジスタを通して回送する。それは、次いで頂点データを幾つかの「入力」レジスタを通して回送し、頂点プログラムを実行する。結果としての変換された頂点は、そこで、「出力」レジスタに出現する。しかし、これらのレジスタは、２Ｄ画面座標に対応するデータを含有しないが、その代りに「相反均質座標」として含有する。「ステッパ」と呼ばれるＧＰＵパイプラインの別のステージ（段）が、これらを２Ｄ画面座標へ転換し、頂点をそれらが視野（「錐台」）の中にあるか否かに従いクリッピングする。

画面にわたり画素の動きを追跡するために、従って、頂点が変換ステージ（段）を通過した後に、頂点への変化だけが特定される必要がある。画素レベルの解像度を入手するために、装置は、テクスチャをオブジェクトの表面へ適用することに通常使用されるであろうと同じ技法を使用して、そのポリゴンの表面にわたり補間する。その補間機能は、ＧＰＵの標準的処理パイプラインの一部である。

頂点を処理する１つの様式は、それらがＶＳによって変換された後にそれらを格納すること、および次いで２つの引き続くフレームの頂点を減算して、画面移動を計算することであろう。これは実行可能な提案であるが、それなら一意的なテクスチャ空間を生成する課題も、解決されなければならない。

代替として、装置は、入力パラメータ間の差分を取ることができ、これらを最終的に２フレームの上の頂点間の差分になるよう処理する。装置は、従って、前回フレームからの頂点の変換処理を特定することに使用されている全ての変数を格納し、そこで、それらを同時に新規ＶＳプログラムに現行フレームの頂点を変換することに使用される変数として供給する。

フレーム０で、装置は入力変数を格納する。フレーム１に対する処理では、フレーム０の変数に加えてフレーム１の変数が入力される。変更されたＶＳプログラムは元と非常に類似であるが、違う点は、元のゲームプログラマによって意図されたように頂点の変換を計算した後に、それは、異なるレジスタに格納された変数を使用して前回フレームの頂点もまた処理することになるように変更されたことである。それは、元来意図されたような単一の変換された頂点の代りに、これらの２つの頂点間の差分を計算することを続行し、その結果を出力する。

図７は、標準的頂点シェーダ１０２を示す。入力頂点データ１０４および頂点シェーダ定数１０６はどんな順序であってもよいことに注意されたい。どの定数が、色情報、ライティング、頂点位置、またはそれ以外と称するかの選択は、未知である。しかし、出力１０８は定義されている：oPosは頂点の「画面空間」位置であり、oD0は発散色であり、oD1は反射色であり、oT0からoT3まではテクスチャ座標の４点である。oFogはフォグの範囲であり、oPtsは点スプライトプロセッサのための点サイズである。

ＶＳプログラムにおいて頂点の新規位置を特定することに使用される入力（「頂点シェーダ定数」）および命令を特定するために、処理は出力oPosで始まり、逆行して動作する。

図８を参照すると、グラフィックスパイプライン２００において、ＣＰＵ上のゲームプログラム２０２は、DirectXラッパー２０４およびパラメータ用記憶装置２６で示される。頂点シェーダ２０８は、変換された頂点および動きベクトルの両方２１０を出力する。

図９を参照すると、システムのステップ３００は第１フレームＦ０を処理することで示される。

最初に３０２、本来の（元の）ＶＳプログラムがＤＸラッパーによって解析され、新規の連係するプログラムが作成される。ここでは、処理は、元のＶＳプログラムを解析し、頂点の位置を純粋に取扱う命令および入力パラメータを特定し、そして新規のＶＳプログラムを作成する。

元のＶＳプログラムは、そこで、ＧＰＵ上へロードされる３０４。

次に３０６、Ｆ０データがパラメータとしてＶＳプログラムにロードされ、コピーが作られる。元のＶＳプログラムによって使用される、Ｆ０において頂点の位置に影響を及ぼす全ての入力パラメータが、格納される。

モデルの単一の頂点がロードされ、処理される３０８。画面空間に変換されたモデルの１つの頂点が、今や利用可能である（これは実際には正規化デバイス座標における４−Ｄベクトルであり、それに対する別名は相反均質座標、ＲＨＣであり、これは「ステッパ」によって画面座標へ転換される）。

最終的に３１０、モデルのさらなる頂点が残っている場合、ステップ３０６へ戻る。

図１０を参照すると、システムのステップ４００は、第２フレームＦ１およびそれに続くフレームを処理することで示される。

元のＶＳプログラムがＧＰＵ上へロードされる４０２。

次に４０４、Ｆ１データがパラメータとしてＶＳプログラムにロードされ、コピーが作られる。元のＶＳプログラムによって使用される、Ｆ１において頂点の位置に影響を及ぼす全ての入力パラメータが、それに続くフレームの処理のために格納される。

モデルの単一の頂点がロードされ、処理される４０８。

前回作成された新規の連係するＶＳプログラムがロードされる４１０。

前回フレームＦ０からの頂点位置に関する入力パラメータ、および現行フレームＦ１に対するパラメータが、新規のＶＳプログラムにロードされ４１２、次いで同じ頂点が、Ｆ０データ、次いでＦ１データを使用して処理され４１４、そして差分が出力される。新規のＶＳプログラムは、これらの２つのフレームに相当する頂点を１回のパスで処理し、２つの結果を減算し、そしてそれをＶＳの正規の出力レジスタを通して出力する。

モデルのさらなる頂点が残っている場合４１６、ステップ４０２へ戻る４１８。

２つのＶＳプログラムをロードおよびアンロードする代りに、１つの可能性は、２つを接合して、１つの大きなＶＳプログラムを作ることである。入力パラメータまたは内部変数が、動きベクトルが計算されるべきか画像がレンダリングされるべきかに従いプログラムの適切な部分へ跳ぶことに使用される。１つのＶＳプログラムを使用することで、収納状態変化は半減され（すなわち、システムはステップ４０４へ一巡して戻ることができ４２０）、従って僅かに処理の速度を上げられる。

レンダリングパイプラインの残りは、そこで、「ステッパ」により通常のように継続して、ポリゴンにわたり補間し、ふさがれた画素を選び取り、そしてメモリに収納するために画素シェーダへ引渡す。唯一の違いは、画面メモリに収納する代りにパイプラインは異なる記憶域に収納するよう命令されていることである。

オプションで、２つの変換された頂点が差分の代りに出力されてもよい。

この処理の全部は「パラメータ化」と呼ばれ、有効な既存のＶＳの部分を特定することは、「レジスタカラーリング」として知られる。これらの技法はコンパイラ理論で使用される。

恩恵を受けることは、既存のハードウェアを使用すること、およびゲームコードを再コンパイルする必要性を回避することにあり、これは既存のゲームコードを特に以下によって変更することによって行われる：

「圧縮のために有用な情報」を究極的に特定するよう既存のゲームプログラムを修正するという面でのレジスタカラーリングの使用。このステップは、限られた数の入力レジスタがあるだけなので、格納され、次いで新規のＶＳプログラムに供給されるべき入力パラメータの量を本質的に少なくできるように使用される。それは、また、頂点のライティングまたはカラーリングを特定する命令をコピーすることを回避することによって新規のＶＳプログラムを短くすることを可能にする。これを行うことは必須事項ではないが、それ無しでは無駄が多いであろうし、新規のＶＳプログラムがＧＰＵに対して大き過ぎるか、またはＧＰＵが所有しない多過ぎる入力レジスタを必要とするリスクが存在する；
動きベクトルを特定するための頂点シェーダの使用；および
頂点の位置変換に影響を与えるパラメータを特定すること、およびそれを後の処理のために格納すること。

頂点は、ゲームコードによって動的に作成され、どんな順序でもＧＰＵへ送られることができよう。正しい対が減算されるように頂点をフレーム間で認知する何らかの様式が必要とされる。これは各頂点に対して署名を作成することによって達成できる。署名は、その頂点をレンダリングすることに使用される、例えば、ＶＳプログラムがそれを処理することに使用される全てのもの（または少なくとも数多くのもの）で作り上げられる。

現行のＧＰＵハードウェアは、後変換された頂点を格納できない、それにより多数パスを必要とする何らかの複雑な特別の影響がある場合、これは頂点変換が毎回計算されねばならぬことを意味する。それが真に複雑である場合、プログラマは、代りにＣＰＵ上でこれらの変換を行うことを選ぶかもしれない。

オプションで、キャッシュが、２つ以上のフレーム間で（動きベクトルを特定することでの使用のために）後変換された頂点を格納することに使用されてもよい。

通常、ＶＳ処理を通る単一のパスは、単一の頂点だけを処理する。ＧＰＵは、並行して動作するいくつかのＶＳを有することがあるが、それら全ては同じ収納対象を使用する。２つの頂点間の差分を計算することは、収納対象を交換することを意味するであろう。正規の処理は、頂点１をロードし、元のＶＳを実行し、修正されたＶＳプログラムをロードおよび実行し、次いで元のＶＳプログラムを再度ロードし、頂点２をロードする等であろう。収納状態および対象を交換することは、オーバヘッドであり、すべての頂点に対してそうすることは、総体的処理を相当に遅くすることになろう。

遅延を最小限にするために、その完結したオブジェクトに対する全ての入力詳細は、格納および編成されてもよく、それにより収納対象は頂点が処理される前に１回だけ変化される。これは収納状態変化および収納対象変化の両方の数を低減することになろう。

状態変化を低減する別の様式は、単一のＶＳプログラムを有することであろう。処理は、元のＶＳプログラムを新規の部分と結合できて、大きいプログラムを作り、次いで入力定数の１つをスイッチとして使用し、それにより単一の新規のＶＳは処理するためのそのコードの一部が元かまたは新規追加かを知る。ＧＰＵは、一時に１画素をレンダリングできるのみであり、それにより両ＶＳプログラムは同時に処理されないかもしれない。従って、２つ以上のＶＳプログラムがあってもよい。

更に、２つの区別できる収納対象を有する代りに、処理は、画面の２倍大きいただ１つを有することができ、単に所望画像を半分へ向け、頂点間の差分をもう１つの半分へ向ける。これは、また、２つのＧＰＵの代りに１つを使用することで助けになる。代替として、処理は、情報の２つの部分を、レンダリングされた画像を色の１つの範囲に、頂点データ間の差分をもう１つの範囲に制限することによって単一の画像に組み込みできよう。

パラメータ化が動作するために、変更されたＶＳプログラムのために十分なスペースがあり、２セットの変数を通過させるのに十分なレジスタがあることを想定している。それはグラフィックスチップの能力およびＶＳプログラムに大いに依存することになる。しかし、処理が問題に行き当たらないことを確実にするのを助けるために行われ得ることがある。

一番は、ホストのゲームプログラムがＧＰＵのデバイスドライバにその能力を尋問する時に、ＧＰＵは、ＧＰＵが実際にサポートするより小さいＶＳプログラム格納場所、および変数を格納するためのより少ないレジスタを有していると、処理が主張することができることである。

どんな１時点でも、最終消費者によって使用されるグラフィックスカードには大きいバラツキがある。それで、ゲームソフトウェアは、それ故に、さまざまな異なる能力に対処しなくてはならない。それ故に、ゲームが１つを起動しようとする前にＧＰＵによって供与される設備を点検することは慣行のことである。ＧＰＵが低い洗練度であると主張することによって、ゲームを壊す機会は少なくされる。その代りに、ゲームは、そのグラフィカルの特色を外すことによって、またはそのセットのコマンドを代りにホストＣＰＵに回送することによって順応するであろう。結果は、ゲームプログラムをすっかり駄目にするのでなく、グラフィカルの特別な効果を少し減退させるだけであろう。

先に記載したように、頂点変換計算を行うだけでなく、ＶＳはライティング等の局面も取扱う。それ故に、ＶＳプログラムの幾つかおよびレジスタの幾つかは、画面上の画素の動きに影響を有しない様式で使用されることになろう。必要なレジスタ数を低減するために、そしてＶＳプログラムの修正バージョンをより速く実行させるために、既存のＶＳプログラムは事前解析されて、有効である部分を特定する。

有効であるものおよび有効でないものを選り分けることは、ゲームプログラマの意図を事前に知らない場合、入力レジスタは差別されていないので、単純でない。しかし、通常の動作では、ＶＳプログラムは、事前指定されたレジスタを使用して変換された頂点を出力することになる（それは、次いで総体的グラフィックスパイプラインにおける別のステージ（段）への入力として使用されることになる）。その知識を装備して、処理は、ＶＳプログラムを通して逆行して動作でき、頂点座標に影響を有することごとくの命令および記憶域を識別して、従って「依存関係グラフ」を構築する。これにより処理は有効な命令および入力レジスタを識別できる。これは、コンパイラ理論でよく知られた問題であり、「レジスタカラーリング」と呼ばれる。処理は、そこで、どんな無用な命令も取り去ることができる。

ＧＰＵは、上記で説明したプログラム可能な種類だけでなく、固定のグラフィックスパイプラインもサポートできる。説明した技法が動作するために、処理は、固定パイプラインを使用したであろう命令の処理を模擬するＰＳおよびＶＳプログラムを最初に作成する必要があろう。これらは、そこで、動きベクトル生成の本発明の技法を適用する前に、元の固定パイプライン命令を置換することに使用されよう。

画素に基づく動きベクトルのグループからブロックに基づく単一の動きベクトルを作成する、および間および内の間のコーディングを決定する方法は、良く知られている。

本発明のこの実施形態は、以下の特徴を有する：
− 画面上の画素の動きベクトルを計算することに２フレームの後変換された頂点を使用すること。
− 最初に頂点がもはや重なり合わない様式でそれらをメモリに格納すること、次いで差分を得るよう２セットの頂点を相互から減算することによって行うこと。
− ２フレームの上の頂点間の差分を生成するために、入力変数における差分を処理することに頂点シェーダを使用すること。

「頂点シェーダ」は、「画素シェーダ」がそうであるように、「プログラム可能なパイプライン」の種類である。
− ２フレームの上の色および／または輝度での差分を特定することに頂点シェーダおよび／または画素シェーダを使用すること。
− 現実の画像および頂点間の差分が同じ「収納対象」として格納され得るように大きい収納対象を使用すること。
− 処理が収納対象を交換し続ける必要がないように後の処理のために入力パラメータを記録すること。
− 頂点位置そのものに影響を与える命令およびデータだけを隔離できるように頂点シェーダプログラムを解析し、それを変更すること。
− ホストゲームプログラムがＧＰＵにその能力を問い合わせる際にホストゲームプログラムにうそをつくこと。
− １つまたは２つ以上のＶＳ／ＰＳ／ＧＰＵだけの中で上記技法を使用すること（すなわち、単一ＧＰＵにおける既存のコードを中断し、新規処理サイクルを新規コードで実行すること、または全く別のＧＰＵを使用して新規コードを実行させること）。
− 画面画素と一致する「動きベクトル」を入手できるようにポリゴンの表面の上の頂点間の差分を外挿すること。

差分は、２つの連続するフレーム間である必要はなく−それはどの２フレームでもよい。

ＧＰＵは、２つ以上のＶＳおよび／またはＰＳを有することが出来る。

ポリゴンの代りに、ゲームは、「ベジェパッチ」または「ｎパッチ」のような技法を使用してオブジェクトを記述してもよく、３Ｄ表面を記述することに代りに数学的関数が使用されることを意味する。それ故に、離散した頂点を追跡する代りに、処理は、より高いレベルの形状記述関数に合わせて入力変数を追跡する必要があるかもしれない。

本発明の技法は、ただ３Ｄオブジェクトだけでなく、広告看板等の２Ｄオブジェクトに対しても使用できよう。

オプションで、方法は、頂点を持つタグの使用を包含するよう修正されてもよく、それにより２フレーム間の同じ頂点を関連付けることがより容易になる。幾つかのゲームはシーンを記述することに動的に生成された頂点を使用する。それがゲームによって同じ順序で作成されることが確かでないので、プログラムが２つの頂点間の差分を特定する時期、実のところ処理が両方の場合で同じオブジェクトの同じ点を取扱っていることを処理は確信できない。

オプションで、全ての頂点を追跡する代りに、処理は、簡単な有界の箱、または空間におけるオブジェクトのｚ位置の両極端を表す２点だけでさえも、等の低解像度モデルを代りに追跡できよう。処理は、そこで、これらの点へ変換機能を適用し（多分ＣＰＵ内で）、そしてこの後変換された結果をオブジェクトの事前変換された頂点へ簡単に外挿できよう。

本発明の利点は、合成画像により、本発明によって提供された識別の方法および手段によって、画像に関する情報に、そのレンダリングより前にアクセスがあり、そしてこの情報は圧縮処理を助長できる、事実を活用することである。その画像のレンダリングと並行してこの情報を処理することによって、圧縮の速度が改善でき、この故にシステムの待ち時間が低減できる。

更なる修正および改善が、本明細書に説明された本発明の範囲から逸脱することなく追加され得る。

本発明に従った集中型対話グラフィカルアプリケーションシステムを概略形式で示す。 ゲームの処理のための代表的パイプラインを概略形式で示す。 グラフィックスプロセッサによってシーンをレンダリングする代表的処理フローを示す。 簡単な３Ｄシーン上へ投影されているテクスチャを示す。 本発明の１つの実施形態に従うゲームシステムの概観を示す。 本発明の実施形態に従う単一ゲームサーバを示す概略図である。 頂点シェーダを概略形式で示す。 本発明の好ましい実施形態に従ったアーキテクチャを概略形式で示す。 本発明の好ましい実施形態に従った第１フレームの処理のためのステップのフローチャートを示す。 本発明の好ましい実施形態に従った第２およびそれに続くフレームの処理のためのステップのフローチャートを示す。

Claims (18)

1. 少なくとも１つのグラフィックスプロセッサモジュールを使用して圧縮ビデオデータ信号を生成する方法であって：
   ａ）グラフィックスプロセッサモジュールのための第１セットの命令を受け取るステップ；
   ｂ）前記第１のセットの命令を傍受し、グラフィックスプロセッサモジュールのための第２セットの命令を生成するステップ；
   ｃ）第１のグラフィックスデータを生成するよう前記第１セットの命令または前記第２セットの命令をグラフィックスプロセッサモジュールにおいて処理するステップ；
   ｄ）第２グラフィックスデータを生成するよう前記第２セットの命令を処理するステップ；
   ｅ）圧縮援助データを生成するよう前記第２グラフィックスデータを処理するステップ；および
   ｆ）圧縮ビデオデータ信号を生成するよう、前記圧縮援助データを使用して、前記第１のグラフィックスデータを処理するステップ；
   を含む、方法。
2. 前記第２セットの命令は、ステップｄ）がステップｃ）より少ないデータ処理能力を使用するように生成される、請求項１に記載の方法。
3. 前記第１のグラフィックスデータは、画像フレームを含む、請求項１または２に記載の方法。
4. 前記方法は、グラフィックスオブジェクト上の点へマップされるべき少なくとも１つの属性を定義するための命令を、前記第２セットの命令内に、特定して生成するステップを含み、その属性は実質的に同じ前記グラフィックスオブジェクト上の実質的に同じ点へマップされるべき、対応する属性よりも容易に識別可能であり、前記第１のグラフィックスデータ内で識別可能である、請求項１〜３のいずれか１項に記載の方法。
5. 前記第１セットの命令は、グラフィックステクスチャ命令を含み、前記第２セットの命令は、異なるグラフィックステクスチャ命令を含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記異なるグラフィックステクスチャ命令は、前記第２のグラフィックスデータにおいて画像フレーム内の領域に対して実質的に一意であるよう編成される少なくとも１つのテクスチャ属性を定義する、請求項５に記載の方法。
7. 前記方法は、１つ以上のグラフィックスオブジェクトのための異なるグラフィックステクスチャマッピングを生成するステップを含む、請求項５または６に記載の方法。
8. 前記方法は、１つ以上のグラフィックスオブジェクトのための投影テクスチャマッピング処理を実行するステップを含む、請求項５〜７のいずれか１項に記載の方法。
9. 前記方法は、１つ以上のグラフィックスオブジェクトのために前記第２グラフィックスデータの少なくとも一部をメモリキャッシュへ書き込むステップを含む、請求項１〜８のいずれか１項に記載の方法。
10. 前記方法は、前記第１のグラフィックスデータを生成するよう前記第１セットの命令または前記第２セットの命令を第１のグラフィックスプロセッサモジュールへ入力するステップと、前記第２のグラフィックスデータを生成するよう前記第２セットの命令を別の第２のグラフィックスプロセッサモジュールへ入力するステップを含む、請求項１〜９のいずれか１項に記載の方法。
11. 前記方法は、圧縮援助データを生成するために、１時点からの前記第１または前記第２セットの命令を、別の時点からの前記第１または前記第２セットの命令と共に処理するための命令を、第２セットの命令の一部として、特定して生成するステップを含む、請求項１、２または３に記載の方法。
12. 前記方法は、圧縮援助データを生成するために、１時点に対応する前記第１または第２セットの命令から処理されるデータを格納するため、そして、別の時点に対応する前記第１または第２セットの命令から処理されるデータと共に処理するための命令を、第２セットの命令の一部として、特定して生成するステップを含む、請求項１、２、３または１１に記載の方法。
13. 前記方法は、圧縮援助データを生成するために、１時点に対応する前記第１または第２セットの命令の少なくとも一部を、別時点に対応する命令と共に処理するために、格納するステップを含む、請求項１、２、３、１１または１２に記載の方法。
14. 前記第２セットの命令の生成は、圧縮援助データの生成のために前記第１セットの命令のいずれが有用であるかを特定するよう前記第１セットの命令を解析するステップを伴う、請求項１〜１３のいずれか１項に記載の方法。
15. 前記第２セットの命令の生成は、前記要素の後続の認識を容易にするよう、前記第１セットの命令の１つ以上の要素のための一意的な署名を作成するステップを含む、請求項１〜１４のいずれか１項に記載の方法。
16. 前記署名は、前記第２セットの命令の中の情報から構築される、請求項１５に記載の方法。
17. 少なくとも１つのグラフィックスプロセッサモジュールを備える、圧縮ビデオデータ信号を生成するための装置であって、
    ａ）グラフィックスプロセッサモジュールのための第１セットの命令を受け取るため、そしてグラフィックスプロセッサモジュールのための第２セットの命令を生成するための命令傍受機能；
    ｂ）第１のグラフィックスデータを生成するよう前記第１セットの命令または前記第２セットの命令をグラフィックスプロセッサモジュール内で処理するための処理機能；
    ｃ）第２のグラフィックスデータを生成するよう前記第２セットの命令を処理するための処理機能；
    ｄ）圧縮援助データを生成するよう前記第２のグラフィックスデータを処理するための処理機能；および
    ｅ）圧縮ビデオデータ信号を生成するよう、前記圧縮援助データを使用して、前記第１のグラフィックスデータを処理するための符号化機能；
    を備える装置。
18. 複数の命令傍受機能を備え、そのそれぞれが異なる命令を異なるグラフィックスプロセッサモジュールへ入力するように成されている、請求項１７に記載の装置。

Images