JP2014203121A - 描画処理装置、描画処理システム、および描画処理方法 - Google Patents

Abstract

【課題】ネットワークの帯域不足や通信エラーによってデータの再送が頻繁に起こると、描画処理に遅延が発生し、アプリケーションの応答性が悪くなる。【解決手段】サーバ１００において、描画ライブラリ２０は描画コマンドをクライアント２００に送信し、データ送信管理部３０は、描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてクライアント２００に送信する。クライアント２００において、データ受信管理部５０は、サーバ１００から描画コマンドの実行に利用される再利用可能なデータを受信する。描画ライブラリ６０は、データ受信管理部５０により受信された再利用可能なデータをＧＰＵ８０にリソースとして設定するとともに、サーバ１００サーバから描画コマンドを受信してＧＰＵ８０に供給する。【選択図】図１

Description

この発明は、描画処理技術、特に描画コマンドと描画コマンドに利用されるデータを提供する技術に関する。

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

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

最近のＧＰＵには、プログラムシェーダと呼ばれるように、シェーダ機能がプログラム可能なものもあり、シェーダプログラミングをサポートするために、一般にグラフィックスライブラリが提供されている。オブジェクトをレンダリングする際、ＣＰＵは、ＧＰＵのハードウェアにより実行されるグラフィックスコマンドを順次生成してＧＰＵに渡す必要がある。

特開２００８−１２３５２０号公報

ネットワークを利用したアプリケーションの場合、サーバからクライアントへネットワーク経由でグラフィックスコマンドとデータが送信され、クライアント側で描画処理が行われる。ネットワークの帯域不足や通信エラーによってデータの再送が頻繁に起こると、描画処理に遅延が発生し、アプリケーションの応答性が悪くなる。特にリアルタイム性の要求されるゲームアプリケーションにおいてデータの再送が頻繁に起こると、ゲームの進行が遅延し、臨場感が損なわれることがある。

本発明はこうした課題に鑑みてなされたものであり、その目的は、ネットワークを利用して描画処理を効率的に実行することのできる技術を提供することにある。

上記課題を解決するために、本発明のある態様の描画処理装置は、描画コマンドをネットワークを介して送信する描画ライブラリ部と、描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてネットワークを介して送信するデータ送信管理部とを含む。

本発明の別の態様もまた、描画処理装置である。この装置は、描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの受信タイミングとは時間をずらしてネットワークを介して受信するデータ受信管理部と、前記データ受信管理部により受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、ネットワークを介して描画コマンドを受信して前記グラフィックスプロセッサに供給する描画ライブラリ部とを含む。

本発明のさらに別の態様は、描画処理システムである。この描画処理システムは、ネットワークを介して描画コマンドを送信するサーバと、前記サーバから描画コマンドを受信するクライアントとを含む描画処理システムであって、前記サーバは、描画コマンドを前記クライアントに送信するサーバ側描画ライブラリ部と、描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらして前記クライアントに送信するデータ送信管理部とを含む。前記クライアントは、前記サーバから描画コマンドの実行に利用される再利用可能なデータを受信するデータ受信管理部と、前記データ受信管理部により受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、前記サーバから描画コマンドを受信して前記グラフィックスプロセッサに供給するクライアント側描画ライブラリ部とを含む。

本発明のさらに別の態様は、描画処理方法である。この方法は、描画コマンドをネットワークを介して送信するステップと、描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてネットワークを介して送信するステップと、描画コマンドの実行に利用される再利用可能なデータを受信するステップと、受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、ネットワークを介して描画コマンドを受信してグラフィックスプロセッサに供給するステップとを含む。

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

本発明によれば、ネットワークを利用して描画処理を効率的に実行することができる。

実施の形態に係る描画処理システムの構成図である。 従来のグラフィックス処理装置のハードウェアの構成図である。 図１の描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。 図１の描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。 図１の描画処理システムによる描画処理の流れを示すシーケンス図である。 図１の描画処理システムによるテクスチャ更新の流れを示すシーケンス図である。 図５のテクスチャ更新によりテクスチャデータが置換された後の描画処理の流れを示すシーケンス図である。 図１の描画処理システムによるテクスチャ削除の流れを示すシーケンス図である。 図１のサーバの描画ライブラリの処理を示すフローチャートである。 図１のサーバの描画ライブラリの処理を示すフローチャートである。 図１のクライアントの描画ライブラリの処理を示すフローチャートである。 図１のクライアントの描画ライブラリの処理を示すフローチャートである。 図１のクライアントの描画ライブラリの処理を示すフローチャートである。 図１の描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。 図１の描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。 図１の描画処理システムによるテクスチャ更新の流れを示すシーケンス図である。 サーバの描画ライブラリの処理を示すフローチャートである。 クライアントの描画ライブラリの処理を示すフローチャートである。 クライアントの描画ライブラリの処理を示すフローチャートである。

図１は、実施の形態に係る描画処理システムの構成図である。サーバ１００とクライアント２００がネットワーク３００を介して接続される。サーバ１００およびクライアント２００の機能ブロックはハードウエアのみ、ソフトウエアのみ、またはそれらの組み合わせによっていろいろな形で実現することができる。

サーバ１００はクライアント２００に描画コマンドとデータを分離して送信する。データ、特にテクスチャデータやモデルデータ、シェーダプログラムなど再利用可能な静的なデータは、描画コマンドとは分離して送信する。なお、描画コマンドを送信する際、再利用されない動的なデータを描画コマンドとともに送信することがある。

サーバ１００は、アプリケーション／ＳＤＫ（Software Development Kit）１０、描画ライブラリ２０、データ送信管理部３０、低品質テクスチャ／モデルデータ記憶部４０ａ、および高品質テクスチャ／モデルデータ記憶部４０ｂを含む。

アプリケーション／ＳＤＫ１０は、描画ライブラリ２０の各種描画コマンドを用いて構成されたゲームなどのアプリケーションプログラムである。低品質テクスチャ／モデルデータ記憶部４０ａおよび高品質テクスチャ／モデルデータ記憶部４０ｂには、アプリケーション／ＳＤＫ１０が利用する、オブジェクトのポリゴンの頂点座標値、頂点カラー、法線ベクトル、ＵＶ値などのジオメトリデータ（モデルデータ）や、ポリゴン表面にマッピングするためのテクスチャが格納される。

描画ライブラリ２０は、ネットワーク３００を介してクライアント２００に描画コマンドを送信するとともに、描画コマンドにおいて再利用可能な静的データの転送要求をデータ送信管理部３０に発行する。

データ送信管理部３０は、描画コマンドの実行に利用されるテクスチャデータやモデルデータなどの静的データを低品質テクスチャ／モデルデータ記憶部４０ａまたは高品質テクスチャ／モデルデータ記憶部４０ｂから読み出して、クライアント２００に送信する。低品質テクスチャ／モデルデータ記憶部４０ａには描画品質が低いテクスチャデータやモデルデータが、高品質テクスチャ／モデルデータ記憶部４０ｂには描画品質が高いテクスチャデータやモデルデータが格納されており、データ送信管理部３０は、ネットワーク３００の輻輳状態やクライアント２００の処理性能などに応じて、いずれかを選択することができる。たとえば、ネットワーク３００が混雑している場合やクライアント２００の処理性能に限界がある場合は、低解像度のテクスチャデータが選択され、ネットワーク３００の帯域に余裕がある場合やクライアント２００が高性能の端末である場合は、高解像度のテクスチャデータが選択される。

クライアント２００は、データ受信管理部５０、描画ライブラリ６０、ＩＤ対応付け管理部７０、グラフィックスプロセッシングユニット（ＧＰＵ）８０、およびテクスチャ／モデルデータキャッシュ９０を含む。

描画ライブラリ６０は、サーバ１００から送信された描画コマンドを受信する。描画ライブラリ６０は、描画コマンドの実行に利用されるテクスチャデータやモデルデータをデータ受信管理部５０に要求する。

データ受信管理部５０は、サーバ１００から送信されたテクスチャデータやモデルデータを受信してテクスチャ／モデルデータキャッシュ９０に格納する。データ受信管理部５０は、描画ライブラリ６０からの要求に応じて描画コマンドの実行に利用されるテクスチャデータやモデルデータを描画ライブラリ６０に供給する。

ＩＤ対応付け管理部７０は、描画コマンドの実行に必要なリソースの識別情報であるリソースＩＤを管理する。サーバ１００の描画ライブラリ２０は、描画コマンドの実行に利用されるリソースの仮の識別情報である仮リソースＩＤを生成して、クライアント２００の描画ライブラリ６０に送信する。クライアント２００の描画ライブラリ６０は、描画コマンドの実行に必要なリソースの割り当てをＧＰＵ８０に要求し、ＧＰＵ８０によって実際に割り当てられたリソースの識別情報である実リソースＩＤをＧＰＵ８０から受け取る。クライアント２００の描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤを対応づけたマッピング情報をＩＤ対応付け管理部７０に供給する。

ＩＤ対応付け管理部７０は、仮リソースＩＤと実リソースＩＤを対応づけて管理し、描画ライブラリ６０からの検索の問い合わせを受ける。描画ライブラリ６０が仮リソースＩＤをキーとして実リソースＩＤの検索をＩＤ対応付け管理部７０に要求すると、ＩＤ対応付け管理部７０は、仮リソースＩＤに対応する実リソースＩＤを返す。

さらに、オプションとして、クライアント２００の描画ライブラリ６０は、サーバ１００の描画ライブラリ２０から、テクスチャデータやモデルデータを一意に特定する識別情報であるデータ識別ＩＤを受信する。ＩＤ対応付け管理部７０は、データ識別ＩＤを仮リソースＩＤと実リソースＩＤに対応づけて管理する。描画ライブラリ６０がデータ識別ＩＤをキーとして仮リソースＩＤと実リソースＩＤの検索をＩＤ対応付け管理部７０に要求すると、ＩＤ対応付け管理部７０は、データ識別ＩＤに対応する仮リソースＩＤと実リソースＩＤを返す。

描画ライブラリ６０は、サーバ１００の描画ライブラリ２０から受信した仮リソースＩＤに対応する実リソースＩＤをＩＤ対応付け管理部７０から取得し、テクスチャ／モデルデータキャッシュ９０に格納されたテクスチャデータやモデルデータを、ＩＤ対応付け管理部７０から取得した実リソースに設定することをＧＰＵ８０に要求する。ＧＰＵ８０は、テクスチャデータやモデルデータを実リソースＩＤで識別されるリソースに割り当てる。

描画ライブラリ６０はＧＰＵ８０に描画コマンドの実行を要求し、ＧＰＵ８０は、実リソースＩＤにマッピングされたテクスチャデータやモデルデータを利用して描画コマンドを実行し、レンダリング結果をディスプレイに表示する。

図２は、従来のグラフィックス処理装置のハードウェアの構成図である。本実施の形態の描画処理システムを理解するための前提として説明する。最近のＧＰＵは、描画命令毎にＣＰＵが逐次データを渡して描画するのではなく、ＧＰＵのローカルメモリに事前にデータを登録して描画処理に利用することが通常である。ＧＰＵ側に十分なメモリ容量があるため、事前にデータを登録しておき、描画コマンドをＧＰＵに指定するだけでＧＰＵのメモリに格納されたデータを読み出して利用することができるからである。

従来のグラフィックス処理装置は、ホストＣＰＵ４００とＧＰＵチップ５００がバスなどのインタフェースで接続されており、ホストＣＰＵ４００からＧＰＵチップ５００に描画コマンドとデータが供給される。

ホストＣＰＵ４００において、アプリケーション／ＳＤＫ１０は、グラフィックドライバ４３０を通して描画コマンドをＧＰＵ５１０に発行するとともに、描画コマンドで利用される静的データ４２０をメインメモリからロードしてＧＰＵ５１０に供給する。ＧＰＵ５１０は、静的データ４２０をＧＰＵメモリ５２０に登録し、描画コマンドの実行の際にＧＰＵメモリ５２０から静的データ４２０を読み出して利用する。

本実施の形態の描画処理システムは、ＧＰＵメモリ５２０に事前にデータを登録することのできるグラフィックス処理装置のアーキテクチャを前提として、ネットワーク３００を介したシステムとして、ホストＣＰＵ４００をサーバ１００側に、ＧＰＵチップ５００をクライアント２００側に設けた構成である。

以下、本実施の形態の描画処理システムによるコマンドとデータを分離して送信する描画処理を説明するが、データを一意に特定するためのデータ識別ＩＤを用いる実装と、データ識別ＩＤを用いない実装とがあり、実施例によって両者を使い分ける必要がある。まず、［Ａ］データ識別ＩＤを用いる実装について説明し、その後で［Ｂ］データ識別ＩＤを用いない実装を説明する。

［Ａ］データ識別ＩＤを用いる実装
図３Ａ〜図９Ｃを参照して、データ識別ＩＤを用いる実装を説明する。この場合、後述のように、仮リソースＩＤ、実リソースＩＤ、およびデータ識別ＩＤを互いに対応づけて管理する。

図３Ａおよび図３Ｂは、描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。

図３Ａを参照する。サーバ１００において、アプリケーション／ＳＤＫ１０は、テクスチャリソース割り当て要求命令をサーバ側の描画ライブラリ２０に発行する（Ｓ１０）。サーバ側の描画ライブラリ２０は、テクスチャリソース割り当て要求命令にしたがって仮リソースＩＤを生成する（Ｓ１２）。

描画ライブラリ２０は、テクスチャリソース割り当て要求命令の命令ＩＤと仮リソースＩＤをネットワーク３００を介してクライアント２００に送信する（Ｓ１４）。描画ライブラリ２０は、アプリケーション／ＳＤＫ１０に仮リソースＩＤを返す（Ｓ１６）。

このように、サーバ１００の描画ライブラリ２０が仮リソースＩＤを発行してアプリケーション／ＳＤＫ１０に返すことにより、クライアント２００のＧＰＵ８０において実リソースＩＤが発行されるのを待つ必要がなくなり、ネットワーク３００を介することによる遅延を回避することができる。また、後述のようにリソースに割り当てるデータを差し替えるために古い実リソースＩＤを削除し、新しい実リソースＩＤを発行することから、クライアント２００から返信される実リソースＩＤの値は変更される。このため、サーバ１００の描画ライブラリ２０では、変更される可能性のある実リソースＩＤではなく、変更されない仮リソースＩＤを用いてリソースを特定することが必要になる。

クライアント２００において、クライアント側の描画ライブラリ６０は、サーバ側の描画ライブラリ２０から送信された命令ＩＤと仮リソースＩＤをネットワーク３００を介して受信する（Ｓ１８）。描画ライブラリ６０は、テクスチャリソース割り当て要求命令をＧＰＵ８０に発行する（Ｓ２０）。ＧＰＵ８０はテクスチャリソース割り当て要求命令を実行して実リソースＩＤを生成し、描画ライブラリ６０に実リソースＩＤを返す（Ｓ２２）。

描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤの対応付けを示すマッピング情報をＩＤ対応付け管理部７０に供給し、ＩＤ対応付け管理部７０はマッピング情報を登録する（Ｓ２４）。仮リソースＩＤと実リソースＩＤを対応づけたマッピング情報は後述のステップＳ７４、Ｓ１６８、およびＳ１３８において仮リソースＩＤをキーにして、対応する実リソースＩＤを検索する際に用いられる。

このように、仮リソースＩＤはサーバ１００の描画ライブラリ２０により生成され、実リソースＩＤはクライアント２００の描画ライブラリ６０の要求にしたがってＧＰＵ８０により生成される。ネットワーク３００による遅延を考慮すると、サーバ１００の描画ライブラリ２０がクライアント２００の描画ライブラリ６０から実リソースを受け取るように構成すると、アプリケーション／ＳＤＫ１０のコマンドの実行に遅れが生じる。そこで、いったんサーバ１００の描画ライブラリ２０が仮リソースＩＤをアプリケーション／ＳＤＫ１０に返しておき、クライアント２００の描画ライブラリ６０が、ＧＰＵ８０により発行された実リソースＩＤを仮リソースＩＤに対応づけるように構成している。

サーバ１００において、アプリケーション／ＳＤＫ１０は、テクスチャリソースにデータを設定する命令をサーバ側の描画ライブラリ２０に発行する（Ｓ２６）。この命令には、仮リソースＩＤ、データ識別ＩＤ、高解像度テクスチャデータ、および低解像度テクスチャデータが引数として与えられる。

サーバ１００の描画ライブラリ２０は、データ識別ＩＤをキーにしてテクスチャデータをクライアント２００に送信済みであるかどうかをデータ送信管理部３０に問い合わせる（Ｓ２８）。データ識別ＩＤは、テクスチャデータを一意に特定する固有情報であり、たとえば、ファイル名などである。

データ送信管理部３０は、データ識別ＩＤにもとづいて送信履歴を検索し、テクスチャデータを送信済みであるかどうかを調べる（Ｓ３０）。データ送信管理部３０は判定結果を描画ライブラリ２０に返す（Ｓ３２）。判定結果が「未送信」であれば、描画ライブラリ２０は、ネットワークの送信状況をデータ送信管理部３０に問い合わせる（Ｓ３４）。データ送信管理部３０は、判定結果を描画ライブラリ２０に返す（Ｓ３６）。判定結果が「帯域不足」であれば、描画ライブラリ２０は、低解像度データ送信の指示をデータ送信管理部３０に供給する（Ｓ３８）。この送信指示には、データ識別ＩＤと低解像度テクスチャデータが引数として与えられる。

データ送信管理部３０は、低解像度データ送信を送信スレッド３５に委譲する（Ｓ４０）。このときもデータ識別ＩＤと低解像度テクスチャデータが引数として与えられる。データ送信管理部３０は、データ識別ＩＤにもとづいて送信履歴を更新する（Ｓ４２）。

さらに、描画ライブラリ２０は、高解像データ送信の予約をデータ送信管理部３０に供給する（Ｓ４４）。このとき、データ識別ＩＤと高解像度テクスチャデータが引数として与えられる。描画ライブラリ２０は、命令ＩＤ、仮リソースＩＤ、およびデータ識別ＩＤをクライアント２００に送信し（Ｓ４６）、命令の完了をアプリケーション／ＳＤＫ１０に通知する（Ｓ４８）。このときデータ自体は送信されないことに留意する。実際のデータ送信は、データ送信管理部３０からデータ送信を委譲された送信スレッド３５が実行する。クライアント２００において、描画ライブラリ６０は、サーバ１００から送信された命令ＩＤ、仮リソースＩＤ、およびデータ識別ＩＤを受信する（Ｓ５０）。

図３Ｂを参照する。サーバ１００の送信スレッド３５は、ネットワーク３００を介してデータ識別ＩＤと低解像度テクスチャデータをクライアント２００に送信する（Ｓ５２）。クライアント２００の受信スレッド５５はデータ識別ＩＤと低解像度テクスチャデータを受信する（Ｓ５４）。

一方、描画ライブラリ６０は、データ識別ＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ５６）。データ受信管理部５０は、データ識別ＩＤにもとづいって受信履歴を検索し（Ｓ５８）、判定結果を描画ライブラリ６０に返す（Ｓ６０）。判定の結果、データ識別ＩＤに対応するデータが未到着であれば、データの到着を待つ（Ｓ６２）。

受信スレッド５５は、送信スレッド３５から低解像度テクスチャデータの受信を完了すると、ローカルキャッシュへ低解像度テクスチャデータを登録し、データ識別ＩＤにもとづいて受信履歴を更新し（Ｓ６４）、描画ライブラリ６０へデータの更新を通知する（Ｓ６６）。

データの到着待ちであった描画ライブラリ６０が再び、データ識別ＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ６８）。データ受信管理部５０は、データ識別ＩＤにもとづいて受信履歴を検索し（Ｓ７０）、判定の結果、データが到着していれば、ローカルキャッシュに格納された低解像度テクスチャデータを描画ライブラリ６０に供給する（Ｓ７２）。

描画ライブラリ６０は、仮リソースＩＤをキーにした実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ７４）。ＩＤ対応付け管理部７０は、仮リソースＩＤに対応づけられた実リソースＩＤを描画ライブラリ６０に返す（Ｓ７６）。

描画ライブラリ６０は、テクスチャリソースにデータを設定する命令をＧＰＵ８０に供給する（Ｓ７８）。この命令には、実リソースＩＤ、低解像度テクスチャデータが引数として与えられる。これにより、実リソースＩＤに低解像度テクスチャデータがマッピングされる。また、描画ライブラリ６０は、仮リソースＩＤ、実リソースＩＤ、およびデータ識別ＩＤを対応づけたマッピング情報の登録をＩＤ対応付け管理部７０に要求する（Ｓ８０）。仮リソースＩＤ、実リソースＩＤ、およびデータ識別ＩＤを対応づけたマッピング情報は後述のステップＳ１０２においてデータ識別ＩＤをキーにして、対応する仮リソースＩＤと実リソースＩＤを検索する際に用いられる。

図４は、描画処理システムによる描画処理の流れを示すシーケンス図である。

サーバ１００において、アプリケーション／ＳＤＫ１０は、仮リソースＩＤを引数としてテクスチャ指定命令を描画ライブラリ２０に発行する（Ｓ１６０）。描画ライブラリ２０は、テクスチャ指定命令の命令ＩＤと仮リソースＩＤをクライアント２００に送信し（Ｓ１６２）、命令の完了をアプリケーション／ＳＤＫ１０に通知する（Ｓ１６４）。

クライアント２００において、描画ライブラリ６０は、サーバ１００から送信された命令ＩＤと仮リソースＩＤを受信する（Ｓ１６６）。描画ライブラリ６０は、仮リソースＩＤをキーにした実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ１６８）。ＩＤ対応付け管理部７０は、仮リソースＩＤに対応づけられた実リソースＩＤを描画ライブラリ６０に返す（Ｓ１７０）。

描画ライブラリ６０は、実リソースＩＤを引数としたテクスチャ指定命令をＧＰＵ８０に供給する（Ｓ１７２）。ＧＰＵ８０はテクスチャ指定命令を実行し、実リソースＩＤに割り当てられたテクスチャデータが指定される。

サーバ１００において、各種描画命令を所定の引数とともに描画ライブラリ２０に供給する（Ｓ１７４）。描画ライブラリ２０は、描画命令の命令ＩＤと引数をクライアント２００に送信し（Ｓ１７６）、命令の完了をアプリケーション／ＳＤＫ１０に通知する（Ｓ１７８）。

クライアント２００において、描画ライブラリ６０は、サーバ１００から送信された命令ＩＤと引数を受信する（Ｓ１８０）。描画ライブラリ６０は、引数とともに描画命令をＧＰＵ８０に供給する（Ｓ１８２）。このとき、現在、ＧＰＵ８０において指定されている実リソースＩＤにマッピングされた低解像度テクスチャデータを使って描画処理が実行される。

図５は、描画処理システムによるテクスチャ更新の流れを示すシーケンス図である。図３Ａで説明したように、描画ライブラリ２０からデータ送信管理部３０に対して、高解像度テクスチャデータ送信の予約がなされており、ネットワーク３００の帯域に余裕があれば、送信スレッド３５により高解像度テクスチャデータがクライアント２００に送信される。

サーバ１００において、送信スレッド３５は、ネットワーク３００の送信状況を確認する（Ｓ９０）。ネットワーク３００の使用可能帯域に余裕があると判定された場合、送信スレッド３５は、ネットワーク３００を介して、データ識別ＩＤと高解像度テクスチャデータをクライアント２００に送信する（Ｓ９２）。

クライアント２００において、受信スレッド５５は、サーバ１００から送信されたデータ識別ＩＤと高解像度テクスチャデータを受信する（Ｓ９４）。受信スレッド５５は、データ識別ＩＤをキーにして受信履歴を確認する（Ｓ９６）。受信スレッド５５は、データ識別ＩＤに対して受信済みの古いデータ（ここでは低解像度テクスチャデータ）がある場合、ローカルキャッシュに格納された古いデータを高解像度テクスチャデータで更新する（Ｓ９８）。受信スレッド５５は、データ識別ＩＤとともにデータの更新を描画ライブラリ６０に通知する（Ｓ１００）。

描画ライブラリ６０は、データ識別ＩＤをキーにした仮リソースＩＤと実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ１０２）。ＩＤ対応付け管理部７０は、データ識別ＩＤに対応づけられた仮リソースＩＤと実リソースＩＤを描画ライブラリ６０に返す（Ｓ１０４）。

描画ライブラリ６０は、実リソースＩＤを引数としてテクスチャのリソース解放命令をＧＰＵ８０に供給する（Ｓ１０６）。これにより、ＧＰＵ８０は実リソースＩＤに対応するリソースを解放する。描画ライブラリ６０は、テクスチャのリソース割り当て要求命令をＧＰＵ８０に供給する（Ｓ１０８）。ＧＰＵ８０は、新しい実リソースＩＤを生成して描画ライブラリ６０に返す（Ｓ１１０）。

描画ライブラリ６０は、データ識別ＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ１１２）。データ受信管理部５０は、データ識別ＩＤにもとづいて受信履歴を検索し（Ｓ１１４）、ローカルキャッシュに格納された高解像度テクスチャデータを描画ライブラリ６０に供給する（Ｓ１１６）。

描画ライブラリ６０は、テクスチャリソースにデータを設定する命令をＧＰＵ８０に供給する（Ｓ１１８）。この命令には、新しい実リソースＩＤ、高解像度テクスチャデータが引数として与えられる。これにより、実リソースＩＤに高解像度テクスチャデータがマッピングされる。また、描画ライブラリ６０は、仮リソースＩＤ、新しい実リソースＩＤ、およびデータ識別ＩＤを対応づけたマッピング情報の登録をＩＤ対応付け管理部７０に要求する（Ｓ１２０）。

上記の説明では、低解像度テクスチャデータを高解像テクスチャデータに置き換えるために、低解像度テクスチャデータがマッピングされた古い実リソースＩＤをいったん削除した上で、新しく生成された実リソースＩＤに高解像度テクスチャデータをマッピングした。ＧＰＵ８０の仕様によっては、実リソースＩＤを削除せずに、同じ実リソースＩＤに新しいテクスチャデータをマッピングすることでデータの置き換えが可能なものもある。その場合は、古い実リソースＩＤの削除、新しい実リソースＩＤの生成の処理は割愛することができる。

図６は、図５のテクスチャ更新によりテクスチャデータが置換された後の描画処理の流れを示すシーケンス図である。図６のテクスチャ更新後の描画処理の各ステップは図４の描画処理の対応する各ステップと同じであるが、ステップＳ１８２において、描画ライブラリ６０がＧＰＵ８０に描画命令を与えたとき、ＧＰＵ８０は、新しい実リソースＩＤにマッピングされた高解像度テクスチャデータを使って描画する点が異なる。

図７は、描画処理システムによるテクスチャ削除の流れを示すシーケンス図である。

サーバ１００において、アプリケーション／ＳＤＫ１０は、仮リソースＩＤを引数としてテクスチャリソースの解放命令を描画ライブラリ２０に発行する（Ｓ１３０）。描画ライブラリ２０は、テクスチャリソース解放命令の命令ＩＤと仮リソースＩＤをネットワーク３００を介してクライアント２００に送信し（Ｓ１３２）、描画ライブラリ２０は、命令の完了をアプリケーション／ＳＤＫ１０に通知する（Ｓ１３４）。

クライアント２００において、描画ライブラリ６０は、サーバ１００から送信された命令ＩＤと仮リソースＩＤを受信する（Ｓ１３６）。描画ライブラリ６０は、仮リソースＩＤをキーにした実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ１３８）。ＩＤ対応付け管理部７０は、仮リソースＩＤに対応づけられた実リソースＩＤを描画ライブラリ６０に返す（Ｓ１４０）。

描画ライブラリ６０は、実リソースＩＤを引数としてテクスチャリソースの解放命令をＧＰＵ８０に供給する（Ｓ１４２）。ＧＰＵ８０は、実リソースＩＤに対応づけられたテクスチャリソースを解放する。描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤを対応づけたマッピングの解除をＩＤ対応付け管理部７０に要求する（Ｓ１４４）。ＩＤ対応付け管理部７０は、仮リソースＩＤと実リソースＩＤのマッピングを解除する。

図８Ａおよび図８Ｂは、サーバ１００の描画ライブラリ２０の処理を示すフローチャートである。

図８Ａを参照する。テクスチャリソースにデータを設定する命令であれば（Ｓ２００のＹ）、ステップＳ２０２に進み、そうでなければ（Ｓ２００のＮ）、図８Ｂに示すステップＳ２１８に進む。

ステップＳ２０２において、描画ライブラリ２０はデータ送信管理部３０に送信履歴を問い合わせる。テクスチャデータを送信済みであれば（Ｓ２０４のＹ）、ステップＳ２１６に進む。テクスチャデータを未送信であれば（Ｓ２０４のＮ）、描画ライブラリ２０はデータ送信管理部３０に現在のネットワーク３００の送信状況を確認する（Ｓ２０６）。ネットワーク３００の帯域に余裕があれば（Ｓ２０８のＹ）、描画ライブラリ２０はデータ送信管理部３０に高解像度テクスチャデータの送信を依頼し（Ｓ２１０）、ステップＳ２１６に進む。ネットワーク３００の帯域に余裕がなければ（Ｓ２０８のＮ）、描画ライブラリ２０はデータ送信管理部３０にまず低解像度テクスチャデータの送信を依頼し（Ｓ２１２）、さらにデータ送信管理部３０に高解像度テクスチャデータのタイムシフト送信を予約し（Ｓ２１４）、ステップＳ２１６に進む。ここで、タイムシフト送信とは、時間をずらしてネットワーク帯域に余裕があるときにデータを送信することである。

ステップＳ２１６において、描画ライブラリ２０は、クライアント２００で処理を実行するために必要となる、テクスチャリソースにデータを設定する命令の命令ＩＤ、仮リソースＩＤ、およびデータ識別ＩＤをクライアント２００に送信する。

図８Ｂを参照する。ステップＳ２１８において、テクスチャリソース割り当て要求命令であれば（Ｓ２１８のＹ）、描画ライブラリ２０は仮リソースＩＤを生成し（Ｓ２２０）、クライアント２００で処理を実行するために必要となる、テクスチャリソース割り当て要求命令の命令ＩＤおよび仮リソースＩＤをクライアント２００に送信し（Ｓ２２２）、仮リソースＩＤをアプリケーション／ＳＤＫ１０に通知する（Ｓ２２４）。ステップＳ１２８において、テクスチャリソース割り当て要求命令でなければ（Ｓ２１８のＮ）、ステップＳ２２６に進む。

ステップＳ２２６において、テクスチャ指定命令であれば（Ｓ２２６のＹ）、描画ライブラリ２０は、クライアント２００で処理を実行するために必要となる、テクスチャ指定命令の命令ＩＤおよび仮リソースＩＤをクライアント２００に送信する（Ｓ２２８）。ステップＳ２２６において、テクスチャ指定命令でなければ（Ｓ２２６のＮ）、ステップＳ２３０に進む。

ステップＳ２３０において、テクスチャリソースの解放命令であれば（Ｓ２３０のＹ）、描画ライブラリ２０は、クライアント２００で処理を実行するために必要となる、テクスチャリソース解放命令の命令ＩＤおよび仮リソースＩＤをクライアント２００に送信する（Ｓ２３２）。ステップＳ２３０において、テクスチャリソースの解放命令以外の他の命令であれば（Ｓ２３０のＮ）、描画ライブラリ２０は、その命令の命令ＩＤおよび仮リソースＩＤをクライアント２００に送信する（Ｓ２３４）。

図９Ａ、図９Ｂおよび図９Ｃは、クライアント２００の描画ライブラリ６０の処理を示すフローチャートである。

図９Ａを参照する。描画ライブラリ６０はイベントを待ち、イベントが発生したとき、命令ＩＤ、引数等を受信する（Ｓ２４０）。

テクスチャリソースにデータを設定する命令であれば（Ｓ２４２のＹ）、ステップＳ４４４に進み、そうでなければ（Ｓ２４２のＮ）、ステップＳ２５８に進む。

ステップＳ２４４において、描画ライブラリ６０は、データ識別ＩＤをキーとしてデータ受信管理部５０に受信履歴を問い合わせる。データを未受信であれば（Ｓ２４６のＮ）、受信待ち状態に入り（Ｓ２４８）、ステップＳ２４４に戻る。データを受信済みであれば（Ｓ２４６のＹ）、描画ライブラリ６０はデータ識別ＩＤに対応するデータをデータ受信管理部５０から取得する（Ｓ２５０）。描画ライブラリ６０は、ＩＤ対応付け管理部７０に問い合わせて仮リソースＩＤを実リソースＩＤに変換する（Ｓ２５２）。描画ライブラリ６０は、データ受信管理部５０から取得したデータを実リソースＩＤを使ってＧＰＵ８０に設定する（Ｓ２５４）。描画ライブラリ６０は、仮リソースＩＤ、実リソースＩＤ、およびデータ識別ＩＤのマッピングをＩＤ対応付け管理部７０に記録し（Ｓ２５６）、ステップＳ２４０に戻る。

ステップＳ２５８において、テクスチャ更新イベントであれば（Ｓ２５８のＹ）、描画ライブラリ６０は、テクスチャ更新処理を行う（ステップＳ２６０）。描画ライブラリ６０によるテクスチャ更新処理の詳細については図９Ｃで説明する。ステップＳ２５８において、テクスチャ更新イベントでなければ（Ｓ２５８のＮ）、図９ＢのステップＳ２６２に進む。

図９Ｂを参照する。ステップＳ２６２において、テクスチャリソース割り当て要求命令であれば（Ｓ２６２のＹ）、描画ライブラリ６０はＧＰＵ８０にリソース割り当て要求を発行して実リソースＩＤをＧＰＵ８０から取得する（Ｓ２６４）。描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤのマッピングをＩＤ対応付け管理部７０に登録する（Ｓ２６６）。ステップＳ２６２において、テクスチャリソース割り当て要求命令でなければ（Ｓ２６２のＮ）、ステップＳ２６８に進む。

ステップＳ２６８において、テクスチャ指定命令であれば（Ｓ２６８のＹ）、描画ライブラリ６０は、ＩＤ対応付け管理部７０に問い合わせて仮リソースＩＤを実リソースＩＤに変換する（Ｓ２７０）。描画ライブラリ６０は、実リソースＩＤを使ってＧＰＵ８０に対してテクスチャを指定する（Ｓ２７２）。ステップＳ２６８において、テクスチャ指定命令でなければ（Ｓ２６８のＮ）、ステップＳ２７４に進む。

ステップＳ２７４において、テクスチャリソースの解放命令であれば（Ｓ２７４のＹ）、描画ライブラリ６０は、ＩＤ対応付け管理部７０に問い合わせて仮リソースＩＤを実リソースＩＤに変換する（Ｓ２７６）。描画ライブラリ６０は、実リソースＩＤを使ってＧＰＵ８０に対してリソースの解放を要求する（Ｓ２７８）。描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤのマッピングをＩＤ対応付け管理部７０から削除する（Ｓ２８０）。

ステップＳ７４において、テクスチャリソースの解放命令以外の他の命令であれば（Ｓ２７４のＮ）、描画ライブラリ６０はＧＰＵ８０にその命令ＩＤに対応する命令を実行させる（Ｓ２８２）。

図９Ｃを参照して、ステップＳ２６０のテクスチャ更新処理を詳細に説明する。描画ライブラリ６０は、データ識別ＩＤに対応づけられた仮リソースＩＤと実リソースＩＤをＩＤ対応付け管理部７０から取得する（Ｓ２８４）。

描画ライブラリ６０は、実リソースＩＤを使ってＧＰＵ８０に対してリソースの解放を要求する（Ｓ２８６）。描画ライブラリ６０は、ＧＰＵ８０に対してリソース割り当て要求を発行して、新しい実リソースＩＤを取得する（Ｓ２８８）。

描画ライブラリ６０は、データ識別ＩＤを使ってデータ受信管理部５０から更新されたデータを取得する（Ｓ２９０）。描画ライブラリ６０は、新しい実リソースＩＤを使って更新されたデータをＧＰＵ８０に登録する（Ｓ２９２）。描画ライブラリ６０は、仮リソースＩＤ、実リソースＩＤ、およびデータ識別ＩＤのマッピングをＩＤ対応付け管理部７０で更新する（Ｓ２９４）。

［Ｂ］データ識別ＩＤを用いない実装
図１０Ａ〜図１３Ｂを参照して、データ識別ＩＤを用いない実装を説明する。この場合、後述のように、仮リソースＩＤおよび実リソースＩＤを互いに対応づけて管理する。

図１０Ａおよび図１０Ｂは、描画処理システムによるテクスチャ登録の流れを示すシーケンス図である。［Ａ］データ識別ＩＤを用いる場合の図３Ａおよび図３Ｂに示した処理ステップと同じものには同一の符号を付している。

図１０Ａを参照する。サーバ１００において、アプリケーション／ＳＤＫ１０は、テクスチャリソース割り当て要求命令をサーバ側の描画ライブラリ２０に発行する（Ｓ１０）。サーバ側の描画ライブラリ２０は、テクスチャリソース割り当て要求命令にしたがって仮リソースＩＤを生成する（Ｓ１２）。

描画ライブラリ２０は、テクスチャリソース割り当て要求命令の命令ＩＤと仮リソースＩＤをネットワーク３００を介してクライアント２００に送信する（Ｓ１４）。描画ライブラリ２０は、アプリケーション／ＳＤＫ１０に仮リソースＩＤを返す（Ｓ１６）。

クライアント２００において、クライアント側の描画ライブラリ６０は、サーバ側の描画ライブラリ２０から送信された命令ＩＤと仮リソースＩＤをネットワーク３００を介して受信する（Ｓ１８）。描画ライブラリ６０は、テクスチャリソース割り当て要求命令をＧＰＵ８０に発行する（Ｓ２０）。ＧＰＵ８０はテクスチャリソース割り当て要求命令を実行して実リソースＩＤを生成し、描画ライブラリ６０に実リソースＩＤを返す（Ｓ２２）。

描画ライブラリ６０は、仮リソースＩＤと実リソースＩＤの対応付けを示すマッピング情報をＩＤ対応付け管理部７０に供給し、ＩＤ対応付け管理部７０はマッピング情報を登録する（Ｓ２４）。

サーバ１００において、アプリケーション／ＳＤＫ１０は、テクスチャリソースにデータを設定する命令をサーバ側の描画ライブラリ２０に発行する（Ｓ２７）。この命令には、仮リソースＩＤ、高解像度テクスチャデータ、および低解像度テクスチャデータが引数として与えられる。

描画ライブラリ２０は、ネットワークの送信状況をデータ送信管理部３０に問い合わせる（Ｓ３４）。データ送信管理部３０は、判定結果を描画ライブラリ２０に返す（Ｓ３６）。判定結果が「帯域不足」であれば、描画ライブラリ２０は、低解像度データ送信の指示をデータ送信管理部３０に供給する（Ｓ３９）。この送信指示には、仮リソースＩＤと低解像度テクスチャデータが引数として与えられる。

データ送信管理部３０は、低解像度データ送信を送信スレッド３５に委譲する（Ｓ４１）。このときも仮リソースＩＤと低解像度テクスチャデータが引数として与えられる。

さらに、描画ライブラリ２０は、高解像データ送信の予約をデータ送信管理部３０に供給する（Ｓ４５）。このとき、仮リソースＩＤと高解像度テクスチャデータが引数として与えられる。描画ライブラリ２０は、命令ＩＤおよび仮リソースＩＤをクライアント２００に送信し（Ｓ４７）、命令の完了をアプリケーション／ＳＤＫ１０に通知する（Ｓ４８）。このときデータ自体は送信されないことに留意する。実際のデータ送信は、データ送信管理部３０からデータ送信を委譲された送信スレッド３５が実行する。クライアント２００において、描画ライブラリ６０は、サーバ１００から送信された命令ＩＤおよび仮リソースＩＤを受信する（Ｓ５１）。

図１０Ｂを参照する。サーバ１００の送信スレッド３５は、ネットワーク３００を介して仮リソースＩＤと低解像度テクスチャデータをクライアント２００に送信する（Ｓ５３）。クライアント２００の受信スレッド５５は仮リソースＩＤと低解像度テクスチャデータを受信する（Ｓ５５）。

一方、描画ライブラリ６０は、仮リソースＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ５７）。データ受信管理部５０は、仮リソースＩＤにもとづいて受信履歴を検索し（Ｓ５９）、判定結果を描画ライブラリ６０に返す（Ｓ６１）。判定の結果、仮リソースＩＤに対応するデータが未到着であれば、データの到着を待つ（Ｓ６３）。

受信スレッド５５は、送信スレッド３５から低解像度テクスチャデータの受信を完了すると、ローカルキャッシュへ低解像度テクスチャデータを登録し、仮リソースＩＤにもとづいて受信履歴を更新し（Ｓ６５）、描画ライブラリ６０へデータの更新を通知する（Ｓ６７）。

データの到着待ちであった描画ライブラリ６０が再び、仮リソースＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ６９）。データ受信管理部５０は、仮リソースＩＤにもとづいて受信履歴を検索し（Ｓ７１）、判定の結果、データが到着していれば、ローカルキャッシュに格納された低解像度テクスチャデータを描画ライブラリ６０に供給する（Ｓ７３）。

描画ライブラリ６０は、仮リソースＩＤをキーにした実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ７４）。ＩＤ対応付け管理部７０は、仮リソースＩＤに対応づけられた実リソースＩＤを描画ライブラリ６０に返す（Ｓ７６）。

描画ライブラリ６０は、テクスチャリソースにデータを設定する命令をＧＰＵ８０に供給する（Ｓ７８）。この命令には、実リソースＩＤ、低解像度テクスチャデータが引数として与えられる。

描画処理システムによる描画処理の流れは図４と同じであるから説明を省略する。

図１１は、描画処理システムによるテクスチャ更新の流れを示すシーケンス図である。図１０Ａで説明したように、描画ライブラリ２０からデータ送信管理部３０に対して、高解像度テクスチャデータ送信の予約がなされており、ネットワーク３００の帯域に余裕があれば、送信スレッド３５により高解像度テクスチャデータがクライアント２００に送信される。

サーバ１００において、送信スレッド３５は、ネットワーク３００の送信状況を確認する（Ｓ９０）。ネットワーク３００の使用可能帯域に余裕があると判定された場合、送信スレッド３５は、ネットワーク３００を介して、仮リソースＩＤと高解像度テクスチャデータをクライアント２００に送信する（Ｓ９３）。

クライアント２００において、受信スレッド５５は、サーバ１００から送信された仮リソースＩＤと高解像度テクスチャデータを受信する（Ｓ９５）。受信スレッド５５は、仮リソースＩＤをキーにして受信履歴を確認する（Ｓ９７）。受信スレッド５５は、仮リソースＩＤに対して受信済みの古いデータ（ここでは低解像度テクスチャデータ）がある場合、ローカルキャッシュに格納された古いデータを高解像度テクスチャデータで更新する（Ｓ９９）。受信スレッド５５は、仮リソースＩＤとともにデータの更新を描画ライブラリ６０に通知する（Ｓ１０１）。

描画ライブラリ６０は、仮リソースＩＤをキーにした実リソースＩＤの検索をＩＤ対応付け管理部７０に要求する（Ｓ１０３）。ＩＤ対応付け管理部７０は、仮リソースＩＤに対応づけられた実リソースＩＤを描画ライブラリ６０に返す（Ｓ１０５）。

描画ライブラリ６０は、実リソースＩＤを引数としてテクスチャのリソース解放命令をＧＰＵ８０に供給する（Ｓ１０６）。これにより、ＧＰＵ８０は実リソースＩＤに対応するリソースを解放する。描画ライブラリ６０は、テクスチャのリソース割り当て要求命令をＧＰＵ８０に供給する（Ｓ１０８）。ＧＰＵ８０は、新しい実リソースＩＤを生成して描画ライブラリ６０に返す（Ｓ１１０）。

描画ライブラリ６０は、仮リソースＩＤをキーにしてデータ受信管理部５０にデータの取得を要求する（Ｓ１１３）。データ受信管理部５０は、仮リソースＩＤにもとづいて受信履歴を検索し（Ｓ１１５）、ローカルキャッシュに格納された高解像度テクスチャデータを描画ライブラリ６０に供給する（Ｓ１１７）。

描画ライブラリ６０は、テクスチャリソースにデータを設定する命令をＧＰＵ８０に供給する（Ｓ１１８）。この命令には、新しい実リソースＩＤ、高解像度テクスチャデータが引数として与えられる。また、描画ライブラリ６０は、仮リソースＩＤおよび新しい実リソースＩＤを対応づけたマッピング情報の登録をＩＤ対応付け管理部７０に要求する（Ｓ１２１）。

図１１のテクスチャ更新によりテクスチャデータが置換された後の描画処理は図６と同じであるから説明を省略する。描画処理システムによるテクスチャ削除は図７と同じであるから説明を省略する。

図１２は、サーバ１００の描画ライブラリ２０の処理を示すフローチャートである。テクスチャリソースにデータを設定する命令であれば（Ｓ２００のＹ）、ステップＳ２０６に進み、そうでなければ（Ｓ２００のＮ）、［Ａ］データ識別ＩＤを用いる実装の場合と同様、図８Ｂに示すステップＳ２１８に進む。

ステップＳ２０６において、描画ライブラリ２０はデータ送信管理部３０に現在のネットワーク３００の送信状況を確認する。ネットワーク３００の帯域に余裕があれば（Ｓ２０８のＹ）、描画ライブラリ２０はデータ送信管理部３０に高解像度テクスチャデータの送信を依頼し（Ｓ２１０）、ステップＳ２１６に進む。ネットワーク３００の帯域に余裕がなければ（Ｓ２０８のＮ）、描画ライブラリ２０はデータ送信管理部３０にまず低解像度テクスチャデータの送信を依頼し（Ｓ２１２）、さらにデータ送信管理部３０に高解像度テクスチャデータのタイムシフト送信を予約し（Ｓ２１４）、ステップＳ２１７に進む。

ステップＳ２１７において、描画ライブラリ２０は、クライアント２００で処理を実行するために必要となる、テクスチャリソースにデータを設定する命令の命令ＩＤおよび仮リソースＩＤをクライアント２００に送信する。

図１３Ａおよび図１３Ｂは、クライアント２００の描画ライブラリ６０の処理を示すフローチャートである。

図１３Ａを参照する。描画ライブラリ６０はイベントを待ち、イベントが発生したとき、命令ＩＤ、引数等を受信する（Ｓ２４０）。

テクスチャリソースにデータを設定する命令であれば（Ｓ２４２のＹ）、ステップＳ４４５に進み、そうでなければ（Ｓ２４２のＮ）、ステップＳ２５８に進む。

ステップＳ２４５において、描画ライブラリ６０は、仮リソースＩＤをキーとしてデータ受信管理部５０に受信履歴を問い合わせる。データを未受信であれば（Ｓ２４６のＮ）、受信待ち状態に入り（Ｓ２４８）、ステップＳ２４５に戻る。データを受信済みであれば（Ｓ２４６のＹ）、描画ライブラリ６０は仮リソースＩＤに対応するデータをデータ受信管理部５０から取得する（Ｓ２５１）。描画ライブラリ６０は、ＩＤ対応付け管理部７０に問い合わせて仮リソースＩＤを実リソースＩＤに変換する（Ｓ２５２）。描画ライブラリ６０は、データ受信管理部５０から取得したデータを実リソースＩＤを使ってＧＰＵ８０に設定し（Ｓ２５４）、ステップＳ２４０に戻る。

ステップＳ２５８において、テクスチャ更新イベントであれば（Ｓ２５８のＹ）、描画ライブラリ６０は、テクスチャ更新処理を行う（ステップＳ２６１）。描画ライブラリ６０によるテクスチャ更新処理の詳細については図１３Ｂで説明する。ステップＳ２５８において、テクスチャ更新イベントでなければ（Ｓ２５８のＮ）、［Ａ］データ識別ＩＤを用いる実装の場合と同様、図９ＢのステップＳ２６２に進む。

図１３Ｂを参照して、ステップＳ２６１のテクスチャ更新処理を詳細に説明する。描画ライブラリ６０は、仮リソースＩＤに対応づけられた実リソースＩＤをＩＤ対応付け管理部７０から取得する（Ｓ２８５）。

描画ライブラリ６０は、実リソースＩＤを使ってＧＰＵ８０に対してリソースの解放を要求する（Ｓ２８６）。描画ライブラリ６０は、ＧＰＵ８０に対してリソース割り当て要求を発行して、新しい実リソースＩＤを取得する（Ｓ２８８）。

描画ライブラリ６０は、仮リソースＩＤを使ってデータ受信管理部５０から更新されたデータを取得する（Ｓ２９１）。描画ライブラリ６０は、新しい実リソースＩＤを使って更新されたデータをＧＰＵ８０に登録する（Ｓ２９２）。描画ライブラリ６０は、仮リソースＩＤおよび実リソースＩＤのマッピングをＩＤ対応付け管理部７０で更新する（Ｓ２９５）。

以下、本実施の形態の描画処理システムによる実施例をいくつか説明する。

［１］実施例１ データ通信量の平均化
本実施例では、ネットワークの負荷状況を監視して、利用可能な帯域が不足する場合は、動的にデータを差し替えてデータ送信量の平均化を行う。本実施例では、リソース割り当て要求により仮リソースＩＤが発行された後にデータを送信するため、データ識別ＩＤは必須ではなく、仮リソースＩＤと実リソースＩＤが対応づけられていればよいため、［Ａ］データ識別ＩＤを用いる実装、［Ｂ］データ識別ＩＤを用いない実装のいずれを用いても実現することができる。

サーバ１００において、ネットワーク監視装置が、送信しようとするデータによってネットワーク３００の利用可能帯域を超えることが予想されると判断したとき、サーバ１００のデータ送信管理部３０は、データ量が少ない低解像度データを代わりにクライアント２００に送信する。事前に用意された低解像度データを利用するか、もしなければ、低解像度データを動的に生成してもよい。一方、データ送信管理部３０は、本来の高解像度データの送信を予約し、ネットワーク３００の利用可能帯域に余裕ができたときに高解像データを送信することにより、データを更新してもよい。

クライアント２００において、データ受信管理部５０は、低解像度データを受信して保存し、描画ライブラリ６０が低解像度データをＧＰＵ８０に設定する。ＧＰＵ８０は、低解像度データを利用して描画処理を実行する。データ受信管理部５０が、高解像データを受信したら、データを更新し、描画ライブラリ６０が高解像データをＧＰＵ８０に設定する。ＧＰＵ８０は、それ以降、高解像度データを利用して描画処理を実行する。

このように、実施例１では、サーバ１００からクライアント２００へコマンドとは分離して静的データを送る構成において、ネットワークの負荷が高い場合には、データ量の少ない低品質データを先に送っておき、ネットワークの負荷が低くなってから、データ量の多い高品質データを送るタイムシフト送信を行う。これにより、データ通信量を平均化してネットワークの輻輳を回避し、結果的に描画処理システム全体の応答遅延を低減することができる。特にゲームなどリアルタイム性が要求されるアプリケーションを実行する際、応答性能を高めることができる。

［２］実施例２ エラー耐性の向上
本実施例では、データ送信時にエラーが発生した場合やデータが破損した場合、クライアント２００においてダミーデータを利用してアプリケーションを継続的に実行し、エラーから回復して正しいデータが送信された後、必要な描画処理を実行する。たとえば、テクスチャデータがエラーによって正しく送信されなかった場合は、クライアント２００はダミーテクスチャを用いて描画処理を実行し、エラー回復後に正しいテクスチャを受信してから改めてテクスチャマッピングを行う。本実施例では、リソース割り当て要求により仮リソースＩＤが発行された後にデータを送信するため、データ識別ＩＤは必須ではなく、仮リソースＩＤと実リソースＩＤが対応づけられていればよいため、上記［Ａ］、［Ｂ］いずれの実装を用いても実現することができる。

サーバ１００において、ネットワーク監視装置は、ネットワーク３００のデータ送信エラーを検出する。サーバ１００のデータ送信管理部３０は、データの再送を予約する。

クライアント２００において、描画ライブラリ６０が要求するデータがデータ受信管理部５０において未到着であれば、描画ライブラリ６０はダミーデータをＧＰＵ８０に設定する。ＧＰＵ８０はダミーデータを利用して描画処理を実行する。データが再送された場合、データ受信管理部５０はデータを保存し、描画ライブラリ６０が正しいデータをＧＰＵ８０に設定する。ＧＰＵ８０は、それ以降、正しいデータを利用して描画処理を実行する。

このように、実施例２では、サーバ１００からクライアント２００へコマンドとは分離して静的データを送る構成において、ネットワーク転送によるエラーが発生した場合には、ダミーデータにより描画処理を実行し、タイムシフトさせてデータを再送する。これにより、ネットワーク転送によるエラー耐性を向上させ、結果的に描画処理システム全体の応答遅延を低減することができる。

［３］実施例３ 事前のデータ転送
本実施例では、ゲームのタイトル画面表示中にテクスチャデータやモデルデータなどを事前に転送する。本実施例では、リソース割り当て要求により仮リソースＩＤが発行される前にデータを転送するため、データを一意に識別するデータ識別ＩＤが必要であり、［Ａ］データ識別ＩＤを用いる実装により実現することができる。

サーバ１００において、データ送信管理部３０は、描画処理に必要なデータを事前に順次送信する。アプリケーション／ＳＤＫ１０が描画コマンドを発行する際、データ送信管理部３０は、転送済みのデータについては送信をスキップする。

クライアント２００において、データ受信管理部５０は、受信したデータを保存し、描画ライブラリ６０からデータを要求された場合、保存したデータを描画ライブラリ６０に供給する。ＧＰＵ８０は、描画ライブラリ６０からデータを受け取り、描画処理を実行する。

このように、実施例３では、サーバ１００からクライアント２００へコマンドとは分離して静的データを送る構成において、描画処理に必要なデータをタイムシフトさせて事前に送信する。これにより、ネットワーク帯域が小さくても、要求されるピーク性能が低くなるので、問題なく動作し、結果的に描画処理システム全体の応答遅延を低減することができる。

実施例１〜３では、データとコマンドとを分離して、コマンドの実行に必要なデータをタイムシフトさせて送信する。実施例１および２では、データ送信をコマンド送信の後にずらして行うが、実施例３では、データ送信をあらかじめ行う。いずれの場合であっても、データ送信のタイミングをずらすことでネットワークの輻輳時にデータ転送量の平均化を図ったり、エラー耐性の向上を図ることができる。

さらに、実施例１では、データ更新の仕組みを利用することにより、先に送信された低品質のデータを後で送信された高品質のデータで差し替えることができ、ネットワークの混雑が解消された段階で描画品質を高めることができる。実施例２においても、データ更新の仕組みにより、ネットワークの輻輳により破損した古いデータを破損していない新しいデータに差し替えることができる。

［４］実施例４ データセットの切り換え
本実施例では、クライアント性能またはネットワーク性能に応じてサーバ１００からクライアント２００に送信するデータセットを切り替える。本実施例では、リソース割り当て要求により仮リソースＩＤが発行された後にデータを送信するため、データ識別ＩＤは必須ではなく、仮リソースＩＤと実リソースＩＤが対応づけられていればよいため、上記［Ａ］、［Ｂ］いずれの実装を用いても実現することができる。

サーバ１００において、クライアント２００またはネットワーク３００の性能を調べる。データ送信管理部３０は、性能に応じて低解像度のデータセットまたは高解像度のデータセットを切り替えて送信する。

クライアント２００において、データ受信管理部５０は、サーバ１００から送信されたデータを保存し、描画ライブラリ６０からデータを要求された場合、保存したデータを描画ライブラリ６０に供給する。ＧＰＵ８０は、描画ライブラリ６０からデータを受け取り、描画処理を実行する。

このように、実施例４では、サーバ１００からクライアント２００へコマンドとは分離して静的データを送る構成において、クライアント性能またはネットワーク性能に応じてデータセットを切り替えて送信する。これにより、性能に応じてネットワーク転送量を抑えることができ、結果的に描画処理システム全体の応答遅延を低減することができる。実施例１および２とは違い、データ更新はせずに、データセットを最初から切り替えて送信するため、データ転送量をさらに抑えることができる。

［５］実施例５ データカスタマイズ
本実施例では、クライアント２００が独自のテクスチャデータやモデルデータをカスタマイズして利用する。本実施例では、データの差し替えを指示するためにデータを一意に識別するデータ識別ＩＤが必要であり、［Ａ］データ識別ＩＤを用いる実装により実現することができる。

クライアント２００において、サーバ１００からデータ受信管理部５０が受信したデータに拘束されることなく、描画ライブラリ６０はクライアント側で適宜カスタマイズしたデータをＧＰＵ８０に設定する。ＧＰＵ８０は、描画ライブラリ６０によって差し替えられたデータにより描画処理を実行する。

このように、実施例５では、サーバ１００からクライアント２００へコマンドとは分離して静的データを送る構成において、クライアント側でデータを適宜カスタマイズして利用する。これにより、ユーザがテクスチャデータやモデルデータをカスタマイズすることが許容され、柔軟な描画処理が可能になる。

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

上記の説明では、サーバ１００からクライアント２００へコマンドとは分離して送信するデータとして主にテクスチャデータを例に挙げて実施例を説明したが、送信するデータは頂点データなどオブジェクトのモデルデータであっても処理は同じである。

仮リソースＩＤ、実リソースＩＤ、データ識別ＩＤのように「ＩＤ」と表記したが、ＡＰＩによってはハンドル、インスタンスのポインタなどいろいろな実装形態があり、何らかの形で一意に識別可能な情報であれば、任意の識別情報を用いることができる。データ識別ＩＤについても、ファイル名等、何らかの形でデータを一意に特定できるものであれば、任意の識別情報を用いることができる。

上記の説明では、仮リソースＩＤの生成はサーバ１００で行われたが、クライアント２００において仮リソースＩＤを生成してサーバ１００に返すようにしてもよい。ただし、仮リソースＩＤを転送するための遅延が発生し、応答速度が低下する可能性がある。

１０ アプリケーション／ＳＤＫ、 ２０ 描画ライブラリ、 ３０ データ送信管理部、 ３５ 送信スレッド、 ４０ａ 低品質テクスチャ／モデルデータ記憶部、 ４０ｂ 高品質テクスチャ／モデルデータ記憶部、 ５０ データ受信管理部、 ５５ 受信スレッド、 ６０ 描画ライブラリ、 ７０ ＩＤ対応付け管理部、 ８０ ＧＰＵ、 ９０ テクスチャ／モデルデータキャッシュ、 １００ サーバ、 ２００ クライアント、 ３００ ネットワーク、 ４００ ホストＣＰＵ、 ４１０ アプリケーション／ＳＤＫ、 ４２０ 静的データ、 ４３０ グラフィックドライバ、 ５００ ＧＰＵチップ、 ５１０ ＧＰＵ、 ５２０ ＧＰＵメモリ。

Claims (12)

1. 描画コマンドをネットワークを介して送信する描画ライブラリ部と、
   描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてネットワークを介して送信するデータ送信管理部とを含むことを特徴とする描画処理装置。
2. 前記データ送信管理部は、前記再利用可能なデータを描画コマンドの送信タイミングよりも後に時間をずらして送信することを特徴とする請求項１に記載の描画処理装置。
3. 前記データ送信管理部は、描画されたときの品質が異なる２種類の前記再利用可能なデータの内、品質の低い方のデータを、前記描画コマンドの送信タイミングとは時間をずらして送信した後、ネットワークの輻輳状態に応じて前記２種類のデータの内、品質の高い方のデータを送信するかどうかを決定することを特徴とする請求項１または２に記載の描画処理装置。
4. 前記データ送信管理部は、ネットワークの利用可能帯域または送信先の端末の処理性能に応じて、描画されたときの品質が異なる２種類の前記再利用可能なデータを切り替えて、前記描画コマンドの送信タイミングとは時間をずらして送信することを特徴とする請求項１または２に記載の描画処理装置。
5. 描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの受信タイミングとは時間をずらしてネットワークを介して受信するデータ受信管理部と、
   前記データ受信管理部により受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、ネットワークを介して描画コマンドを受信して前記グラフィックスプロセッサに供給する描画ライブラリ部とを含むことを特徴とする描画処理装置。
6. 前記データ受信管理部により、描画コマンドの受信タイミングよりも後に受信されるべき前記再利用可能なデータが受信されない場合、前記描画ライブラリ部は、ダミーデータをグラフィックスプロセッサにリソースとして設定することを特徴とする請求項５に記載の描画処理装置。
7. 前記描画ライブラリ部は、描画コマンドの実行に必要なリソースを識別するための仮リソースＩＤを受信し、
   前記仮リソースＩＤと、グラフィックスプロセッサによって実際に割り当てられたリソースを識別するための実リソースＩＤとを対応づけて登録するＩＤ対応付け管理部をさらに含み、
   前記描画ライブラリ部は、ネットワークを介して受信した仮リソースＩＤに対応する実リソースＩＤを前記ＩＤ対応付け管理部から取得し、前記データ受信管理部が受信した再利用可能なデータを、前記ＩＤ対応付け管理部から取得した実リソースＩＤで識別されるリソースに設定することを前記グラフィックスプロセッサに要求することを特徴とする請求項５に記載の描画処理装置。
8. ネットワークを介して描画コマンドを送信するサーバと、前記サーバから描画コマンドを受信するクライアントとを含む描画処理システムであって、
   前記サーバは、
   描画コマンドを前記クライアントに送信するサーバ側描画ライブラリ部と、
   描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらして前記クライアントに送信するデータ送信管理部とを含み、
   前記クライアントは、
   前記サーバから描画コマンドの実行に利用される再利用可能なデータを受信するデータ受信管理部と、
   前記データ受信管理部により受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、前記サーバから描画コマンドを受信して前記グラフィックスプロセッサに供給するクライアント側描画ライブラリ部とを含むことを特徴とする描画処理システム。
9. 前記サーバ側描画ライブラリ部は、描画コマンドの実行に必要なリソースを識別するための仮リソースＩＤを生成して前記クライアント側描画ライブラリ部に送信し、
   前記クライアント側描画ライブラリ部は、描画コマンドの実行に必要なリソースの割り当てを前記グラフィックスプロセッサに要求し、前記グラフィックスプロセッサによって実際に割り当てられたリソースを識別するための実リソースＩＤを前記グラフィックスプロセッサから受け取り、
   前記クライアントは、
   前記仮リソースＩＤと前記実リソースＩＤとを対応づけて登録するＩＤ対応付け管理部をさらに含み、
   前記クライアント側描画ライブラリ部は、前記サーバ側描画ライブラリ部から受信した仮リソースＩＤに対応する実リソースＩＤを前記ＩＤ対応付け管理部から取得し、前記データ受信管理部が受信した再利用可能なデータを、前記ＩＤ対応付け管理部から取得した実リソースＩＤで識別されるリソースに設定することを前記グラフィックスプロセッサに要求することを特徴とする請求項８に記載の描画処理システム。
10. 描画コマンドをネットワークを介して送信するステップと、
    描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてネットワークを介して送信するステップと、
    描画コマンドの実行に利用される再利用可能なデータを受信するステップと、
    受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、ネットワークを介して描画コマンドを受信してグラフィックスプロセッサに供給するステップとを含むことを特徴とする描画処理方法。
11. 描画コマンドをネットワークを介して送信する描画ライブラリ機能と、
    描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの送信タイミングとは時間をずらしてネットワークを介して送信するデータ送信管理機能とをコンピュータに実現させることを特徴とする描画処理プログラム。
12. 描画コマンドの実行に利用される再利用可能なデータを、描画コマンドの受信タイミングとは時間をずらしてネットワークを介して受信するデータ受信管理機能と、
    前記データ受信管理機能により受信された再利用可能なデータをグラフィックスプロセッサにリソースとして設定するとともに、ネットワークを介して描画コマンドを受信して前記グラフィックスプロセッサに供給する描画ライブラリ機能とをコンピュータに実現させることを特徴とする描画処理プログラム。

Images