第186章 潜行岁月 － 天枢协同（中）(2/4)
用率、axi总线拥堵情况……
很快，问题暴露出来。
“你看这里！”阿杰指着屏幕，“在进行多层半透明窗口合成（alpha blendg）和高速拖动时，gpu的渲染管线负载其实并不高，‘灵猴’gpu的处理能力绰绰有余。但是，内存带宽占用率却瞬间飙升，并且axi总线的读延迟也明显增大！”
小张立刻明白了：“瓶颈不在gpu运算本身，而在于gpu访问内存读取纹理数据、以及将渲染结果写回显存（frabuffer）的通路上！在高并发、大吞吐量的图形操作下，内存带宽成为了瓶颈，或者说，是内存控制器和总线仲裁机制不够高效！”
如果是传统的开发模式，发现这个问题后，软件团队能做的很有限，最多只能在软件层面尝试优化渲染算法，减少访存次数。但效果往往不佳，而且治标不治本。他们只能寄希望于硬件团队在下一个芯片版本中改进内存子系统设计，但这至少需要等待几个月甚至一年。
但在启明芯，情况完全不同！
小张立刻通过内部集成的项目管理与协同平台（基于eda平台二次开发），创建了一个高优先级的“性能优化请求”，详细描述了问题现象、性能剖析数据、以及对硬件内存子系统提出的优化建议（比如增大gpu专用cache、优化内存控制器调度算法、或者提高axi总线优先级等），并将这个请求直接指派给了负责“天枢”c内存子系统设计的硬件工程师老王（并非模拟专家老王，可能是另一位数字电路专家）。
几分钟后，远在启明芯深圳研发中心的硬件团队的老王，就在他的工作站上收到了这个请求。
“内存带宽瓶颈？gpu访存延迟高？”老王看着软件团队提供的详尽数据和波形截图，立刻明白了问题的严重性。
他迅速调出“天枢”c内存子系统的rtl代码和“盘古”提供的系统级性能仿真模型，开始进行分析和优化探索。
他首先尝试在仿真模型中增大gpu l2 cache的容量，发现对性能提升有帮助，但带来的面积和功耗代价较大，不是最优方案。
然后，他重点分析了axi总线仲裁器的逻辑。利用“盘古”的性能调试工具，他
本章还未完，请点击下一页继续阅读>>>
