JP2011138494A - 仮想タスクを使用したマルチコアプロセッサの性能解析のための関係モデル化 - Google Patents

Abstract

【課題】グラフィックスアプリケーションにおいて、黙示的に生成されるレンダリングパスを可視化する。
【解決手段】マルチコアプロセッサにおいて、ｓｅｔ ｒｅｎｄｅｒ ｔａｒｇｅｔコマンドによって黙示的に生成されるタスクのＩＤを受信し、前記黙示的に生成されるタスクに続いて、実際にハードウェアでのワークをもたらすｄｒａｗ呼出しタスクと関連付けることより、黙示的に生成されたタスク群全体の継続時間を得て、タスク間の依存関係とともに可視化する。
【選択図】図６

Description

本発明は、概してマルチコアプロセッサに関し、特に、マルチコアマシーンの性能解析に関する。

現代の汎用プロセッサ及びグラフィックスプロセッサは、１つ以上のコアを含む。これらのプロセッサは、数多くのスレッドを実行する。そのため、プロセッサの性能解析は、実行されるタスクの数及び様々なスレッドの数を考えると、非常に複雑な作業となる。

トレースは、通常、プロセッサで実行されるタスク間の時間的シーケンス（順序）を図式で表したものである。ソフトウェアベースのトレース解析により、ソフトウェア設計者は、タスク間のオペレーションシーケンスを理解することが可能となる。

しかしながら、マルチコアプロセッサの場合には、より高度な解析が必要になると考えられる。

本発明の一実施形態を概略的に描いた図である。 図１に示した実施形態によって使用されるシーケンスを描いたフローチャートである。 本発明の一実施形態に係るタスクベースの関係モデルの可視化である。 本発明の一実施形態において生成された親／子関係の可視化である。 本発明の別の実施形態に係る依存関係の可視化である。 本発明の一実施形態に係る仮想タスク可視化を描いた図である。 本発明の一実施形態に係るもう１つの仮想タスク可視化を描いた図である。 一実施形態についてのフローチャートである。

本発明の幾つかの実施形態において、時間的シーケンス以外の関係は、複数のタスクと呼ばれるコードの塊の間の関係で可視化することができる。タスクは、スケジューリング及び実行のためのワークの共通単位である。タスクは、始まりと終わりを有するコードの、どの部分に存在していてもよい。また、継続時間は、そのタスクを実行するサイクルの数として規定されてもよい。

トレースとは、複数のタスク間のリンク（関連付け）のことである。関係モデルは、複数のタスク間の関係を、親と子、兄弟、依存性、及び製造者と消費者といったような言葉で表現する。無論、その他の関係を使用してもよい。

第１タスクと、第１タスクによって生み出された第２タスクとの間には、親子関係が存在する。また、実行の際に、第１タスクが第２タスクに依存する場合には、第１タスクと第２タスクとの間に依存関係が存在する。また、製造者／消費者関係とは、第１タスクがデータを生成してバッファに置き、第２タスクがバッファからそのデータを消費することを意味する。

プリミティブ（基本要素）とは、ある関係の当事者である、あらゆる実体を指す。タスクも、プリミティブの一種である。別のプリミティブとしては、パラメータが挙げられる。パラメータは、バッファ、名前‐値の組、ストリング、若しくは通常のデータ型又はタスクと関係している構造であってもよい。その他のプリミティブも使用可能である。

図１に示すように、性能解析ツール１０は、プロセッサであってもよい制御部１２を含む。プロセッサは、マルチコアプロセッサであってもよい。ある実施形態では、グラフィックスプロセッサであってよいし、別の実施形態では、単一命令複数データ（ＳＩＭＤ）マルチコアプロセッサであってもよい。制御部１２は、ツール１６のグラフィカルユーザーインターフェース又はフロントエンド、複数のシーケンス又はアプリケーションプログラムインターフェース（ＡＰＩ）１８、及びライブラリ２０を記憶するメモリ１４と連結される。ＡＰＩ１８は、複数のプリミティブ及び複数のプリミティブ間の関係性を符号化する。ライブラリ２０は、利用可能な機能のツールボックスを提供する。制御部は、入力／出力２２に連結され、ユーザーが情報を入力する及び出力を受け取るのを可能にする。タスクを含む複数のプリミティブ間の関係を可視化するのに表示部２４を使用してもよい。

性能解析ツール１０は、ソフトウェア内の複数のタスクのような複数のプリミティブ間の関係を理解することにより、ソフトウェア性能を強化することを目的として、ソフトウェア開発者によって使用される。これらの関係を理解することにより、ソフトウェア開発者は、どのようにソフトウェア性能を改善させたらよいか知ることができる。

一般的に、ソフトウェア開発者は、コードの２つのバージョンを開発する。１つのバージョンは、ゲームのように、単純に所望の機能を実行するだけのコードである。もう１つのバージョンは、ある実施形態では、プリミティブの関係を可視化するＡＰＩ１８を含むコードである（他の実施形態では、さらなる解析のために可視化を行わずバイナリ出力を使用してもよい）。ＡＰＩを有するコードのバージョンは、計測器コード（ｉｎｓｔｒｕｍｅｎｔｅｄ ｃｏｄｅ）と呼ばれる。フロントエンド・グラフィカルユーザーインターフェース１６へと計測器コードをストリームすることにより、設計者は、コード内で何が起きているのかを知ることができる。コード内で実行されているスレッド、スレッド内のタスク、及び最も重要であるこれらのタスク間の機能的関係が示される。

図２のブロック２２に示すように、アプリケーションプログラムインターフェース１８により実装されるシーケンスは、スレッド選択を受信することから開始される。次のブロック２４では、プリミティブ識別子が選択される。ブロック２６において、識別子が登録される。そして、ブロック２８において、識別子が１つのプリミティブに割り当てられる。

この時点で、設計者は、選択されたプリミティブとその他のプリミティブとの間の関係を入力する。選択されたプリミティブは、"このプリミティブ"と称され、"このプリミティブ"と関係するプリミティブは、"そのプリミティブ"と称される。

ある実施形態では、シーケンス１８は、設計者が入力した以外の関係性の数についても、自動的に示唆する。例えば、第１タスクが、第２タスクの親である場合、第２タスクは、その親の子供であることを暗に意味する。同様に、第１タスクが第２タスクと関連付けられ、第２タスクが第３タスクと関連付けられる場合、第１タスク及び第３タスクも、互いに関連付けられることを暗に意味し、関係の性質についても示すことができる。このような関係は、推移的関係、又は他の関係性から黙示される関係と称すことができると言える。ある実施形態では、この推移的関係を利用して、ユーザーのデータ入力の負担を軽減できる。また、１からＮ個の関係、すなわち論理出力数の関係が存在すると考えられる。例えば、ある実施形態では、１人の親は何人でも子供を生み出すことができるが、生み出された全ての子供を１人１人別個にエンコードする必要はない。

また、シーケンス１８は、プリミティブ識別子のそれぞれについて、タイムスタンプを提供する。あるタスクが開始及び終了する時刻を、出力として提供する。ある実施形態では、シーケンスは、チャートの行に、一連のスレッドを表示可能である。各行は、スレッドにおけるタスクのシーケンスを含む。また、ネスト化された（入れ子になった）タスクを可視化によって示しても良く、例えば、実行されるタスクの延長線部としてネスト化されたタスクを示してもよい。ユーザーは、タスクの選択に応じて特定のタスクをクリックし、その関係が図式で表示されるようにしてもよい。

システム１０は、時間ベースの追跡システムとは異なる、関係ベースのシステムであってもよい。タスクと様々なバッファとの間の時間的関係は、それら自身間の関係と比較した場合、さほど重要ではない。ある実施形態では、タスク間の関係が示され、別の実施形態では、タスク間の相対的なタイミングについては示されない。ある実施形態では、スレッド内のタスクの時間系列は描かれるが、異なるスレッドにおけるタスクの時間的シーケンスは表示されない。ある実施形態では、時間的関係ではなく、機能的関係が可視化されてもよい。機能的関係とは、時間的シーケンス以外のタスク間のあらゆる関係を含む。

ある実施形態では、タスクのそれぞれは、ｘ方向の長さが、実行に掛かる時間の関数である四角形により表現される。ある実施形態では、マウスのクリック及びドラッグの技術を使用して複数のタスクを選択し、選択されたタスク間及びその他のタスク間の関係を表示させてもよい。

図３は、３つのタスク３６、３８及び４２と、バッファ４０の形態である１つのパラメータとが存在する簡単な例を示している。矢印４４、５２、５０及び４８は、タスク間の関係を表している。例えば、タスク３８は、その結果をバッファ４０に配置し、タスク４２がこれらの結果を利用してもよい。この場合、タスク３８は製造者であり、タスク４２は消費者という関係となる。頂点（ｖｅｒｔｅｘ）タスク３８は、drawタスク３６によって生成されたものであるから、矢印５２は、頂点タスクが、drawタスク３６の子供であることを示している。同様に、ピクセルタスク４２の実行は、頂点タスク３８に依存しているので、この依存関係が矢印４６によって示されている。ある場合には、複数のタスク間に多重の関係が存在していてもよい。また、複数のオブジェクト型が存在してもよい。

図２に示すように、ブロック２８において識別子をプリミティブに割り当てた後、ブロック３０において、このプリミティブについての関係が入力される。ここでは、マニュアル手法が説明されるが、コード解析の結果、ユーザーの介入なしに自動的に関係の入力が行われる自動化手法も考えられる。

次いで、ひし形３２において、符号化すべきさらなるプリミティブが存在するか否か確認する。存在する場合は、今までのフローを繰り返す。存在しない場合は、ひし形３４において、エンコードすべきさらなるスレッドが存在するか確認する。存在する場合は、フローを繰り返す。存在しない場合は、フローが終了する。

図４は、親／子関係の可視化の例を示した図である。ある実施形態では、可視化は、マウスで選択可能なタスク又はプリミティブの表現を有するグラフィカルユーザーインターフェースであってもよい。この例では、４つのスレッドのみが示されている。各スレッドにおいて、タスクが四角形で示されている。

この場合、ユーザーは、第２のスレッドにおける親タスクＢを選択している。この選択に応答して、親／子関係の可視化が自動的に行われる。すなわち、タスクＢから矢印が、タスクＢの子供である第３スレッドの一連の複数のタスクＣへと延びる。また、第３スレッドにおけるタスクＣから、親のタスクＢの孫である第４スレッドにおけるタスクＣへと矢印が延びる。

図５は、依存関係の可視化を示した図である。ここで示す例は、ユーザーが選択したタスクＢが、タスクＡ、Ｃ、Ｄ及びＥに対する依存性を有する以外は、図４に示した例に対応している。すなわち、タスクＢは、タスクＡからの入力に依存し、これが"入力依存性"と名付けられた矢印によって示されている。タスクＣ、Ｄ及びＥは、その出力をタスクＢに依存し、これが"出力依存性"と名付けられた矢印によって示されている。したがって、この可視化では、異なるスレッドにおけるタスク間の機能的関係が示されている。

レンダリングパスのようなグラフィックスアプリケーションでは、上述した手法では、タスクを可視化することができない。しかしながら、レンダリングパスは、プログラムによって実行されるワークの計測に便利であり、アプリケーション開発者レベルでは、プロファイルを行うのに好適なツールとなる場合もある。

グラフィックスアプリケーションプログラムインターフェースは、レンダリングパスを実際に表す明示機能を含まず、また、レンダリングパスが一連のＡＰＩ呼び出し（ｃａｌｌ）の間に黙示的に生成されてしまうため、上述の手法を用いて符号化することはできない。したがって、このように黙示的に生成されるタスクを、仮想タスクを使用して可視化してもよい。より具体的には、例えば、次に示すような呼び出しを、Ｄｉｒｅｃｔ Ｘ ＡＰＩで作成してもよい。
SetRenderTarget(1)
Draw(draw_args_1)
Draw(draw_args_2)
SetRenderTarget(2)
Draw(draw_args_3)

このコード例では、draw1及びdraw2が、第１のレンダリングされた対象のワークの一部であり、draw3は、第２のレンダリングされた対象のワークの一部である。このワークは、ハードウェアで実行され、実行の結果ワークとなるコマンドは、drawingコマンドのみである。set render targetコマンドは、単なる状態設定に過ぎず、それ自身はワークを生成しない。この問題を解決するため、ある実施形態では、仮想タスクを使用する。仮想タスクは、set render target呼び出しで生成されてもよい。
SetRenderTarget(x) {
TAL_BeginVirtualTask("RenderTarget");
TAL_SetCurrentTaskID(x->renderTargetID);
TAL_EndVirtualTask()
}

通常のタスクでは、タスクの継続時間を知るために、開始呼び出し及び終了呼び出しのタイムスタンプが記録される。しかしながら、上記のset render targetを有する例では、実際のタスクはその実行が完了するとすぐに終了となってしまうので、後に実行される本当のワークのプレースホルダであると言える。

仮想タスクの実際の継続時間を与えるために、他の非黙示的に生成されるタスク又は実際に符号化されたタスクを、仮想タスクと関連付けてもよい。例えば、draw呼び出しタスクが生成される場合、このdraw呼び出しタスクは、実際の仮想タスクの子供となる。この仮想タスクの原理を適用すると、set render targetの継続時間は、render target仮想タスクのリストをユーザーに提示する時間及び関連するタスクの全てに基づいて仮想タスクの継続時間を計算する時間で与えられると考えられる。

可視化のタスクは、図６に示すように、最小の及び最大の子供のタスクを使用して、時系列で可視化してもよい。親／子関係から、図６に示す可視化が得られる。例えば、target 1をレンダリングする下層のタスクは、draw 1及びdraw 2の子供として描くことができ、ターゲット２は、draw 3の子供である。したがって、render target 1及びrender target 2により、継続時間を得ることができる。ただし、この継続時間は、基本的には、set render target 1の場合にはdraw 1及びdraw 2、set render target 2の場合にはdraw 3というように関連付けられたdraw呼び出しの継続時間である。

仮想タスクは、複雑なタスクについてのさらなる情報を示すにも有用であり、詳細な情報がなくとも、基本的なプロファイリングを行うことができる。上述のrender targetの例では、図７に示すようにアプリケーション実行において、仮想タスク（render target 2、render target 3）のみが示される。多数のスレッドが存在する場合、ある事例においては、図６に示した例よりも、このことがより明確になると考えられる。例えば、１２８個のスレッドが存在し、各スレッドが、何十万ものタスクを含む場合、set render target 2は、最も長い時間実行され、set render target 3の実行は、set render target 2の完了に依存する。この事実が判明すると、設計者は、プロファイリングを中止して、set render target 2とset render target ３とが同時に実行されるようにアクションをとるか、あるいは、set render target 2が非常に時間の掛かるプロセスであると判明したのでset render target 2を最適化することが考えられる。

図８に示すように、仮想タスクを入力するためのシーケンス６０は、モジュール又は、図２に示したようなＡＰＩ１８の一部であってもよい。まず初めに、ブロック６２において、仮想タスクが、あたかも本当のタスクであるかのように実行される。そして、ブロック６４において、現在のタスク識別子が、あたかも本当のタスクであるかのように設定される。ブロック６６において、タスクが、別のタスクと関連付けられる。例えば、set render targetの仮想タスクは、図６で示したような１つ以上のdraw呼び出しと関連付けられてもよい。この関連により、仮想タスクの継続時間を得ることができる。そして、仮想タスクが終了する（ブロック６８）。

つまり、仮想タスクは、複雑で、高度に並列なソフトウェアに対するプロファイリングツールを構成するのに便利であると考えられる。仮想タスクがない場合、プロファイリングツールは、ＡＰＩを実行するメカニズム以上のものを示すことができず、ある場合においては、単純で重要な性能についてのヒントを得ることが妨げられてしまう場合がある。仮想タスクを使用することにより、このような問題が最初から明確になるような抽象化を得ることができ、ある実施形態では、より生産的で効率的なトップダウンプロファイリングが可能となる。

本明細書に記載されたグラフィックスプロセッシング技術は、様々なハードウェア構造に実装可能である。例えば、グラフィックスの機能を、チップセット内に集積してもよい。あるいは、離散グラフィックスプロセッサを使用してもよい。また、他の実施形態では、グラフィックス機能は、マルチコアプロセッサを含む汎用プロセッサによって実装されてもよい。

また、本明細書において、「ある実施形態」又は「実施形態」と称するものは、実施形態に関連する特定の特徴、構造及び特性が、少なくとも本発明の実装形態の一つに含まれていることを意味する。したがって、本明細書中の様々な箇所で使用されている「ある実施形態において」又は「一実施形態において」という表現は、必ずしも同一の実施形態を示していない。また、特定の特徴、構造及び特性を、記載した特定の実施形態以外の適切な形式で実装してもよく、このような全ての形式も、本願の特許請求の範囲に含まれる。

本発明が、限られた数の実施形態を参照して説明されたが、数多くの改良及び変更が可能であることは、当業者にとって明らかである。添付の特許請求の範囲は、本発明の精神及び範囲におけるこのような改良及び変更も含むことを意図している。

Claims (29)

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. 前記装置は、２つ以上の実際に符号化されたタスクの前記継続時間を使用して、前記黙示的に生成されるタスクの継続時間を示す請求項２８に記載の装置。

Images