ネットワークを走らせる際にあなたが指定したワークを実際に処理させるには、 何か が、実行準備の整ったコマンドを受け取って、その実行環境を構築して、それらのコマンドを実行しなければなりません。 TOPネットワークでは、この 何か は スケジューラ ノードに相当します。

TOPネットワーク内に2個以上のスケジューラノードを配置することができますが、そのネットワークをクックするスケジューラは、TOP Networkノードで指定します。

TOPネットワーク内に複数のスケジューラを配置することで、異なる"プロファイル"をセットアップして、スケジューラ間でそれを切り替えることができます(例えば、小規模なテストをする時にはローカルスケジューラを使用し、プロダクションでフル稼働させる時にはレンダーファームスケジューラに切り替えることができます)。

特定のノードで使用するスケジューラをオーバーライドすることができます。 これによって、ローカルで軽いジョブを実行してファイルシステムの修正を行なうことができるので、ファームにそれらのジョブを送信するオーバーヘッドの負荷を回避することができます(さらに、一部のノードをまったくスケジュールに組ませずにメインプロセスでワークを処理するためのオプションがあります)。 他にも、スケジューラノードは特定のトップレベルのジョブパラメータをオーバーライドすることもできます。

新しいTOPネットワークに対してデフォルトのスケジューラノードは、プロセスキューを使ってワークのスケジュールを組みます。 作業負荷によりますが、これによってオーバーヘッドが小さくなるため、実際にレンダーファームを使用するよりも高速化することができます。

すぐに使えるように、TOPsにはいくつかのレンダーファームパッケージ用のビルトインのスケジューラノードが用意されています(以下参照)。

TOPsは、制御マシンとすべてのサーバーがネットワークファイルシステムを共有している場所で分散されたセットアップのみを扱います。

カスタムスケジューラのバインドを使用することで、他のサードパーティ製または内製のソフトウェアと統合させることができます。

Local Schedulerノードで利用可能な計算リソースの数の上限を変更することができます(デフォルトの上限はローカルコンピュータのコア数です)。

• HQueue SchedulerとLocal Schedulerはどちらともジョブで必要な"CPU数/スロット数"(抽象単位)の概念があり、ジョブを同時に実行する際に使用されるマシン上のスロットの最大数を設定します。

• 例えば、特定のジョブ自体がマルチプロセスまたはマルチスレッドだった場合、4個のコアを使用したいのであれば、そのジョブが4つのスロットを必須とするようにマークすることができます。 Local SchedulerまたはHQueue Schedulerは、最大上限以内で最低でも4つのスロットが"空いている"マシンを確保できた場合にのみそのジョブのスケジュールが組まれます。

• TOPノードで生成されたジョブで必要なスロット数を指定する:

  1. TOPノードを選択します。

  2. パラメータエディタからギアメニューを開いて、 Edit Rendering Parameters を選択します。

  3. 左側のペイン内でNode Propertiesタブを選択します。

  4. Scheduler Propertiesツリーには、スケジューラのタイプ別にオーバーライド可能なプロパティすべてが含まれたフォルダがあり、Localフォルダ下のSlots Per Work Itemを選択します。

  5. そのプロパティのブロックをウィンドウの中央のペイン内のSchedulersフォルダにドラッグします。 これでTOPノード上にそれらのプロパティが追加されます。

  6. そのウィンドウを閉じてから、 Slots Per Work Item のトグルを有効にして、割り当てたいスロット数を設定します。

  Note

  ワークアイテムアトリビュートに基づいて値を可変させたいのであれば、このパラメータにエクスプレッションを作成すると良いでしょう。

• Local Schedulerの Total Slots では、クック時に同時にTOPsが使用できる最大スロット数を指定することができます。

• HQueue CPUs per Job では、マシンあたりのCPU上限を指定することができます。

(将来のバージョンでは、HQueueと同様にデータベースなどの他のリソースタイプの上限を指定することができる予定です)

別々のプロセスでオペレーションを開始させるのも、ファーム上でワークのスケジュールを組むのも、ネットワークファイルシステム上にデータを移すのも、どれもこれもTOP内での作業でオーバーヘッド(余計な負荷)が発生します。 一部のノードには、TOPグラフをクックしているプロセス内で小さいジョブを行なうためのオプションがあり、ファーム上でそれらの小さいジョブのスケジュールを組まずに、同じマシン上でそれらのジョブを実行できるようにそれらの小さなワークアイテムをオーバーライドすることができます。

しかし、HDA Processorノードをローカルで実行させた場合でさえも、そのアセットがすぐにクックを完了するようであれば、それを別々のプロセスで実行させるオーバーヘッドは、パフォーマンス全体に影響を与えてしまいます。 このオーバーヘッドを最適化または回避するために、あなたができる事がいくつかあります:

• HDA Processorノードの代わりにROP Geometryノードを使ってジオメトリを生成し、時間/フレーム番号を使ってWedgeを行なってください。

  同じHIPファイル内に、アセットをTOP Networkとしてインスタンス化して、SOPネットワークのROP Geometryノードを指定します。 そのROP Geometryノードの ROP Fetch タブにある All Frames in One Batch を有効にします。 これによって、1度に1フレームで全フレーム範囲をクックする単一プロセスが作成されます。通常では、これはシミュレーションで使用しますが、軽量なジオメトリのジョブの効率性を上げる際にもよく使用します。

  特定のバッチサイズで試すこともできます。例えば、 All Frames in One Batch の代わりに、1バッチで20フレームを使用するようにすることができます。

• 可能であれば、HDA Processorノードの代わりにInvokeノードを試してみるのも良いでしょう。Invokeノードは、独自のプロセス内ではなく、TOPグラフをクックしているプロセス内でSOPチェーンをクックします。このInvokeノードの制限事項は、コンパイルブロックでしか使用できないことです。小さい/すぐに処理が終わるようなオペレーションでは、この方が 非常に 効率的です。

• Local Schedulerノードで、ローカルマシンのプロセスの数を上げることができます。デフォルトの最大プロセス数は、ローカルマシンが低速にならないように非常に低く設定(コア数/4)されていますが、小さなジョブがローカルで実行されるようにオーバーライドする場合には、おそらく、この数をコア数まで上げた方が良いでしょう。