Dev:JA/Ref/Release Notes/2.70/Threaded Dependency Graph

提供: wiki
< Dev:JA‎ | Ref/Release Notes‎ | 2.70
2014年4月4日 (金) 07:54時点におけるwiki>Yamyamによる版 (Created page with "= Blender 2.70: スレッド化依存グラフ = スレッド化依存グラフは、スレッドの問題を解決し、複数のプロセッサスレッドによるオブジ...")
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Blender 2.70: スレッド化依存グラフ

スレッド化依存グラフは、スレッドの問題を解決し、複数のプロセッサスレッドによるオブジェクトの更新に対応します。 完全なスレッド化依存グラフの完全な再実装は徐々に行われる予定です。このリリースでは、スレッド化されたオブジェクト更新のみが実装されています。


オブジェクト更新のスレッド化

GSoC-DepsGraph-ThreadedCPULoad.png

これは現時点の Blender で非常に重要な改良の一つです。オブジェクトがプロセッサのマルチスレッドで更新されるようになりました。これはアニメーション再生とシーンリフレッシュスピードの両方を改善します。

内部的には、これはタスクベースのオブジェクト更新システムとして実装されています。このシステムは現在、このスレッド化依存グラフを使用してオブジェクトの更新の準備が整った(その依存がすべて最新になった)かどうかを判断し、準備ができたらすぐさま、そのオブジェクトを新しく更新するスケジュールに入れます。これはダイナミックロードバランスと呼ばれ、CPU の効率的な使用を大幅に高めることができます。

このアプローチにより、分かれているリグのような、単独のオブジェクトを別のスレッドで更新することができます。また、同じリグに属するオブジェクトをマルチスレッドで更新することもできます(これは大量のオブジェクトを含む単一のリグで素晴らしい効果を発揮します)。

理想では、すべてのプロセッサコアがアニメーション再生中に使用されますが(N倍のスピードアップ、ここで N はCPUスレッド)、残念ながら、常にそうなるわけではありません。その理由はビューの描画が全くスレッド化されておらず、Blender 内の描画コードは相対的にはあまり早くないためです。

カーブテクスチャスペース(Curve Texture Space)

GSoC-DepsGraph-MatchTextureSpace.png

カーブオブジェクトのバウンディングボックスとテクスチャスペースを計算する方法が、カーブオブジェクトの更新をスレッディングと互換性があるよう変更されました。

変更点はカーブオブジェクトの更新時にカーブオブジェクトのバウンディングボックスとテクスチャスペースを計算する方法が、スレッディングと互換性があるようになったことです。現在バウンディングボックスとテクスチャスペースは、制御点・位置とカーブ半径で近似されるようになっています。

これはデータを簡単かつ予測可能な計算方法です。ただ、いくつかの場合では、やはり正確にテッセレートしたカーブに合うテクスチャスペースを持つ方が便利なこともあります。そこでテクスチャスペースをオリジナルのテッセレートされたカーブに合わせるためのオペレータが追加されました。このオペレータはカーブ(Curve)プロパティの▼テクスチャスペース(Texture Space)パネルにあります。

新しい保護付きアロケータ

新しく保護付きアロケータが追加されました。Blender が長らく使用してきた、古い保護付きアロケータには問題がありました。

  • メモリブロックのアロケート/フリー時にスレッドロックが必要でした。これは複数のスレッドがメモリをアロケートした時に大変なボトルネックとなっていました。
  • CPU キャッシュをあまり効率的に使用しない、かなり巨大な MemHead を使用していました。

いくつかの調整が従来の保護付きアロケータに行われてきましたが、これは挙動を改善したものの、前述した問題を完全には解決しませんでした。そのため、デフォルトで古いアロケータをリプレースする、新しい保護付きアロケータが作成されました。この新しいアロケータはスレッドロックを必要とせず、ほんの少しのメモリオーバーヘッドしかありません。これにより、(Blender が)スレッディングに適した物になりました。

新しいアロケータの欠点は、メモリリークを検知する唯一の方法である、解放されていないデータブロックのリストを与えることができないことです。もし非解放のメモリがあるということを示すメッセージが出たら、Blender を --debug または --debug-memory コマンドライン引数で実行し、アロケート済のブロックを追跡し続ける旧保護付きアロケータに Blender を切り替えてください。

インターフェイスのロック

GSoC-DepsGraph-LockInterface upd.png

レンダリング中にインターフェイスをロックするオプションが追加されました。インターフェイスのロックオプションは、レンダリングとビューポート処理スレッド間のスレッディングの衝突から保護します。このオプションが有効時、UV/画像エディターのみ再描画され、画像の操作(パン、ズーム)のみ可能となります。残りのインターフェイスボタンは利用不可となり、UV/画像エディター外のインターフェイスの再描画はレンダリングが完了するまで停止します。

恐らくいったん(コピーオンライトのような)適切な解決策が実装されれば廃止されるかもしれません。
また、このオプションはビューポートの機能に必要なすべてのデータを解放します。
このオプションは Blender がレンダリング中に「メモリを使い果たす」問題がある時に便利です。

インターフェイスのロックオプションの欠点は、ジョブスライダの[×]ボタンのクリックによるレンダリングのキャンセル機能が無効になることです(Escによるレンダリングのキャンセルは可能です)。 この機能を無効にしたのは、WindowManager からのクリックされるボタンのどれがセーフなのかを予測できないためです。


その他の情報

これは直接 Blender アーティストに影響する変更の単なる要約です。このプロジェクトの技術的な詳細について詳しく知りたい方は、GSoC プロジェクトページ(英文)をご覧ください。