zoukankan      html  css  js  c++  java
  • 移动GPU渲染原理的流派——IMR、TBR及TBDR

      移动GPU渲染原理的流派——IMR、TBR及TBDR

      移动GPU相对桌面级的GPU仅仅能算是未长大的小孩子,尽管小孩子在某些场合也能比成人更有优势(比方杂技、柔术之类的表演)。但在力量上还是有先天的区别,主要表如今理论性能和带宽上。

      与桌面GPU动辄256bit甚至384bit的位宽、1.2-1.5GHz的高频显存相比。移动GPU不仅要和CPU共享内存带宽,并且普遍使用的是双32bit位宽、LPDDR2-800或1066左右的内存系统。总带宽普遍在10GB/s以内。悲催的Tegra 3使用的还是单通道内存模式,搭配DDR3L的带宽只是6.4GB/s。


    眼下GPU性能最强大的iPad 4带宽也只是17GB/s(图片源于Anandtech)

      移动处理器中内存带宽最高的是iPad 3/4。由于他们使用Retina屏幕。2048x1536的高分辨率对GPU带宽要求更高,只是就算是这两款产品,17GB/s的带宽与PC显卡上动辄200GB/s以上的带宽相比还是小儿科了。

      没有高带宽就没有大容量纹理数据,也就不会有高画质。虽然带宽不是制约移动GPU发展的唯一因素。可是在眼下的限制下。移动GPU厂商关心的头等大事就是怎样在尽可能小的带宽需求下提升GPU性能及画质,前面介绍的纹理压缩是一个方法,另一种就是使用不同的渲染方式。主要有IMR、TBR及TBDR等。

    伤不起的“马上渲染模式”——IMR

      IMR(Immediate Mode Rendering)就如字面意思一样——提交的每一个渲染要求都会马上開始,这是一种简单而又粗暴的思路。长处缺点都非常明显。假设不用为性能担忧,这样的方式会非常省事。可是IMR的渲染实行的是无区别对待,那些遮蔽处理的部分依旧会被渲染处理器。这也导致无意义的读写操作很多其它。浪费了大量性能和带宽。

      总之,IMR这样的渲染方式在移动GPU上的评价仅仅能是“负分,滚粗!

    ”。

    变聪明了的“贴图渲染”——TBR

      IMR傻大粗的做法不可取,那就来一个聪明点的方式——TBR(Tile Based Rendering,贴图渲染),它将须要渲染的画面分成一个个的区块(tile),每一个区块的坐标通过中间缓冲器以列表形式保存在系统内存中。

    这样的渲染方式的优点就是相对IMR降低了不必要的渲染任务。缺点就是遮蔽碎片依旧会少量存在,并且须要中间缓冲器。


    TBR渲染将游戏画面分为不同的区块

    再次进化的渲染方式登场——TBDR

      TBR尽管比IMR聪明多了。只是还是存在不少缺陷,TBDR(Tile Based Deferred Rendering,贴图延迟渲染)闪亮登场,它跟TBR原理相似,可是使用的是延迟渲染(Deferred Rendering),合并了完美像素。通过HSR(Hidden Surface Removal,隐藏面消除)等进一步降低了不须要渲染的过程,降低了带宽需求。实际上这些改变和PC上的渲染有些相似。


    TBDR渲染的一个关键是延迟渲染

      其它几家厂商用的都是TBR技术,TBDR主要是Imagination在使用,这也是他们最大的筹码之中的一个。

      在微软的DX11.1升级中也有提到支持TBDR,由于Windows 8系统还专门为平板和触控优化,对TBDR这样的移动平台经常使用的技术加以优化也是必定的。

  • 相关阅读:
    在线思维导图、UML
    SpringBoot定时任务
    SpringBoot邮件发送
    SpringBoot执行异步任务
    banner.txt
    SpringBoot Swagger3.0配置
    SpringBoot durid监控配置
    SpringBoot使用Shiro
    页面LOADING效果
    vue 阻止el-radio事件冒泡
  • 原文地址:https://www.cnblogs.com/slgkaifa/p/6881803.html
Copyright © 2011-2022 走看看