JP2008071261A - 画像処理システム及び画像処理方法 - Google Patents

Abstract

【課題】ＧＰＵの負荷のバランスがとれ、且つ消費電力及び回路面積の増大が抑制された画像処理システム及び画像処理方法を提供する。
【解決手段】グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置（ＣＰＵ）１０と、複数の描画コマンドで描画処理を行って、複数に分割された画面の各領域の画像描画用データを並列に生成するＧＰＵ２１及びＧＰＵ２２とを備え、ＧＰＵ２１及びＧＰＵ２２が、対象とする各領域を互いに動的に変更する。
【選択図】図１

Description

本発明は、描画処理技術に係り、特に複数のグラフィックスプロセッサユニットによって描画処理を並列に行う画像処理システム及び画像処理方法に関する。

グラフィックス描画処理を高速に行うために、複数のグラフィックスプロセッサユニット（ＧＰＵ）を並列に動作させるシステムが採用されている（例えば、特許文献１参照。）複数のＧＰＵによって並列にグラフィックス描画処理を行う場合、複数のＧＰＵにどのように処理を振り分けるかが問題となる。複数のＧＰＵに描画処理を振り分ける方法として、一般的に以下の２種類の方法が使用されている。

（１）アルターネイト・フレーム・レンダリング（ＡＦＲ）法：連続するn個のフレームの処理に、n個のＧＰＵをそれぞれ振り分ける方法。つまり、ＧＰＵを時間的に振り分ける方法である。例えばｎ＝２の場合、２個のＧＰＵをそれぞれ奇数フレームと偶数フレームの処理に振り分ける。

（２）スプリット・フレーム・レンダリング（ＳＦＲ）法：画面をn個の領域に分割し、ｎ個のＧＰＵを各領域の描画処理に割り当てる方法。つまり、ＧＰＵを空間的に振り分ける方法である。例えばｎ＝２の場合、画面を上下２つの領域に分割し、２個のＧＰＵをそれぞれ画面の上側領域と下側領域の描画処理に振り分ける。

ＡＦＲ法では、各ＧＰＵの負荷がほぼ均等となり理想的な負荷バランスを得ることができるが、以下の問題がある。即ち：
（Ａ）ＧＰＵ毎に１画面分のフレームメモリが必要であり、システムトータルとしてはn画面分のフレームメモリが必要となる。

（Ｂ）アプリケーションソフトウェアにおける次フレームの処理に移るタイミングを通知する描画完了通知から、ＧＰＵによる描画処理の完了までのタイムラグが長い。そのため、タイムラグの分だけ描画コマンドをバッファリングする必要がある。

タイムラグが長いほど、描画コマンドをバッファリングするためのコマンドバッファの記憶容量を増大する必要がある。したがって、ＡＦＲ法ではｎ画面分のフレームメモリを格納するため、及び描画コマンドをバッファリングするためにメモリの記憶容量が増大する。その結果、画像処理システム全体としての消費電力及び回路面積が増大する。

一方、ＳＦＲ法ではＡＦＲ法における上記の問題はないが、各ＧＰＵの負荷を均等にすることが難しく、負荷のアンバランスが発生する。そのため、ＳＦＲ法ではＡＦＲ法に比べてシステム全体としての処理効率(性能)が低下するという問題があった。
特開２００３−２０８６２７号公報

本発明は、ＧＰＵの負荷のバランスがとれ、且つ消費電力及び回路面積の増大が抑制された画像処理システム及び画像処理方法を提供する。

本発明の一態様によれば、（イ）グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置と、（ロ）複数の描画コマンドで描画処理を行って、複数に分割された画面の各領域の画像描画用データを並列に生成する複数のグラフィックスプロセッサユニットとを備え、複数のグラフィックスプロセッサユニットが、対象とする各領域を互いに動的に変更する画像処理システムが提供される。

本発明の他の態様によれば、（イ）中央演算処理装置が、グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行するステップと、（ロ）複数のグラフィックスプロセッサユニットが、複数に分割された画面の対象とする各領域を互いに動的に変更しながら複数の描画コマンドで描画処理を行って、各領域の画像描画用データを並列に生成し、その画像描画用データをフレームメモリに格納するステップとを含む画像処理方法が提供される。

本発明によれば、ＧＰＵの負荷のバランスがとれ、且つ消費電力及び回路面積の増大が抑制された画像処理システム及び画像処理方法を提供できる。

次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。又、以下に示す実施の形態は、この発明の技術的思想を具体化するための装置や方法を例示するものであって、この発明の技術的思想は、構成部品の構造、配置等を下記のものに特定するものでない。この発明の技術的思想は、特許請求の範囲において、種々の変更を加えることができる。

本発明の実施の形態に係る画像処理システムは、図１に示すように、グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置（ＣＰＵ）１０と、複数の描画コマンドで描画処理を行って、複数に分割された画面の各領域の画像描画用データを並列に生成するＧＰＵ２１及びＧＰＵ２２とを備え、ＧＰＵ２１及びＧＰＵ２２が、対象とする各領域を互いに動的に変更する。

ＣＰＵ１０は、アプリケーションソフトウェア、アプリケーション・プログラム・インタフェース（ＡＰＩ）ミドルウェア等の各種ミドルウェア、及びデバイスドライバ等のソフトウェアを実行して、描画コマンドを生成する。ＣＰＵ１０がソフトウェアに制御されて処理対象のグラフィックデータから生成する描画コマンドは、ＧＰＵ２１及びＧＰＵ２２に転送される。図１に示すように、ＧＰＵ２１及びＧＰＵ２２は描画処理部２０に含まれる。ＧＰＵ２１及びＧＰＵ２２によって生成された画像描画用データは、フレームメモリ３０に格納される。

又、図１に示した画像処理システムは、プログラム記憶装置４０、メインメモリ５０、入力装置６０及び出力装置７０を更に備える。ＣＰＵ１０、描画処理部２０、フレームメモリ３０、プログラム記憶装置４０、メインメモリ５０、入力装置６０及び出力装置７０は、それぞれバス８０に接続する。図１に示した画像処理システムにおけるデータ転送等は、バス８０を介して行われる。

プログラム記憶装置４０は、アプリケーションソフトウェア、ＡＰＩミドルウェア、デバイスドライバ等の、ＣＰＵ１０によって実行されるソフトウェアのプログラムコードを格納する。

メインメモリ５０は、グラフィックデータ記憶領域５１及びコマンドバッファ領域５２を有する。グラフィックデータ記憶領域５１は処理対象のグラフィックデータを格納する。コマンドバッファ領域５２は、ＧＰＵ２１及びＧＰＵ２２に転送される描画コマンドを格納する。コマンドバッファ領域５２は描画処理部２０に含まれるＧＰＵの個数に応じて区分される。図１に示した例では、コマンドバッファ領域５２は第１コマンドバッファ５２１及び第２コマンドバッファ５２２を有する。後述するように、第１コマンドバッファ５２１及び第２コマンドバッファ５２２は、ＣＰＵ１０がデバイスドライバを実行することによって設定される。又、メインメモリ５０は、ＣＰＵ１０の処理において生成されるデータ等の一時的な保存にも使用される。

入力装置６０はキーボード、マウス、ライトペン又はフレキシブルディスク装置等で構成される。入力装置より画像処理実行者は、入出力データを指定したり、プログラムを変更したりできる。更に、入力装置６０より画像処理の実行や中止等の指示の入力も可能である。

又、出力装置７０としては、画像処理結果或いは出力画像を表示するディスプレイやプリンタ、或いはコンピュータ読み取り可能な記録媒体に保存する記録装置にデータを送信可能なインタフェース装置等が使用可能である。ここで、「コンピュータ読み取り可能な記録媒体」とは、例えばコンピュータの外部メモリ装置、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープ等の電子データを記録することができるような媒体等を意味する。具体的には、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯディスク等が「コンピュータ読み取り可能な記録媒体」に含まれる。

図２に、描画処理部２０がＧＰＵ２１及びＧＰＵ２２を有する場合の処理レイヤ構造を示す。図２において、アプリケーションソフトウェア、ＡＰＩミドルウェア及びデバイスドライバまでの処理レイヤは、ソフトウェアによる処理レイヤである。既に述べたように、ソフトウェアによる処理はＣＰＵ１０によって実行される。図２において、ＧＰＵ２１及びＧＰＵ２２による処理レイヤ、及びフレームメモリによる処理レイヤは、ハードウェアによって処理されるレイヤである。

アプリケーションソフトウェアは、画像処理システムが有するＧＰＵの個数に関係なくグラフィックデータを処理し、処理結果として得られるＡＰＩ関数コールをＡＰＩミドルウェアに引き渡す。ここで「ＡＰＩ関数コール」は、汎用的なグラフィックスＡＰＩ関数を用いて目的の描画を行うための指示である。ＡＰＩミドルウェアはアプリケーションソフトウェアから引き渡されたＡＰＩ関数コールを処理して、ＧＰＵ２１及びＧＰＵ２２等のハードウェアが実行可能な描画コマンドを生成する。デバイスドライバは、ＡＰＩミドルウェアによって生成された描画コマンドをコマンドバッファ領域５２にバッファリングした後、ＧＰＵ２１及びＧＰＵ２２が新たな処理を開始できるタイミングで、例えば１フレーム分等のＧＰＵ２１及びＧＰＵ２２の処理単位の描画コマンドをコマンドバッファ領域５２からＧＰＵ２１及びＧＰＵ２２に転送する。ＧＰＵ２１及びＧＰＵ２２は描画コマンドを用いて描画処理を行い、描画処理結果である画像描画用データはフレームメモリ３０に格納される。画像描画用データは、例えばピクセルデータである。

ＡＰＩミドルウェアによって生成された描画コマンドをＧＰＵ２１及びＧＰＵ２２に転送する具体的な方法の例を、図３に示したフローチャートを参照して説明する。

（イ）ステップＳ１０において、ＣＰＵ１０がデバイスドライバを実行して、メインメモリ５０のコマンドバッファ領域５２に、ＧＰＵ２１及びＧＰＵ２２が描画処理する領域にそれぞれ対応する第１コマンドバッファ５２１及び第２コマンドバッファ５２２を設定する。

（ロ）ステップＳ２０において、ＣＰＵ１０がデバイスドライバを実行して、ＡＰＩミドルウェアによって転送された描画コマンドを設定されたコマンドバッファ領域５２に書き込む。ここで、ＧＰＵ２１によって処理される描画コマンドは第１コマンドバッファ５２１に格納され、ＧＰＵ２２によって処理される描画コマンドは第２コマンドバッファ５２２に格納される。つまり、描画コマンドはＧＰＵ２１及びＧＰＵ２２の各描画処理に用いる描画コマンド毎にコマンドバッファ領域５２に格納される。

（ハ）ステップＳ３０において、ＣＰＵ１０がデバイスドライバを実行して、第１コマンドバッファ５２１及び第２コマンドバッファ５２２のアドレスをＧＰＵ２１及びＧＰＵ２２にそれぞれ設定する。

（ニ）ステップＳ４０において、ＧＰＵ２１及びＧＰＵ２２は、設定されたアドレスに基づき、第１コマンドバッファ５２１及び第２コマンドバッファ５２２からそれぞれ描画コマンドを読み出す。

図４及び図５に、ＡＦＲ法及びＳＦＲ法によってＧＰＵ２１及びＧＰＵ２２に処理を振り分けてフレーム１〜６の描画処理を行う場合のタイミングチャートの例を示す。図４及び図５のそれぞれにおいて、（ａ）はアプリケーションソフトウェアが処理するフレーム番号、（ｂ）はＧＰＵ２１が描画処理するフレーム番号、（ｃ）はＧＰＵ２２が描画処理するフレーム番号、（ｄ）はフレームの描画処理によって得られる出力画像の番号であり、画像１〜６は、フレーム１〜６をそれぞれ描画処理して生成される出力画像である。

図４は、ＡＦＲ法を用いてＧＰＵ２１及びＧＰＵ２２に描画処理を振り分ける場合のタイミングチャートの例を示す。図４に示した例では、ＧＰＵ２１が奇数番号のフレームの描画処理を担当し、ＧＰＵ２２が偶数番号のフレームの描画処理を担当する。一般に、動画において連続するフレーム間の画像は高い相関をもつ。即ち、ＧＰＵ２１及びＧＰＵ２２による各フレームの描画処理に要する時間は、そのフレームの前後のフレームの描画処理に要する時間とほぼ同じである。したがって、図４に示すようにＧＰＵ２１及びＧＰＵ２２が交互にフレームの描画処理を担当することによって、ＧＰＵ２１及びＧＰＵ２２はほぼ休み無く描画処理を続けることができる。ＧＰＵ２１及びＧＰＵ２２によってそれぞれ処理された画像描画用データを対応するフレーム番号順に整理することにより、出力画像が生成される。

ただし、一般的に、アプリケーションソフトウェアによるグラフィックデータの１フレーム分の処理に要する時間は、ＧＰＵ２１及びＧＰＵ２２による１フレーム分の描画処理に要する時間より短い。そのため、アプリケーションソフトウェアにおける各フレームの処理完了から、対応するフレームのＧＰＵ２１及びＧＰＵ２２での描画処理の完了までにタイムラグＴａ１、Ｔｂ１が発生する。第１コマンドバッファ５２１及び第２コマンドバッファ５２２は、少なくともタイムラグＴａ１、Ｔｂ１においてＡＰＩミドルウェアから転送される描画コマンドを保持する必要がある。ＧＰＵ２１或いはＧＰＵ２２は、各フレームの描画処理完了後に、新たな描画コマンドを第１コマンドバッファ５２１及び第２コマンドバッファ５２２から読み出す。

図５は、ＳＦＲ法を用いてＧＰＵ２１及びＧＰＵ２２に描画処理を振り分ける場合のタイミングチャートの例を示す。図５に示した例では、ＧＰＵ２１が画面上側、ＧＰＵ２２が画面下側の描画処理を担当する。ＧＰＵ２１及びＧＰＵ２２によってそれぞれ処理された画像描画用データを合成して各フレームに対応する出力画像が生成される。

一般に、画面上側と画面下側では描画する図形に相関はなく、そのため各フレームにおけるＧＰＵ２１及びＧＰＵ２２の処理量が異なる場合が多い。図５に示した例で画面上側のグラフィックデータのデータ量が画面下側より多い場合、ＧＰＵ２１の処理時間が常にＧＰＵ２２の処理時間より長い。即ち、アプリケーションソフトウェアにおける各フレームの処理完了から、対応するフレームのＧＰＵ２１及びＧＰＵ２２での描画処理の完了までのタイムラグをそれぞれＴａ２及びＴｂ２とすると、Ｔａ２＞Ｔｂ２である。そのため、ＧＰＵ２２に、毎フレーム毎に「Ｔａ２−Ｔｂ２」の休止時間がある。その結果、図５を参照して説明したＳＦＲ法では、ＧＰＵ２２の稼働率が低下し、画像処理システム全体の性能も低下する。

ただし、ＳＦＲ法では１フレーム分の描画処理を複数のＧＰＵで行うため、ＡＦＲ法と比較して一般にタイムラグは短い。そのため、コマンドバッファ領域５２の記憶容量は、ＡＦＲ法を採用する場合よりＳＦＲ法を使用する場合の方が小さい。

図６に、図１に示す画像処理システムによって画像処理する方法のフローチャートの例を示す。以下では、画面を上下を分割した領域の描画処理をＧＰＵ２１及びＧＰＵ２２に振り分ける場合を例示的に説明する。

（イ）ステップＳ１００において、処理対象のグラフィックデータが図１に示した入力装置６０を介してグラフィックデータ記憶領域５１に格納される。

（ロ）ステップＳ１１０において、ＣＰＵ１０がプログラム記憶装置４０に格納されたアプリケーションソフトウェア及びＡＰＩミドルウェアを実行してグラフィックデータ記憶領域５１から処理対象のグラフィックデータを読み出し、グラフィックデータを処理して描画コマンドをフレーム順に生成する。生成された描画コマンドは、メインメモリ５０の空き領域に一時的に格納される。

（ハ）ステップＳ１２０において、ＣＰＵ１０がプログラム記憶装置４０に格納されたデバイスドライバを実行し、図３を参照して説明した方法と同様にコマンドバッファ領域５２に第１コマンドバッファ５２１及び第２コマンドバッファ５２２が設定される。更に、デバイスドライバによって、ＧＰＵ２１が画面の上半分、ＧＰＵ２２が画面の下半分の描画処理を担当するように、ＧＰＵ２１及びＧＰＵ２２の処理領域が設定される。

（ニ）ステップＳ１３０において、ＣＰＵ１０がデバイスドライバを実行することによって、メインメモリ５０に格納された描画コマンドから１フレーム分の描画コマンドが読み出される。読み出された１フレーム分の描画コマンドのうち、画面の上半分に対応する描画コマンドが第１コマンドバッファ５２１に格納され、画面の下半分に対応する描画コマンドが第２コマンドバッファ５２２に格納される。

（ホ）ステップＳ１４０において、１フレーム分の描画コマンドの第１コマンドバッファ５２１及び第２コマンドバッファ５２２への格納が完了したら、処理はステップＳ１５０に進む。１フレーム分の描画コマンドの格納が完了していなければ、処理はステップＳ１３０に戻る。

（ヘ）ステップＳ１５０において、ＧＰＵ２１及びＧＰＵ２２は、デバイスドライバによって設定されたアドレスに基づき、第１コマンドバッファ５２１及び第２コマンドバッファ５２２からそれぞれ描画コマンドを読み出す。そして、ＧＰＵ２１が画面の上半分、ＧＰＵ２２が画面の下半分の描画処理を開始し、処理はステップＳ１６０に進む。

（ト）ステップＳ１６０において、ＣＰＵ１０がデバイスドライバを実行して、ステップＳ１２０において設定された処理領域が逆になるように、ＧＰＵ２１及びＧＰＵ２２の処理領域が再設定される。つまり、ＧＰＵ２１が画面の下半分、ＧＰＵ２２が画面の上半分の描画処理を担当するように設定される。

（チ）ステップＳ１７０において、ＣＰＵ１０がデバイスドライバを実行することによって、ステップＳ１３０で読み出された描画コマンドに対応するフレームの次のフレームに対応する１フレーム分の描画コマンドが、メインメモリ５０から読み出される。読み出された１フレーム分の描画コマンドのうち、画面の下半分に対応する描画コマンドが第１コマンドバッファ５２１に格納され、画面の上半分に対応する描画コマンドが第２コマンドバッファ５２２に格納される。

（リ）ステップＳ１８０において、１フレーム分の描画コマンドの第１コマンドバッファ５２１及び第２コマンドバッファ５２２への書き込みが完了したら、処理はステップＳ１９０に進む。書き込みが完了していなければ、処理はステップＳ１７０に戻る。

（ヌ）ステップＳ１９０において、ＧＰＵ２１及びＧＰＵ２２は、ステップＳ１５０で開始した描画処理後に、デバイスドライバによって設定されたアドレスに基づき、第１コマンドバッファ５２１及び第２コマンドバッファ５２２からそれぞれ描画コマンドを読み出す。そして、ＧＰＵ２１が画面の下半分、ＧＰＵ２２が画面の上半分の描画処理を開始し、処理はステップＳ２００に進む。

（ヲ）ステップＳ２００において、すべてのフレームの描画コマンドの処理が完了したか否かが判断される。すべてのフレームの描画コマンドの処理が完了していなければ、処理はステップＳ１２０に戻る。すべてのフレームの描画コマンドの処理が完了していれば、画像処理を終了する。

ＧＰＵ２１及びＧＰＵ２２が、画面の上半分或いは下半分のいずれかの描画処理を担当するように処理領域を設定するには、第１コマンドバッファ５２１及び第２コマンドバッファ５２２に、ＧＰＵ２１及びＧＰＵ２２が描画処理を担当する領域の描画コマンドを格納する。或いは、ＧＰＵ２１及びＧＰＵ２２に処理させる領域の描画コマンドが格納された第１コマンドバッファ５２１及び第２コマンドバッファ５２２のアドレスを、フレーム毎にＧＰＵ２１及びＧＰＵ２２にそれぞれ設定する。

上記に説明したように、デバイスドライバは、先ずＧＰＵ２１が画面の上半分、ＧＰＵ２２が画面の下半分の描画処理を担当するように設定し、描画コマンドを第１コマンドバッファ５２１及び第２コマンドバッファ５２２に書き込む。上記の設定で１フレーム分の描画コマンドの書き込みが完了した後、デバイスドライバは、ＧＰＵ２１が画面の下半分、ＧＰＵ２２が画面の上半分の描画処理を担当するように設定を変更し、描画コマンドを第１コマンドバッファ５２１及び第２コマンドバッファ５２２に書き込む。ＡＰＩミドルウェアからの描画コマンドの転送が終了するまで、上記のＧＰＵ２１及びＧＰＵ２２の担当する描画処理の設定及び設定の変更と、描画コマンドの第１コマンドバッファ５２１及び第２コマンドバッファ５２２への書き込みを繰り返す。つまり、デバイスドライバはＧＰＵ２１及びＧＰＵ２２が描画処理を担当する領域をフレーム毎に交互に設定する。

尚、上記ではアプリケーションソフトウェア及びＡＰＩミドルウェアを実行して描画コマンドを生成した後に、デバイスドライバを実行して第１コマンドバッファ５２１及び第２コマンドバッファ５２２を設定する例を説明した。第１コマンドバッファ５２１及び第２コマンドバッファ５２２を設定した後に、描画コマンドを生成してもよい。

図６に示したフローチャートに従って描画処理を行った場合のタイミングチャートを図７に示す。図４及び図５と同様に、図７において、（ａ）はアプリケーションソフトウェアが処理するフレーム番号、（ｂ）はＧＰＵ２１が描画処理するフレーム番号、（ｃ）はＧＰＵ２２が描画処理するフレーム番号、（ｄ）はフレームの描画処理によって得られる出力画像の番号である。

図７に示したように、フレーム１については、ＧＰＵ２１が画面上側、ＧＰＵ２２が画面下側の描画処理を担当する。ここで、画面上側のグラフィックデータのデータ量が画面下側より多い場合、ＧＰＵ２２はＧＰＵ２１より早くフレーム１の描画処理を完了する。そして、ＧＰＵ２２は、ＧＰＵ２１がフレーム１の画面上側の描画処理を完了する前に、フレーム２の画面上側の描画処理を開始する。ＧＰＵ２１は、フレーム１の画面上側の描画処理を完了した後、フレーム２の画面下側の描画処理を開始する。連続するフレーム間の画像は高い相関をもつため、フレーム２の描画処理においてはＧＰＵ２１はＧＰＵ２２より処理時間が短い。そのため、ＧＰＵ２１が行うフレーム２の画面下側の描画処理とＧＰＵ２２が行うフレーム２の画面上側の描画処理はほぼ同時に完了する。その後、上記と同様にして、奇数番号のフレームの画面上側及び偶数番号のフレームの画面下側の描画処理をＧＰＵ２１が担当し、奇数番号のフレームの画面下側及び偶数番号のフレームの画面上側の描画処理をＧＰＵ２２が担当して、フレーム３以降の描画処理が実行される。ＧＰＵ２１及びＧＰＵ２２によってそれぞれ描画処理して生成された画像描画用データを合成して各フレームに対応する出力画像が生成される。

上記のように、画面を２つに分割し、分割された各領域の描画処理を１フレーム毎にＧＰＵ２１及びＧＰＵ２２で交代で担当することによって、ＧＰＵ２１とＧＰＵ２２の処理するデータ量（負荷）のバランスがとれる。

以上に説明したように、本発明の実施の形態に係る描画処理システムによれば、ＧＰＵ２１とＧＰＵ２２は、描画処理を担当する画面の領域をフレーム毎に動的に変更する。そのため、ＧＰＵ２１とＧＰＵ２２間の負荷のアンバランスが解消し、図５を参照して説明したＳＦＲ法と比較してＧＰＵ２１及びＧＰＵ２２の稼働率が向上する。その結果、画像処理システム全体の性能が向上する。又、図４を参照して説明したＡＦＲ法と比較してタイムラグが短いため、コマンドバッファの記憶容量を小さくできる。更に、ＡＦＲ法と異なりＧＰＵ２１及びＧＰＵ２２毎に１画面分のフレームメモリを用意する必要がないため、消費電力及び回路面積の増大が抑制された画像処理システムを提供することができる。

（その他の実施の形態）
上記のように、本発明は実施の形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

既に述べた実施の形態の説明においては、画面を上下に分割し、分割された各領域の描画処理をＧＰＵ２１及びＧＰＵ２２で動的に変更させる例を説明した。しかし、画面の分割方法は上下に分割する方法に限らず、例えば画面を左右に分割する等、画面を２つの領域に分割する方法であればどのような分割方法であってもよい。又、実施の形態の説明においてはＧＰＵが２つである場合を例示的に説明したが、画面をｎ個（ｎ＞２）の領域に分割し、ｎ個のＧＰＵを用いて各ＧＰＵが処理する領域を動的に変更させてもよい。

このように、本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。したがって、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

本発明の実施の形態に係る画像処理システムの構成を示す模式図である。 本発明の実施の形態に係る画像処理システムの処理レイヤを示す模式図である。 本発明の実施の形態に係る画像処理システムにおいて、描画コマンドをＧＰＵに転送する方法を説明するためのフローチャートである。 関連技術によってＧＰＵに描画処理を振り分けた場合のタイミングチャートの例である。 関連技術によってＧＰＵに描画処理を振り分けた場合のタイミングチャートの他の例である。 本発明の実施の形態に係る画像処理方法を説明するためのフローチャートである。 本発明の実施の形態に係る画像処理方法によってＧＰＵに描画処理を振り分けた場合のタイミングチャートの例である。

符号の説明

１０…ＣＰＵ
２０…描画処理部
２１、２２…ＧＰＵ
３０…フレームメモリ
４０…プログラム記憶装置
５０…メインメモリ
５１…グラフィックデータ記憶領域
５２…コマンドバッファ領域
５２１…第１コマンドバッファ
５２２…第２コマンドバッファ

Claims (5)

1. グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置と、
   前記複数の描画コマンドで描画処理を行って、複数に分割された画面の各領域の画像描画用データを並列に生成する複数のグラフィックスプロセッサユニット
   とを備え、前記複数のグラフィックスプロセッサユニットが、対象とする前記各領域を互いに動的に変更することを特徴とする画像処理システム。
2. 前記複数の描画コマンドを、前記複数のグラフィックスプロセッサユニットの各描画処理に用いる描画コマンド毎に格納するコマンドバッファ領域を有するメインメモリを更に備えることを特徴とする請求項１に記載の画像処理システム。
3. 前記複数のグラフィックスプロセッサユニットが、前記各領域をフレーム毎に変更することを特徴とする請求項１又は２に記載の画像処理システム。
4. 中央演算処理装置が、グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行するステップと、
   複数のグラフィックスプロセッサユニットが、複数に分割された画面の対象とする各領域を互いに動的に変更しながら前記複数の描画コマンドで描画処理を行って、前記各領域の画像描画用データを並列に生成し、該画像描画用データをフレームメモリに格納するステップ
   とを含むことを特徴とする画像処理方法。
5. 前記複数のグラフィックスプロセッサユニットが、前記各領域をフレーム毎に変更することを特徴とする請求項４に記載の画像処理方法。

Images