TDA4VM: The difference between the output of SDE on SDK 6.02 and SDK 7.0

Hi,

Do you see this issue only for the last few lines? I think one or two lines at the end of the frames are padded, so does this affect your processing?

Regards,

Brijesh

Hi Brijesh,

Yes, only the last four lines. Why does SDK7's padding change compared to SDK6.2? And every time the power is turned off and restarted, the padding changes.Where is the padding made? Is it the SDE accelerator or the software?

Thanks!

Hi,

Compared to SDK6.2 release, are you running anything else along with SDE? like are you using/running DoF with SDE? 

i am still checking why it has changed and will get back as soon as possible.

Regards,

Brijesh

Hi Brijesh,

Hi Brijesh,

Need to confirm how many rows of padding in SDE, which will affect our next processing.

Thanks.

Hi,

I don't expect padding to be more than 1 or 2 lines. Since you are seeing difference of 4 lines, this is something difference. 

Do you use default app_stereo example with the supported images? I want to try recreating this issue, could you please help me with more information?

Have you done any changes in the application or configuration? 

Regards,

Brijesh

Hello DJI Team,

I checked this in the SDK7.0 release. The issue is, in the earlier release, buffer was memset to 0x0, but this is no longer due to optimizations. 

SDE does not really write last 4 lines, so it had some junk values. 

Ideally, algorithm should not process 4 pixels/lines on all 4 boundaries of the frames, because it does not contain valid information. 

The other solution is, the application can memory the buffer first time and then can use as it is.

Regards,

Brijesh

Hello DJI Team,

There are two solutions to this issue.

1, you could update the buffer allocation logic to memset buffer to 0x0, after allocation. So that all buffers are pre-filled with 0s before usage. This will require slight changes in the buffer allocation. But it can potentially delay starting of the graph, because as the graph grows and/or image size increases, it will take more time to memset buffers to 0.

2, You could ignore 4 pixels/lines around the boundary of the frame. I think this is easier solution. Algorithm can just ignore 4 boundary pixels/lines.

Regards,

Brijesh 

Hi Brijesh,

Thank you for replying.

Yes, the second solution is better. But if the first solution is used, how to modify it? Can you provide an example? Thank you!

Best regards,

Walter

Hi Brijesh,

Thanks for your support.

I used the default app_stereo test, but the configuration file is a bit different.

After reading your latest reply to this issue, do you still need to provide a configuration file?

Best regards,

Walter

Hi Walter,

Not really, please ignore that request.

Regarding first solution, vision apps uses DMA Buf implementation for the buffer management and its implemented in ti-processor-sdk-rtos-j721e-evm-07_01_00_11\vision_apps\utils\mem\src\app_mem_linux_dma_heap.c file. I think you could update API appMemAddTupleToList in this API to memset buffers to 0. I guess you want this for confirmation. 

If this is only for confirmation, you could even try to memset the buffer in the SDE node. When buffer reaches to SDE node, please memset it to 0x0, and you will see that last 4 lines are still 0 after processing completes. 

Regards,

Brijesh

HI Brijesh,

Thank you for the solution.I will confirm this solution.

There is other solution to this issue.

SDE Input:  left/right + 16 lines 0 padding . Ignore these 16 lines of padding when processing output.

Do you think this method can solve the problem.

Best regards,

Walter

Hi Walter,

The issue is in the output, not in the input. i am not sure how you will ignore 16 lines in the input, if you just move buffer pointer, it will not be valid, because ignored information is needed. Also even in this case, output will not be valid for 4 boundary pixels/lines.

Regards,

Brijesh

HI Brijesh,

Ok, already understand how to solve the problem.

In addition, we still have a question, why does the SDE accelerator not write data in the last 4 lines? For what reason?("SDE does not really write last 4 lines, so it had some junk values. ")

Thanks again for your support.

Walter

Hi Walter, 

Please refer to the specs for this. I believe it uses specific transform.

Regards,

Brijesh

Hi Brijesh,

I have checked the chip manual 《J721E_DRA829_TDA4VM_AM752x_SR1.0_NDA_TRM.pdf》,the output of SDE in the document shows that there are boarder pixels. Does the problem mentioned refer to boarder pixels? However, the document does not describe the boarder pixels of the SDE accelerator. Which version of the document describes the boarder pixels of the SDE? Thanks!

Best regards,

Walter