高速 I/O デバイスからのリアルタイム再生とストリーミング再生

RV には、高速 I/O デバイスから直接 2K 以上を読み取ることができるいくつかの機能があります。I/O とデコード速度を決定する変数の数は少なくないため、RV で簡単なパラメータ セットを使用することから開始し、一度に 1 つずつ調整してください。一度にすべてを調整しようとすると、最適な設定を見つけるのが難しくなります。

これについては、できるだけ多くの情報を手に入れて記事を更新します。 

クイック スタート

RV はアーティストのデスクトップで最も多く使用されるため、既定の基本設定はストリーミング I/O 用には設定されていません。ストリーミング I/O を有効にする場合の最も重要な変更点を以下に示します。詳細およびその他のオプションについては、以下で説明します。

  1. 先読みキャッシュをオンにする
  2. RV 基本設定のリーダー スレッドの数を増やす(最適な数を求める実験)
  3. 必要に応じて、フォーマットごとのイメージ基本設定で代替 I/O メソッドを試みる
  4. Preferences -> Render セクションにある prefetch を使用する(PBO をオンまたはオフにする)
  5. Linux では、-scheduler SCHED_RR -priorities 99 99 (以下を参照)を使用して RV をルートとして実行し、ソフト リアルタイム再生を行う 

動作環境

推奨できる確立されたシステムはありません。多くのユーザがストリーミング再生を可能にするためにさまざまな設定を試してきました。次の要件を満たすことにより、多くのメリットを得ることができるでしょう。

  • 大量のコア + プロセッサ
  • 大量のメモリ(64 ビット マシンでは 6 GB が理想的)
  • 64 ビット マシン
  • 最近の GPU (必ずしも Quadro である必要はありません)
  • 高品質のマザーボード 
  • 高速 I/O デバイス。たとえば RAID、ioXTREME など (単一の「高速」ディスク ドライブではおそらくうまくいきません)
  • NVidia カード。低価格の 580 Quadro で十分ですが、より新しい製品であればさらに望ましいです。より新しい GeForce カードも同様に理想的です。

ストリーミング I/O イメージ フォーマット

ストリーミングはこれらのフォーマットでのみ動作します。これら以外を使用して目的を達成できるとしたら、それは奇跡です。

  • DPX および Cineon -- 特に 10 ビット ファイル
  • JPEG
  • TARGA (TGA)
  • TIFF -- 通常、圧縮なしの RAW tiff が最善です
  • EXR または ACES

複数のリーダー スレッド

高速 I/O ストリーミングを可能にするには、複数のリーダー スレッドを使用する必要があります。そのためには、先読みキャッシュを使用している必要があります。先読みキャッシュ サイズには可能な限り小さな値を使用することを推奨します。1 GB を超えても(場合によっては大きく超えても)動作するという証言もあります。しかし、1 GB 以下に抑えるのが理想的です。 

少なくとも 2 つのコアがないと、ストリーミング再生を実行できません

2 つのスレッドから開始します。2 つのスレッドで速度を最適化してから、その後で数を増やしてみてください。スレッドの数は、RV の基本設定ダイアログにある[Caching]タブで制御できます。スレッド数を変更した場合は、RV を再起動する必要があります。

コアとプロセッサの数を増やすと性能が向上します。メモリを増やすと性能が向上します。

複数の EXR デコーディング スレッド

EXR ファイルをストリーミングする場合は、デコーディング用にいくつかのコアを予約することができます。EXR デコーディング スレッドの数は、Formats タブの基本設定から変更できます。最初に Automatic を試みてください。

I/O 方式

どの I/O 方式を使用するかを、実験せずに決めることは困難です。I/O 方式は、Preferences Format タブから変更できます。基本的な I/O 方式は次のとおりです。

  • 標準(一部のフォーマットに対応) ファイルを読み取るのに標準的または通常であると考えられる方法を使用します。たとえば、EXR では、EXR ライブラリの一部として提供される「通常の」EXR I/O ストリームを使用します。
  • バッファあり。データは、すべてのデータの単一の論理的な読み取りとして「ストリーミング」されます。ファイル データはファイル システム キャッシュに常駐させることができます(カーネルがそのように決定した場合)。ファイル データは、すべてのデータが読み込まれた後にデコードされます。
  • バッファなし。バッファありの場合に似ていますが、RV はカーネルに対して、ファイル システム キャッシュにファイル データを常駐させないように指示します。理論上、読み取り中にデータのコピーが作成されないため、I/O が高速になる可能性があります。実際には、これが本当に役立つということはありませんでした。バッファなし I/O が有用かどうかについては、インターネット上で多くの議論があります。 
  • メモリ マップ。ファイルの内容はメイン メモリに直接マップされます。これには、ファイルシステムでキャッシュされない、そしてメモリが不要になればいつでもプロセスによって再利用できる、という利点があります。いくつかの点で、これは上記のバッファありの方法に似ています。Windows では、この方法は上記のバッファあり、バッファなし、および標準の方法と比べてローカル I/O の速度を大幅に向上させることができます。
  • 非同期バッファあり。上記のバッファありに似ていますが、カーネルは、自分自身でデータを順番にアセンブルするために待機するのではなく、ランダムな順序でデータを RV に提供することができます。さらに、低レベルの I/O チャンク サイズを使用して、I/O を調整して帯域幅を最大化することができます。この方法は、Windows の場合に最も便利です。Linux と Mac の場合 RV はデコードおよび並行処理を管理するため、Async I/O は RV のコンテキストではあまり役に立ちません。
  • 非同期バッファなし。非同期バッファありと同じですが、可能であればファイルシステム キャッシュへのデータの保存を省略するようカーネルに指示します。これは、Windows の既定の方法です。

経験則

  • 基本設定で Prefetch オプションを使用します。必要な VRAM の量が 2 倍になりますが、RV とグラフィック カード間の帯域幅を大幅に増やすことができます。これは立体視で見るときに特に重要です。Pixel Buffer Objects (PBOs) もオンになっていることが理想的です。最新のグラフィック カードは、PBO をオンにするとメリットを得られます。古いカードを使用している場合は、オンとオフを切り替えて試してみてください。Fermi 以前の Quadro カードでは、オンにするとパフォーマンスの低下を招く場合があるかもしれません。
  • NVIDIA quadro fermi および kepler GPU (fermi 4000、6000、kepler 4000、5000、6000)を Linux または Windows で使用する場合は、Multithreaded GPU Uploads を有効にします。Mac の場合は Apple Client Storage を有効にします。
  • Windows の場合は、最初に非同期バッファなしを試します。その他の選択肢で良い結果を生む唯一の方法はメモリ マップです。
  • Linux の場合、メモリ マップ では再生の動作が不安定になる場合があります (特に ソフトウェア RAID を使用する場合)。 バッファなしバッファあり のどちらかが好ましい方法です。メモリ マップでうまくいくようであれば、それでもかまいません。
  • バッファなしは、Linux では効果は得られない可能性があります。読み込んでいるファイル システムのタイプに依存するようです。たとえば、Ubuntu 10.04 で ext4 を使用する場合、これはバッファありと同じになるようです。実際には、NFS を使用すると逆効果になることがあります。
  • EXR の場合は、標準の方法を使用しないでください。通常は、バッファなしが最良の方法です(システムがサポートしている場合)。
  • EXR B44 画像は 4:2:0 としてサブサンプリングするのが理想的です。また、B44/A は 16 ビットでなければならないことに注意してください。PIZ、ZIP、および ZIPS でエンコードされた EXR は CPU に負荷がかかり、より多くの EXR デコーダ スレッドが必要になる可能性があります。
  • 最近のグラフィック カードを使用している場合は、フォーマットの基本設定で DPX と Cineon 10 ビットの表示色を 10 Bits/Pixel Reversed に設定してみてください。これは、RV の 10 ビット データを扱う最も高速で色の保持性能の最も高い方法です。HP DreamColor のような「30 ビット」対応のモニタを使用している場合は、X サーバ または Windows を 30 ビット モードにして、このように高精度の色と高速ストリーミングの両方を実現できます。
  • 16 ビット モードで 10 ビット DPX を表示するには、I/O デバイスとグラフィック カードからの帯域幅を 8 ビット モードの 2 倍にする必要があります。DPX/Cineon で 10 ビット モードを使用できる場合は、最初に 8 ビットを試してください。
  • I/O デバイスに大きな遅延がある場合は、遅延を解消するためにリーダー スレッドの数を大幅に増やす必要があります。場合によっては、コアの数より多くのスレッドを使用すると有益な場合もあります。これはネットワーク ストレージで発生する場合があります。
  • ドライバの GL V-sync がオンになっているときに、RV の V-sync がオンでないことを確認してください。
  • ピクセル データがファイル内で 4096 バイトを開始するように書かれた DPX ファイルは、リトル エンディアンであり、4 チャネル 8 ビット、3 チャネル 10 ビット、または 4 チャネル 16 ビットを使用し、解像度の幅は 8 で割り切ることができます。 
  • すべてのスピード テストでは、「Realtime」ではなく、「Play All Frames」モード(Control メニュー)を使用していることを確認してください。このコンテキストでは、「Realtime」とは、オーディオにペースを合わせるために RV がビデオ フレームをスキップすることを意味します。
  • すべてのファイル システムですべての I/O 方式がサポートされるわけではありません。特に、バッファなし の I/O 方式は、基礎となるファイル システムの実装ではサポートされていない可能性があります。

テストとファイル システムのキャッシュに関する注意

RV が動作するすべてのオペレーティング システムは、メモリ内のファイル システムからいくつかのページを保持することによって IO スループットを最大化しようとします。アルゴリズムの予測は非常に難しいかもしれませんが、結果として、リアルタイムのストリーミング IO パフォーマンスをテストしようとしている場合、OS からのこの「支援機能」によって数値が無効になる可能性があります。明確に言えば、テストの場合は、メモリ内でのシーケンスの再生なしで、それぞれの実行を開始することができます。これを行う方法の 1 つは、非常に大きなテスト セットを使用することです。いくつかのシーケンスがあって、それぞれ数千のフレームで構成されているとします。フレームが十分に大きく、RAM が十分に小さい場合は、テストを実行するたびに新しいシーケンスに切り替えることで、新しいシーケンスのどの部分もファイル システム キャッシュに存在しないことが保証されます。 

しかし、フレームがメモリに存在しないようにして、なおかつテストに同じシーケンスを繰り返し使用できるようにするためのより確実な方法は、各テストの実行前にファイル システムのキャッシュを強制的にクリアすることです。Linuxでは、次のコマンドを実行します。

sudo echo 1 > /proc/sys/vm/drop_caches

Mac OSX では、次のように実行します。

purge

残念ながら、Windows 上でファイル システムのキャッシュをクリアする方法はわかりませんでした。もしその方法がわかった方がいればぜひお知らせください。

リアルタイム

RV バージョン 3.10.8 以降、Linux では、RV をリアルタイム アプリケーションとして実行させることができます。このモードでは、特にマシンがサーバの時間スライスの持続時間で設定されている場合(かつ、マシンが最大スループット用に調整されている場合)、Linux で最も安定した再生が可能になります。より小さく、より数の多い時間スライスで RV が動作することが理想的です(ディスプレイとオーディオに関する限り)。

このモードで RV を起動するには、次のコマンドを使用します。

rv -scheduler SCHED_RR -priorities 99 99

この場合、Linux 上の RV は通常の Linux スケジューラの代わりに FIFO またはラウンドロビン スケジューラの使用を試みます。これを行うには、CAP_SYS_NICE 機能が必要です。これはさまざまな方法で実現できますが、現在確認できているのは、Linux バイナリで setuid root を実行してルート権限を取得する方法か、単に root として rv を実行する方法の 2 つのみです。setcap を使用してファイルシステム上で rv.bin バイナリをマーキングし、CAP_SYS_NICE のみを有効にしてルート以外のユーザがリアルタイムで実行できるようにするのが理想的ですが、これはうまくいきませんでした(おそらく、理解が不足しているからだと思われます)。

Mac では、RV 3.10.8 は既定でリアルタイム アプリであり、特別な特権は必要ありません。

Windows では、RV 3.10.8 は管理者権限なしで優先順位をできるだけ上位に上げます。 

注: RV がより高い優先順位で実行されるとき、これはそのスレッドのうちの 2 つ、すなわちディスプレイ スレッドとオーディオ スレッドのみを参照しています。これらのスレッドは、どちらも大量の計算作業を行いません。どちらも通常ブロックされています。したがって、RV がカーネル リソースを大量に消費することを心配する必要はありません。

リフレッシュ レートと V-sync

再生を完全にスムーズにする上で最大のハードルは、モニタのリフレッシュ レートに関連付けられた再生 FPS の効果を把握することです。たとえば、通常、LCD モニタのリフレッシュ レートは既定で約 60 Hz (すなわち、1 秒間に 60 回リフレッシュする)になります。60 Hz モニタで 24 FPS マテリアルを再生すると、3/2 プルダウンと同様の結果になります。スムーズな再生効果を得るための理想的なリフレッシュ レートは、48 Hz または 72 Hz、あるいはその他 24 の倍数に等しいリフレッシュ レートです。また、「60 Hz」モニタは実際には 59.88 Hz である場合があります。つまり、30 FPS マテリアルでも完全にスムーズには再生されないことになります。最良の結果を得るには、59.88 / 2 (29.94) FPS が必要です。

マルチモニタ システム

複数のモニタが接続されているシステムには別の問題があります。RV が再生しているモニタが、同期しているモニタではない可能性があります。その場合、再生が非常に不規則になる可能性があります。たとえば Linux では、ドライバは 1 つのモニタにしか同期できません。RV が起動すると同期モニタを変更することはできません。Linux では、次の環境変数を設定することによって、ドライバが同期のために使用するモニタを変更することができます: __GL_SYNC_DISPLAY_DEVICE 。nvidia ドライバの README に関連する記事を以下に示します。

TwinView で __GL_SYNC_TO_VBLANK を使用するときに、OpenGL は表示デバイスの 1 つにしか同期できません。これにより、OpenGL が同期していない表示デバイスでテアリングの問題が発生する可能性があります。環境変数 __GL_SYNC_DISPLAY_DEVICE を使用して、OpenGL が同期する表示デバイスを指定することができます。この環境変数を表示デバイスの名前に設定する必要があります。たとえば「CRT-1」などです。存在する表示デバイスとその名前のリストについては、X ログ ファイルの「Connected displaydevice(s):」という行で確認してください。また、第 10 章、TwinView の構成 「TwinView の構成」および第 16 章、プログラミング モードの「モード タイミングの同期」のセクションの内容も役に立ちます。

RV の V-sync とドライバ V-sync

最後に、ドライバの GL V-sync と RV の V-sync の両方をオンにして RV を実行しないでください。再生の質が明らかに低下します。どちらか一方を使用してください。システム上で、どちらのタイミングの結果が優れているかを実験することができます。これらの設定は次の場所にあります。

  • Rendering タブの RV Preferences に、Video Sync チェックボックスがあります。
  • Nvidia の設定 GUI に、OpenGL の Sync to VBlank チェックボックスがあります。
Nvidia では、ドライバの V-sync を使用し、可能であれば RV の V-sync を無効にすることを推奨します。Linux の場合、RV 3.12.12 は、ドライバが同期用に使用しているモニタを検出しようとし、RV が再生しているモニタでない場合には警告します(シェルまたはコンソール ウィンドウで INFO メッセージを出力します)。プレゼンテーション モードでは、プレゼンテーション デバイスが Linux 上の同期デバイスでない場合、RV 3.12.12 はメッセージ ボックスを表示します。
 
関連項目: V-sync の記事
フォローする

0 コメント

ログインしてコメントを残してください。