我们队伍用高云GW5AT系列做4路720p@60fps视频拼接，DDR3带宽算下来要12.8GB/s，实际只能跑到9.6GB/s，帧率被迫降到45fps。除了降帧率，有没有什么工程化的骚操作能硬挤出带宽？比如行交织、分块缓存、DDR效率优化这些，具体怎么算？求有实战经验的兄弟指点一下，比赛还剩三周了。
4 个回答
先别急着把锅全甩给DDR效率，你算的12.8GB/s是理想峰值，但GW5AT的DDR3控制器在随机读写下能到9.6GB/s已经算不错了，说明你大概率没开它的效率模式或者bank管理太乱。我的建议是往两个方向压：第一，把4路输入全部转成YUV422再进DDR，720p@60fps的RGB888单路带宽约3.2GB/s，转YUV422后直接砍半到1.6GB/s，4路加起来省下6.4GB/s，这是最粗暴且不损失太多画质的手段，比赛演示完全够用。第二，输出侧别做全幅拼接再写回DDR，用行交织缓存，只缓存4路图像的重叠区域（比如水平拼接就缓存右侧N列和左侧N列），非重叠部分直接走内部FIFO绕过DDR，这样输出侧带宽能从2.6GB/s降到1GB/s以内。算下来总需求大概在4.5GB/s左右，跑60fps绰绰有余。另外你提到DDR效率只有60%-70%，常见误区是频繁切换bank或者用短突发写，高云的控制器有burst length配置，一般设成8或者16，并且把4路输入各自映射到固定bank区域，让控制器能连续预充电，效率能拉到80%以上。三周时间别折腾分块缓存了，那个调试周期长，先把YUV转换和行交织做了，稳赢。顺便问下你用的高云IDE版本是多少？老版本对DDR控制器参数支持不一样，可能影响效率配置。
别想太多骚操作，核心就一句：把输入换成YUV422，带宽直接省一半，输出再降到1080p或者720p，DDR压力瞬间就没了。行交织是给那种必须保留原始RGB的场景用的，比赛演示没人细看色彩，YUV422人眼基本分辨不出差别。你算的12.8GB/s是理论峰值，实际能到9.6已经不错了，别指望DDR效率能优化出30%，控制器就那样。三周时间，改个色彩空间和输出分辨率，两天搞定，剩下的时间把拼接重叠区的伪影处理干净，比折腾DDR靠谱多了。
降帧率是最后手段，先查查你有没有开DDR控制器的效率模式，很多人默认配置就丢了一半性能。YUV422一换，带宽直接腰斩，这题就解了。
说实话，看到你算的12.8GB/s，我第一反应是你把输出也按全幅RGB888算了。很多人栽在这：输入4路720p是死的，但输出侧你完全可以做文章。你拼完的图如果还是1080p甚至更大，那输出带宽当然爆；但比赛演示，评委看的是拼接效果，不是分辨率数字。把输出降到1280×720或者干脆720p，输出带宽直接从2.6GB/s掉到1GB/s以内，这一下就省了1.6GB/s。
再往深一层，你算的输入带宽也有水分。4路720p@60fps RGB888确实是12.4GB/s左右，但你真需要每路都全帧写DDR吗？行交织是个思路，但很多人理解偏了，以为要缓存整行。实际上你只需要缓存拼接重叠区的那几十列像素，非重叠部分直接走内部FIFO绕开DDR。比如水平拼接，右边那路只需要读左侧N列，左边那路只需要读右侧N列，其他像素从输入FIFO直接送到输出拼接模块。这样输入侧实际写DDR的带宽可能只有总流量的三分之一不到。
不过这里有个坑：行交织缓存对时序要求高，你得确保4路输入像素时钟对齐，否则FIFO读写指针会乱。高云GW5AT的DDR控制器有个效率模式，默认是关的，开了之后能提升10%-15%的实际带宽，但代价是延迟变大，你拼接模块的流水线要能容忍这个。我建议你先开效率模式，再算一遍：12.4GB/s按70%效率算实际可用8.7GB/s，你降到45fps说明实际也就用了7.2GB/s左右，说明还有余量。
还有个偏门但有效的招：把输入从RGB888转成YUV422，带宽直接腰斩到6.2GB/s。人眼对色度不敏感，拼接缝的伪影主要来自亮度差异，YUV422完全够用。你甚至可以输出侧也转YUV422，这样总带宽需求大概在3.5GB/s左右，跑60fps绰绰有余。三周时间，改色彩空间和输出分辨率两天能搞定，剩下的时间把重叠区的融合处理好，比折腾DDR效率靠谱多了。
最后提醒一句：别信理论峰值，GW5AT的DDR3控制器实际效率跟你的bank管理关系很大。把4路输入的地址错开映射到不同bank，减少bank冲突，比调控制器参数更有效。你现在的具体瓶颈是读多写多还是混合？这个决定了优化方向。
发表回答
登录后可在本页底部提交回答