自動フィールドシフト 高速化版 +16

+16
フレームバッファ確保を分割して行うことで、メモリ確保エラーを減らし、安定性を向上。
提案してくださったHayatePP様、ありがとうございました。

+15
2つの処理を統合することで高速化。(2% 前後)

これまで並列化されていなかった部分も並列化(サブスレッド)。
これにより、Sandy-E / Ivy-E / Haswell-E などで、～25% 高速化。

---

サブスレッドの導入 (並列化されていなかった部分を並列化)

---

自動フィールドシフトはこれまでフレームを解析する部分(scan_frame)しか並列化されていなかった。トラックバーで設定できる「スレッド数」はこのscan_frame部分のスレッド数に相当する(afs メインスレッド数)。

これは(以前の開発環境では)他の部分がメモリアクセス中心の処理のため、並列化してもあまり速度が上がらないため。

ところが、以前測定したように、5960XなどQuad-Channelな環境では、マルチスレッドにしても比較的よくメモリ帯域が伸びていく。

ということは、たとえメモリアクセス中心の処理だったとしても、こういう環境では速度があがるんじゃないかなと思ったので、scan_frame以外の部分の並列化を行う「サブスレッド」を導入して、速度を測った。

---

環境
Aviutl 1.00
Win8.1 x64
MPEG2 1920x1080i, 29.97fps, 10240frames
m2v.aui 0.7.5a

Core i7 4770K Core 3.9GHz / UnCore 3.9Ghz, DDR3-2600, 2ch, 16GB
Core i7 5960X Core 4.4GHz / UnCore 4.0GHz, DDR4-2666, 4ch, 32GB

afs設定
映画/アニメ プリセット、(scan_frame)スレッド数 16

---

測定するときには、自動フィールドシフト設定画面のトラックバーにある「スレッド数」(下の図で灰色のscan_frame部分のスレ数)は16にしたまま、今回導入したサブスレッド(灰色のところ以外の並列数)を1～4まで変化させて測った。

1フレーム平均所要時間 [メインスレッド数: 16 固定] (+14 / +16 (サブスレッド数: 1～4))


scan_frame部分(灰色)のスレッド数は変わらないので、当然その部分の速度は前と(ほぼ)変わらない。

5960Xでは、サブスレッドを増やしていくと、他の部分が高速化され、所要時間が大幅に短縮されていくのがわかる。サブスレッド数を1(並列化なし)から2並列にすると25%近く高速化し、その後も少しづつ速くなっている。

一方、4770Kでは、サブスレッドを1から2に増やしても所要時間の短縮はほんのすこしで、さらにサブスレッド数を増やすと今度は逆に遅くなっていってしまう。

---

5960Xではサブスレッド数を2にするだけで大きな効果があるので、4770Kとのバランスも考えて、公開版ではサブスレッド数を"2"にしてある。

大きな効果があるのを確認したのはHaswell-Eだけだけど、似たような傾向にあるSandy-E, Ivy-Eでも効果があるんじゃないかと思う。

---

あと、HayatePP様にご提案いただいて、今回からafsで使うバッファ用のメモリを16フレーム分一気に取るのではなく、フレームごとに取るようにして、メモリ確保の失敗の回避を試みている。メモリの断片化のせいで、まとまったメモリ確保に失敗することがあり、細かく確保することでこれを回避しやすくなる、と教えていただいた。

指摘していただきありがとうございます。

メモリの確保は初期化時にしか行わないので、メモリ確保回数が増えることで遅くなることは考えなくても良さそう。

こちらの環境では意図的にメモリを食いつぶすなどしないとメモリ確保失敗は起こらないので、わたしには効果の程はよくわからないけれど、メモリ確保失敗が起こりにくくなっていればと思う。

あと64bitOSなら、Aviutlの設定でLargeAddressAwareにチェックを入れていただければ、さらに発生しにくくなるかと。

---

ダウンロード>> (skydrive)　(dropbox)

---