Running scalers on DSP

Discussion in 'NEON / DSP' started by M-HT, Nov 19, 2012.

  1. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    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).
     
    Last edited by a moderator: Feb 6, 2016
    Tags:
  2. mcobit

    mcobit Advanced Member

    Joined:
    Jul 28, 2008
    Messages:
    6,755
    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.
     
    Last edited by a moderator: Nov 19, 2012
  3. Linux-SWAT

    Linux-SWAT Hardcore Member

    Joined:
    Feb 13, 2010
    Messages:
    8,199
    Yeah, give work to this lazy bastard.
     
  4. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    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.
     
    Last edited by a moderator: Nov 19, 2012
  5. PokeParadox

    PokeParadox Founder of Pirate Games - Penjin Coder Staff Member

    Joined:
    Dec 8, 2005
    Messages:
    6,512
    Location:
    UK
    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...
     
    FBnil likes this.
  6. Exophase

    Exophase Nothing good will ever come of Exophase.

    Joined:
    Sep 21, 2006
    Messages:
    10,308
    Location:
    Cleveland OH
    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.
     
    Last edited by a moderator: Nov 20, 2012
  7. gunrock

    gunrock Active Member

    Joined:
    Jan 20, 2011
    Messages:
    500
    Cool findings and great expermentation!


    Now scaling is out, how about MP3 / H264 playback?
     
  8. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    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.

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

    ibisum Well-Known Member

    Joined:
    May 6, 2009
    Messages:
    1,135
    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.
     
  10. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    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).
     
  11. Cloudef

    Cloudef Member

    Joined:
    Dec 30, 2009
    Messages:
    460
    Location:
    Gensokyo
    N900 has codecs for h264 (non baseline) AFAIK. But I never had much luck with them with gst-dsp and dspbridge at least.
     
    Last edited by a moderator: Nov 20, 2012
  12. milkshake

    milkshake Advanced Member

    Joined:
    May 18, 2009
    Messages:
    3,735
    Location:
    Rotherham, UK
    we need to get the dsp working ;) for video
     
  13. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    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.
     
    Last edited by a moderator: Dec 9, 2012
  14. Linux-SWAT

    Linux-SWAT Hardcore Member

    Joined:
    Feb 13, 2010
    Messages:
    8,199
  15. _wb_

    _wb_ Microbe Staff Member

    Joined:
    Apr 5, 2012
    Messages:
    5,387
    Location:
    Brussels, Belgium
    Keep going with these experiments!
     
  16. Askarus

    Askarus Hardcore Member

    Joined:
    Sep 28, 2011
    Messages:
    4,296
    Location:
    Germany
    So is there some use for he DSP which might give noticeable improvements?
     
  17. Farox

    Farox Certified Guru

    Joined:
    Jan 8, 2009
    Messages:
    2,029
    Location:
    Italy
    ++1 on this...very nice to see someone working on DSP.
     
  18. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    @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.
     
    Last edited by a moderator: Nov 26, 2012
  19. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    610
    Location:
    Bratislava
    Small update on the 2xSaI scaler:


    Optimized DSP version: 23.53 ms


    Optimized ARM version: 6.6 ms


    Optimized NEON version: 7.8 ms
     
  20. mcobit

    mcobit Advanced Member

    Joined:
    Jul 28, 2008
    Messages:
    6,755
    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?
     

Share This Page

Loading...