有不少的朋友,特别是刚刚接触DSP的朋友。基于DVRRDK编写C代码发现执行速度特别慢,我在上面简单的对每一个像素的UV分量赋值=0x80,这样就成了灰度图像。对1080P图像进行操作,发现处理每帧要耗时10-20ms,真是慢的不可思议。

近期将SWOSD的完整代码看了一遍发现了玄机。

主要问题是在DDR中读写数据拖慢了速度。

经測试SWOSD进行一帧D1的叠加仅须要400us(叠加大小大概208*32*3个窗体);

细致分析。其内部使用了基于内部 IALG_DARAM0(双通片上数据存储)的乒乓缓存结构:

Int SWOSD_TI_alloc(const IALG_Params *algParams, IALG_Fxns **pf, IALG_MemRec memTab[])
{
const SWOSD_Params *params = (SWOSD_Params *)algParams; memTab[0].size = sizeof(SWOSD_TI_Obj);
memTab[0].alignment = 0;
memTab[0].space = IALG_DARAM0;
memTab[0].attrs = IALG_PERSIST;
//InA InB Out[2]
memTab[1].size = (params->maxWidth*(2+2+2+2))*2;
memTab[1].alignment = 128;
memTab[1].space = IALG_DARAM0;
memTab[1].attrs = IALG_PERSIST; return (2);
}

此函数为TMS320 Algorithm Standard 即xDAIS中的 algAlloc()函数的实现。其返回一个该算法所需的内存记录表。(详见SPRU360E)

Int SWOSD_TI_initObj(IALG_Handle handle, const IALG_MemRec memTab[],
IALG_Handle p, const IALG_Params *algParams)
{
const SWOSD_Params *params = (SWOSD_Params *)algParams;
SWOSD_TI_Obj *obj = (SWOSD_TI_Obj *)handle; if (params == NULL) {
params = &SWOSD_TI_PARAMS;
} obj->swOsdCtrl.openPrm.maxWidth = params->maxWidth;
obj->swOsdCtrl.openPrm.maxHeight = params->maxHeight; obj->memLineBuf = memTab[1].base; return (SWOSD_SOK);
}

在使用时:

pLineBufA[0]  = (Int64*)(swOsdObj->memLineBuf + offset);
offset += width; pLineBufA[1] = (Int64*)(swOsdObj->memLineBuf + offset);
offset += width; pLineBufB[0] = (Int64*)((Int32)swOsdObj->memLineBuf + offset);
offset += width; pLineBufB[1] = (Int64*)((Int32)swOsdObj->memLineBuf + offset);
offset += width; pLineBufOut[0] = (Int64*)((Int32)swOsdObj->memLineBuf + offset);
offset += width; pLineBufOut[1] = (Int64*)((Int32)swOsdObj->memLineBuf + offset);
offset += width;

然后内部将要处理的数据用DMA复制到memLineBuf,并使用乒乓结构:

    SWOSD_TI_DMA_Fast2D1D
(
dmaHandle,
SWOSD_DMA_CH_IN_A,
(void *)pInA,
(void *)((UInt32)pLineBufA[0] + 0x30000000),
width,
2,
srcPitch,
width,
srcPitch,
(-width)
);

至于上面的代码片段中目的地址 (void *)((UInt32)pLineBufA[0] + 0x30000000)中为什么在pLineBufA[0] 加了0x30000000还是没有弄明确。请高人指点。

(由于dma是个外设,他看到的地址和dsp看到的地址是不一样的。

之间有个0x30000000的偏移。

L2 SRAM address is 0x108_00000. The L3 address of c674 L2 SRAM address (GEM UMAP0) is 0x408_0000 .The conversion is from 0x108_0000 to 0x408_0000 by adding 0x0300_0000.
DONT USE 0x300_0000 .IT WILL CRASH THE SYSTEM.)

本文眼下仅仅总结出了原因,至于实现正在尝试。

欢迎交流沟通。

转载注明:http://blog.csdn.net/guo8113/article/details/25026777






最新文章

  1. (转)Three challenges you’re going to face when building a chatbot
  2. 问题解决——VC 断点 无效 一个可能情况?
  3. Swift基础--Swift中的异常处理
  4. CodeForces 710F 强制在线AC自动机
  5. java8-2 多态的概述
  6. [javascript|基本概念|Number]学习笔记
  7. .NET中 MEF应用于IOC
  8. UVA 10462 Is There A Second Way Left? 次小生成树
  9. python登陆教务管理系统
  10. javascript的页面加载及性能优化(兼容IE7)
  11. matlab 向量法建数组(推荐)
  12. [转]Oracle 创建 DBLink 的方法
  13. web服务器负载均衡与集群基本概念二
  14. Java面试准备之JVM
  15. JGUI源码:Accordion兼容IE8实现(3)
  16. null、undefined、typeof、instanceof
  17. Ucinet6 + Netdraw 根据excel文件绘制网络拓扑图
  18. apache配置https协议
  19. Windows 10安装pip方法
  20. Teamwork(The fifth day of the team)

热门文章

  1. Sudoku(dfs)
  2. Spring Data 自动生成
  3. CentOS7 搭建Kafka(三)工具篇
  4. Scala学习2 ———— 三种方式完成HelloWorld程序
  5. BZOJ 4010 拓扑排序+heap
  6. Kali linux 2016.2(Rolling)之 Nessus安装及Plugins Download Fail 解决方法
  7. hibernate_06_单表操作_组件属性
  8. MyEclipse 连接Oracle数据库(初学者必看)
  9. 利用Putty/Plink通过ssh tunnel端口转发实现FireFox和Chrome的加密代理访问
  10. Network-Flow