版面规则
提问时请注意:尽量详细描述操作过程、AVS脚本内容等,最好能写出片名,只贴图有时无法看出问题原因。
提示:发布原创内容请尽量使用附件上传。使用网盘会出现过期失效的问题,请注意。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

1. 区别在于使用x86_32/x86_64的avisynth,不是x264

2. 格式里有用pipeline,有用branch,不知道您用的是哪种用法

3. 如果你的avs里有五个滤镜,你的CPU是8核心,每个滤镜单独跑时,都是5fps,而且正好吃满一个核心,这时如果放在一个脚本里五个滤镜就会抢CPU的一个核心,速度可能变成1fps。如果pipeline的方式,
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### ###
filterB()
### ###
filterC()
### ###
filterD()
### ###
filterE()
### ###
""")[/syntax]
就可以让五个filter几乎按流水线方式吃满5个核心,速度可以维持5fps,只是CPU占用从12.5%变成了62.5%。

4. 如果原始avs里有一个滤镜filterA,只吃单核心,速度是5fps,在8核心CPU上跑,放在一般的avs内吃满12.5%的CPU。如果采用branch(mt)的方式:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### branch: 4
### ###
""")[/syntax]
就可以让其在四个核心内同时处理。如果这个滤镜重复计算很少(譬如完全intra型滤镜),则可能达到5x4=20fps,只是CPU占用从12.5%变成了50%。

5. 如果原始avs里有两个滤镜,都只能吃单核心,如果单独跑时filterA速度是10fps,filterB速度是5fps,放在单个avs内,filterA和filterB去抢占单个核心,速度有可能变成3.33fps。这时如果用pipeline+branch(mt)的方式:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### ###
filterB()
### branch: 2
### ###
""")[/syntax]
这时filterA用一个核心,filterB分成两部分来跑,从而占满2个核心。如果其本身重复计算不多的话(譬如全intra型滤镜),filterB的速度几乎就是原始速度乘以branch数。结果就是整体速度可以维持10fps,只是CPU占用从12.5%提升到了37.5%。

6. 还是上面这个例子,我如果想继续提速,让filterA和filterB都用mt方式,例如:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### branch: 2
### ###
filterB()
### branch: 4
### ###
""")[/syntax]
如果filterA和filterB都是重复计算量很少的intra型滤镜,这时filterA用了两个核心,从10fps提升到20fps,filterB用了四个核心,从5fps提升到20fps,整体速度也是维持在20fps,只不过avs的CPU占用从12.5%提升到了75%。

7. 以上例子前提是内存足够,且均未考虑source filter/tcp/系统CPU分配的开销,实际提速不会有这么高。

8. pipeline的原则是,在整个流水线过程中尽量保持每个部分的速度相当。例如filterA和filterB速度相当时,用pipeline分割之后两个不再抢占同一个核心,而是分别使用不同核心,则速度就会翻倍。如果filterA的速度非常快,譬如100fps,而filterB的速度非常慢,譬如1fps,这种情况就不适合用pipeline,因为即使不抢占核心了,filterB的速度还是瓶颈,filterA使用的核心根本没占满,完全在等filterB处理进度。

9. QTGMC这种有大量inter型处理的滤镜,如果内存足够,并且作为瓶颈原来只能吃满单个核心的话,用mt的方式单独跑avs还是可以有速度提升,只不过这个提升是以大量的CPU的重复计算为代价的。假设QTGMC里inter的计算有50%,intra的计算有50%,则用branch: 4的时候,50%的inter计算被重复做了4次,这部分不会有提速,另外50%的intra计算是不重复的,这部分是会提速的。总体看来,虽然有提速,但是CPU开销比较浪费。

10. 以上所有例子只考虑单独跑avs的情况。如果是在用x264压avs,则还需要考虑x264的CPU占用。如果本来一个intra的avs占12.5%,而x264占12.5%,x264在等avs,所以没有用上空闲的剩余CPU。用branch: 4,则avs占到了50%,而x264的处理也需要x4才能跟得上avs的提速,则几乎正好占满100%的CPU,总速度差不多为原来的4倍(CPU 25%->100%,fps x 4),也就是说CPU占用以及速度都和同时开4个x264跑4个avs差不多。而如果是QTGMC的话,avs的CPU占用提升到4倍,但是因为有冗余处理,实际速度只提升到原来的50%x4=2倍(仅intra部分提速,剩下的50%inter需要重复做所以不会提速),则x264只需要增加到25%的占用,总速度也只有2倍(CPU 25%->75%,fps x 2),也就是说CPU占用相当于同时开3个x264跑3个avs,但是速度只相当于同时开2个x264跑2个avs。而pipeline方式因为不会重复计算,这种开销增大但速度没有同等程度增加的现象相对来说较不明显。所以仅intra计算时,pipeline与branch(mt)配合使用是没问题的;而inter计算较多的情况下,只用pipeline而不用branch(mt)对整体速度的提升的性价比更高。

11. 如果本来avs+x264的CPU总开销就比较高,譬如70%-100%,在没有重复计算的情况下,avs提速,avs和x264抢占CPU,整体速度可能不会有明显提升,甚至也许因为抢占CPU,系统的CPU分配过程会导致一定的下降;而如果有重复计算的话,avs和x264抢占CPU,而且avs在CPU开销增加的同时没有同等程度的速度增加,则整体速度有可能反而大幅下降。所以mp_pipeline提速还需要本来avs+x264的总CPU占用比较低为前提。

12. 仅个人观点,实际是否如此以SAP菊苣的解释为准。
上次由 06_taro 在 2012-02-01 12:36,总共编辑 2 次。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
rshadow
帖子: 57
注册时间: 2011-03-23 10:18
联系: ICQ

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

感谢taro菊苣,思路又清晰许多了。

代码: 全选

MP_Pipeline("""
source
### ###
QTGMC()
### branch: 4,4
### ###
""")
小白当时开的大概是这个,大概因此吃过多CPU了囧?不过实际上cpu基本都没有满载过啊,内存那时候是5.8G/8G的情况。


照上面4.的方式,修改AVS为

代码: 全选

MP_Pipeline("""
source
### ###
filterA
filterB
### branch: 3
### ###
""")
速度同样是10fps,cpu占用也是为37.5%……这样反而不用考虑A、B滤镜各自的速度了,貌似branch就多半不用考虑pipeline了。这样是会有什么问题呢?(内存?)

{:cat_18} 另外怎么可以测试该情况下某个(些)滤镜跑的速度呢?不然搭配起来总觉得是带点碰运气的样子。

另外x264也要占用上挺多cpu的样子,这个情况下加上--threads比较好?[/s]

edit:刚回复完发现多了好多内容,继续努力学习 {:cat_16}
先砍掉……看完再重新回复嗯
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

rshadow 写了:刚刚试用了一下,有几个问题一直搞不懂:

1. x86和x64文件夹下的avs,区别是只在于使用x86或x64的x264的吗?用了avs4x264mod后效果一样?

2.模仿着格式试着跑了一回QTGMC,貌似速度更悲剧了 {:cat_7}
请问一下,这个该在什么时候用呢?EP滤镜组合不太能理解,能举些实例吗?

3.那个……合理的组合是指跑AVS和x264的速度相近吗?先前见msg7086提到过“跑一下banchmark看哪边的fps高”,不知道和这个有木有关联?(其实偶根本不知道神马是banchmark…orz
1、x86和x64分别适用于对应的AVS版本,其它方面完全一样。

2、用的是branch模式么?现在看来branch在大部分情况下都是没有效果的,甚至还会降低速度,尤其是QTGMC这类复杂的脚本,所以最好是不要用了。另一个使用场景是把MCTD之类的脚本分到单独的进程,然后在这个进程的脚本里面使用SetMemoryMax(3072)来加大帧缓存,这样在大内存的机器上*有可能*提高速度(不同的机器配置效果不一样,也有可能出现反效果)。

3、benchmark指的是人肉跑不同的脚本测试速度。。。合理的组合是指在不同进程里面合理分配AVS滤镜,这个具体的我也说不清楚,主要还是得靠经验。。。

edit: 回完才发现撞车了囧 taro巨巨解释基本无误(比我写得好多了orz)
T: @SAPikachu
头像
msg7086
帖子: 600
注册时间: 2011-02-19 0:49

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

3. benchmark就是实测速度快慢。比如你要测试MCTD的情况,你可以开mt,开pipe或者定单核,分别跑一次,看哪种跑法最快,就用哪种跑法。也称作Profiling。

2. branch我可能会推荐加入spatial级别的帧分割,这对于ivtc()之类的滤镜跑双线效果挺好……不过本质上还是要滤镜本身支持多线才是最好的
至于temporal分割,对于qtgmc/mctd来说,最好是把chunk size开大,比如 ### branch: 2, 500,这样可以显著减少重复计算。FIXME if I was wrong

顺便补充一下

pipeline本质上用的是网络连接吧?感觉管道是不是效率会更高一些呢?
Delogo LGD Collections 各种台标下载 | Home Of VapourSynth Evolution

<回答が無い理由>
1. 誰も知らない
2. 質問文が意味不明
3. 知ってるが、お前の態度が気に入らない
4. 良いボケが思いつかない
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

msg7086 写了:
2. branch我可能会推荐加入spatial级别的帧分割,这对于ivtc()之类的滤镜跑双线效果挺好……不过本质上还是要滤镜本身支持多线才是最好的
至于temporal分割,对于qtgmc/mctd来说,最好是把chunk size开大,比如 ### branch: 2, 500,这样可以显著减少重复计算。FIXME if I was wrong

顺便补充一下

pipeline本质上用的是网络连接吧?感觉管道是不是效率会更高一些呢?
因为下游进程是顺序请求的,加大chunk size本身作用不大,要加上prefetch,比如说在branch后面加上ThreadRequest(x)。哪位有空可以测试下。。。

理论上pipe是会好点,不过需要用到Pipeline的一般都是很EP的滤镜,个人认为差别应该很小。(还有就是我懒得重写成pipe了(死
T: @SAPikachu
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

对了,其实现在应该也可以在pipeline的一个进程能用TCPServer另一个进程内用TCPSource来传递超过1个clip的吧……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

06_taro 写了:对了,其实现在应该也可以在pipeline的一个进程能用TCPServer另一个进程内用TCPSource来传递超过1个clip的吧……
其实输出多个clip要实现问题并不大,不加是因为很容易会出现线程问题导致rp。。。
T: @SAPikachu
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

这样啊……嘛……我这里用
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
xxxSource
TCPServer(22150)
nrFilter
### ###
""")
MCTD_PP(last, TCPSource("127.0.0.1", 22150, "None"), sharp=true)
[/syntax]
这样似乎没出现过什么RP,最多是偶尔在多次启动时有时候会失败,也许是一个slave还没关闭就重开了,结果port重复了吧……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

06_taro 写了:这样啊……嘛……我这里用
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
xxxSource
TCPServer(22150)
nrFilter
### ###
""")
MCTD_PP(last, TCPSource("127.0.0.1", 22150, "None"), sharp=true)
[/syntax]
这样似乎没出现过什么RP,最多是偶尔在多次启动时有时候会失败,也许是一个slave还没关闭就重开了,结果port重复了吧……
这种用法是不推荐的,很有可能会有各种线程方面的RP。。。不过刚才在外面突然想到个方法可以以线程安全的方式传送多个clip,晚点有空改代码去(encx264的更新又得继续坑了orz
T: @SAPikachu
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: MP_Pipeline 0.3 - 多进程运行avs脚本 [2012-01-01]

于是坐等安全的方式~
可以在MP_Pipeline里安全地上mask才是王道啊~
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

回到 “AviSynth”