半肾
精华
|
战斗力 鹅
|
回帖 0
注册时间 2004-7-14
|
本帖最后由 HJYtm 于 2013-12-20 15:00 编辑
https://www.youtube.com/watch?v=QIWyf8Hyjbg&hd=1
有条件的可以看链接英文解说，我稍微翻译一下发布会的状况
该发布会由AMD赞助的Oxide开发商解说
先科普一下Batch：以下单独的发送到GPU执行的指令（复数batches=指令数量）
模型、特效、粒子、GPU运算
Batch类似于函数调用（该调用速度为每帧需要CPU的十万分之一秒，但相对来说在GPU上会慢一些）
（渲染前提：四核八线程 ~10k units,~50k batches）游戏帧渲染延迟的比较
没有MANLTE的：
条件1 6个添加的驱动进程（3个活动驱动进程的情况下） 结果：大于约99ms CPU执行延迟+0ms GPU执行延迟=至少大于99ms帧产生时间
条件2 使用了递延上下文功能 6个添加的驱动进程（5个活动驱动进程的情况下） 结果：大于约99ms CPU执行延迟+0ms GPU执行延迟=至少大于99ms帧产生时间（仍然和不使用该功能一样无法调用机能提高帧时）
有了MANLTE的：
条件：无需任何驱动进程 结果：约18ms CPU执行延迟+约15ms GPU等待=每帧约33ms
而6核12线程条件下以上的33ms延迟结果不变下能达到~80k batches
从前开发优化PC驱动的常见情况：
就像一个大的黑箱子，完全不清楚什么造成了性能的开销 得到的情况是陷入追踪和出错
驱动进程和游戏进程常常冲突
常见情况的从前解决方法（用来查出出错和原因的王道方法）：
组织美术资源最小化场景的改变
让游戏摄像机弄的更接近游戏物体
缩减游戏的物体数量
返回到之前用过的进程总数
因此对于奇特的游戏常常会很难调用到有限的GPU资源（个人估计就是雷条那种情况了）
从前开发PC的种种难题：
美工们干活做东西需要为驱动优化一辈子直到做完
美工们不管恰不恰当都需要把物体打包放入同样的材质里
美工们得优化batch数（防止帧延迟问题导致太慢）
设计师得限制自己的设计情况纯粹是因为batch数会导致帧延迟出错，比方：
限制1：设计师只能达到想要20个军队，每个军队100个单位，组成四个阵营，并且做出影子和水面反射
限制2：视角没法缩放到整体地图让人一目了然
从前开发游戏时的各种就像邦迪创可贴一样的优化建议：
不捆绑材质：该建议会使得材质变成全局化、着色器逻辑更复杂、材质管理更复杂、并且材质通常此时已经被美工群组捆绑了
几何实例化：该建议需要优化最快的调用种类、序列化引擎并且提高开发费用
物体打包化
递延上下文：该建议常常会导致失败、最小化测量得到的收益
从前的优化环境导致游戏的劣化情况：
使得用户体验被严重限制，游戏设计师对于这些问题束手无力
增加开发费用并且严重影响开发者脑力
游戏可以开发的种类受到严重限制
PC硬件环境的Batch的性能限制已经达到了危机情况
何时出现从前开发PC游戏产生该问题的危机？
多核CPU成为了主流的时候（从单核性能瓶颈开始）
PC新显卡的主流FLOPS数不断提高都接近了多核CPU主流时的400~500%了，然而每帧的Batch数却仍然低下只有从前的一倍不到
什么导致了驱动问题受制约？
API没有正确对应硬件的容量
对于应用程序来说缺少能力来合理的管理GPU的内存
要求驱动去追踪并处理发生的灾害
驱动和API为了共存只能限制整个内核的扩展性
API没法和硬件一起进化
解决方案怎么办？
要比家用机制约更少，并且不能让开发者们花太多功夫导致费用过高懒得搞
要比硬件具体本身看的更远更能挖掘硬件的性能潜力
要让挖掘了性能后的PC游戏硬件下跑的就像家用机一样流畅
要满足开发者多年来期盼的低层解决方案
这是MANTLE带来的解决方案：
GPU的构架更稳定、不同版本间产生的波动更少
数据种类更标准化，GPU和CPU共享多种数据格式：Long term trend、GPU/CPU converge（汇合）
GPU成为了通用计算设备，几乎只会受到硬件规格的限制
Unified Memory（统一内存）的到来
深入MANTLE：
按照设计师想做的做出来：不需要缩减内容得到更多的游戏感受
让开发者们相互信任，不需要在程序和驱动之间踢皮球，因为驱动变的更利索了
硬件规格的性能虽然不会改变，但是内存（显存）和命令数的危机问题被解决了
所有高性能引擎的利用、所有家用机引擎的移植、驱动故障导致的性能稳定性骤减问题，都需要MANTLE来彻底优化
MANTLE API解剖：
GPU作为处理器执行（着色器）程序，每个程序都有进出口
API不需要提供进出口来给GPU来执行着色器程序
没有多余的CPU性能被浪费，并且无需占用和参与CPU进程
对于Nitrous这款演示游戏，运行MANTLE的前提条件：
对于主流游戏引擎来说，MANTLE不贵也不困难
只需要2个人仅数月工作来支持：在最小化样本代码的预测试版MANTLE中，该游戏就可以使用所有的机能来展示物件和性能，比如UAVs、原子介绍、计算着色器、GPU通用计算指令等等
对引擎来说只有很少的改变
引擎代码数量只从原先的3500行增加到了4500行
对于开发商来说支持MANTLE意味着：
极小代价获得高Batch处理能力
开创了各种游戏种类的开发途径
新的渲染和游戏技术
稳定性和优化的维护时间缩短
超高的性能增加即使MANTLE的更多特性还没有被使用
而且跑的更快
MANTLE的商业案例前景：
便宜的获得支持，可和其他API同时使用，减少数年的开发费用，极大的扩大客户市场、推向产业发展
支持了MANTLE的同时得到了：
程序更灵敏
更多特效
解锁了高端GPU性能
有了适合的GPU后只需要中端CPU性能即可满足游戏需求
CPU核心数越多会导致CPU游戏性能的叠加，不用再去在乎CPU的单核性能了
游戏的结果是：
API导致的瓶颈至少降低了10多倍
CPU多核心数支持比之前更好，同时多核要比之前跑的更顺畅
部分游戏的部分条件下比之前跑的快3倍
彻底改变了单核性能越高游戏速度越快的老规则
CPU测试中8核心的8350FX跑的和价格贵一倍的I7 4770K游戏速度上差不多成绩
在290显卡上，即使8350FX被限制在2.0Ghz频率下，GPU仍然没有被CPU制约性能
MANTLE一路向前：
可以被做成功
100K以上的Batch数量成为了现实，CPU发展可以堆核心数而不是主频
目前的演示只是个开始
2015年目标达到300K的Batch数量
2018年目标要达到100W的Batch数量
GPU和CPU开始相互呼应相互调用
在非多媒体应用程序中GPU可以成为协处理器 |
|
沪公网安备 31010702007642号 )
发表于 2013-12-20 02:35
