TDA4AL-Q1: How to improve the processing time at vxWaitGraph() in PC emulation mode

Dear TI experts,

Add more information.

We found the flow is calling vxScheduleGraph() before vxWaitGraph() in x86_app_run_graph().

We saw the waiting graph completed(vxWaitGraph()) time too long, seems is vxScheduleGraph() spent long time.

Could you help to improve this?

Thanks.

Main_x86.c (rtos-build\vision_apps\apps\basic_demos\app_single_cam)

static vx_status x86_app_run_graph(AppObj *obj)
{

APP_PRINTF(" Running graph ...\n");
start_time = clock();
status = vxScheduleGraph(obj->graph);
APP_ASSERT(status==VX_SUCCESS);
end_time = clock();
duration = (double)(end_time - start_time) / CLOCKS_PER_SEC;
APP_PRINTF(" Running graph to finish...duration = %f s\n", duration);

APP_PRINTF(" Waiting for graph to finish...\n");
start_time = clock();
status = vxWaitGraph(obj->graph);
end_time = clock();
duration = (double)(end_time - start_time) / CLOCKS_PER_SEC;
APP_ASSERT(status==VX_SUCCESS);
APP_PRINTF(" Graph finished...duration = %f s\n", duration);

Dear TI experts,

Is it possible the root cause is by using vxScheduleGraph() in x86_app_run_graph()?

vxScheduleGraph()

{

   ....

    graph->schedule_mode = (vx_enum)VX_GRAPH_SCHEDULE_MODE_NORMAL;   <= using this schedule mode, that "Schedule graph in non-queueing mode"

....

}

/*! \brief Schedule graph in non-queueing mode
*/
VX_GRAPH_SCHEDULE_MODE_NORMAL = VX_ENUM_BASE(VX_ID_KHRONOS, VX_ENUM_GRAPH_SCHEDULE_MODE_TYPE) + 0x0,

If yes, could we change schedule mode like VX_GRAPH_SCHEDULE_MODE_QUEUE_AUTO or VX_GRAPH_SCHEDULE_MODE_QUEUE_MANUAL?

Thanks

Alex

Hi Alex,

I am looking into this, will get back to you soon

Regards,
Gokul

Hi Gokul,

We found if we converse 10 RAW files, the color of 1st YUV file is normal, but the color of 2nd ~10th YUV files all are abnormal, the color will change to purple color.

Could you also help this color issue?

Ref files:
1st YUV - img_viss_0000.yuv
2nd YUV - img_viss_0001.yuv

Output-Yuv.zip

Config file:

x86_app_IMX728_RCCG.cfg

Thank you.

Hi Gokul,

In PC emulation mode, is it possible for the processing time to convert a RAW file to a YUV file to reach 50ms?

Thanks.

Hi May,

Host emulation uses C models for the hardware accelerators like vpac. And this C model performance is purely depends upon the host CPU that you are using.

AlexCW Kuan said:

If yes, could we change schedule mode like VX_GRAPH_SCHEDULE_MODE_QUEUE_AUTO or VX_GRAPH_SCHEDULE_MODE_QUEUE_MANUAL?

These scheduling modes are used in graph pipeline mode and your have to modify your application accordingly. This will not improve the node's processing time. It will improve the overall graph's performance when you have multiple nodes in it.

May Huang said:

We found if we converse 10 RAW files, the color of 1st YUV file is normal, but the color of 2nd ~10th YUV files all are abnormal, the color will change to purple color.

Could you also help this color issue?

Which application are you running and can you share your graph.

May Huang said:

In PC emulation mode, is it possible for the processing time to convert a RAW file to a YUV file to reach 50ms?

Can you mention the usecase for using host emulation, you can use host emulation to write your application and simulate it but you may not get the exact performance that you get from hardware.

If you want to reduce the processing time of c models then you can try with different host cpu that has higher compute or We have to involve 3rd party to optimize the c model to reduce the time.

Regards,
Gokul

Hi Gokul,

Thanks for your reply.

From your suggestion, we consider that it cannot reach about 50ms dealing one RAW to YUV in PC emulator mode.

We need to study how to implement RAW files to YUV files at target TDA4AL device via vpac DSP.

Our purpose to do lots of RAW files to YUV files is that our SV team will do road test and do video recording.

SV team will save all RAW files in road test in order to re-process these RAW files with new IQ tuning, that can reduce the number of road test.

Our PC emulator is running on Main_x86.c (vision_apps\apps\basic_demos\app_single_cam).

And we find the test_mode exist at App_single_cam_main.c (vision_apps\apps\basic_demos\app_single_cam) and seems to read RAW files to VISS at target,

but we had not found this test_mode can finally output to YUV files yet, can you comment us for this at this case ? Or we can raise new case to discuss with you.

Thanks

Alex

Hi Alex,

AlexCW Kuan said:

We need to study how to implement RAW files to YUV files at target TDA4AL device via vpac DSP.

Okay.

AlexCW Kuan said:

but we had not found this test_mode can finally output to YUV files yet, can you comment us for this at this case ? Or we can raise new case to discuss with you.

So you want to give raw image input from a file and save the yuv output ?

If so, can you refer to this faq, which modifies multi_cam demo to give file based input and you can use the existing save viss output image option to save the yuv output.

If you need more info on this topic please raise another thread.

Regards,
Gokul