Linux/TDA2: VXLIB Remap Performance

Thanks for your question.

Explanation of difference you are seeing

All of the performance numbers listed in the test report reflect the core DSP performance without considering memory stalls.  Therefore it is a best case performance assuming all of the code and data are in L1 memory.  In reality, this is not usually possible, so these numbers give an idea of what the performance should not get better than.

Now I have done some testing to see what the performance is assuming all data and memory were accessed from DDR cached memory, and this kernel which used randomly generated remap table ranged from 23 to 82 cycles per output pixel on average.  When I ran the same test except put the code and data in DSP L2 memory, the performance improved to range from 10 to 30 cycles per output pixel.  Here is a summary of performances:

1. CPU only (no L2/DDR memory) : 7.5 cycles

2. Code/Data in L2: 10 to 30 cycles

3. Code/Data in DDR: 23 to 82 cycles

The difference between case 1 and 2 is the L1 cache miss penalty.  The difference between case 2 and case 3 is the L2 cache miss penalty to DDR.

The cache miss rate will vary based on remap table.  For example, a unity remap table will have a high cache hit rate since subsequent input pixel accesses will be on same cache line that was already fetched.

Proposal for Improvement

As seen above, the best thing you can do to improve performance is to process the data from L2 RAM.  Since the whole input image probably does not fit into L2 RAM, DMA the input from DDR into L2 RAM prior to calling this function.  This probably requires you to pipeline the processing in a ping/pong fashion across blocks of input/output.   What I mean is make a loop wherein you initiate a transfer of an input block into L2 RAM, and while the DMA is happening, call VXLIB function on a previously DMA'd block in L2.  When the VXLIB function is done, initiate the next transfer, and continue on until the end of the whole frame.

Since you are doing a remap, which blocks you transfer and how big the transfer is depends on the remap function you are doing.

Final Questions

After rereading your post, I'm curious why you are using remap for whole panorama.  Is most of the remap a copy, or does most every pixel get shifted/warped relative to input?  If you are primarily just appending input images together, you can use a DMA for all/most of the copy and that will be the fastest.