Running scalers on DSP

[M-HT]

Hi,


I was curious whether it's feasible to run scalers on the DSP, so I did some programming and testing.


I started with the scale2x algorithm to resize a 256x256 16-bit image.


I used dspbridge and the DSP for Dummies framework to run things on DSP and for compiling I used TMS320C6x C/C++ Compiler v7.3.2.


For optimizing I didn't use any assembler, but I did use compiler intrinsics.


Everything was measured at stock Pandora speed (600 MHz).


Result 1:


The overhead of calling the scaler on DSP is 3.43 ms.


Considering that scaling the image using NEON scaler costs 1.06 ms, it looks like running scale2x on DSP is pointless.


The next idea would be to take another scaler which on arm/neon needs more time than the overhead and run it on DSP (possible scalers are 2xSaI, SuperEagle2x, Super2xSaI, ...).


Result 2:


The best optimized version of scale2x on DSP needed 12.25 ms (including the overhead) to resize the image.


This version processes two pixels at once - two 16-bit values in 32-bit register - similar to how the NEON scaler works.


The best version without processing two pixels at once (except reading and writing to memory) needed 15.32 ms (including the overhead) to resize the image.


Since scale2x is a really simple scaler, it seems that it's not possible to run a more complicated scalers on DSP with acceptable speed (because it would run much slower than scale2x).

 

[mcobit]

Oh, cool experiments.


Is the speed measured against the time that it takes the cortex/neon to do the scaling alone or while it has to do some other task like emulation at the same time.


If you consider that the cortex might be slower while doing heavy emulation and the dsp has nothing else to do, maybe there would be some speedboost none the less, if you can unload scaling to the dsp.

 

[Linux-SWAT]

Yeah, give work to this lazy bastard.

 

[M-HT]

All measurements were done while doing nothing else - only the scaling.


The overhead of calling the DSP is quite large. Part of it might be running in parallel with the main processor, which would reduce the time needed to run the scaler on the DSP, but unless the overhead is smaller than running the scaler on the main processor, it is pointless to run the scaler on the DSP.


Just for comparison - an unoptimized scale2x running on arm takes about 3 ms on the same image.

 

[PokeParadox]

Yeah, give work to this lazy bastard.

That sounded really offensive and ungrateful until I realised you were talking about the DSP and not M-HT!


Also I'm glad you are at least exploring this - There must be something useful that could be done with the DSP...

 

[Exophase]

Very curious what all this overhead is being spent on. The only overhead I can think of that should exist at all is flushing cache, not even necessarily if you write directly to an uncached framebuffer. If the overhead were brought down to almost nothing then even a scaler that needs 12ms to complete on the DSP would be preferable in most cases.

 

[gunrock]

Cool findings and great expermentation!


Now scaling is out, how about MP3 / H264 playback?

 

[M-HT]

Very curious what all this overhead is being spent on. The only overhead I can think of that should exist at all is flushing cache, not even necessarily if you write directly to an uncached framebuffer. If the overhead were brought down to almost nothing then even a scaler that needs 12ms to complete on the DSP would be preferable in most cases.

I suspect, that the image is being copied around instead of being in shared memory. At the moment I'm passing the data inside the messages that are sent to/from the DSP. I'm probably supposed to set up a shared memory somehow, put the data there and pass pointers around.


But even if the overhead was (close to) zero, it seems that the scalers on DSP are limited to scale2x, eagle2x, maybe scale3x because of (lack of) speed.

Cool findings and great expermentation!


Now scaling is out, how about MP3 / H264 playback?

I tried h264 decoding a while ago and it seems that the h264 decoder by TI only supports the baseline profile.

 

[ibisum]

Fascinating thread .. would be very interested in any details you can provide about how to set this up/demo/sample code, etc. I think it'd be pretty nice to be using the DSP for synthesis, as in analog emulation, but for sure in that case shared memory would have to be used.

 

[M-HT]

I've been reading some documentation and the framework source code and the framework uses shared memory for the input/output buffer, so my suspicion was wrong and I have no idea why the overhead is so large and whether it's possible to make it smaller.


I also tried doing some work while calling the DSP and the measured overhead was 3.27 ms - bit smaller, but still quite large.


@torpor:


I should put something together, but a lot of (most?) information comes from the framework page (and pages it links to).

 

[Cloudef]

I tried h264 decoding a while ago and it seems that the h264 decoder by TI only supports the baseline profile.

N900 has codecs for h264 (non baseline) AFAIK. But I never had much luck with them with gst-dsp and dspbridge at least.

 

[milkshake]

we need to get the dsp working for video

 

[M-HT]

If someone wants to test the code, I've put some things together.


First is a PND that installs/uninstalls the DSP codecs and sets up the dspbridge: dsp-installer.pnd


Then the source and binary of my scale2x implementation: dsp-scale2x.tar.bz2 Newer version with more scalers: dsp-scalers.tar.bz2


The arm binary is "dummy" and the dsp binary is "dummy.dll64P" (like I wrote before, it uses the DSP for Dummies framework).


Each file has it's own makefile - "Makefile-arm" and "Makefile-dsp".


To build the dsp binary, you need the TI DSP Compiler and doffbuild tools.


You can download the compiler from this TI page - you need to register with TI.


The doffbuild tools are in this archive: bridge-tools.tar - after unpacking it's in the ti/dspbridge/dsp/doffbuild subdirectory.

 

[Linux-SWAT]

Cool !

 

[_wb_]

Keep going with these experiments!

 

[Askarus]

So is there some use for he DSP which might give noticeable improvements?

 

[Farox]

we need to get the dsp working for video

++1 on this...very nice to see someone working on DSP.

 

[M-HT]

@Askarus:


Not yet.


@Farox, milkshake:


DSP can be used to decode video, but it doesn't seem useful.


The h264 decoder only supports baseline profile and most videos that I saw use at least main profile, so those can't be decoded on DSP.


Mpeg-4 videos can also be decoded on DSP, but I'm not sure it's (much) faster than using an optimized arm+neon decoder.


---


I took a look at the overhead. I tried doing some work in another thread, but that didn't help. The communication with DSP seems to block the whole process.


From reading the framework source, calling a function on DSP takes three ioctl calls - flushing source buffer, invalidating destination buffer and sending a message. Receiving a function result from DSP takes two ioctl calls - receiving a message and invalidating destination buffer.


I don't know if the overhead can be lowered, so I'm counting it as it is now.


---


I took a look at the 2xSaI scaler.


On arm, an unoptimized version (almost a straight copy) takes 13.4 ms.


On DSP, an unoptimized version takes 45 ms. A small (obvious) optimization takes it down to 36 ms.


On a different source images, the times may be different.


Optimizing it to 60 fps (16.66 ms) seems impossible, but 30 fps (33.33 ms) might be doable.


So if an optimized arm version takes longer than the overhead and the DSP version can be optimized to less than 33 ms and you're aiming for 30 fps (and you want to use this scaler), then the DSP can finally be usefull for something.

 

[M-HT]

Small update on the 2xSaI scaler:


Optimized DSP version: 23.53 ms


Optimized ARM version: 6.6 ms


Optimized NEON version: 7.8 ms

 

[mcobit]

Thats quaite an improvement.


Did you try to compare the scalers when the system is under load?


I mean, would it be faster to do the scaling on the dsp while the arm runs an emulator or is it still slower than doing it both on the arm?