This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: app_multi_cam cannot adjust the number of pipelines

Part Number: TDA4VM

Hi, TI.

The default pipeline of app_multi_cam application in 8.2 SDK is 4. Now, due to a practical application requirement, we want to modify its pipeline number to 2, but found that the modified program cannot run correctly.

#define APP_BUFFER_Q_DEPTH   (4)
#define APP_PIPELINE_DEPTH   (7)

To locate this problem, we added a print message to the code.

We first ran the program with the default pipeline configuration and got the following output, which is consistent with our expectations.

Then we change the pipeline configuration in the figure below to 2, recompile the program and run it again.

It can be seen that the program is blocked in the vxGraphParameterDequeueDoneRef interface of frame 0 and cannot continue to run.

I understand that the pipeline is just a parameter configuration, and the graph of the program is set to any pipeline number including 1 should be able to run. And the same application in 7.0 and 7.1 SDK can run normally.

SDK currently used: ti-processor-sdk-rtos-j721e-evm-08_02_00_05

Could you possibly tell us how to solve this problem?

Thanks, I would appreciate it if you could give a prompt reply.

  • Hi,

    I think the issue here is due to "APP_BUFFER_Q_DEPTH  (2)",

    With APP_BUFFER_Q_DEPTH  (3) or above, it will work with APP_PIPELINE_DEPTH (1) too.

    This is because the capture node expects at least 3 buffers before it tries to dequeue the buffer from the node.

    Please let me know if this resolves your issue.

    Regards,
    Nikhil

  • Hi, Nikhil,

    thank you for your prompt reply. 

    I have tried setting APP_BUFFER_Q_DEPTH to 3 and APP_PIPELINE_DEPTH to 1, but it still doesn't work, it still blocks on the vxGraphParameterDequeueDoneRef interface.

    However, setting APP_BUFFER_Q_DEPTH to 4 and APP_PIPELINE_DEPTH to 1, it works fine. In this way, does it mean that the capture node needs at least 4 buffers before it tries to dequeue the buffer from the node?

    Another phenomenon is that I set APP_PIPELINE_DEPTH to 1, and call vxQueryGraph after vxVerifyGraph to query the number of pipelines of the graph. The returned result is 3, as shown by the arrow in the above figure. Is this because the tiovx framework automatically adjusts the number of pipelines to 3?

    I don't quite understand the above phenomenon. I have the following questions:

    1. As you said,  'the capture node expects at least 3 buffers before it tries to dequeue the buffer from the node', where can I get this information? Do other nodes also have this limitation. 

    2. Does this limitation have something to do with the refs_list_size of graph_parameters_queue_params_list in the image below? 

    3. What is the relationship between refs_list_size of graph_parameters_queue_params_list and pipeline_depth of graph?

    4. Is there a way to manually specify the pipeline depth of the graph? 

    Thanks,

    Dian Luo

  • I don't think you should change the pipeline depth since it's part of the internal state machine of ovx to run nodes concurrently and also it does not harm the memory usage. 

    on the contrary, slightly optimize the "APP_BUFFER_Q_DEPTH" sometimes make sense, but 4 is already a good one.