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.

[MCSDK Video] How to re-launch PCIE demo without reset and dnld DSP?



Hi All,

Follow instructions of MCSDK VIDEO 2.1 PCIE Demo Guide(http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_PCIE_Demo_Guide#Run_Video_Demos),
We use following scripts to launch PCIE demo.
./reset_dsp.sh <cpu_frequency>
./dnld_dsp.sh <num_dsps>
./demoSave2File.sh
Even if we want to re-launch the demo, it still need to reset dsp and download dsp image again, we can't execute demoSave2File.sh twice.
How can I modify it to support re-launching without download image again?

Test Environment:
OS: Ubuntu 12.04.1 LTS 64bit
DSP: Lightning (DSPC-8681E)
SDK: mcsdk_video_02_01_00_08,  Desktop Linux SDK 01.00.00.07

Best Regards,
Harvey

  • Hi Harvey,

    Can you please let us know the motivation of relaunching the demo without reset and download? If you are trying to demo multiple input clips, you can add more entries in multiClip.cfg as described in Wiki: http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_PCIE_Demo_Guide#Codec_Re-configuration

    Thanks,

    Hongmei

  • Hi Hongmei,

    My use case will receive real-time encoding tasks, while receiving a encoding task it will launch a host application and assigned to use one idle DSP or idle cores. Then if the second task coming, it will launch another host application and use other idle DSP or idle cores.
    And when a task is finished, it can make the assigned DSP or cores be available for other task to use it again.
    If we want to use the same core again, we have to reset and download DSP first, it will interrupt other running tasks.

    Best Regards,
    Harvey

  • Hi Harvey,

    Thanks for the information. In order to achieve what you described, major changes on the host  are needed. Currently we cannot run two or more MCSDK Video host applications at the same time, since the host application manages part of the DSP memory.

    On the DSP side, after the encoding task is completed, each core can go back to query messages sent from the host. Currently there are four host to DSP message types, as processed in siuVctRunMediaTask. Additional host-DSP message types can be added to reallocate a core for executing new tasks.

    switch( rxMsg->msgId)

    {
    case HOST2DSP_MEDIA_CONFIG_REQ:
    ...
    case HOST2DSP_MEDIA_PROCESS_REQ:
    ...

    case HOST2DSP_MEDIA_FLUSH_REQ:
    ...

    case HOST2DSP_MEDIA_STATS_REQ:

    ...

    You mentioned "encoding task". Can you please let us know more details about the tasks in your application? Is it just video encoding? or it can be video encoding or decoding? or it can be some other processing on video, such as resizing? Is the content limited to video, or there can be audio or something else?

    Thanks,

    Hongmei

  • Hi Hongmei,

    Yes, the "encoding task" is just video encoding task.

    Can I use JTAG to trace the DSP program when running the PCIE demo?
    I have tried loading sv04.out by JTAG, but it seems will run tftp mode.

    Best Regards,
    Harvey

  • Harvey,

    Once you download the DSP (from host), then connect with CCS/JTAG. You'll need to "load symbols", not "load program". 

    Loading the program would overwrite the DSP image downloaded by host. The default behavior of sv04.out is to operate in TFTP mode, which will be changed during download from host.

    Regards,

    Vivek

  • Hi,

    I have used JTAG to trace DSP while running MCSDK Video PCIE demo.
    When I run demoSave2File.sh second time without reset and re-download dsp image, DSP can receive and try to create the new task.
    But it will be failed when assign resource.
    CCS log:
    ...
    [C66xx_0] Algorithm Instance Creation Done @ core 0...
    [C66xx_0] Assign Resource Failed for core 0.. Exiting

    Why assign resources will be failed when executing the second task and how to fix it?

    Best Regards,
    Harvey

  • Hi Harvey,

    This issue can happen when the RMAN resources are not freed in the first time of running the encoding task. Using H264HP encoder as the example, siu_osal_fc_free_resources( ) is called in xdm2p0_vid_enc_delete( ). Host needs to trigger DSP to execute xdm2p0_vid_enc_delete( ) after encoding is completed so that RMAN resources can be freed.

    Thanks,

    Hongmei

  • Hi Harvey,

    We wonder if our proposed change has addressed the issue or not. Please let us know if it has fixed the issue or any further help is needed.

    Thanks,

    Hongmei

  • Hi Hongmei,

    Because DSP will receive HOST2DSP_MEDIA_CONFIG_REQ message before starting a encoding task, I modify siuVctRunMediaTask() to execute xdm2p0_vid_enc_delete() when process HOST2DSP_MEDIA_CONFIG_REQ case.
    After the modification the demo application can run twice successfully, but It still have problem while running third time.
    DSP gets into infinite loop of custom_exception_handler()  after calling fxns->algInit(alg, memTab, p, params)) in ALG_create().

    Thank you,

    Harvey


  • Hi Harvey,

    Which codecs are you testing and seeing the exception?

    Thanks,

    Hongmei

  • Hi Harvey,

    If you are testing mullti-core codecs (e.g., H264HP encoder), code change is needed for siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem() in dsp\siu\ividmc\siuVidMc.c in order to handle memory alloc-free-realloc correctly.

    In the current code, there is a Shared_MemTab structure which stores the array of base pointers that are allocated (XDAS_Int32 *baseptr[IVIDMC_MAXCORES][IVIDMC_SHMEM_NUM_KEYS]). These pointers are allocated using a global array which is mapped to the shared memory region (SL2 or DDR).

    In siuVidMc_Map_Shmem(), the allocation is done by incrementing the pointer to the global array by the size of memory which is already allocated.

    In siuVidMc_Unmap_Shmem(), it sets the baseptr[core_id][shmem_key] to NULL. There is no mechanism to keep track of which chunk of the global array is free and can be be allocated for further requests.

    Because of the above, if we call siuVidMc_Unmap_Shmem() to free all the allocated shared memory regions, and then call siuVidMc_Map_Shmem() again in the next encoding task, the global variable which stores the size of memory already allocated is still the same as that before siuVidMc_Unmap_Shmem() is called. Also, the global pointer which  is used to allocate memory is still offset by that size. Therefore, siuVidMc_Map_Shmem() will soon return an error saying that it has run out of memory.

    Please modify the above two functions accordingly and let us know if that can resolve the issue or not.

    Thanks,

    Hongmei

  • Hi Hongmei,

    Yes, I use pcie_h264enc_demo of mcsdk_video_02_01_00_08.

    I set breakpoints in siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem(), but the breakpoint in siuVidMc_Unmap_Shmem() is never hit.
    Should I call any function to trigger siuVidMc_Unmap_Shmem().

    Thank you,

    Harvey

  • Hi Harvey,

    If xdm0p9_vid_enc_delete() is called, there will be a call chain of ALG_delete() --> fxns->algFree(). Internally inside the codec, fxns->algFree() will trigger siuVidMc_Unmap_Shmem() if there are more than 1 cores in the core team mapping. How many cores are there in your test case? If it is 1, siuVidMc_Unmap_Shmem() will not be triggered.

    BTW, we are obsoleting H264BP encoder since H264HP encoder (which can handle BP/MP/HP encoding) is already in place and has been integrated in MCSDK Video 2.1.0.8. Is it possible for you to use H264HP encoder instead?

    Thanks,

    Hongmei

  • Hi Hongmei,

    Sorry, my previous reply is incorrect, actually I use pcie_h264hpenc_demo(H264HP Encoder) of mcsdk_video_02_01_00_08.
    I have tested both 1 and 2 cores, it will call xdm2p0_vid_enc_delete() before start a new encoding task, but the breakpoint in siuVidMc_Unmap_Shmem() is still never hit.

    Thank you,

    Harvey

  • Hi Harvey,

    Thanks for the information. Yes, you are right. The H264HP encoder internally is not calling siuVidMc_Unmap_Shmem(). We will report this issue and fix it in the future codec release.

    For now, please try triggering siuVidMc_Unmap_Shmem() from xdm2p0_vid_enc_delete(). Please also make changes as needed in siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem() so that "alloc - free - realloc" of the shared memory regions can be correctly done.

    Thanks,

    Hongmei

  • Hi Hongmei,

    Thank you for your reply.

    I have no idea about what parameters I should set to siuVidMc_Unmap_Shmem() in xdm2p0_vid_enc_delete().
    Could you give me a guideline or if you can provide a patch that would be a great help.

    Thanks,

    Harvey

  • Hi Harvey,

    If your application calls xdm2p0_vid_enc_create() every time when running the encoding, the shared memory buffers are reset in siuVidMc_Init_ShmemTab(). In that case, the problem you saw should not be related to the issue with siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem(). Please verify this by setting breakpoint in siuVidMc_Unmap_Shmem() and stepping into it to see if the exception happens from there.

    When the exception happens, can you please check CCS-ROV for possible errors? What is B3 in the exception log?

    Thanks,

    Hongmei

  • Hi Hongmei,

    Yes, my application calls xdm2p0_vid_enc_create() every time when running the encoding task.

    The breakpoint in siuVidMc_Unmap_Shmem() is never hit, the exception happens in siuVidMc_Map_Shmem():

    ...
          if (codecShm->shmemsize_DDR2_uncached > shmem_size) {
            shMem = codecShm->shmem_DDR2_uncached;
            codecShm->shmem_DDR2_uncached += shmem_size;
            codecShm->shmemsize_DDR2_uncached -= shmem_size;
          } else {
    ->        siu_exc_assert (0, SIUMGR_EXC_EXT_SHM_OVERFLOW | SIU_EXCEPTION_TYPE_CHANNEL, inst);
          }
    ...
    When the exception happens, codecShm->shmemsize_DDR2_uncached = 312576 and shmem_size = 16617968, so it get into the else case.
    My test case is use the demoSave2File.sh script of pcie_h264hpenc_demo and assign to single core 0, the issue will occur while running third time.

    Thank you,

    Harvey

  • Hi Harvey,

    Thanks for the information. According to what you are providing, we have two questions.

    1) Internally in H264HP encoder, the codec requests shared memory regions in cached DDR only. However, in your application, it looks like there are requests for shared memory regions in non-cached DDR. Can you please check what triggers this non-cached DDR request? You can check this from the call stack.

    2) As we mentioned earlier, xdm2p0_vid_enc_create() calls siuVidMc_Init_ShmemTab(), inside which the whole codecShm is reset, including

    codecShm->shmemsize_DDR2_uncached  = codecShmHandle->extShmSizeUncached;

    For codecShmHandle->extShmSizeUncached, it is set as 0 in vct\src\siuVctInit.c: codecShmHandle->extShmSizeUncached= 0; 

    However, in your application, codecShm->shmemsize_DDR2_uncached has a non-zero value. Can you please check when and how it got this non-zero value? This can be checked using hardware watchpoint after its initialization in siuVctInit.c.

    One tip for debugging in case you didn't know: the optimization flags in dsp/mkrel/c64x/makedefs.mk can be temporarily commented out as follows. 

    #C_OPT_FLAGS  = -mt -mw -os -o3 --optimize_with_debug

    Then, remove existing .oc files and rebuild sv04. This will allow stepping into every line of the sv04 framework code.

    BTW, we tried the calling sequence of create/process+flush/delete for 15 iterations, and it works fine.

    Thanks,

    Hongmei

  • Hi Hongmei,

    1) You are right, I copied the incorrect code segment, The exception happens in CACHED DDR case. You can check the attached snapshot again.
    ScreenShot.png

    2) When first time siuVidMc_Init_ShmemTab() is called, codecShm->shmem_DDR2 and codecShm->shmemsize_DDR2 can be init by the code:
      if ( codecShm->shmem_DDR2 == NULL ) {
        codecShm->shmem_DDR2      = codecShmHandle->extShm;
        codecShm->shmemsize_DDR2  = codecShmHandle->extShmSize;
      }
    But after first init, codecShm->shmem_DDR2 is set as non-null value, so codecShm->shmem_DDR2 and codecShm->shmemsize_DDR2 won't be reset anymore.
    codecShm->shmemsize_DDR2 will be getting lower after siuVidMc_Map_Shmem() is triggered, until codecShm->shmemsize_DDR2 < shmem_size and get into exception.

    Can I remove the if conditions in siuVidMc_Init_ShmemTab()?
    ...
    //  if ( codecShm->shmem_SL2 == NULL )
    ...
    //  if ( codecShm->shmem_DDR2 == NULL )
    ...
    //  if ( codecShm->shmem_DDR2_uncached == NULL)

    Should I use any other method to reset codecShm->shmem_DDR2 ... ?

    Thank you,

    Harvey

  • Hi Harvey,

    Thanks for the confirmation. From what you provided, it looks like you are using the multi-channel patch release on top of MCSDK Video 2.1.0.8. The if  NULL checks were added for supporting multiple channels on C6678.

    If your testing/application is for single channel only, you can remove the if checks. With that, you should be able to run the encoding many times.

    When multi-channel is needed, you can try resetting "codecShm->shmem_SL2", "codecShm->shmem_DDR2", and "codecShm->shmem_DDR2_uncached" in xdm2p0_vid_enc_delete() after calling ALG_delete(), assuming that all the channels have completed the encoding by that time.

    We mentioned earlier that the H264HP encoder is not calling siuVidMc_Unmap_Shmem() to free shared buffers. This will be fixed in the next release of H264HP encoder. With that fix and appropriate changes in siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem(),  we will have a cleaner way to handle alloc-free-realloc of shared buffers. For now, please try the workarounds above.

    Thanks,

    Hongmei

  • Hi Hongmei,

    Thanks for your help.
    Could you let me know, when will you release new H264 HP encoder and related patch.

    Best Regards,

    Harvey

  • Hi Harvey,

    We are planning to make an engineering release of H264HP encoder early next week. We will let you know when the release is ready.

    Thanks,

    Hongmei

  • Hi Harvey,

    Attached below please find the engineering release of H264HP encoder. Please update to use the encoder lib (h264hpvenc_ti.le66) from this new installer. There are no API changes from the GAed H264HP encoder (1.0.0.1).

    6646.C66x_h264hpvenc_01_00_01_03_ELF.zip

    With this new codec lib, siuVidMc_Unmap_Shmem() is expected to be called when deleting the codec instance. Please verify this by setting a breakpoint in siuVidMc_Unmap_Shmem() to see whether it is getting hit.

    After verifying the above, code changes are needed for siuVidMc_Map_Shmem() and siuVidMc_Unmap_Shmem() to correctly handle memory alloc/free/realloc as mentioned in our earlier discussion. One way is to use BIOS APIs: use Memory_calloc() to get shMem in siuVidMc_Map_Shmem(), and use Memory_free() to free shmem_base in siuVidMc_Unmap_Shmem(). One example of using Memory_calloc() and Memory_free() can be found in MCSDK Video dsp\siu\osal\bios6\siuFcBios6.c: functions siuFcAllocExtMemory() and siuFcFreeExtMemory().

    Please let us know if there are any further questions/issues.

    Thanks,

    Hongmei

  • Hi Hongmei,

    Thanks for your help.
    The breakpoint in siuVidMc_Unmap_Shmem() can be hit after updating the new H264HP encoder.

    I have a question about the usage of Memory_calloc().
    The first argument type of Memory_calloc() is xdc_runtime_IHeap_Handle.
    How to get or create the xdc_runtime_IHeap_Handle, when I want to call Memory_calloc() in siuVidMc_Map_Shmem()?

    Thank you,
    Harvey

  • Hi Harvey,

    xdc_runtime_IHeap_Handle can be obtained via calling HeapMem_create(), as shown in function siu_fc_heap_create() in MCSDK Video file dsp\siu\osal\bios6\siuFcBios6.c. In this function, you can refer to how external heap is created. For symbols _lcf_bios_fc_external_heap_begin and _lcf_bios_fc_external_heap_end, please refer to MCSDK Video file dsp\ggcfg\build\hdg\sv01\ggvf0.becmd for how they are defined along with the corresponding memory in external DDR.

    Thanks,

    Hongmei

  • Hi Hongmei,

    I used the symbols _lcf_bios_fc_external_heap_begin and _lcf_bios_fc_external_heap_end in siuVidMc_Init_ShmemTab() directly, but it caused compile errors:
     ...
     undefined                            first referenced                        
      symbol                                  in file                             
     ---------                            ----------------                        
     _lcf_bios_fc_external_heap_begin     ../../siu/c64x/make/siu.lib<siuVidMc.oc>
     _lcf_bios_fc_external_heap_end       ../../siu/c64x/make/siu.lib<siuVidMc.oc>
     ...
     
    Should I define these symbols in dsp\ggcfg\build\hdg\sv04\ggvf0.becmd?
    Actually, I have no idea about how the ggvf0.becmd works, can I just copy related statements from dsp\ggcfg\build\hdg\sv01\ggvf0.becmd to dsp\ggcfg\build\hdg\sv04\ggvf0.becmd without any modification?

    Thank you,
    Harvey

  • Hi Harvey,

    Yes, those symbols need to be defined in dsp\ggcfg\build\hdg\sv04\ggvf0.becmd, along with the section, e.g.,

    _lcf_shm_external_heap_begin = __lcf_shm_external_heap_begin;
    _lcf_shm_external_heap_end = __lcf_shm_external_heap_end;

    ...

    .shmHeap > DDR_CACHED
    {
    __lcf_shm_external_heap_begin = .;
    . += 0x2000000;

    __lcf_shm_external_heap_end = .;

    } PAGE 0 type = NOINIT

    Please note that this heap is replacing shared_mem_DDR2[] in sinVctInit.c.  So, the size above is set as 0x2000000, and it can be placed in DDR_CACHED. Meanwhile, EXTERNAL_SHARED_DATA_MEM_SIZE in sinVctInit.c shall be reduced to a small number (e.g., 128 for space holder) in order to get the memory for the above .shmHeap.

    ggvf0.becmd is just the linker command file for the video builds. The only difference is its ability to handle multicore and multichanel cases (parsed by Perl), such as:

    From sv04 ggvf0.becmd:

    /* foreach $ch in (1..NUMCH) expand */
    .gg_ch$(ch) > DATA_CH$(ch) PAGE 0
    /* endfor $ch */

    From sv01 ggvf0.becmd:

    /*----------------------------------------------------------------------------*/
    /* foreach $core in (1..8) expand */
    /*----------------------------------------------------------------------------*/
    DATA_SCRATCH_CORE$(core): origin = $(0x0C180000 + (($(core)-1) * 0x50000)), length = 0x50000 /* Remember to change ggmemmap.beh */
    /* endfor $core */

    Thanks,

    Hongmei

  • Hi Hongmei,

    It works after defining related symbols in dsp\ggcfg\build\hdg\sv04\ggvf0.becmd.
    Thanks for your help.

    Best Regards,
    Harvey