TDA4VM: Graph dequeue is blocked at high lanebandspeed

Hi HK Chu,

Graph parameter and lane speed are not related. Graph parameter is SW concept, whereas lane speed is set in the HW. If you are not using capture node's output as graph parameter, which node's output is graph parameter? In this case, please make sure to not enqueue/dequeue parameter from capture node. 

Also if you are using LDC node's output as graph parameter, are you still providing/priming enough buffers to the LDC node? 

Where is the output of LDC node connected? Is it connected to Display? Then please make to enqueue 2 to 3 buffers to the LDC node..

Regards,

Brijesh

Thanks, Brijesh 

I'm also confused why the lane speed setting affects the graph.
I am using the output of the LDC node as graph parameter, I created the output of the LDC in the graph init phase. Here is how the buffer is created and how I use it.

1. Create the buffer.

vx_image ldc_output;
ldc_output = vxCreateImage(obj->context, 
                obj->sensorObj.image_width,
                obj->sensorObj.image_height, 
                VX_DF_IMAGE_NV12);
for(i=0; i < APP_PIPELINE_DEPTH; i++)
{
    if(status == VX_SUCCESS)
    {
        obj->ldc_out_nv12_array[i] = vxCreateObjectArray(obj->context, (vx_reference)ldc_output, 
                                                            obj->sensorObj.num_cameras_enabled);
        status = vxGetStatus((vx_reference) obj->ldc_out_nv12_array[i]);

        obj->ldc_out_nv12[i] = (vx_image)vxGetObjectArrayItem((vx_object_array)obj->ldc_out_nv12_array[i], 0);
        status = vxGetStatus((vx_reference)obj->ldc_out_nv12[i]);
    }
}
vxReleaseImage(&ldc_output);

2. Graph parameters queue params configration

graph_parameter_index = 0;
add_graph_parameter_by_node_index(obj->graph, obj->ldcObj.node, 7);
obj->captureObj.graph_parameter_index = graph_parameter_index;
graph_parameters_queue_params_list[graph_parameter_index].graph_parameter_index = graph_parameter_index;
graph_parameters_queue_params_list[graph_parameter_index].refs_list_size = APP_BUFFER_Q_DEPTH;
graph_parameters_queue_params_list[graph_parameter_index].refs_list = (vx_reference*)&obj->ldc_out_nv12[0];
graph_parameter_index++;

3. Enqueue inputs during pipeup dont execute

    if(obj->pipeline < 0)
    {

        /* Enqueue inputs during pipeup dont execute */
        if (status == VX_SUCCESS)
        {
            status = vxGraphParameterEnqueueReadyRef(obj->graph, parameter_index,
             (vx_reference*)&obj->ldc_out_nv12[obj->enqueueCnt], 1);
        }
        obj->enqueueCnt++;
        obj->enqueueCnt   = (obj->enqueueCnt  >= APP_BUFFER_Q_DEPTH)? 0 : obj->enqueueCnt;
        obj->pipeline++;
    }

4. /* Execute 1st frame */

Same with step 3.

5. Run graph dequeue

status = vxGraphParameterDequeueDoneRef(obj->graph, parameter_index,
         (vx_reference*)&frame_deq, 1, &num_refs);

6.  Run graph enqueue

vxGraphParameterEnqueueReadyRef(obj->graph, parameter_index,
             (vx_reference*)&frame_enq, 1);

Hi HK Chu,

Display keeps the last buffer enqueued and does not return until new buffer is enqueued. So can you please make sure that atleast 2 buffers are always enqueued? 

Regards,

Brijesh

Hello Brijesh,
Sorry, I forgot to answer, I didn't use the display node.
The depth of the graph pipeline is set to 8. As you can see from the following log, 8 buffers are enqueued, but the dequeue is blocked.

I noticed that dequeue number(178) and enqueue number(177) are not the same. Is this the reason?

    12.515286 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=57)
    12.515319 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=190, pipe=0)
    12.515329 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=53, pipe=0)
    12.515346 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=62)
    12.515360 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=191, pipe=1)
    12.515366 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=96, pipe=1)
    12.515380 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=67)
    12.515390 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=192, pipe=2)
    12.515397 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=97, pipe=2)
    12.515415 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=72)
    12.515428 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=193, pipe=3)
    12.515435 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=98, pipe=3)
    12.515448 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=77)
    12.515458 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=194, pipe=4)
    12.515465 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=99, pipe=4)
    12.515477 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=82)
    12.515495 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=195, pipe=5)
    12.515501 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=100, pipe=5)
    12.515514 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=87)
    12.515530 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=196, pipe=6)
    12.515538 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=101, pipe=6)
    12.515550 s:  VX_ZONE_INFO:[tivxDataRefQueueEnqueueReadyRef:89] Q (queue=177, ref=92)
    12.515560 s:  VX_ZONE_INFO:[ownGraphScheduleGraph:767] Scheduling Graph (graph=197, pipe=7)
    12.515566 s:  VX_ZONE_INFO:[ownNodeKernelSchedule:630] Scheduling Node (node=102, pipe=7)
    12.615665 s:  VX_ZONE_INFO:[tivxDataRefQueueDequeueDoneRef:162] DQ (queue=178) .. NO BUFFER
    
    

Hi HK Chu,

Could you please confirm if the MCU2_0 core is still running or is it hanged?

From the above logs, i believe you have enabled the VX_INFO logs too right?
Could you also run "source ./vision_apps_init.sh" before running the application to get the remote core logs too?

And could you share the full logs with VX_INFO logs enabled?

This could exactly say where is it hanged / halted in the remote cores.

Regards,

Nikhil