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.

What are the average performance of DM365 Resizer(It's very urgent)?

Can you tell me the average performance of DM365 resizer?

We use two DM365 resizers simultaneously(some kernel 2.6.18 modification is required).

Our pseudo code the followings.

Resizer->config(1280,720,1280,720,704,480,1,1);

Resizer->execute(srcBuf,dstBuf0,dstBuf1);

I want to know the average execution time of DM365 Resizer which converts 1280x720 into 1280x720,704x480 simultaneously.

My average measurement is 20ms. It's very terrible.

Please let me know. It is very urgent.

Thank you in advance.

  • 20ms doesn't sound too terrible.  What target performance do you need to meet?

    You can change the clock of the Resizer module using

    the clk_dv parameter:

    It specifies the ratio of the Resizer module clock to the SDRAM clock.

    The default value is 1/6.

    Since you are not up-sizing, you could probably increase the ratio to make resizing faster.

    For example, to make the ratio 1/2:

        rsz_ss_config.input.clk_div.m = 10;
        rsz_ss_config.input.clk_div.n  = 20;

     

     

  • What is the mode you are using for Resizer input? Is it DDR input (Single-shot mode) or ISIF input (continuous mode)? These mode are set in the resizer configuration.

     

    If it is continuous mode, then RSZ works on the input Pixel clock coming to the parallel port. There is nothing much that can be done on this clock input and time taken for RSZ to send the output will depend on this clock.

     

    I believe you are using single shot mode, where the input to RSZ is in the DDR and you want to do a resize operation from 1280x720 to 1280x720+704x480. In this mode, as John mentioned, the clock of resizer is derived internally from DDR clock. If you are using DDR clock of 243 MHz and the resizer default clocking of 1/6, then the RSZ clock becomes 40.5MHz. 1280x720 input is 921600 pixels, so time taken to consume the whole frame and dump out the data is 921600/40.5MHz = 22.75msec.

    You can surely get a better performance than this by changing clock divider. The maximum throughput that is possible will depend on your system load. In a negligibly loaded system, you can take this divider to 1/2 which means RSZ clock of 121.5MHz, which translates to 7.5msec

     

    Regards,

    Anshuman

  • Thank you for your help.

    When SINGLE_SHOT_MODE is used and set clock divider 1/3, some strange effects appears. Captured file is attached.

    As you can see, there are some "flicker effect" which is red box in attached file. What is the cause of this effect?

    Data flows are the followings.

    V4L2(1280,720)->Resizer(1280,720,1280,720,704,480)->H.264 encoder(1280,720)->network streaming.

     

  • Thank for your help.

    We have resolved Resizer performace problem by setting Resizer as continuous mode.

    But, the above problem appears in continuous-mode.

    What is the cause of this bad effect?

     

     

  • Hello,

    I'm trying to reduce the time required to resize a 720p image on DM365 270Mhz, DDR2 at 216Mhz. My setup is this:

    capture (DDR) -> resizer A (DDR, SS mode) -> encoder

    I've edited linux/Resize.c in DMAI source code to print/modify the clk_div.m and clk_div.n for the resizer A in SS mode. If I leave M=1 N=6 or even M=1 N=4, everything works. A resize operation requires about 26ms or 18ms in the second case.

     

    If I try with M=1 N=2 (or M=10, N=20) the resize time drops to 8ms, but the image is severly ruined. The effect is like an horizontal tearing of the encoded image:

    Can you please help me with this issue?

     

  • Did you figure out the reason to cause the flicking issue?

    I am having the similar problem now and any help will be appreciated.

  • Hi,

    no I've never had the time to investigate further. Basically, I've not been able to make the resizer work faster than the basic setting (or with slightly better timings, but not much better). Since output (and input) buffers used to resize are always the same, I suspect that the "tearing" is caused by the resizer failing to complete its job. The effect is that the previous content of the buffers shows when current resize job shows: since resizing starts from the top of the buffer, if it stops before completing, the remaining buffer shows the content of previous resizes. Since there are 3 such buffers, the effect shows as a tearing and you don't notice that the lower part of the image is something resized in the past.

    About the actual cause, I don't know. I suspect that high memory bandwidth requirements by edma, arm and encoder/decoder can cause it. Still, I have no proof.

    The net result is that I cannot make the resize work at higher frequencies.

     

  • Did you figure out the reason to cause the flicking issue?

    I am having the similar problem now.  I use dm368 with 340Mhz DDR.  RSZ works in continues mode.  The image resolution is 1600*1200.

    any help will be appreciated.

  • HI Anshuman,

    Present settings of my resizer clock divider is 1/8 for 640x480 and its taking 15ms for resize.
    DDR clock = 243Mhz
    When I tried to chage it to 1/3 its reduced to 8ms.
    I am getting flickering noise when I set to 1/2.
    would clock divider 1/2 works properly? how to fix this? 
    Regards,
    Mahesh