• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CE: pointer to pointer

Curtis Newton
Intellectual 590 points


 

I use Codec Engine version 2.25.01 and has a IUNIVERSAL algo. Now I try to transer pointer-to-pointers from the GPP-side to the DSP. Before calling UNIVERSAL_process I fill the inBufs structure (XDM1_BufDesc) on the GPP:

inBufs.descs[1].buf = (XDAS_Int8*)pData;

inBufs.descs[1].bufSize = (XDAS_Int32)nb_data*sizeof(unsigned char*);

inBufs.descs[1].accessMask = 0;

 

pData is of type unsigned char**

pData and all pData[] are taken from the CMem using Memory_alloc();

 

On the DSP-side I try to use the data in pData:

pData=(unsigned char**)inBufs->descs[1].buf;

but pData[i][] has garbage in it (all zero exept first element)

Is there in general a problem with pointer to pointer and Codec engine? Or do I miss something else?

 

C.

 

  • 0
    TI__Genius 17205 points

    Yes, we can't support pointers-to-pointers in the inBufs (or outBufs or inOutBufs).  The reason is that the IUNIVERSAL GPP-side stubs (within the UNIVERSAL_process() API) perform address translation on 'known addresses' in the interface (e.g. inBufs.descs[i].buf).  It doesn't know that in your case the data in the buffer also contains addresses and needs to be address translated as well.

    Even if the ptrs issue were resolved, a similar issue will likely arise on the DSP side, where Cache Management is performed on 'known buffers'.  Again in this example, the IUNIVERSAL DSP-side 'skeletons' don't know you are passing buffers 'outside of the IUNIVERSAL interface', and won't perform any cache management on them.

    How many buffers are you trying to pass?  inBufs allows the app to provide up to 16 buffers as 'input'.  If you have more than that, you could consider using the inOutBufs array as well which will give you another 16 buffers (although they're treated as 'inout', you can use them as just 'in').

    A few other ideas if you're really stuck:

       * If your system is closed, and just has your one algorithm, you could hack up the IUNIVERSAL stubs and skels (codec_engine_###/packages/ti/sdo/ce/universal/*) to handle the address translation and cache management specific to your algorithm's needs.
       * If you know you don't need cache managed on the DSP side (e.g, your alg only accesses those buffers using DMA), you could perform the address translation in your app when filling in the inBufs (using the CMEM APIs for virt2phys translation).  You should only convert the addrs IUNIVERSAL doesn't know about - i.e. the ptrs _inside_ the inBufs data buffer.  And don't forget to phys2virt them after the process() call returns.
       * You could stop using IUNIVERSAL and create your own algorithm interface (CE is extensible and allows arbitrary interfaces to be integrated).  Using this, you can define your interface to be whatever you want, and since you know where the buffers are, you can address translate and cache manage them appropriately.  See the 'scale' example in codec_engine_###/examples/ti/sdo/ce/examples/extensions/scale + ...examples/codecs/scale and the CE Algorithm Creator's Guide section on "Supporting non XDM algorithms"

    Chris

  • 0 in reply to Chris Ring
    Intellectual 590 points

    Hi Chris,

     

    thanks for the answer!

     

    C.