> > I looked at this yesterday evening (thanks to derf, crashanddie, and others > > for answering my C questions), trying to move some parts of the priv > > structure to SARAM (sorry for the SRAM typo above). Unfortunately just > > moving the bare minimum (the X array) won't happen as there's not enough > > SARAM (so dsp_dld tells me). I don't know where it's all gone, anyone have > > any ideas? > > Do you use any buffers allocated by malloc? My guess is that malloc > does allocation of DARAM and SARAM memory. > In any case, memory returned by malloc should be not worse than the > memory buffer explicitly statically placed to EXTMEM.
Yes, I think you're right, in the avs_kernelcfg.cmd file it talks about a DARAM_heap and a SARAM_heap, presumably it's possible to allocate from either somehow (using the CSL MEM_* calls probably, I don't know off hand which heap is used for task data, but will have a look this evening). It also talks about a/the stack being in SARAM. To answer the question, only if the thing to be malloc'd is small. In this case it's only a couple of structures (and they are large), so I've manually created them in EXTMEM2. I know this is not ideal, but they won't fit in SARAM. Over lunch I had a play with the things I talked about in my last email. Removing the memcpy (from the slow SDRAM X[] array to the fast SARAM fast_in[] array) made the code marginally slower - at least there were more drop outs, so it appears that the memcpy() overhead is less than the extra time needed to access the data in SDRAM. I shaved a few array elements off the output[] SARAM array (down from 100 to 78 elements, this fits the current Bluez encoder parameters, but if they were changed upwards, both the input[] and output[] arrays would probably need to be made bigger). I also removed the #PRAGMAs I had been using to place the const data from sbc_tables.h in SARAM as from looking the avs_kernelcfg.cmd file, .const data is already placed in SARAM (SARAM_DATA section) and I thought this might free up some room to fit the X[] array in SARAM directly. It didn't. Moving the const tables freed 72x32bits, removing the fast_in[] array (not needed if X[] itself is fast) freed 80x32bits, but the X[] array requires 2x160x32bits. It still doesn't fit :( Brad (Midgley) was talking earlier about implementing zero-copy; this would be good as then at least some of the data could be left in the SARAM input/output arrays (both faster because these are SARAM and because it doesn't need a copy). I'll have a look at this. So onto trying to optimise the inner loop... Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
