原文:https://juejin.cn/post/6844904132864655367

GPU架构杂乱备忘——IMR、TBR、TBDR

之前觉得涉及到gpu架构相关的问题只需要知道个大概就好,毕竟在图形api的层面上应该把硬件的细节给隐蔽掉,gpu的架构千千万万,每家厂商每个型号都不一样,开发者没必要掉进这个细节里面。但是最近重看Metal,特别是2.0之后新增的功能,逐渐深刻意识到一个事实——图形api已经迎来了真正的第三代。当然DX12、Vulkan和Metal在诞生时就打出了“现代图形api”的旗号,与传统api划出界限,我也只算是后知后觉。这些现代图形api的一个特点就是开放更多操纵硬件的细节,全权交给开发者来定夺。不过真正让我觉得有必要深入了解一下gpu架构的原因却是Metal在面对桌面级gpu和移动级gpu给出了差异相当大的两套api,这也让桌面端和移动端的图形编程变得截然不同。

桌面级gpu架构——IMR(Immediate Mode Rendering)

IMR就是我们普遍熟悉和使用的gpu架构,以n卡为例从Tesla发展到Turing依旧还是IMR架构。这种架构也和之前的图形api与渲染管线天然契合。每一个绘图的指令来到显卡,显卡便立即执行,从头到尾跑完整个管线,最终将结果输入到Frame Buffer中。但是这种架构有一个问题,在开启深度测试后,每个fragment的输出都要和Depth Buffer中的深度值进行深度测试,如果通过测试则需要更新Depth Buffer和Frame Buffer。这个过程包括了对System Memory的一次读取和两次写入,而fragment的数量巨大,这样就带来了很大的访问System Memory的压力。而IMR的解决办法则是给gpu配备足够大缓存和足够大的带宽。不过代价却是显卡为了容纳下更多缓存使得主板越来越大,并且频繁大量的带宽访问造成巨大的耗电与发热而不得不增加单独的风扇。这些代价在桌面电脑上尚能接受,可到了移动端就变成了洪水猛兽。无论是物理空间还是耗电对于移动设备来说都弥足珍贵,也因此不得不推出一种全新的gpu架构

移动级gpu架构——TBR(Tile Based Rendering)

TBR架构在gpu很近的位置增加了一片高速缓存,通常被称为Tile Memory(图中也叫On-Chip Buffer)。受限于成本、耗电等原因这块缓存不会很大,大概几十k这个量级。首先整个屏幕的画面会被分割成无数个小块,被称为tile,通常32*32大小,这样Tile Memory中足够容纳得下这个tile的相关数据。当一个绘图指令抵达显卡时,不在像IMR一样立即完成渲染,而是将通过vertex shader和裁剪后的顶点数据,根据所在tile进行分组,并将分组后数据存储到System Memory中,这块缓存也被称为Parameter Buffer (PB, 图中Primitive List和Vertex Data),然后处理下一个绘制指令。当所有绘制指令的顶点数据都做好处理存进PB或是PB达到一定容量之后才开始进行管线的下一步,即显卡会以tile为单位从PB中取回相应的顶点数据,进行光栅化、fragment shader以及逐片元处理。原本在逐片元处理中需要频繁的访问System Memory变为代价极低的对Tile Memory的访问。直到这个tile的frament将数据全部更新到Tile Memory上之后,再将该Tile Memory中的数据写回System Memory,然后执行下一个tile的处理。相比于imr零碎的大量的不可估计的对于System Memory的读写操作,TBR中变为了有限的(和tile数量一致)整块的写操作。虽然PB也在System Memory上,但是对于PB的访问是顶点数量级的(显然vertex要远小于fragment)且数据会经过特殊的压缩处理,所以这个置换依旧值当。

不过这种架构也带来了一些问题,因为渲染管线会在中途中断,这就导致在这时切换Frame Buffer变得异常麻烦。TBR的做法是会将缓存的渲染数据全部强制绘制,绘制完毕后再些换到新的Frame Buffer,这无形中就增加Tile Memory和System Memory之间数据的拷贝。也因此在移动设备上切换Frame Buffer的使用要十分慎重。但从另一方面来看那些渲染数据并没有立刻渲染,而是缓存了起来,这也带来了很大的优化空间。

更强的移动级gpu架构——TBDR(Tile Based Deferred Rendering)

将TBDR放在这里可能会造成一种误解,认为TBDR是TBR的升级版。事实上,TBDR的是Imagination公司所独有的一种移动级gpu架构,被广泛应用于旗下PowerVR等产品中。由于其相比同时期其他TBR架构的显著优势受到苹果公司的青睐,而被搭载到iphone上。近几年iphone已经开始使用完全自研的A系列处理器也依旧是延续着TBDR架构。TBDR的优势在于利用PB中缓存的顶点数据,提前对流入到管线剩余部分的片段进行了筛选,来解决传统渲染管线的一个老大难问题——过度绘制(over draw),而实现这一步的关键就在于HSR(Hidden Surface Removal)技术。

如上图所示Image Synthesis Processor (ISP)从PB中逐图元的取回当前tile的顶点数据(只有顶点数据),ISP会对数据进行差值并对差值得到的片元数据计算深度,并进行深度和模板测试。如果通过测试,则更新片上的深度和模板缓存,同时在tag buffer中记录该片元的图元id。当一个tile的所有图元都经过ISP的处理后,tag buffer中便会得到每个像素所对应的唯一可见的图元id。然后对这些可见的图元,以图元为单位从PB中取回顶点之外的其他varying数据(比如uv之类)通过TSPF进行差值,然后传给fragment shader。这也解释了TBDR总流程图中vertex data的两条分支,*1代表流入ISP的顶点数据,*2代表流出TSPF的其他数据。

TBDR也有一些弊端,比如那些在fragment shader中会丢弃的片元(alpha 测试)无法再fragment shader之前直到其是否需要绘制,因此对于这些片元需要通过上图中的GCS提前提交给fragment shader并计算出确切深度后返回给ISP,这个过程阻塞掉其他片元的计算,因此是一种比较昂贵的代价。另外对于半透明物体(alpha混合)由于一个片元的颜色不仅由最近片元决定,所以此时会强制绘制缓存的片元,这样便也增加了Tile Memory和System Memory之间的拷贝。因此应该将物体分组,先开启深度测试绘制非透明物体,再关闭深度测试绘制透明物体。

虽说HSR这种技术被Imagination申请了专利,并且在狭义上只有应用了HSR技术的显卡在能叫TBDR。但其他厂商也有自己针对TBR架构的优化,比如Arm的Forward Pixel Kill和骁龙的Flex Render都在力图减少过度绘制。同时在软件层面也有被称为TBD(Tile Based Deferred Shading)的着色管线,不过这和TBDR完全是两个层级的概念。

再看IMR、TBR和TBDR

IMR和TBR因为这块Tile Memory带来了完全不同的渲染流程,有些原本适用的法则,在移动端上则完全不一样。除了上面提到过的切换FBO,alpha测试以及alpha混合等问题。比如在IMR上,每一帧clear是完全不必要的,因为整个屏幕都会被重新绘制而覆盖掉上一帧的内容。但对TBR来说每一帧不clear则以为着需要在每一个tile开始的时候将上一帧的数据拷贝到Tile Memory中,为防止这种完全没必要的拷贝所以在TBR上需要每帧clear。如果考虑到TBR中Tile Memory的宝贵以及访问System Memory的难度,纹理采样也变成了一种昂贵的操作。纹理数据是存储在System Memory上,少量近期访问过的纹理会缓存在Tile Memory中,因此使用压缩纹理可以让有限的Tile Memory缓存更多的纹理数据,同时LUT(Look-Up Table)这种不符合空间局部性的纹理数据会大幅降低缓存命中应该少用。

TBR这样一种为了适合移动端种种限制而不得不诞生一种“妥协”的架构,虽有上述的种种限制,但却也带了意想不到威力。这块神奇的Tile Memory不仅带来了可以忽略的读写成本,也为渲染管线提供了一块临时的缓存。这块缓存的意义就在于,原本多个pass才能完成的渲染流程变成一个pass就可以。为了实现这种优化,在Metal 2.0中提供ImageBlock和Tile Shader等技术,允许开发者对Tile Memory上的数据进行编程,这也让移动端和桌面端渲染管线的实现有了极大的不同

GPU架构杂乱备忘——IMR、TBR、TBDR相关推荐

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

    移动GPU渲染原理的流派--IMR.TBR及TBDR 移动GPU相对桌面级的GPU只能算是未长大的小孩子,虽然小孩子在某些场合也能比成人更有优势(比如杂技.柔术之类的表演),但在力量上还是有先天的差别 ...

  2. 底层进阶 | 移动端 GPU 架构 -- TBR 模型

    在知乎上关注了好多图形学大佬,感觉现在知乎的技术氛围要比掘金推荐旧文好多了,经常会推送感兴趣的领域内容,而且还可以和作者私信交流. 这段时间看到有大佬分享 GPU 架构相关的内容,做图像渲染的还是要懂 ...

  3. aws 认证_AWS ML专业认证备忘单

    aws 认证 the highly important and carefully crafted piece, * this will only be useful after completing ...

  4. 备忘: VC++ 自动适用编译两种模式库文件 (DLL, LIB)

    为什么80%的码农都做不了架构师?>>>    一个好的程序设计规划总会有属于自己的基础代码库.重用这些代码库,DLL或LIB方式最好的选择之一.在写新的项目或程序是,我们不可能每次 ...

  5. 为什么ui框架设计成单线程_评估UI设计的备忘单

    为什么ui框架设计成单线程 Whether you're evaluating your design proposals or giving feedback to a colleague duri ...

  6. vf更改当前路径_这份 window.location 备忘单,让你更有条理解决地址路径问题!...

    如果你想获取站点的URL信息,那么window.location对象什么很适合你!使用其属性获取有关当前页面地址的信息,或使用其方法进行某些页面重定向或刷新? https://segmentfault ...

  7. element-ui 网格_UI备忘单:列表与网格

    element-ui 网格 重点 (Top highlight) Grids or lists? That is the question we will look at in this cheat ...

  8. 对 zebra 的一点理解 thread+socket+read部分 (备忘)

    一.主要从 daemon 的 thread角度 分析备忘. 注意: 具体函数功能详见附录,分析要结合zebra源代码(thread.c中). 1.每个daemon(e.g igmp-snooping. ...

  9. 【智能车】上海交通大学AuTop战队开源算法提纲备忘

    写在前面 本文是作者在学习上海交通大学AuTop战队开源算法时列的提纲备忘,并做了很多资料的链接,像是一个目录,分享给大家一起学习, 如有侵权,联系删除: 参考:https://github.com/ ...

最新文章

  1. 在ubuntu下设置eclipse开发STM32等嵌入式设备
  2. window7/10 安装Tomcat
  3. yii2 gradview 输出当前时间和图片
  4. DBSCAN密度聚类
  5. wordList01
  6. kotlin实现继承_Kotlin程序| 继承的例子
  7. 【C++ Primer | 08】课后习题答案
  8. 吞噬星空怎么会有鸿蒙,论吞噬星空与鸿蒙的关系
  9. 4月第一个惊喜:iPhone 9现已直接上架苹果中国官网?
  10. BP神经网络——从二次代价函数(Quadratic cost)到交叉熵(cross-entropy cost)代价函数
  11. 帛书《要》篇“夫子老而好易”章
  12. 企业中常见的杀毒软件
  13. 【中间件技术】第一部分 概述(1) 软件构件与中间件基本概念
  14. 汇编语言程序vs. 汇编程序
  15. Python数据预处理--文本特征提取(以Jieba工具包为例)
  16. gst 笔记1:信号、消息、事件、状态
  17. 100本名著浓缩而成的100句话
  18. Ubuntu16.04下xbrowser远程图形化桌面配置(简单几步完成~)
  19. 【元器件】电容选型指南
  20. git本地用户配置,及邮箱配置

热门文章

  1. 开怀大笑有助于使心中的郁闷情绪得到疏导
  2. CCNA 640-802,CCENT和CCNP练习题库LMI的自动检测,转换,以及更多!
  3. Spark1.x升级Spark2.x常见异常【map】
  4. 2021-2027全球与中国镍钛合金医疗器械市场现状及未来发展趋势
  5. 组队学习-动手学数据分析-第二章第2、3节
  6. HSI、HSV、RGB、CMYK、HSL、HSB、Ycc、XYZ、Lab、YUV颜色模型的区别
  7. Simplicity Studio开发环境安装
  8. Cimplicity 国内知名汽车厂设备监控PMC系统
  9. Linux下的power_supply小析
  10. 面试官:说一下你们线上JVM是如何优化的?一不小心聊了2个小时!!