H264 解码耗时分析

在数字基带处理器上代码的最佳放置

美国模拟器件公司 Jose Fridman 　

在手机等嵌入式系统中，除了处理器执行时间外，最重要的资源就是设备总线和存储器接口。本文将介绍一种在使用指令高速缓存时其带宽消耗的基础上，统计分析高速缓存所采用的方法。这种方法是传统基于指令周期的分析方法的补充，并且也为在外部存储接口受限制的设备中优化应用程序提供了一种手段。在外部接口受限制的设备中优化那些使用高速缓存的应用程序的读取带宽，对提升指令周期性能有着良好效果。作为例子，将分析H.264视频解码器在AD6900中集成Blackfin DSP的运行情况。

最近几年，高速缓冲存储器(caches)在DSP和嵌入式系统中已经很普遍。在高速缓存出现前，嵌入式软件需要对片内SRAM和片外SRAM、SDRAM和Flash等所有物理存储资源中的代码进行管理。软件工程师必须根据运行时间统计查找所有对全部运行时间起关键作用的代码模块的位置。例如，当需要一个对运行时间非常关键的模块时，例如通信系统中的数据均衡器，其代码在执行之前必须从低速的片外存储器移至高速的片内SRAM。这个预载入的过程确保了模块快速执行，并且在预定义的执行时间范围内。

然而，这种预载入过程很消耗时间，而且除了相当小的系统，这种预载入过程都会是非常复杂的。例如，现在的手机系统已经发展到了非常复杂的程度，特别是那些新一代的多模手机，其中GSM调制解调与FDD WCDMA调制解调模式共存。除了移动通信标准，手机可能还需要支持多种无线连接标准(例如IEEE 802.11无线局域网和蓝牙标准)以及多媒体标准(例如MPEG-4和H.264标准)。因此无线标准的多样性使已经很复杂软硬件系统又增加了负担，从而使很明确的代码放置问题也不再容易。

而另一方面，如果我们在设计一个具有指令高速缓存的系统时没有考虑程序代码的合理放置，很可能会在从高速缓存获取程序代码以及用来存储程序代码的内存，由于带宽的原因会花费很多时间。例如，如果将整个程序放在外部Flash中，这种情况就会出现。

本文中，我们将介绍一种方法，在使用指令高速缓存的条件下确定在Blackfin DSP上运行大型软件系统中代码段的最佳位置。我们采用该方法实现手机终端数字基带处理器(DBB)AD6900中的代码优化配置，同样该方法适用于所有基于Blackfin处理器的设备。

AD6900的体系结构描述

下面简单介绍一下AD6900 DBB处理器，AD6900的结构如图1所示。在图1的右上方是Blackfin处理器的子系统，其中包含Blackfin的内核、L1代码和数据存储器(按照caches或SRAM配置)、L2存储器、称作DSPDMA的Blackfin直接存储期存取(DMA)控制器和一组用于采集和处理GSM数据的DSP外围设备。Blackfin子系统与系统总线接口单元(SBIU)相连，SSIU是一个多端口交叉开关，提供DSP和L1存储器以及系统其他部分之间的连接。图的右下方是ARM926EJ-S子系统。第三级系统片内存储器称作系统随机存储器(RAM)(即L3存储器)，Blackfin和ARM内核都可访问L3。通过外部总线控制器(EBS)、SDRAM控制器(SDC)和一个与非门闪存控制器(NFC)可访问外部存储器(L4)。

图1 AD6900结构框图

专用的APBUS子系统支持多媒体连接功能，即显示和采集设备的接口。它包含一个并行外围设备接口(PPI)控制器，支持10bit摄像机传感器或视频输入接口(包括ITU-656和ITU-601数字视频)，以及一个用于并行LCD显示专用外部总线接口，称作EBUS2，它可消除噪声并且可在主外部存储主接口上装入数据。多通道DMA控制器方法，称作APPDMA，它支持几种视频格式，包括YUV4:2:2、YUV4:2:0、RGB565和其他格式，能满足多媒体接口设备对数据移动的需求。

AD6900基于层次存储系统。从Blackfin处理器的角度来看，L1存储器仅提供了一种有限的快速零等待状态存储。而较低等级的存储器(例如L2、L3和L4存储器)提供了增大的存储容量，但以比较低的速率接入。Blackfin DSP具有两通道32B总线宽度、16KB指令高速缓存。

H.264视频编解码器

H.264视频解码器标准，又称为MPEG 4 Part 10/AVC，正推动着大量新的无线手机应用。这里我们采用H.264解码器作为在AD6900系统中放置代码方法的一个案例，因为H.264解码器需要高速代码读取带宽。

表1 按DSP占用百分比对H.264函数的分类统计分析

表1列出了在Blackfin DSP上运行的H.264解码器的统计分析，展示了一些调用最频繁的函数(整个应用中大约有100个函数)。表中提供的信息是许多分析器的典型数据，其中包括调用函数次数，总的周期数目，以及该函数对DSP处理器负载的贡献。在这个具体的实验中，使用一种基线分析基准来测试一段具有21个时间片(slice)(例如帧)的视频向量，每15个预计算时间片(P-slices)构成1个I-slice的视频矢量。与其他许多DSP类似，借助Blackfin VDSP工具可以获取这种类型统计分析信息。使用这些信息，编码开发商就可以注重选择和优化那些消耗DSP指令周期最多的函数，例如_decode_residual和_filter_mb_edgev_4.ix。事实上，这两个函数和其他一些频繁调用的函数已经优化为汇编语言。一般，大约10%的代码已经优化为汇编，其余90%仍为C语言。

这种统计分析中还包含每个函数基所需要的指令高速缓存线路占用数目的信息。例如，函数_decode_residual不但是消耗指令周期最多的函数，还使指令高速缓存读取相当多的高速缓存线路。在这种情况下，仅仅这一个函数就消耗了整个H.264解码器所需的高速缓存线路数目的10.5%。

类似的，其他函数，也许不是占用DSP指令周期最多的函数，也需要占用大量的指令高速缓存数目。在表1中我们用框线标出要求指令高速缓存线路占用率最大的三个函数，占用总数的几乎40%。总之，DSP消耗的指令周期和指令高速缓存线路占用率无关。许多函数，也许消耗的DSP指令周期较少，但却需要相当多的高速缓存线路占用率，而有一些消耗DSP指令周期较多的函数可能需要较少的高速缓存线路(例如，_filter_mb_edgev_4pix消耗6.7%的DSP指令周期，但只消耗0.1%的指令缓存)。

该信息之所以有用，在于当全部程序代码都放在了低级存储器中时，例如片外Flash存储器，代码读取会消耗相当大的指令缓存带宽。取指令所消耗的带宽会占用视频和临时数据的总线资源，还会降低解码器效率。读取指令占用了整个解码器所需片外存储器带宽的50%，而其余50%用于存储视频数据、查表和状态信息。

如果将表1中强调的三个函数放在离DSP近的存储器中，例如L1程序存储器，那么可以节省大约40%的片外读指令带宽。这是根据高速缓存线路占用率进行统计分析的主要目的。

更一般地，在表2中示出了同样的分类，但是按照指令高速缓存占用率递减顺序排列的。我们可以看见一些函数虽然并不占用太多DSP指令周期，但却需要大量的指令高速缓存占用率。例如，如果采用传统的基于指令周期的统计分析方法处理函数_hl_motion，那么我们可能认为并不需要优化该函数，因为它只消耗0.7%的DSP指令周期。然而，它需要占用5.5%指令缓存线路占用率，因此在这种情况下应该将该函数放置在离DSP近的存储器中，可以大幅度提升其应用性能。

表2 按照指令高速缓存占用率对H.264函数的分类统计分析

利用表2提供的统计分析，我们挑选那些消耗指令高速缓存最大的函数，并且将其放入L1 DSP存储器。该函数的数量取决于系统其他部分的需求和L1存储器可用容量。在这个具体例子中，我们有一个16KB的L1 DSP存储器并且将它放在函数的顶层，可使程序读取带宽下降54%。随着带宽的减小，H.264解码器占用总周期的时间将会减少10%。H.264解码器的程序代码长度大约为125KB，这就意味着通过重新链接并且将13%的代码移动到片内存储器，可以提升指令执行周期性能。

结论

当考虑优化应用程序时，我们常常只关注问题的一方面：应用程序所消耗DSP资源的程度，即消耗的指令周期或每秒指令数(MIPS)。然而，在许多嵌入式系统中最重要的资源除了处理器执行时间外，还有整个设备的总线及外部存储器接口。这些资源在高集成度系统中尤其重要，例如手机中数字基带处理器，其外部接口通常是最重要的系统资源之一。在本文中我们介绍了一种根据运行在基于指令高速缓存系统所消耗的带宽统计分析应用程序的方法。在外部接口受限制的设备中优化那些使用高速缓存的应用程序的读取带宽，对提升指令周期性能有着良好效果。

H264 解码耗时分析相关推荐

WebRTC[1]-WebRTC中h264解码过程的源码分析
目录前言正文 <WebRTC工作原理精讲>系列-总览_liuzhen007的专栏-CSDN博客_webrtc 原理前言欢迎大家订阅Data-Mining 的<WebRTC工作原理 ...
海思HI35xx平台软件开发快速入门之H264解码实例
前言 H264视频编码技术诞生于2003年,至今已有十余载,技术相当成熟,它的优势在于有高的视频的压缩率,利用帧间和帧内预测(Estimation).变换(Transform)和反变换.量化(Quan ...
h264解码之环路滤波
代码以ffmpeg为例,h264解码代码在h264.c里. 环路滤波(Loop Filter)部分 FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大 ...
FFmpeg学习 avcodec软解码函数分析
前言本文分析ffmpeg软解码流程,相关函数如下,以find_stream_info中的try_decode_frame为例: 相关函数都在libavcodec包下. 基本调用流程如下: const ...
linux之x86裁剪移植---ffmpeg的H264解码显示（420、422）
在虚拟机上yuv420可以正常显示 ,而945(D525)模块上却无法显示 ,后来验证了directdraw的yuv420也无法显示 ,由此怀疑显卡不支持 ,后把420转换为422显示. 420显示如 ...
CANN AICPU算子耗时分析及优化探索
摘要:本文以GreaterEqual作为测试算子,该算子计算逻辑较为简单(output = input1 >= input2),旨在尽可能降低计算耗时,使得算子耗时尽可能以数据操作和算子调度作为 ...
编译时如何看到每个文件的编译选项_导出 Clang 可视化编译耗时分析报告 —— ftimetrace 的使用...
前言笔者最近加入了新的团队,开始负责编译打包相关工作,因而开始学习优化编译时间相关技术.讲真,蛮开心的,每天都有挑战,同时每天都有收获,天天都在涨姿势,所以想记录下来并分享出来,也方便以后自己需要时 ...
android 耗时分析,启动耗时分析（四）-具体方法耗时分析
原创文章,转载请注明出处,多谢! 如果cpu频率.调度和 compiler filter都一一排除了,没问题.那接下来就看是否有具体方法耗时. 一.常用的分析手段: 1.systrace 这里可按s ...
python利用装饰器进行运行耗时分析
运行环境 python 3.7.0.特设置了DEBUG模式,便于打开和关闭耗时分析功能. import time DEBUG = 0 # 在需要分析时效性的时候将该量置为1,否则置为0def prin ...

H264 解码耗时分析

H264 解码耗时分析相关推荐

最新文章

热门文章