search

monome / aleph

open source sound computer
Other
80 stars 39 forks source link

bfin profiling #223

Open electropourlaction opened 9 years ago

electropourlaction commented 9 years ago

faster sample I/O to enable more delays and reverb like timbres. I don't have any answers at this moment but willing to help.

catfact commented 9 years ago

is this different from issue #62? if not, can we just keep the discussion there?

electropourlaction commented 9 years ago

This issue would be about SDRAM access when audio processing is enabled, and related stuff.

catfact commented 9 years ago

i still don't quite know what you mean. you want SDRAM access in general to be faster somehow?

electropourlaction commented 9 years ago

yes, if that makes any sense.

electropourlaction commented 9 years ago

I did some rethinking, this should really be renamed to be about setting up a profiling tool for the bfin, maybe oprofile, or other (some ideas where mentioned here already http://llllllll.co/t/aleph-how-to-gauge-if-dsp-is-powerful-enough-for-x/718 ) that makes it possible to see calculation time per function.

electropourlaction commented 9 years ago

renamed topic, will have a look at this later (autumn probably), http://blackfin.uclinux.org/doku.php?id=linux-kernel:oprofile

catfact commented 9 years ago

... but we're not running a uclinux kernel... looked into it early on, but the overhead is a little much

catfact commented 9 years ago

if you just want to get time spent in a specific program, i would check out the Cycle Counter system registers (in section 21 of the blackfin programmers reference manual) or the real-time-clock. they are already set up to record execution cycles in CRT startup. it should not be hard to read the cycles at begin and end of function you're profiling, and report that value in a parameter read.

this link talks about it: unfortunately the source code links are dead(!) but you get the idea: http://blackfin.uclinux.org/doku.php?id=making_the_blackfin_perform

alternatively, you could set up the RTC (hardware clock) at startup and use that.

as far as in-depth call stack analysis, i don't really think that's likely to happen in any sort of automatic way for baremetal GNU/GCC programs. of course if we were using VDSP we'd have access to their profiling tools.

electropourlaction commented 9 years ago

thanks for the advice! I will need to take some time to educate myself on it, but interesting stuff nonetheless!

electropourlaction commented 8 years ago

crazy crazy price tag but I'm just curious, would it be possible to use VisualDSP++ 5.1 for bfin executables on the aleph? or is this a kernel issue again? sorry for still being so very ignorant on these matters, anyway it sure looks interesting to have built in profiling, optimizations(!), WAV PCM libraries, etc.

catfact commented 8 years ago

for sure, it would work.

but seriously, you can probably get whatever data you want by polling the execution counter. doubt that VDSP profiler stack is doing much else than that.

and bfin-elf-gcc knows a lot of good tricks too! but one needs to give it half a chance, which i never did.

i need to do a tiny bit more testing and then share the block-processing framework at least with people who want to write new modules. no sense writing per-sample code and then rewriting it later.

ngwese commented 8 years ago

i'd certainly be interested in the block processing code...

catfact commented 8 years ago

@ngwese i just pushed my test branch and made a longer comment on the relevant issue thread (https://github.com/tehn/aleph/issues/69)