JP4674729B2 - グラフィックス処理装置、グラフィックスライブラリモジュール、およびグラフィックス処理方法 - Google Patents

Description

この発明は、グラフィックス処理技術に関する。

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

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

シェーダプログラミングをサポートするために、一般にグラフィックスライブラリが提供されている。既存のグラフィックスライブラリは、ＧＰＵのハードウエア特有の機能を隠蔽化し、特定のＧＰＵに依存しないライブラリ関数を提供しているため、アプリケーションから見た場合、ハードウエアとソフトウエアの境界線が不透明である。そのため、プログラマが特定のＧＰＵのハードウエアレベルでグラフィックス処理を制御したい場合など、きめ細かな制御には既存のグラフィックスライブラリは適していない。

また、ＣＰＵがグラフィックス処理に関与するシステム構成の場合、ＣＰＵが汎用処理に時間を取られたり、ＧＰＵとの同期処理に時間がかかる状況では、ＣＰＵがボトルネックとなってシステム全体の性能が低下する。

本発明はこうした課題に鑑みてなされたものであり、その目的は、グラフィックスライブラリを用いたプログラミングの柔軟性を高めることにある。また、別の目的は、マルチプロセッサシステムにおいてグラフィックス処理の効率化を図ることにある。

上記課題を解決するために、本発明のある態様のグラフィックス処理装置は、グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムにもとづいて描画コマンドを生成するメインプロセッシングユニットと、前記メインプロセッシングユニットにより生成される描画コマンド列を保持するコマンドバッファが設けられるメモリと、前記コマンドバッファに保持された描画コマンド列を読み出して描画処理を実行するグラフィックスプロセッシングユニットとを含む。前記メインプロセッシングユニットは、アプリケーションプログラムから呼び出される各グラフィックス関数を、グラフィックスライブラリ内に描画属性を保持することなく、描画コマンドに変換し、前記コマンドバッファに蓄積する。

本発明の別の態様は、グラフィックスライブラリモジュールである。このグラフィックスライブラリモジュールは、アプリケーションプログラムから呼び出されるグラフィックス関数群をファイルにまとめたグラフィックスライブラリモジュールであって、当該グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムから呼び出される各グラフィックス関数を、当該グラフィックスライブラリ内に描画属性を保持することなく、描画コマンドに変換することにより、描画コマンド列を生成する機能をコンピュータに実現させる。

本発明のさらに別の態様は、グラフィックス処理方法である。この方法は、グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムから呼び出される各グラフィックス関数を、当該グラフィックスライブラリ内に描画属性を保持することなく、描画コマンドに変換することにより、描画コマンド列を生成し、コマンドバッファに保持するステップと、前記コマンドバッファに保持された描画コマンド列を読み出して描画処理を実行するステップとを含む。

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

本発明によれば、グラフィックスプログラミングの柔軟性を高め、また、グラフィックス処理の効率を向上させることができる。

実施の形態１
図１は、実施の形態１に係るグラフィックス処理システムの構成図である。このグラフィックス処理システムは、メインプロセッシングユニット１００と、グラフィックスプロセッシングユニット２００と、メインメモリ１２０と、ローカルメモリ２２０とを含む。

メインプロセッシングユニット１００は、単一のメインプロセッサであってもよく、複数のプロセッサを含むマルチプロセッサシステムであってもよく、あるいは、複数のプロセッサコアを１個のパッケージに集積したマルチコアプロセッサであってもよい。グラフィックスプロセッシングユニット２００は、グラフィックプロセッサコアを搭載したグラフィックチップである。

メインプロセッシングユニット１００の入出力ポートとグラフィックスプロセッシングユニット（以下、単に「ＧＰＵ」という）２００の入出力ポートは、入出力インタフェース（以下、「ＩＯＩＦ」と呼ぶ）１１０で接続されており、メインプロセッシングユニット１００とＧＰＵ２００は互いにＩＯＩＦ１１０を介してデータをやりとりすることができる。ＩＯＩＦ１１０は、非常に高速なインタフェースであり、その帯域幅は、メインプロセッシングユニット１００とメインメモリ１２０の間を結ぶバス１２２や、ＧＰＵ２００とローカルメモリ２２０の間を結ぶバス２２２の帯域幅にほぼ等しい。

グラフィックスライブラリ３００は、描画処理を行うために生成されるグラフィックスコマンドを生成および管理するためのライブラリであり、アプリケーション３１０からこのライブラリを呼び出してグラフィックス処理を実行することができる。また、グラフィックスライブラリ３００は、メモリ管理やデータ転送制御の機能を提供し、それらの機能を利用して、アプリケーション３１０から、メモリマッピングや、ジオメトリ情報、テクスチャ、シェーダプログラムなどのデータのメモリ間転送などを実行することができる。

メインプロセッシングユニット１００は、アプリケーション３１０がグラフィックスライブラリ３００を用いて生成した描画コマンドを、メインメモリ１２０内に設けられたコマンドバッファ１０にキューイングする。ＧＰＵ２００は、コマンドバッファ１０に蓄積された描画コマンドを順次読み出して処理する。

メインプロセッシングユニット１００によるコマンドバッファ１０への描画コマンドの書き込みはｐｕｔコマンドにより実行される。ＧＰＵ２００によるコマンドバッファ１０からの描画コマンドの読み出しはｇｅｔコマンドにより実行される。コマンドバッファ１０に対する描画コマンドの読み書きには、後述のｐｕｔポインタおよびｇｅｔポインタを用いた管理機構が提供されている。また、コマンドバッファ１０の読み書きに際し、メインプロセッシングユニット１００またはＧＰＵ２００を待たせるための同期機能が提供されており、アプリケーション３１０は、メインプロセッシングユニット１００からＧＰＵ２００への処理の流れをきめ細かく制御することができる。

メインプロセッシングユニット１００は、オブジェクトの３次元モデルにもとづいて、ポリゴンの頂点座標値、頂点カラー、法線ベクトル、ＵＶ値などのジオメトリデータ１２を生成し、メインメモリ１２０に格納する。また、メインプロセッシングユニット１００は、ポリゴン表面にマッピングするためのテクスチャ１４をメインメモリ１２０に格納する。さらに、メインプロセッシングユニット１００は、ハードディスクなどの記録媒体からシェーダプログラム１６を読み込み、メインメモリ１２０に格納する。

メインメモリ１２０のメモリ領域はＩ／Ｏアドレス空間にメモリマッピングされており、ＧＰＵ２００は、Ｉ／Ｏアドレス空間にメモリマップされたメインメモリ１２０のメモリ領域をＩＯＩＦ１１０経由で読み取ることができる。このように、ＧＰＵ２００は、ローカルメモリ２２０の他にメインメモリ１２０へアクセスすることができるため、ジオメトリデータ、テクスチャなどグラフィックス演算に必要なデータをローカルメモリ２２０にもメインメモリ１２０にも配置することができる。

ジオメトリデータ１２、テクスチャ１４およびシェーダプログラム１６が格納されたメインメモリ１２０内のメモリ領域は、ＩＯＩＦ１１０のコントローラに設けられたメモリ内のＩ／Ｏアドレス空間にメモリマッピングされる。ＧＰＵ２００は、ＩＯＩＦ１１０を介して、Ｉ／Ｏアドレス空間にメモリマッピングされたジオメトリデータ１２、テクスチャ１４およびシェーダプログラム１６を読み出す。

ＧＰＵ２００は、シェーダプログラム１６にしたがって、ジオメトリデータ１２を用いてポリゴンのラスタライズデータを生成し、ピクセルデータをフレームバッファ２０に書き込む。さらに、ＧＰＵ２００は、ポリゴン表面にテクスチャ１４をマッピングし、テクスチャマッピング後のピクセルデータをフレームバッファ２０に書き込む。

また、ＧＰＵ２００は、ローカルメモリ２２０内にジオメトリデータ２２、テクスチャ２４およびシェーダプログラム２６が格納されている場合、ローカルメモリ２２０からこれらのデータを読み出し、グラフィックス演算に利用する。これらのデータは、メインメモリ１２０からローカルメモリ２２０にあらかじめＤＭＡ転送してもよく、ＧＰＵ２００がＩＯＩＦ１１０経由でメインメモリ１２０から読み出し、ローカルメモリ２２０に格納してもよい。

図２（ａ）〜（ｃ）は、メインプロセッシングユニット１００がグラフィックスライブラリ３００を用いて生成する描画コマンドを説明する図である。一般に、描画コマンドは、図２（ａ）のようにインストラクション（命令）とデータを含む。ここで、インストラクションとは、ＧＰＵ２００が使用するインストラクションセットに含まれるものであり、グラフィックスチップに依存する。グラフィックスライブラリ３００は、グラフィックス関数をＧＰＵ２００で実行可能なインストラクションに変換する機能を提供する。

なお、描画コマンドは、図２（ｂ）のようにインストラクションのみからなる場合もあり、図２（ｃ）のように、インストラクションに対して複数のデータが付加される場合もある。以下、描画コマンドを単に「コマンド」という。

図３は、コマンドバッファ１０に対するコマンドの読み書きの管理機構を説明する図である。メインプロセッシングユニット１００は、ｐｕｔコマンドを発行してコマンドバッファ１０にコマンドを書き込む。一方、ＧＰＵ２００は、ｇｅｔコマンドを発行してコマンドバッファ１０からコマンドを読み出す。同図では、コマンドバッファ１０の上から下へ順にコマンドが書き込まれ、書き込まれたコマンドが上から下へ順に読み出される。コマンドバッファ１０は、一例としてリングバッファで実装されている。

コマンドバッファ１０の読み書きを管理するために、ｐｕｔポインタとｇｅｔポインタが用いられる。ｐｕｔポインタは、メインプロセッシングユニット１００が最後にコマンドの書き込みを完了させたコマンドバッファ１０の位置（アドレス）を指し、ｇｅｔポインタは、ＧＰＵ２００が次にコマンドを読み出すコマンドバッファ１０の位置（アドレス）を指す。ｐｕｔポインタ、ｇｅｔポインタはそれぞれ書き込み（ｗｒｉｔｅ）ポインタ、読み出し（ｒｅａｄ）ポインタと呼ばれることもある。

メインプロセッシングユニット１００は、コマンドバッファ１０にコマンドの書き込みが終わると、ｐｕｔポインタをその書き込んだコマンドの位置に進める。ＧＰＵ２００は、ｇｅｔポインタがｐｕｔポインタと異なる位置を指していれば、コマンドバッファ１０からコマンドを読み出す。ＧＰＵ２００は、コマンドバッファ１０からコマンドの読み出しが終わると、ｇｅｔポインタを一つ先に進める。ｇｅｔポインタがｐｕｔポインタを追いかけるようにしてコマンドバッファ１０からコマンドが読み込まれ、ｇｅｔポインタがｐｕｔポインタと同じ位置を示したとき、すなわち読み出すコマンドがなくなったとき、ＧＰＵ２００はコマンドの読み出しを停止し、新たにコマンドが書き込まれるのを待つ。アプリケーション３１０は、コマンドをコマンドバッファ１０に格納した後、ｐｕｔポインタを進めることで、ＧＰＵ２００に新しいコマンドを読ませることができる。

ｐｕｔポインタ、ｇｅｔポインタは、ＧＰＵ２００が管理するレジスタファイル２１０のｐｕｔレジスタ２１１、ｇｅｔレジスタ２１２にそれぞれマップされており、ＧＰＵ２００はこれらのレジスタの値を参照することでｐｕｔポインタとｇｅｔポインタが指すコマンドバッファ１０のアドレスを取得することができる。

次にアプリケーションプログラムにおいてグラフィックスライブラリ３００が提供するグラフィックス関数を呼び出した場合に、グラフィックスライブラリ３００内部でグラフィックス関数が描画コマンドに変換され、コマンドバッファ１０に描画コマンドが蓄積される仕組みを説明する。まず、比較のために、一般的なグラフィックスライブラリにより描画コマンドが生成される仕組みを説明した後で、本実施の形態のグラフィックスライブラリ３００により描画コマンドが生成される仕組みを説明する。

図４Ａは、一般的なグラフィックスライブラリにより描画コマンドが生成される様子を示す図である。上から下へプログラムの進行が示されている。コマンドバッファ１０には最初、２つのコマンドＹ、Ｚが格納されている（コマンド列４０）。プログラムにおいて関数Ａが呼び出されると、ライブラリ内部において、描画属性を格納したステートテーブルが更新されるが、この時点ではまだ描画コマンドは生成されない。したがって、コマンドバッファ１０には２つのコマンドＹ、Ｚだけが格納された状態が続く（コマンド列４１）。

次に、プログラムの進行に伴い、関数Ｂ、Ｃが呼び出されるが、ライブラリ内部においてステートテーブルが更新されるだけで、コマンドは生成されず、コマンドバッファ１０には２つのコマンドＹ、Ｚだけが格納された状態がさらに続く（コマンド列４２、４３）。

最後に、描画関数が読み出されると、ライブラリ内部に保持されたステートテーブルを参照してコマンドＡ〜Ｇが生成され、コマンドバッファ１０に蓄積される。その結果、コマンドバッファ１０には、既に存在する２つのコマンドＹ、Ｚに続いて、新しく生成されたコマンドＡ〜Ｇが格納された状態になる（コマンド列４４）。

このように、一般的なグラフィックスライブラリ、たとえば商用のシェーダプログラミング言語のライブラリや、オープンソースで提供されているグラフィックスライブラリでは、ライブラリ内部で描画属性を保持し、描画属性を更新しながら、ライブラリにとって都合のよいタイミングでグラフィックスチップ独自のインストラクションを生成している。グラフィックスライブラリ内部に保持される描画属性として、背景色やブレンディング関数のパラメータ、テクスチャの属性などがある。

グラフィックスチップによってグラフィックス関数を実現する描画コマンドが異なり、グラフィックスチップ独自の拡張がなされていることもある。そこで既存のグラフィックスライブラリは、グラフィックスチップに依存したインストラクションを隠蔽するため、描画属性をステートテーブルに保持し、呼び出されるグラフィックス関数に応じて、ステートテーブルに保持された描画属性を更新し、最終的にグラフィックスチップに適した描画コマンドを生成する。このようなグラフィックスライブラリの機能は、プログラマがグラフィックスチップの独自仕様を意識しないでアプリケーションプログラムを書くことができる点で利便性があり、特に、高機能化が進み、インストラクションセットが豊富となったグラフィックスチップに対するプログラミングを容易にする。また、グラフィックスチップのハードウエアでサポートされていない機能をソフトウエアで補ってＣＰＵで実行することも可能となる。

しかしながら、既存のグラフィックスライブラリには次のようなデメリットもある。
（１）関数単位の処理が遅い。ライブラリ内部で保持する描画属性を更新し、他の関連する情報と矛盾しないか、テストする必要があり、ＣＰＵによる計算時間がかかるからである。

（２）アプリケーションから見た場合、ソフトウエアとハードウエアの境界線が不明確である。すなわち、アプリケーションからは、呼び出したグラフィックス関数にもとづいてグラフィックスライブラリがいつ、どのような描画コマンドが生成するか、不透明である。どこまでがグラフィックスチップの機能で、どこからがソフトウエアで処理されているかがわからないため、デバッグが困難である。また、高速化のためにプログラムをチューニングしたり、性能低下の原因を解析することが難しい。

（３）メモリに対する操作自由度が低い。コマンドバッファがいつ、どのように作られるかが不透明であるため、グラフィックスライブラリ内でメモリ管理を行ったり、同期を取ることが難しい。
（４）グラフィックスライブラリは複数の描画コマンドリストを生成することができない。

このように、既存の一般的なグラフィックスライブラリは、グラフィックス機能をハードウエアレベルで管理したり、細かく制御したいというプログラマの高度なニーズには十分に応えることができない。そこで、本実施の形態では、ＧＰＵ２００に特化したグラフィックスライブラリ３００を提供し、プログラミングの自由度を高め、また、メモリ管理が自由にできるようにしている。

図４Ｂは、実施の形態のグラフィックスライブラリ３００により描画コマンドが生成される様子を示す図である。図４Ａで説明した既存のグラフィックスライブラリとは違い、本実施の形態のグラフィックスライブラリ３００は、描画属性を一切保持しないため、各関数Ａ、Ｂ、Ｃが読み出される度に、グラフィックスライブラリ３００内部で描画コマンドが生成される。

コマンドバッファ１０には最初、２つのコマンドＹ、Ｚが格納されている（コマンド列５０）。プログラムにおいて関数Ａが呼び出されると、グラフィックスライブラリ３００内部においてＧＰＵ２００用のコマンドＡが生成され、コマンドバッファ１０に蓄積される（コマンド列５１）。

同様に、関数Ｂが呼び出されると、グラフィックスライブラリ３００内部においてＧＰＵ２００用のコマンドＢが生成され、コマンドバッファ１０に蓄積される（コマンド列５２）。さらに、関数Ｃが呼び出されると、グラフィックスライブラリ３００内部においてＧＰＵ２００用のコマンドＣ、Ｄが生成され、コマンドバッファ１０に蓄積される（コマンド列５３）。

最後に、描画関数が読み出されると、グラフィックスライブラリ３００内部においてＧＰＵ２００用のコマンドＥ〜Ｉが生成され、コマンドバッファ１０に蓄積される（コマンド列５４）。

図４Ａおよび図４Ｂの違いを具体的な例で説明する。既存のグラフィックスライブラリであるＯｐｅｎＧＬ（Open Graphics Library）を用いて、次のプログラムを実行するとする。

glBlendColor(); //ブレンド色の設定
glAlphaFunc(); //アルファテスト関数の設定
glViewport(); //ビューポート領域の設定
glDepthRange(); //Ｚ値と奥行き値の対応関係の設定
glFrontFace(); //ポリゴンの表裏の定義
glScissor(); //シザリングボックスの設定
glDrawElement(); //プリミティブのレンダリング

各関数glBlendColor()、glAlphaFunc()、glViewport()、glDepthRange()、glFrontFace()、glScissor()が呼び出されると、グラフィックスライブラリ内で、ブレンド色、アルファテスト関数、ビューポート領域、Ｚ値と奥行き値の対応関係、ポリゴンの表裏、シザリングボックスといった描画属性が設定され、最後に描画関数glDrawElement()が呼び出された時点で初めて、描画属性をもとにしてグラフィックスチップ専用の描画コマンドが生成される。

既存のグラフィックスライブラリでは、関数の呼び出し毎にライブラリ内で保持された描画属性が更新される。最終的に描画関数が呼び出される前に呼び出されたライブラリ関数によって描画属性がどのような状態にあるかによって実際に生成される描画コマンドが異なる。既存のグラフィックスライブラリでは描画属性情報を内部的に抱えているため、ある関数を呼び出して描画属性が変更されると、その変更された描画属性が次の関数の呼び出しにも引き継がれてしまうからである。

また、ライブラリ関数の間に依存関係があり、描画属性が上書きされる場合、ライブラリ関数の呼び出し順序によって、最終的に生成される描画コマンドが異なる。たとえば、テクスチャ画像を設定する関数glTexImage2D()とテクスチャパラメータを設定する関数glTexParameter()を呼び出す場合を例に説明すると、先にglTexImage2D()を呼び出してテクスチャ画像の属性を設定してから、次にglTexParameter()を呼び出してテクスチャパラメータを設定する場合と、先にglTexParameter()を呼び出してテクスチャパラメータを設定したから、次にglTexImage2D()を呼び出してテクスチャ画像の属性を設定する場合とでは、最終的にグラフィックスチップで実行されるべき描画コマンドが異なることになる。

一方、本実施の形態のグラフィックスライブラリ３００を用いて、同様のプログラムを書くと次のようになる。

gcmSetBlendColor(); //ブレンド色の設定
gcmSetAlphaFunc(); //アルファテスト関数の設定
gcmSetViewport(); //ビューポート領域の設定
gcmSetFrontFace(); //ポリゴンの表裏の定義
gcmSetScissor(); //シザリングボックスの設定
gcmSetDrawIndex(); //プリミティブのレンダリング

各関数gcmSetBlendColor()、gcmSetAlphaFunc()、gcmSetViewport()、gcmSetFrontFace()、gcmSetScissor()が呼び出される時点で、グラフィックスライブラリ３００内で、ブレンド色設定コマンド、アルファテスト関数設定コマンド、ビューポート領域設定コマンド、ポリゴンの表裏設定コマンド、シザリングボックス設定コマンドがそれぞれ生成される。最後に描画関数gcmSetDrawIndex()が呼び出される時点で、プリミティブをレンダリングするためのコマンドが生成される。グラフィックスライブラリ３００内部では描画属性が一切保持されず、ライブラリ関数が呼び出されると、ただちに各種の設定コマンドに変換される。

本実施の形態のグラフィックスライブラリ３００では、ライブラリ内部に描画属性を保持しないため、ライブラリ関数は描画属性の状態に影響されない。以前の他のライブラリ関数の呼び出しによってどのような描画コマンドが設定されようとも、同じライブラリ関数に対して常に同じ描画コマンドが生成される。また、ライブラリ関数の呼び出し順序を変えても、生成される描画コマンドに違いは生じない。たとえば、テクスチャ画像を設定する関数gcmSetTexture()、テクスチャのアドレスを設定する関数gcmSetTextureAddress()、テクスチャのフィルタリングを設定する関数gcmSetTextureFilter()を呼び出す場合、gcmSetTexture()、gcmSetTextureAddress()、gcmSetTextureFilter()の順に呼び出しても、gcmSetTextureFilter()、gcmSetTexture()、gcmSetTextureAddress()の順に呼び出しても、描画コマンドは同一のものが生成される。

ライブラリ内部に描画属性を保持しないことにより、グラフィックスライブラリ３００が複数のコマンドバッファにコマンドを生成することが可能になる。グラフィックスライブラリ３００が第１のコマンドバッファにコマンドを生成し、次に第２のコマンドバッファにコマンドを生成し、さらに第１のコマンドバッファに戻ってコマンドを生成するというように、第１のコマンドバッファと第２のコマンドバッファを切り替えながらそれぞれのコマンドバッファにコマンドを生成する。このような場合でもグラフィックスライブラリ３００は、内部的に描画属性を抱えていないので、２つのコマンドバッファが互いに影響を及ぼすことはなく、２つのコマンドバッファに独立にコマンドを生成していくことができる。

一方、既存のグラフィックスライブラリでは、内部的に描画属性を保持しているため、第１のコマンドバッファに生成するコマンドのためにある描画属性を変更し、続いて第２のコマンドバッファにコマンドを生成する場合、第１のコマンドバッファで設定した描画属性が第２のコマンドバッファのコマンド生成に引き継がれてしまう。既存のグラフィックスライブラリが、本実施の形態のグラフィックスライブラリ３００のように２つのコマンドバッファに独立にコマンドを生成するためには、次のようにする必要がある。既存のグラフィックスライブラリが第１のコマンドバッファにコマンドを生成し、次に第２のコマンドバッファにコマンドを生成し、さらに第１のコマンドバッファに戻ってコマンドを生成するとき、第２のコマンドバッファにコマンドを生成したときに設定した描画属性をリセットし、第１のコマンドバッファにコマンドを生成するときの描画属性の設定状態に戻す。このようにコマンドバッファを切り替える度に描画属性の設定を元に戻すのは計算時間やメモリ量の面で効率的ではないため、既存のグラフィックスライブラリでは、一つのコマンドバッファにコマンドを生成するのが現実的であり、複数のコマンドバッファにコマンドを生成できるようには構成されていないのが通常である。

グラフィックスライブラリ３００では、ライブラリ関数がグラフィックスチップ専用の描画コマンドに即座に変換されるため、ＧＰＵ２００のハードウエアでサポートされていない機能をメインプロセッシングユニット１００においてソフトウエア処理することで機能を補うことは難しくなる。しかし、その反面、グラフィックスライブラリ３００には以下のようなメリットがある。

（１）関数単位の処理が高速である。ライブラリ内部で描画属性を保持しないため、描画属性の情報を検証する必要がないからである。

（２）アプリケーションから見た場合、ソフトウエアとハードウエアの境界線が明確であり、プログラマは、呼び出されたグラフィックス関数にもとづいてグラフィックスライブラリがどのタイミングでどのような描画コマンドを生成するかを正確に把握することができ、デバッグが容易になる。また、高速化のためにプログラムをチューニングしたり、性能低下の原因を解析することが容易である。

（３）グラフィックスライブラリをアプリケーションのメモリ管理機構に組み込むことができる。コマンドバッファがいつ、どのように作られるかが明確であるため、グラフィックスライブラリ内でメモリ管理を行ったり、同期を取ることが容易になる。
（４）グラフィックスライブラリは複数の描画コマンドリストを生成することができる。

（５）基本的には非同期に動作するＧＰＵ２００とメインプロセッシングユニット１００間のやりとりがプログラマにとって明確になるため、時間軸に沿った処理の流れをトレースすることが可能になる。

（６）ハードウエアに対する描画属性の設定をアプリケーション側でトラックすることができるようになる。これによりプログラマがアプリケーションの性能をハードウエアレベルで細かくチューニングすることが可能になる。

以下、グラフィックスライブラリ３００において複数の描画コマンドリストを用いる方法とその応用例を説明する。

図５は、コマンドバッファ１０のフロー制御を説明する図である。グラフィックスライブラリ３００は、ジャンプ、コール／リターンというフロー制御に関するコマンドをサポートしている。ジャンプは、パラメータで指定したアドレスへｇｅｔポインタを飛ばすコマンドであり、これによって任意の位置のコマンドリストをＧＰＵ２００に読ませることが可能になる。コールは、ジャンプ同様にパラメータで指定したアドレスへｇｅｔポインタを飛ばして、ＧＰＵ２００に飛び先のコマンドリストの読ませる。コールはリターンと対に用いられ、コールの次に続くコマンドのアドレスがリターンコマンドの戻りアドレスに設定される。

同図には、次のようなフロー制御の一例が示されている。（１）コマンドバッファ１０内のコマンドリストにおいてジャンプコマンドが実行され、別のコマンドリスト１１に飛ぶ。（２）飛び先のコマンドリスト１１においてコールコマンドが実行され、さらに別のコマンドリスト１３に飛ぶ。（３）コール先のコマンドリスト１３内でリターンコマンドが実行され、コール元のコマンドリスト１１に戻る。（４）コール元のコマンドリスト１１内でジャンプ命令が実行され、ジャンプ先のコマンドバッファ１０に飛ぶ。

ジャンプコマンドやコールコマンドを用いて複数のコマンドリストを自在につなげることでプログラムの流れを制御することができるようになる。また、プログラムをモジュール化してモジュール毎にコマンドリストを作って保持しておき、モジュール単位のコマンドリストをジャンプコマンドやコールコマンドで参照することで、コマンドリストを再利用することができるようになる。

図６（ａ）、（ｂ）は、複数のコマンドリストをジャンプコマンドでつなぐ様子を示す図である。図６（ａ）に示すように、第１コマンドリスト３０のジャンプＡは、第２コマンドリスト３１の先頭アドレスに飛ぶコマンドである。第２コマンドリスト３１のジャンプＢは、第３コマンドリスト３２の先頭アドレスに飛ぶコマンドである。第３コマンドリスト３２のジャンプＣは、第４コマンドリスト３３の先頭アドレスに飛ぶコマンドである。これにより、第１、第２、第３、第４コマンドリスト（符号３０、３１、３２、３３）の順にコマンドがＧＰＵ２００により読み出されて実行される。

図６（ｂ）に示すように、ジャンプコマンドの飛び先のアドレスを変更することで、コマンドリストの実行順序を簡単に変更することができる。第１コマンドリスト３０のジャンプＡの飛び先を第３コマンドリスト３２の先頭アドレスに変更し、第３コマンドリスト３２のジャンプＣの飛び先を第２コマンドリスト３１の先頭アドレスに変更する。これにより、第１、第３、第２、第４コマンドリスト（符号３０、３２、３１、３３）の順にコマンドがＧＰＵ２００により読み出されて実行される。

図７は、ジャンプコマンドによりループ処理を実現する様子を示す図である。第１コマンドリスト３０のジャンプＡにより、第２コマンドリスト３１の先頭アドレスに飛ぶ。第２コマンドリスト３１のジャンプＢにより、第３コマンドリスト３２の先頭アドレスに飛ぶ。第３コマンドリスト３２のジャンプＣにより、第４コマンドリスト３３の先頭アドレスに飛ぶ。第４コマンドリスト３３のジャンプＤにより、第１コマンドリスト３０の先頭アドレスに飛ぶ。これにより、第１〜第４コマンドリスト（符号３０〜３３）をこの順に繰り返し実行するループ処理が実現される。

図８（ａ）、（ｂ）は、ジャンプコマンドによりコマンドリストが再利用される仕組みを説明する図である。図８（ａ）は、比較のため、コマンドリストを再利用しない場合を示す。コマンドリストＣＡ１は、繰り返し利用されるプログラムモジュールＸに対応するコマンド列であり、４つのコマンドＷ、Ｘ、Ｙ、Ｚを含む。コマンドリストＣＡ１の最後のジャンプＡ１により、次のコマンドリストＣＢに飛ぶ。コマンドリストＣＢの最後のジャンプＢにより、さらにコマンドリストＣＣに飛ぶ。

コマンドリストＣＣの後、プログラムモジュールＸが再び呼び出され、コマンドリストＣＡ１と同じ４つのコマンドＷ、Ｘ、Ｙ、Ｚを含むコマンドリストＣＡ２が新たに生成される。コマンドリストＣＣの最後のジャンプＣの飛び先は、新たに生成されたコマンドリストＣＡ２の先頭アドレスに設定される。

新たに生成されたコマンドリストＣＡ２の最後のジャンプＡ２の飛び先は、次に実行されるコマンドリストＣＤの先頭アドレスに設定される。コマンドリストＣＤの後、プログラムモジュールＸが再び呼び出されるが、ここでもまたコマンドリストＣＡ１と同じ４つのコマンドＷ、Ｘ、Ｙ、Ｚを含むコマンドリストＣＡ３が新たに生成され、コマンドリストＣＤの最後のジャンプＣＤの飛び先は、新たに生成されたコマンドリストＣＡ３の先頭アドレスに設定される。新たに生成されたコマンドリストＣＡ３の最後のジャンプＡ３の飛び先は、次に実行されるコマンドリストＣＥの先頭アドレスに設定される。

このように、同一のプログラムモジュールＸが繰り返し呼び出される場合に同じコマンドリストを繰り返し生成することは非効率である。そこで、本実施の形態では図８（ｂ）のように、最初に作られたコマンドリストＣＡを再利用する。図８（ａ）とは違い、最初に作られたコマンドリストＣＡは再利用に備えてコマンドバッファに保持される。コマンドリストＣＣの後、プログラムモジュールＸが呼び出されると、コマンドリストＣＡが再利用され、コマンドリストＣＣの最後のジャンプＣの飛び先はコマンドリストＣＡの先頭アドレスに設定される。再利用されるコマンドリストＣＡの最後のジャンプＡ２の飛び先は、次のコマンドリストＣＤの先頭アドレスに設定される。

コマンドリストＣＤの後、再度プログラムモジュールＸが呼び出されるが、既に存在するコマンドリストＣＡが再利用され、コマンドＣＤの最後のジャンプＤの飛び先はコマンドリストＣＡの先頭アドレスに設定される。再利用されるコマンドリストＣＡの最後のジャンプＡ３の飛び先は、次のコマンドリストＣＥの先頭アドレスに設定される。

図８（ｂ）では、再利用されるコマンドリストＣＡの先頭にジャンプコマンドで飛ぶようにしたが、ジャンプコマンドの代わりにコールコマンドを用いてコマンドリストＣＡの先頭に飛ぶようにしてもよい。この場合、呼び出し先のコマンドリストＣＡの最後にリターンコマンドが実行され、いったんコール元に戻り、その後、次のコマンドリストに飛ぶことになる。

以上述べたように、グラフィックスライブラリ３００は、複数のコマンドリストを生成して、自在につなげたり、再利用することができる。コマンドリスト毎に独立したコマンドバッファを用いてもよく、一つのコマンドバッファに複数のコマンドリストを格納してもよい。

グラフィックスライブラリ３００は、プログラムモジュール毎に独立したコマンドバッファを用いてコマンドリストを生成することができる。たとえば、描画対象のオブジェクト毎に異なるコマンドバッファを用いたり、背景描画用に別のコマンドバッファを用いることができる。これにより、描画処理をコンポーネント化したり、分業することができる。また、オブジェクト毎に用意されたコマンドバッファを適宜選択することにより、描画対象となるオブジェクトを変更してシーンの再構成を容易に行うことができる。

一度生成したコマンドリストを再利用することにより、メモリの利用効率が向上し、また、メインプロセッシングユニット１００によるコマンド生成処理の負担が大幅に削減される。

なお、メインプロセッシングユニット１００がマルチプロセッサである場合や、マルチスレッドなどにより並列処理が可能である場合、複数のコマンドリストは並列に生成されてもよい。グラフィックスライブラリ３００が複数のコマンドバッファを独立に設定できることから、マルチプロセッサまたはマルチスレッドにより、プログラムを並列実行し、コマンドリストの生成を並列化することができる。

実施の形態２
図９および図１０は、実施の形態２に係るグラフィックス処理システムの構成図である。実施の形態２のメインプロセッシングユニット１００は、メインプロセッサ１０２とサブプロセッサ１０４を含むマルチプロセッサである。メインプロセッサ１０２は、汎用的な処理を実行するプロセッサである。一方、サブプロセッサ１０４は、グラフィックスに関する演算を実行するプロセッサであり、たとえば頂点シェーダやテクスチャマッピングなどのグラフィックス専用の機能を実行するのに適したプロセッサである。

実施の形態２では、実施の形態１のメインプロセッシングユニット１００とＧＰＵ２００の協調動作について説明する。実施の形態１で説明した構成と動作は実施の形態２についても当てはまるため、重複する説明は省略する。

図９は、メインプロセッサ１０２がグラフィックス処理に関与し、メインプロセッサ１０２、サブプロセッサ１０４、およびＧＰＵ２００が協調動作する構成である。

アプリケーションプログラムにしたがって、サブプロセッサ１０４は描画コマンドの実行に必要なジオメトリデータ１２とテクスチャ１４を生成する（符号６１）。サブプロセッサ１０４は描画コマンドの実行に必要なデータの生成が終わったことをメインプロセッサ１０２に通知する（符号６２）。メインプロセッサ１０２は、メインプロセッサ１０２からの通知を受けて、コマンドバッファ１０に描画コマンドを生成する（符号６３）。

このように、描画コマンドの実行に必要なジオメトリデータ１２やテクスチャ１４がサブプロセッサ１０４によって生成された後、メインプロセッサ１０２において描画コマンドが生成されることになるため、サブプロセッサ１０４からメインプロセッサ１０２への通知によって同期を取ることが必要になる。

メインプロセッサ１０２により描画コマンドの生成が終わると、メインプロセッサ１０２は、ＧＰＵ２００に対して、メインメモリ１２０の読み出し先アドレス、読み出しサイズ、読み出しタイミングを指定することで、ＧＰＵ２００にコマンドバッファ１０に蓄積されたコマンドを読ませる。実施の形態１では、ｐｕｔポインタとｇｅｔポインタを用いてコマンドバッファ１０に対する読み書きを管理する実装例を説明した。コマンドバッファ１０に対する読み書き以外にも、描画処理の終了通知や描画処理途中でラインタイムに更新される描画属性情報の取得などにおいても、メインプロセッサ１０２とＧＰＵ２００間の同期処理が必要になる。

メインプロセッサ１０２とＧＰＵ２００間の同期処理のために、メインプロセッサ１０２はＧＰＵ２００のレジスタファイル２１０内の専用レジスタ２１３にデータを書き込むことで通知を行う。あるいは、メインメモリ１２０内の共有領域１８にメインプロセッサ１０２とＧＰＵ２００がデータを読み書きすることにより、メインプロセッサ１０２とＧＰＵ２００間の同期処理がなされてもよい。

図９の構成では、メインプロセッサ１０２が描画コマンドを生成するため、メインプロセッサ１０２の処理負荷が増え、システム全体の処理性能が低下する。また、メインプロセッサ１０２とサブプロセッサ１０４間の同期処理と、メインプロセッサ１０２とＧＰＵ２００間の同期処理が必要である。メインプロセッサ１０２が別の処理をしているとき、同期処理のレイテンシが大きくなり、グラフィックス処理のリアルタイム性が損なわれる。

ゲームなどのリアルタイムアプリケーションでは、メインプロセッサ１０２の役割が増えてきている。メインプロセッサ１０２は、グラフィックス処理とディスプレイ出力、音声出力、音声認識や画像認識などの認識処理、物理シミュレーションなどのシミュレーション処理、各種入出力デバイスの制御、映像や音声などの符号化や復号などのストリーミング処理、人工知能、セキュリティ処理などを行う。このため、メインプロセッサ１０２がボトルネックになってアプリケーションの性能が決まってしまう。そこでメインプロセッサ１０２にしかできないＩ／Ｏ処理やセキュリティ処理などはメインプロセッサ１０２に任せ、メインプロセッサ１０２からグラフィックスに係る処理をオフロードしてメインプロセッサ１０２の処理負荷を軽減する。

グラフィックスはユーザの目に見える部分であり、高い品質が要求され、処理するデータ量も多いから、グラフィックス処理をメインプロセッサ１０２からオフロードすることによる効果は大きく、メインプロセッサ１０２を本来の汎用処理に専念させることができる。

メインプロセッサ１０２を使用しないで描画処理を行うシステムを構築するためには、描画コマンドの生成、コマンドバッファ１０の制御、およびＧＰＵ２００との同期処理をメインプロセッサ１０２をメインプロセッサ１０２を介さずに実現する必要がある。

図１０は、メインプロセッサ１０２がグラフィックス処理に関与せず、サブプロセッサ１０４とＧＰＵ２００が協調動作する構成である。

サブプロセッサ１０４は、描画コマンドに必要なジオメトリデータ１２とテクスチャ１４を生成する（符号６１）とともに、メインプロセッサ１０２に代わって描画コマンドもコマンドバッファ１０に生成する（符号６３）。サブプロセッサ１０４が描画コマンドの生成を行うから、図９のようにサブプロセッサ１０４からメインプロセッサ１０２への通知を行う必要はない。

コマンドバッファ１０の制御については、サブプロセッサ１０４が生成された描画コマンドリストに関する情報をＧＰＵ２００に通知することで行われる。この通知は、サブプロセッサ１０４がＧＰＵ２００のレジスタをＤＭＡにより更新することで行われる。通知のタイミングは描画コマンドを生成するサブプロセッサ１０４が制御すればよいため、メインプロセッサ１０２を介在させて同期を取る必要はない。

ＧＰＵ２００との同期処理についても、メインプロセッサ１０２を介在させることなく、サブプロセッサ１０４が直接、ＧＰＵ２００と同期を取ればよい。同期を取る手段として、サブプロセッサ１０４がＧＰＵ２００のレジスタファイル２１０の専用レジスタ２１３を制御する方法（符号７０）、メインメモリ１２０内の共有領域１８をサブプロセッサ１０４とＧＰＵ２００が読み書きする方法、ＧＰＵ２００がサブプロセッサ１０４に割り込みを行う方法（符号７２）がある。メインプロセッサ１０２を同期処理に介在させなくて済むため、メインプロセッサ１０２がボトルネックとなってリアルタイム性が損なわれる状況を回避することができる。

実施の形態３
図１１は、実施の形態３に係るグラフィックス処理システムの構成図である。実施の形態３のメインプロセッシングユニット１００は、メインプロセッサ１０２と複数のサブプロセッサ１０４ａ〜１０４ｄを含むマルチプロセッサである。実施の形態２と同様、メインプロセッサ１０２は汎用プロセッサであり、サブプロセッサ１０４ａ〜１０４ｄは汎用処理以外の処理、ここではグラフィックス処理を担当するプロセッサである。

複数のサブプロセッサ１０４ａ〜１０４ｄは同一のインストラクションセットを実行する同質（homogeneous）のプロセッサである。メインプロセッシングユニット１００全体で見た場合は、メインプロセッサ１０２とサブプロセッサ１０４ａ〜１０４ｄは互いに異種（heterogeneous）のプロセッサであるから、メインプロセッシングユニット１００全体としては異種混合のマルチプロセッサである。メインプロセッシングユニット１００は、これらのプロセッサを１つのパッケージに集積したマルチコアプロセッサであってもよい。

各サブプロセッサ１０４ａ〜１０４ｄは、それぞれ独立にコマンドバッファ１０ａ〜１０ｄに描画コマンドリストを生成する。これによりコマンドリストの並列生成が可能になる。実施の形態１で説明したように、複数のコマンドリストをジャンプコマンドでつなげることができる。また、あるサブプロセッサで生成されたコマンドリストを別のサブプロセッサで再利用することもできる。サブプロセッサ１０４ａ〜１０４ｄが同一のインストラクションセットをサポートする同質のプロセッサであることから、各サブプロセッサで生成したコマンドバッファを連携させたり、再利用することが可能になる。

ＧＰＵ２００は、サブプロセッサ１０４ａ〜１０４ｄにより生成された複数のコマンドリストをメインメモリ１２０から読み出して実行する。実施の形態２で説明したように、メインプロセッサ１０２はグラフィックス処理に関与せず、Ｉ／Ｏなどの汎用処理をもっぱら行う。

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

実施の形態では、アプリケーションプログラムの実行時に、メインプロセッシングユニット１００によりリアルタイムで描画コマンドが生成される場合を説明したが、アプリケーションプログラムを実行するのに先立ち、オフラインでメインプロセッシングユニット１００が描画コマンドを生成し、前もって描画コマンドリストを記録装置に記録しておいてもよい。アプリケーションプログラムの実行時に、メインプロセッシングユニット１００が記録装置から描画コマンドリストを取得してメインメモリ１２０にロードし、ＧＰＵ２００が描画コマンドリストからコマンドを読み出して実行する。ゲームなどのリアルタイム性の高いアプリケーションでも、定型的に実行される処理についてはあらかじめオフラインで描画コマンドリストを生成しておけば、メインプロセッシングユニット１００の処理負荷を軽減することができ、リアルタイムで実行すべきグラフィックス処理により多くの計算資源を当てることができるようになる。

実施の形態１に係るグラフィックス処理システムの構成図である。 図２（ａ）〜（ｃ）は、図１のメインプロセッシングユニットがグラフィックスライブラリを用いて生成する描画コマンドを説明する図である。 実施の形態１に係るコマンドバッファに対するコマンドの読み書きの管理機構を説明する図である。 一般的なグラフィックスライブラリにより描画コマンドが生成される様子を示す図である。 実施の形態１のグラフィックスライブラリにより描画コマンドが生成される様子を示す図である。 実施の形態１に係るコマンドバッファのフロー制御を説明する図である。 図６（ａ）、（ｂ）は、複数のコマンドリストをジャンプコマンドでつなぐ様子を示す図である。 ジャンプコマンドによりループ処理を実現する様子を示す図である。 図８（ａ）、（ｂ）は、ジャンプコマンドによりコマンドリストが再利用される仕組みを説明する図である。 実施の形態２に係るグラフィックス処理システムの構成図であり、メインプロセッサがグラフィックス処理に関与し、メインプロセッサ、サブプロセッサ、およびグラフィックスプロセッシングユニット（ＧＰＵ）が協調動作する構成を示す。 実施の形態２に係るグラフィックス処理システムの構成図であり、メインプロセッサがグラフィックス処理に関与せず、サブプロセッサとＧＰＵが協調動作する構成である。 実施の形態３に係るグラフィックス処理システムの構成図である。

符号の説明

１ コマンドバッファ、 １２ ジオメトリデータ、 １４ テクスチャ、 １６ シェーダプログラム、 １８ 共有領域、 ２０ フレームバッファ、 １００ メインプロセッシングユニット、 １０２ メインプロセッサ、 １０４ サブプロセッサ、 １１０ ＩＯＩＦ、 １２０ メインメモリ、 ２００ グラフィックスプロセッシングユニット、 ２１０ レジスタファイル、 ２１１ ｐｕｔレジスタ、 ２１２ ｇｅｔレジスタ、 ２１３ 専用レジスタ、 ２２０ ローカルメモリ、 ３００ グラフィックスライブラリ、 ３１０ アプリケーション。

Claims (12)

1. グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムにもとづいて描画コマンドを生成するメインプロセッシングユニットと、
   前記メインプロセッシングユニットにより生成される描画コマンド列を保持するコマンドバッファが設けられるメモリと、
   前記コマンドバッファに保持された描画コマンド列を読み出して描画処理を実行するグラフィックスプロセッシングユニットとを含み、
   前記メインプロセッシングユニットは、アプリケーションプログラムからグラフィックスライブラリを用いて一のグラフィックス関数が呼び出されたとき、次にグラフィックスライブラリを用いて別のグラフィックス関数が呼び出されるまでグラフィックスライブラリ内に描画属性を保持することなく、前記別のグラフィックス関数が呼び出される前に前記一のグラフィックス関数を描画コマンドに変換することにより、アプリケーションプログラムから呼び出される各グラフィックス関数を描画コマンドに変換し、前記コマンドバッファに蓄積することを特徴とするグラフィックス処理装置。
2. 前記メインプロセッシングユニットにより最後に描画コマンドの書き込みが完了した前記コマンドバッファの位置を示す書き込みポインタと、前記グラフィックスプロセッシングユニットにより次に描画コマンドが読み出されるべき前記コマンドバッファの位置を示す読み出しポインタとにより、前記コマンドバッファに対する読み書きが管理されることを特徴とする請求項１に記載のグラフィックス処理装置。
3. 前記メインプロセッシングユニットは、プログラムモジュール別に描画コマンド列を生成してコマンドバッファに保持し、あるプログラムモジュールに対応する描画コマンド列の最後のコマンドとして、次に実行されるべき別のプログラムモジュールに対応する描画コマンド列の先頭アドレスを飛び先とするジャンプ命令を生成することを特徴とする請求項２に記載のグラフィックス処理装置。
4. 前記ジャンプ命令は、前記読み出しポインタを次に実行されるべき別のプログラムモジュールに対応する描画コマンド列の先頭アドレスを指すように変更する命令であることを特徴とする請求項３に記載のグラフィックス処理装置。
5. アプリケーションプログラムにより同一のプログラムモジュールが複数回呼び出される場合、前記メインプロセッシングユニットは、いったん生成した前記同一のプログラムモジュールに対応する描画コマンド列を次の実行時まで前記コマンドバッファに保持し、前記同一のプログラムモジュールが再度呼び出されるとき、描画コマンド列を改めて生成することなく、前記コマンドバッファに保持された前記同一のプログラムモジュールに対応する描画コマンド列を再利用することを特徴とする請求項３に記載のグラフィックス処理装置。
6. 前記メインプロセッシングユニットは、前記同一のプログラムモジュールが再度呼び出されるとき、前記読み出しポインタを前記コマンドバッファに保持された前記同一のプログラムモジュールに対応する描画コマンド列の先頭アドレスを指すように変更するためのジャンプ命令を描画コマンドとして生成することを特徴とする請求項５に記載のグラフィックス処理装置。
7. 前記メインプロセッシングユニットが、処理単位であるスレッドを複数並列に実行させるマルチスレッド方式でアプリケーションプログラムを実行する場合、各スレッドは、描画コマンド列を並列に生成してそれぞれのコマンドバッファに保持し、その描画コマンド列の最後のコマンドとして、次に実行されるべき描画コマンド列の先頭アドレスを飛び先とするジャンプ命令を生成することを特徴とする請求項１または２に記載のグラフィックス処理装置。
8. 前記メインプロセッシングユニットが、互いに独立に動作する複数のプロセッサを含む場合、各プロセッサは、描画コマンド列を並列に生成してそれぞれのコマンドバッファに保持し、その描画コマンド列の最後のコマンドとして、次に実行されるべき描画コマンド列の先頭アドレスを飛び先とするジャンプ命令を生成することを特徴とする請求項１または２に記載のグラフィックス処理装置。
9. アプリケーションプログラムから呼び出されるグラフィックス関数群をファイルにまとめたグラフィックスライブラリモジュールを含むコンピュータプログラムであって、
   当該グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムからグラフィックスライブラリを用いて一のグラフィックス関数が呼び出されたとき、次にグラフィックスライブラリを用いて別のグラフィックス関数が呼び出されるまでグラフィックスライブラリ内に描画属性を保持することなく、前記別のグラフィックス関数が呼び出される前に前記一のグラフィックス関数を描画コマンドに変換することにより、アプリケーションプログラムから呼び出される各グラフィックス関数を描画コマンドに変換することにより、描画コマンド列を生成する機能をコンピュータに実現させることを特徴とするプログラム。
10. プログラムモジュール別に描画コマンド列を生成し、あるプログラムモジュールに対応する描画コマンド列の最後のコマンドとして、次に実行されるべき別のプログラムモジュールに対応する描画コマンド列の先頭アドレスを飛び先とするジャンプ命令を生成する機能をさらにコンピュータに実現させることを特徴とする請求項９に記載のプログラム。
11. アプリケーションプログラムにより同一のプログラムモジュールが複数回呼び出される場合、いったん生成した前記同一のプログラムモジュールに対応する描画コマンド列を次の実行時までメモリ内に保持し、前記同一のプログラムモジュールが再度呼び出されるとき、描画コマンド列を改めて生成することなく、前記メモリに保持された前記同一のプログラムモジュールに対応する描画コマンド列を再利用する機能をさらにコンピュータに実現させることを特徴とする請求項１０に記載のプログラム。
12. メインプロセッシングユニットが、グラフィックスライブラリが提供するグラフィックス関数を用いて記述されたアプリケーションプログラムからグラフィックスライブラリを用いて一のグラフィックス関数が呼び出されたとき、次にグラフィックスライブラリを用いて別のグラフィックス関数が呼び出されるまでグラフィックスライブラリ内に描画属性を保持することなく、前記別のグラフィックス関数が呼び出される前に前記一のグラフィックス関数を描画コマンドに変換することにより、アプリケーションプログラムから呼び出される各グラフィックス関数を描画コマンドに変換することにより、描画コマンド列を生成し、コマンドバッファに保持するステップと、
    グラフィックスプロセッシングユニットが、前記コマンドバッファに保持された描画コマンド列を読み出して描画処理を実行するステップとを含むことを特徴とするグラフィックス処理方法。

Images