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.

Video Driver Buffers and Codec memory space

Hi,

1. Working on the DM6446, I have customized the driver to allow the number of buffers allocated in the driver configurable through a command line argument. However, for counts above 4, I find that the allocation fails. I have a 256MB board and use 62MB for linux pool. I think 5 buffers of 720x605x2 bytes size should be allocatable in the present configuration. Can anyone comment?

2. The total memory on the board is shared by the linux pool and the codec engine space. Does allocating extra memory in the CMEM space vis-a-vis increasing the driver buffers has any trade-off in terms of DSP system performance?

Thanx!

Sundar

  • Hi Sundar

    1) Are we talking VPBE or V4L2 video driver?  What APIs are you using to allocate buffers, linux kernel APIs, Linux user space APIs, or CMEM APIs?  If you are working with VPBE driver, you may be exceeding maximum buffer size allowed by Linux kernel; we ran into this problem when implemeting the following App Note:

    http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=1302&abstractName=spraan0

    We got around this by modifying a couple of header files (see app note for details), although I am hesitant to recommend modifying any of the standard Linux header files unless yo have a good reason to do so.  Why do you need 5 buffers?

    2) based on DVSDK software architecture we provide, ARM, CMEM and DSP meory spaces are defined in advance by the system integrator; this means that even if you do not use all the memory allocated for CMEM, DSP will not use it either (except for passing buffers back and forth to ARM).  If as a system integrator, you increase the amount of memory available to CMEM, you must decreade the amount available to ARM ad/or DSP, and of course this could theoretically reduce performance depending on how software processes are using memory. 

  • Juan,

    1. My video display driver buffers are being used amongst multiple encoders and the VPBE on the same DSP. In order to avoid a sort of lock up of buffers between any encoders and the VPBE, I want to increase the number of buffers allocated in the driver.

  • You should have plenty of space there to allocate the buffers, since each additional frame buffer is not even 1MB, but it may be worth redefining your memory map to see if that has any effect. One thought on this is that the buffers must be contiguous in physical memory for the VPSS to work on them, so if you have space but still cannot allocate it, this could just be due to lack of enough contiguous space. Unfortunately I am not sure how best to fix that off hand, though making more space available for the allocation could help to show if that could be the issue.

  • Sundar said:

    Juan,

    1. My video display driver buffers are being used amongst multiple encoders and the VPBE on the same DSP. In order to avoid a sort of lock up of buffers between any encoders and the VPBE, I want to increase the number of buffers allocated in the driver.

    If you are working on the driver buffers (as it appears you are from your comments above), you should note that even though Linux OS has plenty of memory available for these buffers, you have certain limitations to adhere to.  As Bernie suggested, buffers need to be contigious ans this is ensured by the order in which the VPBE driver loads and the APIs it uses for allocating its buffers (explanation is sort of complex, just be assured that there is a special memory range used by Linux drivers that ensured contigous buffers during boot up).  That takes care of the contigous requirement.  The other limitation like I suggested above is that there is a limit to the maximum buffer size allowed as defined in the standard Linux header files; since FBDEV allocates one huge buffer (proportional to the size x number of buffers used ), increasing the number of buffers to 5 or the size (as we did in our App Note http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=1302&abstractName=spraan0) may cause this max buffer size limitation to be exceeded.  You may be experiencing this.  We worked around this by modifying the standard Linux header files to increase the size limit, but as I mentioned earlier, it is never a good idea to modify standard Linux header files.