OE3.0.22编译fft算子进入custom_operator中后，出现fft2d结果不正确的问题

已解决

Tiansheng2024-12-26

在OE3.0.22中，之前出现过fft2d结果不正确的问题。我在论坛中提出过这个问题，通过了dsp镜像文件解决了这个问题。

但是我现在需要把fft算子编译进入DSP的自定义算子镜像中，fft2d结果不正确的问题又会出现。

请问除了升级OE到3.0.27版本外是否有其他办法可以解决这个问题？

是否可以提供fft库文件的更新，或者其他相关文件的更新，使我可以在OE3.0.22中同时使用fft算子和自定义算子？

这里是和这个问题相关的之前的提问：

UCP的FFT2D结果不正确 - 地平线开发者社区

UCP的FFT API和自定义DSP算子可以同时使用吗？ - 地平线开发者社区

谢谢。

算法工具链

DSP征程6

0/1000

Huanghui
Lv.5
你好，你这里实际上涉及到的是两个问题：
1. 自定义算子和已有的参考算子通用的问题。这个在3.0.22上就可以搞定，不需要升级。
2. 对与FFT计算不准确的问题，你可以在解决1问题时生成的image上再试试，实际上你把已有的算子和自定义算子合并到一个image时是通过库的方式引入的，而库本身可能是没有问题的（猜测）；你直接使用我们编译好的vdsp0 image测试时FFT有问题很可能我们再生成image时引入的，而我们生成 vdsp0 image是构建的代码可能是有问题的。
2024-12-26
0
2
- Tiansheng回复Huanghui:
  我是测试过了，才提出这个问题的，解决1问题时，我把fft的函数注册到了自定义算子的DSP镜像中，并且链接了cadence fft库。但是生成的镜像，就没有办法获得正确的fft2d结果。
  不知道你们是否有在你们的环境里测试结果的正确性？是否可以通过升级到3.0.27解决这个问题？
  2024-12-26
  0
  回复
- Huanghui回复Tiansheng:
  那我试试哈，稍后反馈你
  2024-12-26
  0
  回复
Huanghui
Lv.5
你好，这个问题根本原因是libfft.a的库文件中的功能实现问题，我这里先把3.0.27版本中包含的可用的libfft.a给你，你自己把/open_explorer/samples/ucp_tutorial/deps_aarch64/ucp/plugin/dsp_plugin/cadence/libfft/lib/libfft.a这个文件覆盖更新一下就OK了。我验证过了。
https://pan.baidu.com/s/1Vv8dAW8c57b7RIhOfAnFPw?pwd=qa3r
2024-12-26
0
4
- Tiansheng回复Huanghui:
  Hello 请问你是在3.0.22里验证的，还是3.0.27验证的？我这边在OE3.0.22替换了之后结果依然是不对的。
  2024-12-26
  0
  回复
- Huanghui回复Tiansheng:
  我是在3.0.22中验证的
  2024-12-26
  0
  回复
- Tiansheng回复Huanghui:
  我这边验证的结果，第一次计算会正确，但是多次运行后还是会出现之前的状态，结果不正确并且每次的结果不同。请问是否可以分享一下你们和原来的custom_operator文件夹做了哪些修改？
  2024-12-27
  0
  回复
- Huanghui回复Tiansheng:
  不好意思，这个我之前同步有误，重新验证了一下，结果如下：
  1. 问题确实是库文件中的实现导致的，而且是DSP端的库存在问题。我重新上传了库文件，你还是要用 https://pan.baidu.com/s/16tJ82ruNjMs6aMj2J7G3dg?pwd=y9jf下面的库问题替换docker容器中/open_explorer/samples/ucp_tutorial/deps_aarch64/ucp/plugin下面的相应目录。
  2. arm端的测试代码我就是使用的/open_explorer/samples/ucp_tutorial/hpl/code下面的hpl的代码，只是为了测试对fft_ifft_2d.cpp文件做了一点变动，我把变动完的代码也上传到了网盘下面，你可以看一下。
  3. 就在3.0.22下面测试就OK！当然，如果你有3.0.27的话也可以直接用3.0.27，简单很多。
  2024-12-27
  0
  回复