TDA4VM: The delay from camera capture to eDP display is different in linux single process and multi process

Hi Cherry,

Please address my below queries.

1. By single process and multi process in Plan 1 and Plan2, do you mean that in plan 1, both capture and display is in the same graph? and in plan2 capture is in one graph and display is in another?

2. In Plan1, Does this graph only has capture node and display node?
    In Plan2, again is it only capture node in one graph and only display node in another graph?

3. Where is the start and end point for calculating this delay? is it from output of capture node to first frame on display?

4. In Plan 2, are you dequeuing from one graph and enqueueing into the second?

Regards,
Nikhil

Hi Nikhil,

Thanks for your support!

1.  Plan1,  capture and display  is in different  graph .  Plan2，  caputre is in one graph in process1  and display is in one graph is prcess2

2. Yes,  only caputre node and display node in plan1 and plan2.  Plan1,  capture and display  is in  different  graph  of 1 process,   Plan2 , only capture node is in one graph  in process1,  only display node is in one graph iprocess2.

3. They  use  the GTC timestamp to calculate the code function time consuming ，and take a  picture of ms timer and display  to calculate the capture and display delay. 

4. In Plan2,  dequeue the capture data from caputre node  and  tivxReferenceExportHandle  in prcocess 1 ,  get it  by tivxReferenceImportHandle  and display it in process2.

It's found that the delay of ipc of process1 and process2 is < 1ms,  and the time consuming  in vxProcessGraph is almost is Plan1 and Plan2 . So it is not enough to cause this problem. 

Thanks and regards,

Cherry

Hi,

May I know is there any updates regarding the question above?

Thanks and regards,

Cherry

Hi Cherry,

Understood the scenario in Plan 1.

Regarding the scenario in Plan 2, Could you please clarify if it is like a producer - consumer scenario between two processes where the file descriptors are being exchanged?
Also Is it possible to share the source code in order to review it?

Regards,
Nikhil

Hi Nikhil,

Yes, it is a server - client mode.  The  file descriptors  is exchanged by binder.

In server process:

vx_reference ref;

tivx_utils_ref_ipc_msg_t ipcMsg;

ref = (vx_reference)pmap_info->image;

ret = tivx_utils_export_ref_for_ipc_xfer(ref, &ipcMsg);
if (ret != VX_SUCCESS)
{
    LOGE("tivx_utils_export_ref_for_ipc_xfer() failed for object image");

    break;
}
for(INT32 i=0; i<ipcMsg.numFd; i++)
{
    fd32[i] = (int32_t)ipcMsg.fd[i];
    if(fd_desp)
    {
        fd_desp[i] = fd32[i];
    }
} 

send fd_desp by binder .

In client process：

int32_t fd[VX_IPC_MAX_VX_PLANES];
int32_t numFd;

vx_reference ref ;

vx_image image;

reveive fd by binder

for(int32_t i =0; i<numFd; i++)
{
    ipcMsg.fd[i] = fd[i];
}

ret = tivx_utils_import_ref_from_ipc_xfer(m_vxContext, &ipcMsg, &ref);
if(ret == VX_SUCCESS)
{
    image = (vx_image)ref;
}

Thanks and regards,

Cherry

Hi Cherry,

In this scenario, as the IPC and vxProcessGraph doesn't seem to be the issue,
Could you measure the time when the thread is getting scheduled?
Also the time taken from Dequeue to enqueue.

Regards,
Nikhil

Hi Nikhil,

The customer measured the GTC time in different process function. In the capture process,  as the fps is 30, the interval time of dequeue is about 33.3ms, the measure interval time is same, the time taker form  dequeue to enqueue is about  40 us ~ 80 us which should be OK.

In the display process,  they find the time of  vxProcessGraph is from  1 ms  to 21 ms  in eDP out  scenario, the cycle time is about  60 s( 1800 frames),  but in n CSITx out  scenario , the time of vxProcessGraph is always about  11 ms.  It is the same in Plan1. 

Is it a normal condition？

What is the difference  between  one process and multi process in tiOpenVx framework? For example, RAM, DMA and other H/W resource etc.

Thanks and regards,

Cherry

Hi,

Quick update: 

The customer  find a issue about  two or more processes uses OpenVX in  the rtos-sdk/tiovx/tiovx_release_notes.html of  SDK 08_01_00.

Could you help elaborate more on it or give more details?

Thanks and regards,

Cherry

Hi Cherry,

The issue TIOVX-1132 was as mentioned below

• low priority process takes spinlock
• then high priority thread wakes up and tries to spinlock.
• Since the spinlock is not available, it just spins/busy waits.
• Since lower priority thread does not get chance to run, it does not releases the spinlock and higher priority thread just keeps busy waiting.
  
  

This issue is fixed in SDK 8.1
May I know which SDK version is the customer using?
If the version is before SDK 8.1 could you try with below patch in the tiovx folder. This patch is the fix for the issue TIOVX-1132

/cfs-file/__key/communityserver-discussions-components-files/791/TIOVX_5F00_1132_5F00_Fix.zip