如何使用DSP加速OMAP上的代码？

Question

我正在为OMAP3430制作视频编解码器。我已经有用C ++编写的代码，我尝试修改/移植它的某些部分以利用DSP（SDK（OMAP ZOOM3430 SDK）我有一个额外的DSP）。

我尝试移植一个小的for循环，它运行的是非常少量的数据（~250字节），但在不同的数据上大约需要2M次。但CPU和DSP之间通信的过载远远超过增益（如果我有的话）。

我认为这个任务就像在普通计算机中优化GPU的代码一样。我的问题是移植什么样的部件会有益？ GPU程序员如何处理这些任务？

编辑：

1. GPP应用程序分配大小为0x1000字节的缓冲区。
2. GPP应用程序调用DSPProcessor_ReserveMemory为每个分配的缓冲区保留DSP虚拟地址空间，使用比分配的缓冲区大4K的大小来考虑自动页面对齐。总预留大小也必须沿着4K页面边界对齐。
3. GPP应用程序调用DSPProcessor_Map将每个分配的缓冲区映射到上一步保留的DSP虚拟地址空间。
4. GPP应用程序准备一条消息，通知DSP执行阶段虚拟地址空间的基地址，该地址已映射到GPP上分配的缓冲区。 GPP应用程序使用DSPNode_PutMessage将消息发送到DSP。
5. GPP调用memcpy将要处理的数据复制到共享内存中。
6. GPP应用程序调用DSPProcessor_FlushMemory以确保已刷新数据缓存。
7. GPP应用程序准备一条消息，通知DSP执行阶段已完成写入缓冲区，DSP现在可以访问缓冲区。该消息还包含写入缓冲区的数据量，以便DSP知道要复制的数据量。 GPP使用DSPNode_PutMessage将消息发送到DSP，然后调用DSPNode_GetMessage等待从DSP听回消息。

此后DSP程序的执行开始，DSP在完成处理时通知GPP。只是为了尝试我不在DSP程序中进行任何处理。我只是将“处理完成”消息发送回GPP。这仍然需要耗费大量时间。可能是因为内部/外部内存使用，还是因为通信过载？

Answer 1

OMAP3430没有板载DSP，它有一个连接到系统总线的IVA2 +视频/音频解码引擎，而Cortex核心具有类似DSP的SIMD指令。 OMAP3430上的GPU是基于PowerVR SGX的设备。虽然它确实有可编程着色器，但我不认为有任何支持通用编程ala CUDA或OpenCL。我可能错了，但我从来没有听说过这样的支持

如果你使用板载的IVA2 +编码/解码引擎，你需要为这个单元使用适当的库，它只支持我所知道的特定编解码器。您是否正在尝试将自己的库编写到此模块中？

如果您使用Cortex的内置DSPish（SIMD指令），请发布一些代码。

如果您的开发板上有一些额外的DSP，那么什么是DSP以及它如何连接到OMAP？

关于桌面GPU的问题，在视频解码的情况下，你使用供应商提供的函数库来调用硬件，有几个，Linux上的Nvidia VDAPU，windows上的类似库（PureViewHD我认为它叫做）。 ATI还有用于板载解码引擎的linux和windows库，我不知道名字。

Answer 2

我不知道您传输数据的时间基准是什么，但我知道SDK的规格表中列出的TMS32064x具有非常强大的DMA引擎。 （我假设它是原始的ZOOM OMAP34X MDK。它说它有64xx。）我希望OMAP有一些simalar，使用它们是最充分的优势。我建议在64xx的内部ram中设置“乒乓”缓冲区，并使用SDRAM作为共享内存，并通过DMA进行传输处理。外部RAM将成为任何6xxx系列器件的瓶颈，因此请保留可锁定在内部存储器中的任何内容以提高性能。通常，这些部件能够在内部存储器中将8个32位字总线连接到处理器内核，但是根据它允许您映射为直接访问RAM的级别缓存，部件之间会有所不同。 TI的成本敏感部件将“可映射存储器”移动得比其他一些芯片更远。此外，TI提供的所有部件手册均可以PDF格式免费下载。他们甚至还免费提供了TMS320C6000 CPU和指令集手册以及许多其他书籍的硬拷贝。

就编程而言，您可能需要使用一些“处理器内在函数”或内联汇编来优化您正在进行的任何数学运算。对于64xx有利于整数操作，因为它没有内置浮点核心。 （这些是在67xx系列中。）如果查看执行单元并且您可以映射计算，使得不同的部分以可以在单个循环中发生的方式针对不同的操作，那么您将能够实现最佳性能那些部分。指令集手册列出了每个执行单元执行的操作类型。如果您可以打破计算到双数据流集并稍微展开循环，那么当完全优化启用时，编译器将“更好”。这是因为处理器分为左侧和右侧，两侧的执行单元几乎相同。

希望这有帮助。

Answer 3

根据我的测量结果，CPU和DSP之间的一个消息传递周期大约需要160us。我不知道这是因为我使用的内核还是桥驱动程序;但对于一个简单的背部和背部来说，这是一个很长的时间。发消息。

如果总计算负载与消息传递所需的时间相当，那么将算法移植到DSP似乎是合理的。如果算法适合在CPU和DSP上同时计算。