lqf3dnow 发表于 2011-1-11 17:18

Gato_shin 发表于 2011-1-11 17:27

這部分電路和顯卡的硬解電路類似，都是絕對的針對性應用，雖然都能通過CUDA以不低的效率代替……
不知道來福士黛兒給移動設備轉片子是不是也能利用，能的話就好了

chakane048 发表于 2011-1-11 17:37

这个是什么编码？

wtyrambo 发表于 2011-1-11 17:44

1W5码率压BD还不算很缺,要给个8000码率压看哪个压出来色块少就行了

nintendoll 发表于 2011-1-11 17:46

软件问题，gpu转码和纯cpu转码速度怎么可能才相差这么点

Castiel 发表于 2011-1-11 17:47

都是转成264

鸡蛋灌饼 发表于 2011-1-11 18:33

引用第4楼nintendoll于2011-01-11 17:46发表的:
软件问题，gpu转码和纯cpu转码速度怎么可能才相差这么点 images/back.gif

那你以为差多少？
压缩算法没那么好并发的

lqf3dnow 发表于 2011-1-11 18:42

Sheny 发表于 2011-1-11 18:43

损失很小,可以忽略.CUDA差距太大。

Castiel 发表于 2011-1-11 18:44

看质量要放警车那张

nintendoll 发表于 2011-1-11 18:51

可能是软件和参数问题吧，转码不是cuda宣传的主要应用之一吗，不快个至少5倍都不好意思拿出来说

鸡蛋灌饼 发表于 2011-1-11 18:55

引用第8楼Sheny于2011-01-11 18:43发表的  :
损失很小,可以忽略.CUDA差距太大。 images/back.gif

我擦我知道N卡的差，没想到这么差
黄老板快扣他们奖金！什么破烂货上当啊！
引用第9楼Castiel于2011-01-11 18:44发表的  :
看质量要放警车那张 images/back.gif

警车那张我觉得x264那张图没缩放好，感觉其他的用的都是Lanczos，这张用的是最近点法似的……
引用第10楼nintendoll于2011-01-11 18:51发表的:
可能是软件和参数问题吧，转码不是cuda宣传的主要应用之一吗，不快个至少5倍都不好意思拿出来说 images/back.gif

就CUDA方案那瞎狗眼的质量，我还是另下吧……

Castiel 发表于 2011-1-11 19:02

1.5Mbps 480p

x86
http://images.anandtech.com/reviews/cpu/intel/sandybridge/review/quicksync/darkknight/snb.png

SNB QS
http://images.anandtech.com/reviews/cpu/intel/sandybridge/review/quicksync/darkknight/quicksync.png

6970
http://images.anandtech.com/reviews/cpu/intel/sandybridge/review/quicksync/darkknight/6870.png

460 cuda
http://images.anandtech.com/reviews/cpu/intel/sandybridge/review/quicksync/darkknight/gtx460.png

nintendoll 发表于 2011-1-11 19:03

质量差是软件算法问题，cuda只是一个编程平台，躺着中枪了

Castiel 发表于 2011-1-11 19:06

引用第11楼鸡蛋灌饼于2011-01-11 18:55发表的:

就CUDA方案那瞎狗眼的质量，我还是另下吧…… images/back.gif

我也觉得大概缩放算法有问题, quicksync那张才是应该得到的结果
顺便, 6970其实和软压差别应该不大, 硬件加速部分大概微乎其微

Castiel 发表于 2011-1-11 19:07

引用第13楼nintendoll于2011-01-11 19:03发表的:
质量差是软件算法问题，cuda只是一个编程平台，躺着中枪了 images/back.gif

据说是nv提供的算法库的问题, 为了速度强行做并行结果精度不要了

f3uki 发表于 2011-1-11 19:14

敢给个低码率下的psnr和ssim么...

nintendoll 发表于 2011-1-11 19:16

那倒可能，cuda还不成熟，不过cuda进步还是很快的，特别是compute capability 2.0以后改进相当大，nv自己的库都是软件跟不上硬件

mocnsm 发表于 2011-1-11 19:19

警车那张...intel赢了

Sheny 发表于 2011-1-11 19:21

据闻负责quicksync那组人，现在天天和H264那队搅基鬼混。如果搭上库，CUDA就真没戏了。

Castiel 发表于 2011-1-11 19:21

cuda的视频压缩库精度跟上了估计比软压还慢...

鸡蛋灌饼 发表于 2011-1-11 19:41

引用第17楼nintendoll于2011-01-11 19:16发表的  :
那倒可能，cuda还不成熟，不过cuda进步还是很快的，特别是compute capability 2.0以后改进相当大，nv自己的库都是软件跟不上硬件 images/back.gif

就NV那软件实力，还是算了吧
一股编译器都搞不定的架势……
引用第19楼Sheny于2011-01-11 19:21发表的  :
据闻负责quicksync那组人，现在天天和H264那队搅基鬼混。如果搭上库，CUDA就真没戏了。 images/back.gif

doom10上有个帖子，各种嘴炮和欢乐
引用第20楼Castiel于2011-01-11 19:21发表的  :
cuda的视频压缩库精度跟上了估计比软压还慢... images/back.gif

视频压缩算法本身的问题，很多东西不是想并行就能并行的，不能并行的话GTX580都不如PIII
据说x264本身也是多线程质量比单线程差一点

ov_efly 发表于 2011-1-11 19:46

INTEL 那个模糊还是明显的
警车那张

uroko 发表于 2011-1-11 20:05

總結：還是x86好

yibabilun 发表于 2011-1-11 21:32

谁给普及一下x264视频压缩算法? 外行如我觉得如果画面分块+分时+1pass不预测关键帧应该很适合并行啊?

数据交换在时间和空间上都完全近邻,对并行效率最大的影响只来自于按照局域图像复杂度动态调整码率. 这确实不好优化,因为不规则分块造成的效率损失远大于计算本身.

鸡蛋灌饼 发表于 2011-1-11 21:35

引用第24楼yibabilun于2011-01-11 21:32发表的  :
谁给普及一下x264视频压缩算法? 外行如我觉得如果画面分块+分时+1pass不预测关键帧应该很适合并行啊?

数据交换在时间和空间上都完全近邻,  对并行效率最大的影响只来自于按照局域图像复杂度动态调整码率. 这确实不好优化,因为不规则分块造成的效率损失远大于计算本身.


....... images/back.gif

这两个都只能算预处理……

另外要注意现在的显卡本质上是多核SIMD处理器，分支一多立马SB

Castiel 发表于 2011-1-11 22:46

画面分块分时的预处理怎么并行化...

分好后倒是可以并行了, 但是分块工作不均匀了, 没有缓存走内存各种纱布

fjzxc 发表于 2011-1-11 22:48

还是X86 看起来最好呃

yibabilun 发表于 2011-1-11 22:52

具体科普一下算法吧..我不清楚具体细节.

我的意思是把时空块分到每个线程然后就这么算下去..我不是说分块和分时这个操作本身..我说这东西适合并行,是基于这样的观点:

压缩某个局域的时候和远处的数据如何没有什么关系.最多就是考虑到近邻的图像复杂度而对压缩率做一些修正.这样的假设下数据交换很少,并性最基本的需求,也就是尽量少的数据通信..之后才能谈用节点指标玩出各种花样代替分支或者展开循环..

这算预处理那么正餐是做什么?

yibabilun 发表于 2011-1-11 22:59

引用第20楼Castiel于2011-01-11 19:21发表的:
cuda的视频压缩库精度跟上了估计比软压还慢... images/back.gif


这个也许不会...实验上商业卡的双精度效率大约是单精度的1/3到1/2,远没有标称的1/10左右那么悲剧.当然如果nv下限到在压缩库里大量使用硬件快速函数那就不好说了.

chiyi1908 发表于 2011-1-11 23:00

460。。。

yibabilun 发表于 2011-1-11 23:11

引用第26楼Castiel于2011-01-11 22:46发表的:
画面分块分时的预处理怎么并行化...

分好后倒是可以并行了, 但是分块工作不均匀了, 没有缓存走内存各种纱布 images/back.gif


我觉得只能平均分格子简单的压一下,算算每个格子的方差,然后收集到cpu做分块吧..不知道具体算法我瞎胡扯也没用.

据说fermi的显存访问效率比上一代好了,但是最近也没空折腾验证..

Castiel 发表于 2011-1-12 00:28

现阶段基于dct的图像压缩, 都是以方块来处理的, 但是要达到合适的质量, 这个方块大小应该是根据图片来的, 然后分成64x64, 32x32, 16x16, 8x8丢给处理线程.
所谓预处理就是来算最合适的分块.
对于CPU来说不同大小分块影响不大, 线程数不多也可以一个个来.
对于cuda来说如果大分块多, 剩下的所有处理单元就要等大分块完成才能进行下一帧, 由于所谓GPGPU单线程性能非常悲剧, 那么并行化得到的性能提升说不定是负的.
如果cuda直接把所有图像都8x8了, 那么的确无比快, 但是损失质量或者码率. 个人觉得anand的测试结果反映的就是这个问题, 和计算精度没啥关系.

完美的解决方案大概是基于波的编码, 这个可以轻松并行化, 没有分块直接把所有信息往多个波上投影就行了, 但是缺少一致性缓存的cuda明显会对显存造成很重的压力...

tency 发表于 2011-1-12 00:31

妹子还是软的好

chiman 发表于 2011-1-12 01:03

看来接下来字幕组要通通换电脑了

鸡蛋灌饼 发表于 2011-1-12 01:55

引用第28楼yibabilun于2011-01-11 22:52发表的:
具体科普一下算法吧..我不清楚具体细节.

我的意思是把时空块分到每个线程然后就这么算下去..我不是说分块和分时这个操作本身..我说这东西适合并行,是基于这样的观点:

压缩某个局域的时候和远处的数据如何没有什么关系.最多就是考虑到近邻的图像复杂度而对压缩率做一些修正.这样的假设下数据交换很少,并性最基本的需求,也就是尽量少的数据通信..之后才能谈用节点指标玩出各种花样代替分支或者展开循环..
....... images/back.gif

不要无视帧内预测和帧间预测
这两个活能并行是不假，但不是纯SIMD处理器能并行的好的……

简而言之对于一个纯SIMD处理器，稍微复杂点的活就各种不给力了。也难怪黄老板急着要ARM
再不弄ARM几年后就要被Intel的SuperComputing on Chip连底裤一块扒了……

引用第34楼chiman于2011-01-12 01:03发表的:
看来接下来字幕组要通通换电脑了 images/back.gif

没意义吧，追速度的第一波全是RMVB，别说换SnB，就算是Bridge Sandy也那个德行
后面的高质量压制又不急……

真要为了速度不顾一切，第一波直接上外挂肉。

xiaoyaowuming 发表于 2011-1-12 11:54

压RMVB的话 核心越多越给力 目前来看

丝塔戈依 发表于 2011-1-12 15:49

第一批新平台的本本已经开卖了，有人当小白鼠了么！

Microsoft 发表于 2011-1-12 18:12

为啥都没原图呢...
话说我竟然觉得SNB QUICKY比X86还好...幻觉么...
CUDA最渣看来毫无疑问
倒是...AMD貌似跟CPU比没效率上的提升啊...

belatedeffort 发表于 2011-1-12 21:01

引用第38楼Microsoft于2011-01-12 18:12发表的 :
为啥都没原图呢...
话说我竟然觉得SNB QUICKY比X86还好...幻觉么...
CUDA最渣看来毫无疑问
倒是...AMD貌似跟CPU比没效率上的提升啊... http://bbs.saraba1st.com/2b/images/back.gif

看上去QS压出的没x86那么锐利（当然也可能是我眼睛的问题）。不过据某些大大（具体是谁不记得了）说有时候看着比较舒服的柔和恰恰是质量没那么好的体现。
页: [1] 2
查看完整版本: Intel SNB处理器内置视频编码引擎与纯软件和GPU编码速度和品