RDNA4目前几乎已经可以确定的一项改进是TBIMR的引入。那么这个东西到底是什么呢？
TBIMR最强大的地方就是节约带宽，使得新一代GPU靠更小的带宽可以追上上一代更高带宽GPU的性能。
64CU 256bit 打96CU 384bit，看起来根本没得打。但是N31存在严重带宽瓶颈，那96个CU是处于非常“饥饿”的状态的。Navi31的带宽问题，可以参考ATI吧大佬求秒帝的架构分析
https://tieba.baidu.com/p/8612042957?pid=148638248103&cid=0#148638248103
通俗的说法就是，64个吃饱饭的人，打96个饥肠辘辘没有力气的人，还真有一战之力。

要讲TBIMR，那首先要讲什么是IMR。IMR全称叫Immediate Mode Rendering，直译为实时模式渲染。这就是以前大部分PC上的GPU最传统的渲染方式。这里说的渲染，你其实可以直接理解为光栅化（下文都是如此），光栅化是图形流水线里承前启后的一段，它把那些带有坐标的顶点构成的多边形，转变成一个一个像素输出到屏幕。

IMR是全屏绘制的，需要构建一个全屏幕的帧缓冲区（framebuffer），这个缓冲区所需的内存非常大，一般有几十MB的数量级，分辨率越高，这个缓冲区越大。很容易看出，这么大的东西在以前根本没办法放在GPU的缓存里，只能把这么大的东西先存入显存。传输的过程中就消耗了相当多的带宽。
而且光栅化之后图形流水线还没结束，还要对像素进行着色、深度测试、模板交互。由于你的帧缓冲区是放在显存上的，那这个过程就意味着需要不断对显存上的数据进行读写存取，这也会大量消耗带宽。
优化的方式也有很多种，比如增大L1/L2/L3，比如RDNA2、ADA LOVELACE都引入了巨大的LLC（last level cache）。但是，这是治标不治本的。
在过去，只有电脑GPU采用IMR这种渲染方式，因为电脑GPU可以造的很大，不缺带宽（理论上讲），很适合处理这种巨量的信息。
但那是以前，现在由于工艺价格越来越昂贵，每晶体管价格从14nm工艺之后就几乎不再降低了，所以芯片的面积现在可以说寸土寸金。在过去用大核心打小核心，其实没那么吃亏，比如08年时，核心面积576mm²的GTX260，打核心面积256mm²的HD4870，看起来亏得妈都不认识了，但由于那时候工艺没那么贵，所以其实也并没有那么吃亏，09年初GTX260甚至杀到了1299的价格，放在今天一个570多面积的GPU卖1299白菜价（考虑物价因素也就相当于今天的4000 5000），简直是天方夜谭，因为一个380mm²的5080现在价格是10000+。

由于GPU上显存控制器占据相当庞大的面积，如果能节约带宽，如果能把过去384bit的GPU，做成256bit，那就是节约了巨大的面积，也节约了巨大的成本。怎么降低位宽，还不影响性能呢？那就只有减少带宽的消耗。除了引入LLC，还有个办法就是引入TBIMR。
上面已经讲了IMR，而TBR，tile-based rendering就是现在移动设备所采用的渲染方式。其核心思想是：将帧缓冲分割为一小块一小块，然后逐块进行渲染。刚才不是说全屏绘制需要构建一个全屏幕的帧缓冲区？现在我把全屏幕的帧缓冲区切割成一小块一小块的了，之前GPU的缓存根本放不下那么大的数据，切割成一小块之后，就能放进去了。不难看出，TBR的核心优势就是，能够利用GPU的片上缓存，降低对速度缓慢延迟巨高的显存的频繁读写，也降低了显存带宽的占用。

有人说，TBR那么好，为什么电脑GPU不采用这种方式？因为TBR也有它的弱点。把全屏幕的帧缓冲区切割成一小块一小块，会引入新的问题。你想想，我们的游戏世界是由众多多边形构成的，把帧缓冲区切割成一小块一小块，那势必就会有一些多边形横跨在了两个块上，产生了新的“顶点”，所以TBR需要把这个因素考虑进去，到最后TBR还需要生成一张分块的列表，记住哪个多边形在哪些块上，也由于这个原因，TBR需要把所有顶点处理完毕之后才能进行光栅化操作，把图形流水线分成了两个阶段，增加了延迟。这就是TBR有别于“Immediate Mode”的原因。此外，这个分块的列表放在显存里，它也会占用带宽。移动平台，手机游戏，由于不会放复杂的模型，不会有巨量的曲面细分，这个分块的列表还不算太复杂，使用TBR还不成什么问题。但是电脑上的游戏模型非常复杂，多边形数量繁多，直接采用TBR，有可能你节省的带宽还没这个分块列表额外增加的带宽多。

那么要采用什么方式来节约带宽呢？TBIMR应运而生。

这里我要澄清一个误区，从2014年，GTX750、970、980时代，各种营销号就在说，NVIDIA采用了移动平台上的TBR的渲染方式，节约带宽和功耗。这种说法是错误的。NV采用的正是TBIMR模式。
TBIMR相当于结合了IMR、TBR的长处，它既不用建立全屏巨大的帧缓冲区，又不用像TBR那样要处理完顶点才进行光栅化。TBIMR我的理解就是，建立的帧缓冲区的大小根据GPU的缓存来进行调整，使它刚好匹配缓存能容纳的数量。当缓存被写满之后，就进行光栅化、着色、各种测试等等，处理完毕后，就把缓存里的这些数据移出去，再进行下一批，这样既保留了传统渲染方式“Immediate Mode”的优点，又采纳了TBR分块处理节约带宽的优点。由于每次只对能占据缓存那么大小区域的地方进行分块处理，这样分块的列表也不会非常复杂。
大家还记得10年前AMD显卡的黑暗时代吗？128bit的GTX960，性能居然快可以摸到384bit的R9 280。512bit的R9 290X，性能相比256bit的GTX980完全处于下风，即使4K分辨率也相差甚远。除了maxwell架构使用了更好的色彩压缩技术节约带宽，主要原因就是TBIMR的引入。而AMD也不是没有设想过借鉴这个技术，在vega时代AMD也尝试过加入DSBR，这就是一个类似TBIMR的技术。但由于像上面所说的，TBIMR是会引入新的问题的，如果这些新问题解决不好，那节约带宽的作用就非常有限，反而把渲染流程搞得复杂化了。技术沉淀不够，人力不足，导致DSBR最终被搁置。
RDNA1，AMD通过大刀阔斧的架构改进，增加了L0缓存，采用了双CU协作的方式，也扩大了L1的容量，也不断改进了色彩压缩，这让256bit 40CU的5700xt即使4K分辨率也可以碾压2048bit 64CU的vega64。RDNA2时,AMD引入了无限缓存，像上文所说的，巨大的LLC可以改善带宽的占用，因为原本被迫要放到显存里的帧缓冲区，现在可以放到这个缓存里了。这就是为什么RDNA2 规模堆到了80CU，频率跑到了2.3GHz，居然用和5700xt相同的256bit显存位宽就搞定了。
但是到RDNA3/ADA时，对面的黄仁勋使用了写轮眼，他把AMD的LLC技术复制过去了，把L2缓存进行了巨量扩充。前面说过，直到RDNA3，AMD依然没有TBIMR类似的技术。所以，在大家都采用LLC时，AMD这边就开始有劣势了。384bit 96mb LLC的7900xtx，即使在4K分辨率下，相比256bit 64mb的4080，优势也没多少。带宽的瓶颈，让RDNA3的双发射翻倍浮点性能提升极其有限，同频率对比，RDNA3每个CU仅仅比RDNA2快5%。
RDNA4很久以前曝光的规格，明确说采用了20Gbps GDDR6显存。我们一开始对RDNA4都是抱有非常悲观的态度的，由于没用采用更高频率的显存，那就意味着RDNA4很可能必须依然要采用384bit vs256bit的方式来和黄卡竞争，甚至情景更加恶劣，因为blackwell已经石锤要上GDDR7显存了。本来256bit GD6 vs 256bit GD6，就存在巨大劣势，现在人家到GD7了，RDNA4的处境实在让人担心。

终于到了2024年的7月，发布在移动平台上的RDNA3.5核显PPT里，加入了这么一页。好比历史书上“烛影斧声”短短几个字，可能就隐藏着一件惊天动地的大事，RDNA3.5 PPT里这简单的“improved memory managerment”“primitive batch processing”，其实就包含着这么惊天动地的信息，那就是TBIMR正式在AMD GPU上启用。这个从NV maxwell发布之后10年都未尝越过的冰山，在这一刻被消融掉。

这下你知道为什么，仅仅256bit的9070xt，哪怕只是光栅性能居然直追7900xtx了吧？当然，TBIMR也只是RDNA4架构的一项改进，RDNA4的光栅性能提升还会有其他因素。除了光栅以外，RDNA4也还有很多其他改进，光线追踪、基于AI的超分辨率......
我依然坚持，RDNA4绝对不是小修小补的一代，它的改进比RDNA123的每代都大。这一切的谜底，都在3月5号揭晓。而留给“64CU超成灰也摸不到96CU”“256bit拿头打384bit”嘴硬党的时间，只剩下8天而已。3月5号之后，这些贴子大概率会突然消失不见，原因你懂的。

看到这里可能有人问：我怎么知道RDNA4有没有采用TBIMR？你光用嘴说他用，他就用了？
是否采用TBIMR，可以有工具来进行测试。等到3月5日9070xt发布时，求秒帝会对此进行详细测试。
这个工具的界面如图（从油管上视频截下来的）

这张图是传统的IMR光栅化方式

这张是采用了TBIMR的GPU的渲染方式（显卡好像是GTX970还是1080来着）
可以很清楚地看到，分成一个一个小块渲染。
同时也能看出，很多个小块组成一个大的矩形。结合前面的分析我们不难知道，这是因为这些个小块组成的矩形，其大小刚好能被放在GPU的缓存里。这就意味着避免对GPU显存的读写，节约带宽占用。
RDNA4如果采用了TBIMR渲染方式，那它也可以使用这个工具测试出来。
其实目前看，这一点是板上钉钉的。

最后说一句，由于本人不是游戏开发从业人员，不是硬件工程师，
上面的分析都是爬各种技术文章获得的信息，只能做到一个基本的科普，其中存在大量民科认知导致的谬误，
但最终结论不会有太大的问题。

顶顶六叔

顶顶六叔

再民科地解释一下。
GPU整个渲染流程就好像画画，顶点阶段是画线稿，像素阶段是涂色。
以前画画要准备一张超大的桌子（显存），才能放得下整张画布。但是桌子离放颜料、画笔的地方很远，要来回跑很多次（帧缓冲在显存里，频繁读写占用带宽）。
现在我不一整张一整张地画了，而是把一张画布裁成很多很多小块画布，每次批量画小块画布，这样我就不用跑到桌子那边画，而是在膝盖上（片上缓存）就完成了作画过程。
但是裁成了小块带来了新的问题，原本大的画布我可以很方便的画一个长直线，现在裁成了一个个小画布，一条直线被分成了好几段，我必须要知道这条长直线位于哪几个画布，每个画布和这条线相交的点在哪里（分块渲染需要处理新产生的顶点，全部定点处理完毕才能上色）才能把它正确滴画出来。最后我还要有一张表，可以查询每个小画布上有哪些线，这样才能在后续过程中给它们正确上色（否则，分成的小块画布画的线如果相同的话，在上色的时候无法区分）。如果线稿很复杂，包含很多线，那分成小画布画反而会带来性能损失（PC上复杂多边形不太契合tbr渲染）。
所以现在我采取一种折衷的方法，我先画几个小画布的线稿，上色，当这几个画布快要摆满我的膝盖的时候，我就把它们统一放到桌子上。然后再画几块小画布，再放到桌子上。。。。这样既减少了去桌子的次数，又不会因为线稿复杂而搞的焦头烂额。每次画几块画布，取决于我的膝盖有多大（tile根据GPU的缓存调整）

有些说不如7900x大部分都是js，不然哪里高价卖卡，尤其是n卡