Forums - fcvPyramidLevel_v2 memory alllocation on DSP

3 posts / 0 new
Last post
fcvPyramidLevel_v2 memory alllocation on DSP
louis.muffang
Join Date: 16 Jul 20
Posts: 5
Posted: Fri, 2020-10-09 08:23

Hello everyone,

 

I am trying to use the fcvTrackLKOpticalFlowu8_v3 on the DSP as the CornerApp example used FAST features extractor in the Hexagon SDK.

I can run it on the CPU by calling fcvSetOperationMode, fcvMemInit, fcvPyramidAllocate_v3, and then create and use them in the optical flow tracking. (By the way how can I see the exact differences between the 4 modes?)

I can use rpcmem for my buffers and create an interface to call a FastCV funtion (which does NOT use pyramids as arguments).

However, I would like to know how can I allocate memory for pyramids on the cDSP (or at least shared with the CPU with rpcmem) ? It seems to me that setting an operation mode, fcvMemInit, ect...  is for CPU usage only.

Otherwise, how can I set fcvPyramidLevel_v2as an in parameter in the .idl interface?

Thank you for your help!

  • Up0
  • Down0
louis.muffang
Join Date: 16 Jul 20
Posts: 5
Posted: Thu, 2020-10-22 07:58

I found the origin of the issue I had.

With the function fcvPyramidAllocate_v3 I had the error "undefined symbol PLT" on mini-dm. However everything works just fine with fcvPyramidAllocate_v2 but I don't know why and how..

Is that okay to call fcvPyramidAllocate (_v2 or _v3) on the DSP object implementation (_imp.cpp file)? Here is a part of my code form the cpp implementation file liked to the skel shared library:

fcvPyramidLevel_v2* fcvimgpyr = new fcvPyramidLevel_v2[nPyramidLevels];

fcvPyramidLevel_v2* fcvimgpyr_last = new fcvPyramidLevel_v2[nPyramidLevels];

fcvPyramidAllocate_v2(fcvimgpyr_last, srcWidth , srcHeight, srcWidth, 1, nPyramidLevels, 0);

fcvPyramidAllocate_v2(fcvimgpyr, srcWidth, srcHeight, srcWidth, 1, nPyramidLevels, 0);

fcvPyramidCreateu8_v3(src1, srcWidth, srcHeight, srcStride, nPyramidLevels, FASTCV_PYRAMID_SCALE_HALF, fcvimgpyr_last);

fcvPyramidCreateu8_v3(src2, srcWidth, srcHeight, srcStride, nPyramidLevels, FASTCV_PYRAMID_SCALE_HALF, fcvimgpyr);

fcvTrackLKOpticalFlowu8_v3(src1, src2, srcWidth, srcHeight, srcStride, fcvimgpyr_last_dsp, fcvimgpyr_dsp, featureXY, featureXY_estimate, featureXY_out, featureStatus, featureLen, windowWidth, windowHeight, nPyramidLevels, FASTCV_TERM_CRITERIA_BOTH, maxIterations, maxEpsilon, use_initial_estimate);

 

I also call fcvPyramidLevel_v2 at the end on both pyramid pointers.

I looked at the execution time and the fcvTrackLKOpticalFlowu8_v3 funtion is slower when called from the DSP compared to when I call it from the CPU (alomost twice as slow, 11 ms as opposed to 6ms). Why is that?  Of course I removed the time of the FastRPC call, all parameters are the same and DSP frquency is at 940 MHz (max at 1190MHz).

I am running this funtion on a SDM845 and as mention in the Hexagon SDK, the funtion fcvTrackLKOpticalFlowu8_v3 is further optimized for HVX (supported on v65). Is this optimized implementation used when it is called directly from the DSP ? I is hard to see what the funtion does at a low level..

Thanks for your reply.

  • Up0
  • Down0
jeff4s Moderator
Join Date: 4 Nov 12
Posts: 106
Posted: Thu, 2020-10-22 10:51

Hi,

For questions of running FastCV on DSP there is another forum where you can post the questions:

https://developer.qualcomm.com/forums/software/hexagon-dsp-computer-vision

Cheers,

-Jeff

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.