1. Not sure - Niclas (and others) can probably tell you. I _think_ you'll still need CMEM, as there are at least intermediate buffers which CMEM is used for... but I'll defer to somebody else as I don't know the demos very well. You can grep the demos for "Memory_allocContig" - if you find it, there's a dependency on CMEM.
2. CMEM is 100% ARM-side, so DSP servers don't have a dependency. Link doesn't have a dependency either. Only these have dependencies: * Codec Engine's ARM-side libraries (when "remote" codecs are used). In that configuration, CE's Memory_allocContig() APIs are implemented using CMEM. * Applications (like the demos) are allowed to call CMEM APIs if they wish. I'd recommend using the Memory_allocContig() APIs - as they're portable to other environments - but if portability isn't important, you can call CMEM API's directly. Chris > -----Original Message----- > From: George Gu [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 17, 2006 8:56 PM > To: Ring, Chris; Anderberg, Niclas; > [email protected] > Subject: RE: RE: RE: CMEM and video driver issues, need your help > > > Chris, > > Thanks first. > > There are two more questions: > 1. If I use current demos from DVEVM, like H.264 encode/decode, my > application will not need CMEM? > 2. Which modules depend on CMEM in current TI software > framework? DSPLINK or > CODEC SERVER or both? > > George Gu > (Xiangyu Gu) > Wintech Digital System Co. > Beijing, China > Ph: 8610-8278-2828 ext.168 > Fax: 8610-8278-0028 > http://www.wintechdigtal.com > ---------------------------- > > -----Original Message----- > From: Ring, Chris [mailto:[EMAIL PROTECTED] > Sent: 2006年12月18日 11:25 > To: George Gu; Anderberg, Niclas; > [email protected] > Subject: Fwd: RE: RE: CMEM and video driver issues, need your help > > 1. The only requirement is that the inBufs and outBufs > buffers which the > DSP operates on must be physically contiguous. The user can > achieve this in > several ways - one way is to get the buffers from a driver > which ensures > they're contiguous (like vpfe, as Niclas describes). Another > way to get > contiguous buffers, if there is no driver involved (e.g. > transcoding from > one file format to another) is to use buffers provided by > CMEM (or using the > portable Codec Engine Memory_allocContig() API calls). > > Again, Codec Engine doesn't care _how_ the application gets > the contiguous > buffers; CMEM or otherwise. > > 2. When the DSP decodes a video frame, the decoded frame is > written into > the outBufs, provided to the VIDDEC_process() call. These outBufs are > provided by the application; and as described in #1, they > must be physically > contiguous, and can be acquired however the application wishes. > > Chris > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > ] On Behalf Of George Gu > > Sent: Sunday, December 17, 2006 5:54 PM > > To: Anderberg, Niclas; > [email protected] > > Subject: RE: RE: CMEM and video driver issues, need your help > > > > Nicals, > > > > Thanks for your reply. I read your mail and have new questions: > > > > 1. If CMEM does not copy data, then what is the usage of > the pools of > > CMEM? > > 2. When DSP decode a video frame, it will put the raw data > in to DSP > > memory section----DDRALGHEAP, is it right? If yes, how > these data can > > be got by Linux Application? e.g. DSP will copy these data > into CMEM > > buffer pool? > > > > Thanks > > > > > > > > George Gu > > (Xiangyu Gu) > > Wintech Digital System Co. > > Beijing, China > > Ph: 8610-8278-2828 ext.168 > > Fax: 8610-8278-0028 > > http://www.wintechdigtal.com > > ---------------------------- > > > > -----Original Message----- > > From: > > [EMAIL PROTECTED] > > ncidsp.com > > [mailto:[EMAIL PROTECTED] > > nux.davincidsp > > .com] On Behalf Of Anderberg, Niclas > > Sent: 2006年12月15日 20:43 > > To: George Gu; [email protected] > > Subject: Fwd: RE: CMEM and video driver issues, need your help > > > > George, > > > > 1) The constraint for the DSP algorithms (actually the DSP core > > itself) is that they have to work on contiguous buffers. The vpfe > > device driver allocates it's own contiguous frame buffers in kernel > > mode and doesn't need CMEM. > > > > 2) Codec Engine doesn't copy the frame buffers, it just passes a > > pointer. > > The DSP and ARM *physical* memory maps are identical on Davinci. > > > > 3) loadmodules.sh contains the worst case for any of the encode, > > decode or encodedecode demos running (but not > simultaneously). If you > > only ever use one of the demos your pool selection would look > > different. > > For the demos, > > you can find every Memory_contigAlloc() call and see what the worst > > case buffer sizes are and put these in loadmodules.sh. > > > > 4) Non-cacheable from the ARM, but Codec Engine does manage > cache for > > these buffers from a DSP standpoint. > > > > Regards, > > Niclas > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > ] On Behalf Of > > George Gu > > Sent: Friday, December 15, 2006 8:24 AM > > To: [email protected] > > Subject: CMEM and video driver issues, need your help > > > > All, > > > > There are some questions about CMEM and video driver, which > need your > > help. > > > > 1. Does vpfe capture buffers located in Linux Memory space? > > If yes, how > > does them be transferred to DSP? I guess CODEC Engine will > copy them > > into CMEM buffer pool first and then DSP will use these > data in CMEM > > buffer pool, is it right? > > > > 2. Base on question 1, CODEC ENGINE copy the capture data > use DMA? or > > memory copy? > > > > 3. When insert CMEM.ko, there are some parameters, such as > pool counts > > and pool size, how can I determine these parameters when I use a > > certain codec combos, such as H264 encoder+ H264 decoder+mpeg4 > > decoder??? > > In TI's H264 > > encodedecode demo, I found > "pools=1x3145728,3x829440,1x61440,1x10240" > > (loadmodules.sh), why there is a pool with 3145728 byte? > > > > 4. The CMEM memory is non-cacheable both for ARM and DSP? > > > > > > Thanks very much. > > > > George Gu > > (Xiangyu Gu) > > Wintech Digital System Co. > > Beijing, China > > Ph: 8610-8278-2828 ext.168 > > Fax: 8610-8278-0028 > > http://www.wintechdigtal.com > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
