(57)【要約】【課題】ＧＰＵのアーキテクチャに応じた最適な実行モデルで計算する。【解決手段】ＣＰＵを備えるホストとＧＰＵを備えるデバイスとを含むシステムにおいて、ＧＰＵは複数のマルチコア（ＭＣ）を備え、各ＭＣは複数のコアとメモリとを備え、カーネルプログラムはスレッドとブロックとで構成され、ＧＰＵにカーネルプログラムを実行させる際に、ホストは、プログラムのコンパイルに必要なメモリと各ＭＣが持つメモリとに基づいて最大ブロック数／ＭＣを算出し、データ総数からスレッド総数を求め、スレッド総数をＧＰＵのＭＣ数で除算して平均スレッド数／ＭＣを算出し、選択可能な複数のスレッド数／ＭＣの中から、最大ブロック数／ＭＣ及び平均スレッド数／ＭＣに基づいてスレッド数／ＭＣを決定し、決定したスレッド数／ＭＣに基づいて、各ＭＣにスレッドが平均化して分割されるようにブロックを構成する。【選択図】図１２
2019113984.tif 000002
【特許請求の範囲】
【請求項１】
ＣＰＵを備えるホストと、前記ＣＰＵに制御されるＧＰＵを備えるデバイスと、を含み、前記ＣＰＵと前記ＧＰＵとがインターフェースを介して接続されるシステムにおける、前記ホストで動作する計算制御プログラムであって、
前記ＧＰＵは、複数のマルチコアを備え、
各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、
前記ＧＰＵが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、
前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、
前記ＧＰＵに前記カーネルプログラムを実行させる際に、
前記ホストに、
プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、前記インターフェースを介して前記ＧＰＵから取得した各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップ、
処理対象のデータの総数から実行するスレッドの総数を求め、前記インターフェースを介して前記ＧＰＵから前記マルチコアの数を取得し、前記スレッドの総数を前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップ、
設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップ、
決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップ、を実行させる、
ことを特徴とする計算制御プログラム。
【請求項２】
前記第１ステップでは、１スレッドあたりのレジスタ数及び１ブロックあたりの共有メモリ容量を、各々の前記マルチコアが持つレジスタ数及び共有メモリ容量以下とする、
ことを特徴とする請求項１に記載の計算制御プログラム。
【請求項３】
前記第２ステップでは、１マルチコアあたりのスレッド数を、最小実行単位数の倍数とする、
ことを特徴とする請求項１又は２に記載の計算制御プログラム。
【請求項４】
前記第２ステップでは、ランタイムＡＰＩを用いて、前記ＧＰＵに含まれる前記マルチコアの数を取得する、
ことを特徴とする請求項１乃至３のいずれか一に記載の計算制御プログラム。
【請求項５】
前記第３ステップでは、設定可能なスレッド数／ブロックを、ひとつのブロックに所属することができるスレッドの最大数である最大包含数以下、及び／又は、マルチコアが担当することができる最大のスレッド数である最大実行数以下とする、
ことを特徴とする請求項１乃至４のいずれか一に記載の計算制御プログラム。
【請求項６】
前記第３ステップでは、ランタイムＡＰＩを用いて、前記最大包含数、及び／又は、前記最大実行数を取得する、
ことを特徴とする請求項５に記載の計算制御プログラム。
【請求項７】
前記第４ステップでは、構成されたブロックを、更に、同数のスレッドが所属するブロックに分割する、
ことを特徴とする請求項１乃至６のいずれか一に記載の計算制御プログラム。
【請求項８】
前記第４ステップでは、ブロックを分割する際に、最小実行単位数の倍数のスレッドが所属するブロックに分割する、
ことを特徴とする請求項７に記載の計算制御プログラム。
【請求項９】
ＣＰＵを備えるホストと、前記ＣＰＵに制御されるＧＰＵを備えるデバイスと、を含み、前記ＣＰＵと前記ＧＰＵとがインターフェースを介して接続されるシステムにおける計算制御方法であって、
前記ＧＰＵは、複数のマルチコアを備え、
各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、
前記ＧＰＵが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、
前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、
前記ＧＰＵに前記カーネルプログラムを実行させる際に、
前記ホストは、
プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、前記インターフェースを介して前記ＧＰＵから取得した各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップと、
処理対象のデータの総数から実行するスレッドの総数を求め、前記インターフェースを介して前記ＧＰＵから前記マルチコアの数を取得し、前記スレッドの総数を前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップと、
設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップと、
決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップと、を実行する、
ことを特徴とする計算制御方法。
【請求項１０】
前記第１ステップでは、１スレッドあたりのレジスタ数及び１ブロックあたりの共有メモリ容量を、各々の前記マルチコアが持つレジスタ数及び共有メモリ容量以下とする、
ことを特徴とする請求項９に記載の計算制御方法。
【請求項１１】
前記第２ステップでは、１マルチコアあたりのスレッド数を、最小実行単位数の倍数とする、
ことを特徴とする請求項９又は１０に記載の計算制御方法。
【請求項１２】
前記第２ステップでは、ランタイムＡＰＩを用いて、前記ＧＰＵに含まれる前記マルチコアの数を取得する、
ことを特徴とする請求項９乃至１１のいずれか一に記載の計算制御方法。
【請求項１３】
前記第３ステップでは、設定可能なスレッド数／ブロックを、ひとつのブロックに所属することができるスレッドの最大数である最大包含数以下、及び／又は、マルチコアが担当することができる最大のスレッド数である最大実行数以下とする、
ことを特徴とする請求項９乃至１２のいずれか一に記載の計算制御方法。
【請求項１４】
前記第３ステップでは、ランタイムＡＰＩを用いて、前記最大包含数、及び／又は、前記最大実行数を取得する、
ことを特徴とする請求項１３に記載の計算制御方法。
【請求項１５】
前記第４ステップでは、構成されたブロックを、更に、同数のスレッドが所属するブロックに分割する、
ことを特徴とする請求項９乃至１４のいずれか一に記載の計算制御方法。
【請求項１６】
前記第４ステップでは、ブロックを分割する際に、最小実行単位数の倍数のスレッドが所属するブロックに分割する、
ことを特徴とする請求項１５に記載の計算制御方法。
【請求項１７】
ＣＰＵを備えるホストと、前記ＣＰＵに制御されるＧＰＵを備えるデバイスと、を含む画像形成装置であって、
前記ＧＰＵは、複数のマルチコアを備え、
各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、
前記ＧＰＵが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、
前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、
前記ＧＰＵに前記カーネルプログラムを実行させる際に、
プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップと、
処理対象のデータの総数から実行するスレッドの総数を求め、前記スレッドの総数を前記ＧＰＵに含まれる前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップと、
設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップと、
決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップと、を実行する、
ことを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算制御プログラム、計算制御方法及び画像形成装置に関し、特に、CPU（Central Processing Unit）を備えるホストとCPUに制御されるGPU（Graphics Processing Unit）を備えるデバイスとを備えるシステムにおけるホストで動作する計算制御プログラム、GPUのアーキテクチャに応じた実行モデルで計算を行う計算制御方法及び画像形成装置に関する。
【背景技術】
【０００２】
画像を出力する画像形成装置は、プログラムを実行するCPUを備え、CPUによって制御される。更に、画像を形成する機能の拡張及び性能の向上を図るために、GPUを備える画像形成装置が登場している。GPUは、CPUと同じ筐体に搭載されてワンチップ化されたSoC（System on a Chip）や、CPUとPCI-Express（以下、PCIeと略す。）を介して接続されるなどして、CPUによって制御される。
【０００３】
いままでは、GPUとCPUとは一対一の関係であって、相互に専用のプログラミングがなされるのが通常であったが、コストダウンやユーザ仕様に特化するため等の理由で、GPUのオプション化が望まれるようになった。PCIeの規格を使用すれば、CPUはオプション基板に搭載された回路を制御できるため、外付けのオプション化が容易である。今後は、オプション化されて外付けされる、ユーザの要望に沿ういろいろな性能のGPUを効果的に動かすための方法が必要となる。
【０００４】
CPUでオプション基板に搭載された回路を制御する方法に関して、例えば、下記特許文献１には、PCI-Expressのルートコンプレックスに設定されたメイン演算手段と、前記メイン演算手段の起動を制御する起動制御手段と、PCI-Expressのルートコンプレックスに設定されたサブ演算手段を搭載するオプション基板を接続可能な接続手段と、を備え、前記起動制御手段は、前記接続手段に接続された前記オプション基板を検出する検出手段と、前記オプション基板が検出される場合、前記メイン演算手段が起動する前の段階で、前記オプション基板に関する能力情報を取得する取得手段と、前記取得された能力情報に基づいて、前記メイン演算手段と前記サブ演算手段のいずれか一方を選択する選択手段と、前記メイン演算手段および前記サブ演算手段のうちから選択された一方をルートコンプレックスとして起動する切換手段と、を含む、画像形成装置が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４−２２８９２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
元来、画像処理専用のハードウェアとして開発されたGPUは、チップ単体ではなく、PCI-Expressカードとして販売されており、マザーボードやノートPCにあらかじめ搭載されている場合が多い。デバイスとしてのGPUは、ホストとしてのCPUと一対一の関係であるため、プログラミングをするとき、対象となるGPUの既定のハードウェアを考慮して調整をすれば十分であった。
【０００７】
しかしながら、GPUの性能の向上やGPUのマルチコア化に伴って、想定されるアーキテクチャで設計されたプログラムがたとえ動作するにしても、動作が最適であるかどうかは分からない。すなわち、GPUが搭載するコア数に応じてGPUの性能の向上が予想できるアーキテクチャであるとは限らない。また、カーネル関数のスレッド／ブロックの構造や、動作するグリッドの構成によって大きく性能が変わる。また、コンパイラも、より良いカーネル関数性能を引き出せるスケジューリングの方法を予測する知見を十分有しているとは言えない。
【０００８】
具体的には、GPUにカーネル関数を実行させる場合、GPUの構成（マルチコアの数、レジスタ数、共有メモリ容量など）を考慮して、カーネル関数のグリッド、ブロック、スレッドを設定するが、その際、オペレータが、1ブロックあたりのスレッド数や1マルチコアが処理するブロック数などを経験的に決め、その条件でプログラムを動作させる。そのため、例えば、占有率（マルチコア内で並列実行されているスレッド数と1マルチコアあたりの最大で実行できるスレッド数との比）が低くなって、処理効率が低下するなどの問題が生じる。
【０００９】
本発明は、上記問題点に鑑みてなされたものであって、その主たる目的は、使用対象となるGPUのアーキテクチャに応じた最適な実行モデルで計算することができる計算制御プログラム、計算制御方法及び画像形成装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の一側面は、CPUを備えるホストと、前記CPUに制御されるGPUを備えるデバイスと、を含み、前記CPUと前記GPUとがインターフェースを介して接続されるシステムにおける、前記ホストで動作する計算制御プログラムであって、前記GPUは、複数のマルチコアを備え、各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、前記GPUが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、前記GPUに前記カーネルプログラムを実行させる際に、前記ホストに、プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、前記インターフェースを介して前記GPUから取得した各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップ、処理対象のデータの総数から実行するスレッドの総数を求め、前記インターフェースを介して前記GPUから前記マルチコアの数を取得し、前記スレッドの総数を前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップ、設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップ、決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップ、を実行させることを特徴とする。
【００１１】
本発明の一側面は、CPUを備えるホストと、前記CPUに制御されるGPUを備えるデバイスと、を含み、前記CPUと前記GPUとがインターフェースを介して接続されるシステムにおける計算制御方法であって、前記GPUは、複数のマルチコアを備え、各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、前記GPUが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、前記GPUに前記カーネルプログラムを実行させる際に、前記ホストは、プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、前記インターフェースを介して前記GPUから取得した各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップと、処理対象のデータの総数から実行するスレッドの総数を求め、前記インターフェースを介して前記GPUから前記マルチコアの数を取得し、前記スレッドの総数を前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップと、設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップと、決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップと、を実行することを特徴とする。
【００１２】
本発明の一側面は、CPUを備えるホストと、前記CPUに制御されるGPUを備えるデバイスと、を含む画像形成装置であって、前記GPUは、複数のマルチコアを備え、各々の前記マルチコアは、複数のコアとレジスタと共有メモリとを備え、前記GPUが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと、複数のスレッドをまとめたブロックと、で構成され、前記マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、前記GPUに前記カーネルプログラムを実行させる際に、プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と、各々の前記マルチコアが持つレジスタ数及び共有メモリ容量と、に基づいて、最大ブロック数／マルチコアを算出する第１ステップと、処理対象のデータの総数から実行するスレッドの総数を求め、前記スレッドの総数を前記GPUに含まれる前記マルチコアの数で除算して、平均スレッド数／マルチコアを算出する第２ステップと、設定可能なブロック数／マルチコアと設定可能なスレッド数／ブロックとの組み合わせで決定される複数のスレッド数／マルチコアの中から、前記最大ブロック数／マルチコア、及び、前記平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定する第３ステップと、決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する第４ステップと、を実行することを特徴とする。
【発明の効果】
【００１３】
本発明の計算制御プログラム、計算制御方法及び画像形成装置によれば、使用対象となるGPUのアーキテクチャに応じた最適な実行モデルで計算することができる。
【００１４】
その理由は、CPUを備えるホストとCPUに制御されるGPUを備えるデバイスとを含むシステムにおいて、GPUは、複数のマルチコアを備え、各々のマルチコアは、複数のコアとレジスタと共有メモリとを備え、GPUが実行するカーネルプログラムは、計算を行う主体単位であるスレッドと複数のスレッドをまとめたブロックとで構成され、マルチコアは、少なくとも１つのブロックに所属する全てのスレッドを実行するものであり、GPUにカーネルプログラムを実行させる際に、ホストは、プログラムのコンパイルに必要となるレジスタ数及び共有メモリ容量と各々のマルチコアが持つレジスタ数及び共有メモリ容量とに基づいて、最大ブロック数／マルチコアを算出し、処理対象のデータの総数から実行するスレッドの総数を求め、スレッドの総数をGPUに含まれるマルチコアの数で除算して、平均スレッド数／マルチコアを算出し、選択可能なスレッド数／マルチコアの中から、最大ブロック数／マルチコア、及び、平均スレッド数／マルチコアに基づいて、適用するスレッド数／マルチコアを決定し、決定したスレッド数／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成するからである。
【００１５】
これにより、GPUがオプション化された場合であっても、ユーザが要求する仕様に対応することができる。また、GPU自体の性能の進化に対応することができる。また、GPUの使用の並列度を上げることができ、GPUの性能を十分に引き出すことができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施例に係るマルチノードGPUの構成例を示す模式図である。
【図２】本発明の第１の実施例に係るマルチGPUの構成例を示す模式図である。
【図３】本発明の第１の実施例に係るGPUの構成例を示す模式図である。
【図４】本発明の第１の実施例に係るMCの構成例を示す模式図である。
【図５】ホストプログラムとカーネルプログラムの関係を説明する模式図である。
【図６】プログラムの実行の流れを説明する模式図である。
【図７】ブロックとMCとの関係を説明する模式図である。
【図８】本発明の第１の実施例に係るMCの数によるスケーリングの例（NBLOCK=8の場合）を示す模式図である。
【図９】本発明の第１の実施例に係るスケーリングの限界を示す模式図である。
【図１０】本発明の第１の実施例に係るブロックの分割を示す模式図である。
【図１１】本発明の第１の実施例に係る1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数と1MCが処理するウォープ数との関係を示すテーブルである。
【図１２】本発明のプログラムモデルを示す模式図である。
【図１３】本発明の第１の実施例に係る1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数とを決定する方法を説明するテーブルの一例である。
【図１４】本発明の第２及び第３の実施例に係るGPUのプロパティを示すテーブルである。
【図１５】本発明の第４の実施例に係る1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数とを決定する方法を説明するテーブルである。
【図１６】従来のホストとデバイスとの関係（SoCの場合）を説明する模式図である。
【図１７】従来のホストとデバイスとの関係（デバイスがPCにつながった外部演算装置の場合）を説明する模式図である。
【発明を実施するための形態】
【００１７】
背景技術で示したように、画像を形成する機能の拡張及び性能の向上を図るために、GPUを備える画像形成装置が登場している。GPUは、図１６に示すように、CPUと同じ筐体に搭載されてワンチップ化されたSoCの形態や、図１７に示すように、CPUとPCIeを介して接続される形態などで構成され、CPUによって制御されるが、コストダウンやユーザ仕様に特化するため等の理由で、GPUのオプション化が望まれている。PCIeの規格を使用すれば、CPUはオプション基板に搭載された回路を制御できるため、今後は、オプション化されて外付けされるGPUを効果的に動かすための方法が必要となる。
【００１８】
GPUは、ホストとしてのCPUと一対一の関係であり、プログラミングをするとき、対象となるGPUの既定のハードウェアを考慮して調整をすれば十分であった。しかしながら、GPUの性能の向上やGPUのマルチコア化に伴って、想定されるアーキテクチャで設計されたプログラムがたとえ動作するにしても、動作が最適であるかどうかは分からない。
【００１９】
ここで、GPUにカーネル関数を実行させる場合の従来の考え方について説明する。CPUを備えるホストと複数のマルチコア（Multi Core、以下、MCと略す。）を備えるGPUを含むデバイスとを含むシステムにおいて、CPUがGPUにカーネル関数を実行させる際、従来は、オペレータが1ブロックあたりのスレッド数、1MCが処理するブロック数を経験的に決め、その条件でプログラムを動作させていた。
【００２０】
例えば、1ブロックあたりのスレッド数を64に設定した場合、1ブロックあたりのウォープ数（1ウォープ＝32スレッド）は、式（１）より2［warp/block］となる。ここで、1MCあたり最大48ウォープの処理が可能と仮定すると、1MCが処理するブロック数は、式（２）より、24［block/MC］となるが、1MCあたり最大8ブロックの処理が可能であるため、1MCが処理するブロック数は8［block/MC］となる。この場合、1MCあたり同時に実行されるウォープ数は、式（３）より、16［warp/MC］となる。1MCあたり最大48ウォープが同時に実行できるので、占有率は、式（４）より、33%となる。
【００２１】
64［thread/block］／32［thread/warp］＝2［warp/block］  …  （１）
48［warp/MC］／2［warp/block］＝24［block/MC］  …  （２）
8［block/MC］×2［warp/MC］＝16［warp/MC］  …  （３）
16［warp/MC］／48［warp/MC］＝0.33（33%）  …  （４）
【００２２】
上記占有率はMC内で並列実行されているスレッド数と1MCあたりの最大で実行できるスレッド数との比であり、通常は高い値の方が好ましいため、占有率を上げるために、例えば、1ブロックあたりのスレッド数を256に設定する。この場合、1ブロックあたりのウォープ数は、式（５）より、8［warp/block］となる。ここで、上記と同様に1MCあたり最大48ウォープの処理が可能と仮定すると、1MCが処理するブロック数は、式（６）より、6［block/MC］となる。この値は、1MCあたりの最大ブロック数である8以下であるため、1MCが処理するブロック数は6［block/MC］となる。この場合、1MCあたり同時に実行されるウォープ数は、式（７）より、48［warp/MC］となる。1MCあたり最大48ウォープが同時に実行できるので、占有率は、式（８）より、100%となる。
【００２３】
256［thread/block］／32［thread/warp］＝8［warp/block］  …  （５）
48［warp/MC］／8［warp/block］＝6［block/MC］  …  （６）
6［block/MC］×8［warp/MC］＝48［warp/MC］  …  （７）
48［warp/MC］／48［warp/MC］＝1.00（100%）  …  （８）
【００２４】
このように、１ブロックあたりのスレッド数を多くすれば占有率を上げることができるが、スレッド、ウォープ、ブロックの設定に際して、1ブロックに含まれる最大のスレッド数、1MCに同時に含まれる最大のブロック数、1MCに同時に含まれる最大のウォープ数、1MCに搭載されているレジスタ数、1MCに搭載されている共有メモリの容量などの様々な制約を受けることから、従来は、オペレータが1ブロックあたりのスレッド数や1MCが処理するブロック数を経験的に決めていた。そのため、GPUの使用の並列度を上げることができず、データ処理を効率的に実行することができない場合が生じるという問題があった。
【００２５】
そこで、本発明の一実施の形態では、1ブロックあたりのスレッド数や1MCが処理するブロック数をオペレータが経験的に決めるのではなく、プログラムが自動的に算出するようにする。具体的には、プログラムのコンパイルに必要なレジスタ数、共有メモリの容量と、GPUの各MCが持っているレジスタ数、共有メモリの容量と、に基づいて、最大ブロック数／MCを算出する。次に、処理対象のデータの総数から実行するスレッドの総数やウォープの総数を求め、それらをGPUのMC数で除算して、平均スレッド数（又は平均ウォープ数）／マルチコアを算出する。次に、設定可能なブロック数／マルチコアと設定可能なスレッド数（又はウォープ数）／ブロックとの組み合わせで決定される複数のスレッド数（又はウォープ数）／マルチコアの中から、最大ブロック数／マルチコア、及び、平均スレッド数（又は平均ウォープ数）／マルチコアに基づいて、適用するスレッド数（又はウォープ数）／マルチコアを決定する。次に、決定したスレッド数（又はウォープ数）／マルチコアに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成する。そして、そのスレッド／ブロック構成で、プログラムを動作させる。
【００２６】
言い換えると、プログラム処理対象になるデータの総数を、データの計算を行う主体であるスレッドの総数に換算し、全てのスレッドを、使用対象のGPUが保有するMCそれぞれに平均的に分配する。その際、MCが保有する資源に応じて許容されるスレッド数に均等に分割してブロックにする。このように、GPUの全てのMCが均等に割り当てられたスレッドを処理することによって、GPUの使用の並列度を上げることができ、データ処理を効率的に実行することができる。
【実施例１】
【００２７】
上記した本発明の実施の形態についてさらに詳細に説明すべく、本発明の第１の実施例に係る計算制御プログラム、計算制御方法および画像形成装置について、図１乃至図１３を参照して説明する。図１は、本実施例のマルチノードGPUの構成例を示す模式図であり、図２は、本実施例のマルチGPUの構成例を示す模式図である。また、図３は、実施例のGPUの構成例を示す模式図であり、図４は、本実施例のMCの構成例を示す模式図である。また、図５は、ホストプログラムとカーネルプログラムの関係を説明する模式図、図６は、プログラムの実行の流れを説明する模式図であり、図７は、ブロックとMCとの関係を説明する模式図である。また、図８は、本実施例のMCの数によるスケーリングの例（NBLOCK＝8の場合）を示す模式図であり、図９は、本実施例のスケーリングの限界を示す模式図、図１０は、本実施例のブロックの分割を示す模式図である。また、図１１は、1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数と1MCが処理するウォープ数との関係を示すテーブルであり、図１２は、本発明のプログラムモデルを示す模式図、図１３は、1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数とを決定する方法を説明するテーブルである。
【００２８】
本実施例のシステムは、例えば、MFP（Multi-Functional Peripherals）などの画像形成装置であり、CPUを備えるホストと複数のMCを備えるGPUを備えるデバイスとを含む。ホストとデバイスとは、同一基板に実装される形態と別々の装置に構成される形態とがある。
【００２９】
図１は、ホスト１０とデバイス２０とが同一基板に実装される形態の一例であり、ホスト１０とデバイス２０とはPCIeを介して接続される。図２は、ホスト１０とデバイス２０とが別々の装置に構成される形態の一例であり、ホスト１０となるPCとデバイス２０を含む外部演算装置とがPCIeを介して接続される。本実施例の計算制御方法は、どちらの形態のシステムに対しても適用可能である。
【００３０】
図３は、GPUの具体的な構成を示す模式図であり、GPUは、複数のMCとGiga Thread EngineとL2 CacheとDRAMとPCIeとを含む。MCは「並列」プロセッサ（ストリーミングマルチプロセッサ（SM）とも呼ばれる。）であり、MCの数はGPUのグレード及びアーキテクチャに依存する。Giga Thread Engineは、処理をMCに振り分ける。L2 Cacheは、R/W可能な二次キャッシュである。DRAMは、全てのMCとPCIeからアクセス可能なメモリである。PCIeは、ホスト１０との接続インターフェースである。
【００３１】
図４は、MCの具体的な構成を示す模式図であり、GPUアーキテクチャである「Kepler」の一例である。MCは、レジスタとｍ行ｎ列（ここでは１６行１２列）のCoreとｍ個のSFU、LD/ST及びDPと共有メモリ（L1 Cache）とテクスチャCacheとを含む。レジスタは、高速にアクセス可能なメモリであり、カーネル関数で使用する変数のための領域として利用される。Coreは、プロセッサである。SFUは、Special Function Unitであり、MC内で共有となる超越関数演算と倍精度浮動小数点演算を行う演算器である。LD/STは、Load/Storeであり、メモリからのデータの読み出し/書き込みを行う。DPは、倍精度演算ユニットである。共有メモリ（L1 Cache）は、各MCが共有するメモリである。テクスチャCacheは、DRAM内の読み込み専用のテクスチャ用メモリが使用するキャッシュである。
【００３２】
このような構造のシステムを用いてプログラムを実行する場合、図５に示すように、ホストプログラムはカーネルプログラムに書き換えられて実行される。特に、ホストプログラムの中の並列ループは、チャンク分割されたカーネルプログラムによって並列処理が行われる。
【００３３】
図６は、プログラムの実行の流れを示す模式図であり、GPUはCPUからの制御で動作する。CPUからGPUにプログラム処理対象のデータが転送され、1MCあたりのブロック数（図中の「NBLOCK」）と1ブロックあたりのスレッド数（図中の「NTHREAD」）が指定されてカーネル関数が起動される。GPUでは、指定された条件に従ってカーネル関数を実行し、処理後のデータをCPUに転送する。
【００３４】
図７は、MCとブロックとの関係を説明する模式図である。図７において、各ブロックに所属するスレッドの数は全て同じである。また、同一ブロックに所属する全てのスレッドは同じMCに割り当てられる。また、MCは複数のブロックを実行することがある。また、どのブロックがどのMCに割り当てられるかはGPUが決定して、プログラムは制御できない。また、ブロックで実行される順番はGPUが決定する。また、ブロック間の同期は行われない。
【００３５】
図８は、MCの数に応じたスケーリング（各MCへのブロックの割り当て）の例を示す模式図であり、図８（ａ）に示すように、プログラム（グリッド）がblock0〜7の8ブロックで構成される場合を示している。図８（ｂ）に示すように、GPUが2個のMCで構成される場合、8個のブロックは2個のMCに割り当てられるため、各々のMCは4つのブロックを順番に処理することになる。また、図８（ｃ）に示すように、GPUが4個のMCで構成される場合、8個のブロックは4個のMCに割り当てられるため、各々のMCは2つのブロックを順番に処理することになる。また、図８（ｄ）に示すように、GPUが8個のMCで構成される場合、8個のブロックは8個のMCに割り当てられるため、各々のMCは1つのブロックを処理することになる。
【００３６】
図９は、スケーリングの限界を示す模式図であり、同様にプログラム（グリッド）がblock0〜7の8ブロックで構成される場合において、GPUが16個のMCで構成される場合、16個中の8個のMCは各々1つのブロックを処理し、残りの8個のMCは使用されないことになる。すなわち、この場合は、全てのMCにブロックを割り当てることができない。
【００３７】
実行の並列度を上げるためにはブロックの分割が必要であるため、図１０に示すように、各々のブロックに所属するスレッドを同数で分割する。この場合、プログラム（グリッド）はblock0*〜15*の16個のブロックで構成されるため、各々のMCは1つのブロックを処理することになる。
【００３８】
図１１は、ひとつのMCに同時に含まれるブロック数と、ひとつのブロックに含まれるスレッド数（又は、ひとつのブロックに含まれるウォープ数）と、ひとつのMCが処理するウォープ数と、の関係を示すテーブルである。ここで、これらには各々以下の制約がある。
［制約１］ひとつのブロックに含まれる最大のスレッド数は512である。つまり、ひとつのブロックに含まれる最大のウォープ数は16（＝512÷32）個である。
［制約２］ひとつのMCに同時に含まれる最大のブロック数は8個である。
［制約３］ひとつのMCに同時に含まれる最大のウォープ数は32個である。
【００３９】
これらの3つの制約により、ひとつのMCが処理するウォープ数は、テーブル内の太線で囲んだ値を取り得るが、並列実行されるブロックの数は、MCに搭載されているレジスタ数や共有メモリの容量によって制限される（以下の2つの制約を更に受ける）。
［制約４］ひとつのMCに搭載されているレジスタ数は16384個（1個あたり4バイト）である。
［制約５］ひとつのMCに搭載されている共有メモリの容量は16384バイトである。
【００４０】
このように、ひとつのMCに同時に含まれるブロック数、及び、ひとつのブロックに含まれるスレッド数又はウォープ数（スレッド数／ブロック又はウォープ数／ブロック）は、ひとつのMCが処理するウォープ数に応じて決めることができるが、ひとつのMCが処理するウォープ数を選択するにあたって上記5つの制約を満たす必要がある。そこで、従来は、オペレータが1ブロックあたりのスレッド数、1MCが処理するブロック数を経験的に決め、その条件でプログラムを動作させていた。これに対して、本実施例では、プログラムが1ブロックあたりのスレッド数、1MCが処理するブロック数を決めることができるようにしている。
【００４１】
図１２は、本発明のプログラムモデルを示す模式図である。プログラムをコンパイルする際に、1スレッドあたりのレジスタ数（図中の「レジスタ数／Thread」）及び1ブロックあたりの共有メモリ容量（図中の「共有メモリ／block」）を算出する。また、GPUの各MCが持っているレジスタ数、共有メモリの容量を取得する。そして、これらに基づいて、最大ブロック数／MCを算出する。一方、要素数（処理対象のデータの総量）をスレッドに変換し、複数のスレッドをウォープに変換し、GPUのMC数で除算することにより、平均ウォープ数（又は平均スレッド数）／MCを算出する。次に、設定可能なブロック数／MCと設定可能なウォープ数（又はスレッド数）／ブロックとの組み合わせで決定される複数のウォープ数（又はスレッド数）／MCの中から、最大ブロック数／MC、及び、平均ウォープ数（又は平均スレッド数）／MCに基づいて、適用するウォープ数（又はスレッド数）／MCを決定する。次に、決定したウォープ数（又はスレッド数）／MCに基づいて、各々のMCにウォープ（スレッド）が平均化して分割されるようにブロックを構成する。そして、そのスレッド／ウォープ／ブロック構成で、プログラムを動作させる。
【００４２】
その際、設定可能なスレッド数／ブロックを、ブロックの最大包含数以下、及び／又は、マルチコアの最大実行数以下とすることが好ましい。上記最大包含数は、ひとつのブロックに所属することができるスレッドの最大数であって、デバイスの種類に依存して予め決められている。また、最大実行数は、マルチコアが担当することができる最大のブロック数、及び、最小実行単位数のスレッド（ウォープ）の最大の集合数であって、デバイスの種類に依存して予め決められている。
【００４３】
図１３は、上記プログラムモデルに基づいて、1ブロックあたりのスレッド数、1MCが処理するブロック数を求める方法を説明するテーブルである。例えば、要素数＝15000、MC数＝30の場合、
全Warp数＝（15000÷32−1）÷32＝469（小数点以下切り捨て）
平均Warp数／MC数＝469÷30＝15.63（個）
となることから、図１３の太枠内が、選択できるWarp数／MCとなる。ここで、ひとつのMCに同時に含まれる最大のブロック数（最大ブロック数／MC）を4と仮定すると、破線以下が選択できるWarp数／MCとなる。
【００４４】
選択するWarp数／MCに対応するスレッド数／ブロックの最終候補として、128と160が挙げられる。スレッド数／ブロック＝128のとき、4ブロックを同時にMCに含めると、ひとつのMCが実行するWarp数は16である。スレッド数／ブロック＝160のとき、4ブロックを同時にMCに含めると、ひとつのMCが実行するWarp数は20である。ひとつのMCに実行させる平均Warp数が15.63個であることを考えると、スレッド数／ブロック＝128の方が比較的適していると言える。
【００４５】
以上説明したように、本実施例では、プログラムのコンパイルに必要なレジスタ数、共有メモリ容量と、GPUの各MCが持っているレジスタ数、共有メモリ容量とに基づいて、最大ブロック数／MCを算出し、データの総数から実行するスレッドの総数（又はウォープの総数）を求め、それらをGPUのMC数で除算して、平均スレッド数（又は平均ウォープ数）／MCを算出し、設定可能なブロック数／MCと設定可能なスレッド数（又はウォープ数）／ブロックとの組み合わせで決定される複数のスレッド数（又はウォープ数）／MCの中から、最大ブロック数／MC、及び、平均スレッド数（又は平均ウォープ数）／MCに基づいて、適用するスレッド数（又はウォープ数）／MCを決定し、決定したスレッド数（又はウォープ数）／MCに基づいて、各々のマルチコアにスレッドが平均化して分割されるようにブロックを構成し、そのスレッド／ウォープ／ブロック構成で、プログラムを動作させる。これにより、GPUのすべてのMCに均等にスレッドを割り当てることができるため、GPUの使用の並列度を上げることができ、データ処理を効率的に実行することができる。
【実施例２】
【００４６】
次に、本発明の第２の実施例に係る計算制御プログラム、計算制御方法及び画像形成装置について、図１４を参照して説明する。図１４は、本実施例のGPUのプロパティを示すテーブルである。
【００４７】
第１の実施例で説明したように、平均スレッド数（又は平均ウォープ数）／MCを算出するためには、GPUが保有するMC数を取得する必要がある。このGPUの情報を入手する方法として、例えばGPUメーカが提供するランタイムAPIを使用することができる。GPUのIDを引数にしてランタイムAPI関数を呼ぶと、図１４に示すようなGPU固有のプロパティ構造体を取得することができる。そして、取得したプロパティ構造体の中の「num. of multiprocessors」の項目（図中の（１）参照）から、GPUが保有するMCの数を知ることができる。
【実施例３】
【００４８】
次に、本発明の第３の実施例に係る計算制御プログラム、計算制御方法及び画像形成装置について、図１４を参照して説明する。図１４は、本実施例のGPUのプロパティを示すテーブルである。
【００４９】
GPUのアーキテクチャに応じた実行モデルを設計するためには、ひとつの要素（例えば、プログラム上の配列の各要素）にひとつのスレッドを対応させるのが合理的で一般的である。ただし、スレッドの最大数はGPUに依存して決められている。そこで、GPU固有のプロパティを用いて、スレッドの最大数を計算することができる。
【００５０】
例えば、上述したランタイムAPIを使用してGPU固有のプロパティを取得することができる。取得したプロパティ構造体の中に、「max size of each dim. of block」（ブロックの最大幅＝スレッドの最大数、図中の（２）参照）と「max size of each dim. of grid」（グリッドの最大幅＝ブロックの最大数、図中の（３）参照）と「max thread / block」（ひとつのブロック内のスレッドの最大数、図中の（４）参照）が含まれる。
【００５１】
例えば、スレッドの最大数＝(512, 512, 64)とは、ブロック内に指定できるスレッドの最大数は、x方向が512個、y方向が512個、z方向が64であることを示す。ただし、ひとつのブロック内で指定できる全スレッド数は512個である。また、ブロックの最大数＝(65535, 65535, 1)とは、グリッド内で指定できるブロックの最大数は、x方向が65535個、y方向が65535個、z方向が1個であることを示す。従って、このGPUの場合は、保有するスレッドの最大数は、65535×65535×512となる。処理する要素の数が、GPUが保有するスレッドの最大数以下の場合には、ひとつの要素にひとつのスレッドを対応させる。一方、処理する要素の数が、GPUが保有するスレッドの最大数より多い場合には、複数の要素にひとつのスレッドを対応させることになる。
【実施例４】
【００５２】
次に、本発明の第４の実施例に係る計算制御プログラム、計算制御方法および画像形成装置について、図１５を参照して説明する。図１５は、本実施例の1ブロックあたりのウォープ数（スレッド数）と1MCに同時に含まれるブロック数とを決定する方法を説明するテーブルである。
【００５３】
前記した第１の実施例では、要素数が多く、全てのMCにスレッドを割り当てることができる場合について記載したが、本実施例では、要素数が少ない場合の計算制御方法について説明する。
【００５４】
まず、従来の方法の問題点を考察する。1ブロックあたりのスレッド数を256に設定した場合、1ブロックあたりのウォープ数は、式（９）より8［warp/block］となる。ここで、1MCあたり最大32ウォープの処理が可能と仮定すると、1MCが処理するブロック数は、式（１０）より、4［block/MC］となる。この値は、1MCあたり最大ブロック数である8以下であるため、1MCが処理するブロック数は4［block/MC］となる。この場合、1MCあたり同時に実行されるウォープ数は、式（１１）より、32［warp/MC］となる。1MCあたり最大32ウォープが同時に実行できるので、占有率は、式（１２）より、100%となる。
【００５５】
256［thread/block］／32［thread/warp］＝8［warp/block］  …  （９）
32［warp/MC］／8［warp/block］＝4［block/MC］  …  （１０）
4［block/MC］×8［warp/MC］＝32［warp/MC］  …  （１１）
32［warp/MC］／32［warp/MC］＝1.00（100%）  …  （１２）
【００５６】
ここで、要素数を減らしたときのブロック数は、
要素数＝15000のとき、15000／256＝58.5→59［block］、
要素数＝7500のとき、7500／256＝29.29→30［block］
要素数＝3750のとき、3750／256＝14.64→15［block］
となる。MC＝30と仮定すると、要素数＝3750では、半数のMCしか使われないことになるため、実行構成（1ブロックあたりのスレッド数）を見直して同様の計算を行う。
【００５７】
これに対して、本実施例では、以下のように計算する。図１５は、1ブロックあたりのスレッド数、1MCが処理するブロック数を求める方法を説明するテーブルである。例えば、要素数＝3750、MC数＝30の場合、
全Warp数＝（3750÷32−1）÷32＝118（小数点以下切り捨て）
平均Warp数／MC数＝118÷30＝3.93（個）
となる。図１５の太枠内が、選択できるWarp数／MCを示す。ここで、ひとつのMCに同時に含まれる最大のブロック数（最大ブロック数／MC）を4と仮定すると、破線以下が選択できるWarp数／MCとなる。
【００５８】
選択するWarp数／MCに対応するスレッド数／ブロックの最終候補として、32と64と96が挙げられる。スレッド数／ブロック＝32のとき、4ブロックを同時にMCに含めると、ひとつのMCが実行するWarp数は4である。スレッド数／ブロック＝64のとき、2ブロックを同時にMCに含めると、ひとつのMCが実行するWarp数は4である。スレッド数／ブロック＝96のとき、2ブロックを同時にMCに含めると、ひとつのMCが実行するWarp数は6である。
【００５９】
ひとつのMCに実行させる平均のWarp数が3.93個であることを考えると、スレッド数／ブロック＝32又は64の方がスレッド数／ブロック＝96よりも比較的適していると考える。スレッド数／ブロック＝32又は64のとき、ひとつのMCが実行するWarp数は4で同じであるが、Warp数が同じであるならば、ブロック数を多くした方がスレッド間の同期がとり易いという理由から、スレッド数／ブロック＝32の方が比較的適していると考える。
【００６０】
このように、従来の方法では、32［warp/MC］に対応する8［warp/block］が選択されるが、本実施例では、4［warp/MC］に対応する1［warp/block］が選択されることになり、要素数が少ない場合においても、GPUのすべてのMCに均等にスレッドを割り当てることができるため、GPUの使用の並列度を上げることができ、データ処理を効率的に実行することができる。
【００６１】
なお、本発明は上記各実施例に限定されるものではなく、本発明の趣旨を逸脱しない限りにおいて、その構成や制御は適宜変更可能である。
【００６２】
例えば、１つのGPUに含まれるMCの数や１つのMCに含まれるコアの数などは適宜変更可能である。また、図１１、１３、１５では、テーブル内にWarp数／MCを記載したが、Thread数／MCを記載してもよい。
【産業上の利用可能性】
【００６３】
本発明は、CPUを備えるホストとCPUに制御されるGPUを備えるデバイスとを備えるシステムにおけるホストで動作する計算制御プログラム、当該計算制御プログラムを記録した記録媒体、GPUのアーキテクチャに応じた実行モデルで計算を行う計算制御方法及び画像形成装置に利用可能である。
【符号の説明】
【００６４】
１０  ホスト
２０  デバイス
【図１】
2019113984.tif 000003
【図２】
2019113984.tif 000004
【図３】
2019113984.tif 000005
【図４】
2019113984.tif 000006
【図５】
2019113984.tif 000007
【図６】
2019113984.tif 000008
【図７】
2019113984.tif 000009
【図８】
2019113984.tif 000010
【図９】
2019113984.tif 000011
【図１０】
2019113984.tif 000012
【図１１】
2019113984.tif 000013
【図１２】
2019113984.tif 000014
【図１３】
2019113984.tif 000015
【図１４】
2019113984.tif 000016
【図１５】
2019113984.tif 000017
【図１６】
2019113984.tif 000018
【図１７】
2019113984.tif 000019