我觉得吧，这段字不管是你拷贝粘贴的还是自己打的，你根本就是个一瓶子不满半瓶子逛荡的家伙。
....... images/back.gif
真正的实现上当然会尽可能的提升指令的并行性，单个核心里，多发射乱序执行已经是现在高性能处理器的基本结构了。
限制并行性的几点
第一，structure hazerd，一般只需要增加执行单元和下级pipeline就行了，比如常用的执行单元如ALU可以设置多份，位于不同的执行pipeline上，这样可以并行执行，提升效率。这个最简单，没什么好讨论的。关键在于平衡取指令和指令执行的吞吐量，比如当你的取值单元能够同时从cache上取得多条指令的时候，下级多发射就要适应取指令的效率，多了浪费资源，少了会造成发射队列的堵塞。流水线的设计就是让整体的吞吐量平衡。
第二，control harzerd，分支跳转指令带来的顺序，也就是你纠结的“不能先后执行”，这部分你看到教科书上的做法是通过branch prediction，书上会告诉你（事实上也是）预测的效率非常高，但是书上不会讲到，现在的RISC指令集的branch指令非常复杂，甚至有混编，branch prediction的挑战不是预测成功率，而是预测之后change flow的target address无法从指令中获取，如何保证在较低功耗的情况下，实现高准确率的target buffer是很大的挑战。
第三，data hazerd，数据真相关，这个是影响性能的关键，书上会讲到，通过forwarding，还有tomasulo算法等等，能够完美的解决这些问题。然而，实际的高性能处理器，流水线很深，里面有众多执行单元，如果按照书上的算法实现，就会有大量的数据forwarding通路和发射控制通路，对后端布线简直是噩梦，按照书上的做法，timing会一塌糊涂。因此各家现在有很多方法，在保证较大乱序发射窗口的情况下，避免下级流水线执行单元数据回馈。
后面两个问题，大家都有自己的技术解决，不过计算机体系结构发展这么多年，指令并行性技术上大的创新也很久没有看到了，以后多核是发展方向，单个核内也就这样了。
嘛～我的水平远没达到架构设计者的程度，但至少做的东西已经tape out很多了，每次看到自己的片子流出来还是小有成就感的。而且商业上的东西要考虑的因素很多，还是感觉不如以前同学学校里玩自由。
顶楼和书上讲的都是基本的问题，最终的实现会面临很多实际的困难～这些除非自己做，否则没有亲身体会。
PS：multi core的cache coherence部分的timing简直是屎一样，可以让你de到吐血
我一直是认为硬解码视频是一个专门的模块进行的，虽然对Neon指令集不是很了解，不过怎么看都是CPU加速而已，如果只是辅助CPU加速解码算法，那播放高码率视频必然还是要吃很高频率的。
记得以前翻资料时候看到过Galaxy S系列的硬解码模块芯片，实在想不起来叫啥... ...
哦翻到了，Galaxy S系列使用的硬解码模块叫VXD370，苹果3GS当时也用的和Galaxy S一样构架的处理器，只是经过苹果自己改造，硬解码模块也改成了VXD375。
记得当时苹果3GS官方对视频限制很大，但有人越狱用第三方软件测试1080P 30mbps High@4.1流畅播放，40mbps似会卡顿（记不清了）。
不知道那位能找到关于这个VXD370的相关资料。Galaxy S系各种马甲产品，还存在有的能放1080P有的不能放，不知道是不是C110、C111里面的VXD型号不同。
PowerVR VXD370 supports up to 1080i/1080p and 2048x1024 resolutions and may be configured to support either single streams or up to four multiple streams. The decoder supports the wide range of decode standards including: H.264 (to High Profile), WMV9 (to Main profile), VC1 (to Advanced profile), MPEG-2 (Main profile), MPEG-4 (to Advanced simple profile), and JPEG. VXD370 can be configured with any subset of these standards, enabling effective management of codec royalty costs.
Re:Re:回 44楼(无责任灰猫) 的帖子
引用第48楼无责任灰猫于2011-11-25 16:06发表的 Re:回 44楼(无责任灰猫) 的帖子 :G7X没用过，G80肯定是H.264硬解无误，CPU占用很明显，而且我确定不是CUDA加速。所以绝对不是一开始就提供了完整硬解。
....... images/back.gif
作为G80拥有者告诉你 G80对H264不是完全硬解 G84/G92/G94才有的
Re:Re:Re:回 44楼(无责任灰猫) 的帖子
引用第50楼RPG-7于2011-11-25 16:25发表的 Re:Re:回 44楼(无责任灰猫) 的帖子 :作为G80拥有者告诉你 G80对H264不是完全硬解 G84/G92/G94才有的 images/back.gif
观海同志，你暴露了
Re:Re:Re:Re:回 44楼(无责任灰猫) 的帖子
引用第51楼532于2011-11-25 16:29发表的 Re:Re:Re:回 44楼(无责任灰猫) 的帖子 :观海同志，你暴露了
images/back.gif
经过G80/G200/GF100的使用
我充分的体会了NV的坑爹，积累了经验而成长为一名成熟理智的玩家
告诫各位，用NV就是无尽的烦恼 感觉这文方向不错
Re:Re:Re:Re:Re:回 44楼(无责任灰猫) 的帖子
引用第52楼RPG-7于2011-11-25 16:32发表的 Re:Re:Re:Re:回 44楼(无责任灰猫) 的帖子 :经过G80/G200/GF100的使用
我充分的体会了NV的坑爹，积累了经验而成长为一名成熟理智的玩家
告诫各位，用NV就是无尽的烦恼 images/back.gif
人人都说NV好，第一次买NV的显卡就把我坑美了。。。。
当年PCI-E流行了，无奈自己机器是老式的AGP接口，又想体验DX9的半条命2，最后就买了6200A
买回来就悲剧了。。。一播放WMV视频就CPU100%，只能右键属性降低图形性能才行，驱动我时常关注，Y的就是没解决这个问题。。。
过了一年后至于解决没解决WMV加速的问题就不得而知了，因为显卡烧了。。。
我是经常看动画MAD啥的，之前一直用的64位宽ATI9600SE，刚换6200A时候就觉得播放视频不对，怎么视频这么灰白暗淡无色。。。
最后知道NV卡视频处理方面确实比ATI差，至于视频解码发展到现在了，我想应该没啥差距了吧，但还是看人贴图对比有明显差距。 最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
dsp不是硬件设备吗？难道硬件造好了，还可以自己编程支持硬解格式吗？ 引用第56楼chronicle于2011-11-25 23:48发表的:
最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
....... images/back.gif
现在只要不是用通用运算指令解码的都被宣传为“硬解”了，所以嘛........... 引用第56楼chronicle于2011-11-25 23:48发表的:
最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
....... images/back.gif
现在只要不是用cpu里面的通用运算指令来解码的都被宣传为“硬解”了
Re:Re:Re:Re:Re:Re:回 44楼(无责任灰猫) 的帖子
引用第55楼liaojings1于2011-11-25 18:01发表的 Re:Re:Re:Re:Re:回 44楼(无责任灰猫) 的帖子 :人人都说NV好，第一次买NV的显卡就把我坑美了。。。。
当年PCI-E流行了，无奈自己机器是老式的AGP接口，又想体验DX9的半条命2，最后就买了6200A
买回来就悲剧了。。。一播放WMV视频就CPU100%，只能右键属性降低图形性能才行，驱动我时常关注，Y的就是没解决这个问题。。。
过了一年后至于解决没解决WMV加速的问题就不得而知了，因为显卡烧了。。。
....... images/back.gif
自从NV在驱动里头加入手动选择Level的选项以后N卡视频方面就一直比A卡好，而且是绝大多数的方面都有比较明显的优势，唯一不爽的是高性能卡可能搭载的是老版的VP，低端马甲卡没有性价比可言，性能甚至无法满足多媒体应用
我没用过最新的A卡，但是我可以负责任的说4系列的A卡是渣
引用第56楼chronicle于2011-11-25 23:48发表的:
最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
....... images/back.gif
很多人认为系统播放器能解码的就叫硬解 引用第30楼dennisyy于2011-11-24 19:14发表的:
其实我觉得真正的硬解应该是像mp3解码芯片那样的，专用ASIC电路
其它的都是将算法转换成指令，区别就是指令专门对这种算法加速多少
比如我最近手头上设计的这个CPU，乘法可以有三种配置，最慢的32个周期，最快的1个周期
慢配置下，做解码性能肯定不行，性能偏向于“软解”，快配置下，就是所谓的“硬解”性能了 images/back.gif
这种东西现在很难找到了
不说罕见的，现在的GPU连blit都是走shader了……
引用第34楼moonite于2011-11-24 20:02发表的 Re:回 13楼(hhtrivial) 的帖子 :
原来android能支持baseline以上？刚好在做的几个平台的流媒体视频项目，看了开发文档android写的是baseline - http://developer.android.com/guide/appendix/media-formats.html，试了下hero就算是baseline如果ref>6就必死，wp7和ios因为本身硬件有要求比较好调，但是因为android的关系要降低压制参数 images/back.gif
baseline及以下的参数战斗力太差了
CABAC都没有
引用第56楼chronicle于2011-11-25 23:48发表的:
最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
....... images/back.gif
DSP是可编程的
不然你以为书记SB Live为啥能战（近）10年…… 引用第56楼chronicle于2011-11-25 23:48发表的:
最近刷电信的c8650
看了几个非官方rom，居然说支持硬解rmvb，而非官方rom却不支持硬解rmvb。
有大大解说一下吗。
....... images/back.gif
你可以理解为硬件部分加速，举个例子（当然只是示例说明下大概的量级，并不太准确，因为乘累加已经是很多CPU的基本指令了，而且实际的编解码算法操作也完全不同）
比如某种视频解码算法，每次的运算是：
OUT = ((A*B+C)*D+E)*F+G
假设一个没有乘法指令的CPU要执行这个算法，一般会
1.程序会写一个循环，不停的移位，然后做加法，实现A*B
2.结果加C
3.重复上面的完成后面的乘法和加法
没有硬件乘法的CPU执行第一步，需要执行几十条指令，优化乘法算法之后会好一些，但还是很慢。
你可以理解这种方式是所谓最慢的“软解”
假设某个CPU内部加了多媒体加速单元，里面的乘法器可以执行乘法指令，则
1.直接算A*B
2.结果加C
3.重复上面的完成后面的乘法和加法
假设这条是单周期乘法，第一步只需要一条指令一个时钟周期，那么这个示例算法就比第一种快一个数量级了
再假设，有一个DSP，支持乘累加指令，可以直接算A*B+C这种操作
1.直接算A*B+C
2.重复上面的完成后面的乘累加
可以看到，用这种方式，只需要三条指令就能做完示例算法，比上面只有乘法的方法快一倍
再假设，有一个硬件电路，能够直接接受ABCDEFG输入，一步算出OUT = ((A*B+C)*D+E)*F+G
1.算出结果，然后，没有然后了
这种方式是最快的，这个是理论上的硬件解码
之前说了，理论上的硬件解码速度快，面积和功耗成本也最少，可是灵活性太差
如果某一天，一种新的编码诞生了，需要算OUT = (A*B+C)*(D*E+F)+G
对于DSP来说，只需要换一下指令的源操作数，还是可以通过三条成累加实现，但上述最后一种方法的硬件电路就废了
引用第60楼鸡蛋灌饼于2011-11-26 00:59发表的:
这种东西现在很难找到了
不说罕见的，现在的GPU连blit都是走shader了…… images/back.gif
因为我是做CPU的所以不太懂ASIC方面的应用，不过我认为不是任何的应用都需要个人设备一样的灵活性
（后面都是作为外行乱想的，欢迎探讨或者开喷）
在某些场合下，ASIC的编解码芯片还是有市场的，工业的摄像头、医用的影像检查设备啊
这些应用应该对实时性（也就是速度）要求很高，编解码慢了画面卡一卡出个马赛克什么的不允许（“对不起，太太，您怀的是一个...呃，机器卡了。小王！过来帮我把后台愤怒的小鸟杀了！”）
而且一旦做成产品，编码解码格式算法也不会三天两头升个级，需要的是稳定性（“都可以升级了谁买新产品啊，掀桌”）
所以这些应用的视频编解码方面用硬件ASIC比较合适，速度快成本低～ 引用第61楼dennisyy于2011-11-26 09:07发表的:
因为我是做CPU的所以不太懂ASIC方面的应用，不过我认为不是任何的应用都需要个人设备一样的灵活性
（后面都是作为外行乱想的，欢迎探讨或者开喷）
在某些场合下，ASIC的编解码芯片还是有市场的，工业的摄像头、医用的影像检查设备啊
....... images/back.gif
那么dsp到底是什么层面的东西？
软件层面？硬件层面？
我们现在手机上所谓的硬解到底是你说的三种假设中得哪一种？ 硬解不就和3d 加速一回事么
比如某算法必用一个函数foo，cpu的做法是用一系列指令实现，而加速芯片的做法是把这个函数直接做硬件里
速度上加速芯片要比cpu 快，但如果算法有什么变动，cpu还可以运行而加速芯片就吃鳖了 引用第61楼dennisyy于2011-11-26 09:07发表的:
因为我是做CPU的所以不太懂ASIC方面的应用，不过我认为不是任何的应用都需要个人设备一样的灵活性
（后面都是作为外行乱想的，欢迎探讨或者开喷）
在某些场合下，ASIC的编解码芯片还是有市场的，工业的摄像头、医用的影像检查设备啊
....... images/back.gif
做个（相对）通用的片子出来然后靠它的可编程性来实现各种功能是更经济的选择，因为这样开发难度会降低
不说远的，你可以试着用VHDL/Verilog写个全硬件的AES加密/解密芯片，然后再对比下C程序……
引用第63楼精钢魔像于2011-11-26 11:52发表的:
硬解不就和3d 加速一回事么
比如某算法必用一个函数foo，cpu的做法是用一系列指令实现，而加速芯片的做法是把这个函数直接做硬件里
速度上加速芯片要比cpu 快，但如果算法有什么变动，cpu还可以运行而加速芯片就吃鳖了
images/back.gif
后面没错，前面的……
现在的“3D加速”已经有一大半不归硬件管了
回 60楼(鸡蛋灌饼) 的帖子
因为android平台的硬件没一个标准底线（现在才知道），所以为了兼容性只能用baseline。一开始我是看了那文档，以为android平台的硬件标准是至少能完全支持baseline的（ref1-16也在baseline标准内），但是实际上却不是硬性规定的样子（ref>6在hero上播不了） 引用第62楼chronicle于2011-11-26 11:13发表的:
么dsp到底是什么层面的东西？
....... images/back.gif
SOC层面上的任何一件事情，都需要做到软硬件配合
硬件上选择性能合适成本合适的DSP<-这里的P指的是processor，是一个处理器，有自己的指令集
软件上，把常用的解码算法程序，编译成DSP支持的指令，并优化得到最好的性能和code density（高端应用不太关注后者）
这样就可以发挥出“硬解”的真正性能了
我们手机上说的硬解，应该是中间两种
1.ARM/MIPS在CPU里面附带多媒体加速单元，或协处理器
这个比较典型的就是arm v7架构里面的neon，能够支持高级SIMD和浮点运算指令（选配的，tegra2就没有）
或者
2.TI/NV/高通等等厂商在做soc的时候，集成的GPU或者DSP或者其它什么多媒体加速单元
支持通用的或者各家自己的指令集或者接口 引用第64楼鸡蛋灌饼于2011-11-26 12:26发表的:
后面没错，前面的……
现在的“3D加速”已经有一大半不归硬件管了 images/back.gif
这倒是，主要是现在片子都卖的太便宜了，自己做或者找design service去custom，量不大的话成本上没有任何优势
对于soc实现来说，平台和系统的可重用性也是很重要的一个考量
话说旁边一个team前段时间还在做AES的指令加速呢，具体我们这边也不了解 引用第60楼鸡蛋灌饼于2011-11-26 00:59发表的:
DSP是可编程的
不然你以为书记SB Live为啥能战（近）10年…… images/back.gif
也就是说其实可以通过后期的编程让机子支持某些原本不支持的格式硬解？
还是说其实dsp本身的硬件构造已经在一定程度上限制了这种软件编写的拓展性？所以后期的编程不是万能的 引用第68楼chronicle于2011-11-26 15:46发表的 :
也就是说其实可以通过后期的编程让机子支持某些原本不支持的格式硬解？
还是说其实dsp本身的硬件构造已经在一定程度上限制了这种软件编写的拓展性？所以后期的编程不是万能的
images/back.gif
两者都有可能，关键看DSP
如果DSP的指令集是图灵完全的那理论上你甚至可以在上面跑个OS——不过这还叫毛DSP啊
现实情况估计在两者之间：DSP的能力有一定限制，但依然高于视频解码所需要的能力
页:
1
[2]