[announce] c64_tools (DSP loader and IPC)

Discussion in 'NEON / DSP' started by bsp, Sep 15, 2013.

  1. Letalis Sonus

    Letalis Sonus Advanced Member

    Joined:
    Mar 5, 2009
    Messages:
    1,040
    As far as I've heard, OpenMAX is first choice on ARM systems. That whole mess is mostly just x86 related and basically runs down on VA-API vs VDPAU, while it seems that there are wrappers for both to make use of the other API.
     
  2. M-HT

    M-HT Very Active Member

    Joined:
    Nov 30, 2007
    Messages:
    607
    Location:
    Bratislava
    I think with exception of Intel, you need additional closed source software to use HW acceleration (using VA-API, VDPAU, ...). But I'm not disputing the rest of your post.
    What do you consider proper video acceleration to be? I think the OMAP3 DSP/video accelerator is not capable of more than the codecs TI already released. There's also Theora decoder for the DSP, but it's not fullspeed.
    I haven't released the latest version (it's not really ready for release). But I can give you what I have. (When I get home, I'll put it in my thread about scalers.)
    I don't know how OPL really works, but it's possible that in my test the OPL wasn't using all capabilities/channels/... so it required less CPU time. Also Dosbox has two OPL emulators. The default one, which I tested, is faster, but less accurate (I don't know how much faster). And I think the default OPL sample rate is 44100.
    Anyway, I won't be working on OPL emualation on DSP, but someone else could take a look at it.

    I trust the testing by notaz :) , but I'll run the stresstest.
     
  3. ekianjo

    ekianjo Hardcore Member

    Joined:
    May 7, 2012
    Messages:
    8,261
    Location:
    神戸市、日本 (Japan)
    Fair enough. But parallel programming is not straightforward, as you mentioned in your post, so that's an extra level of difficulty in implementing any solution using the DSP. 
     
  4. Letalis Sonus

    Letalis Sonus Advanced Member

    Joined:
    Mar 5, 2009
    Messages:
    1,040
    Even if you take the required firmware for using the UVDs with the free radeon driver as "additional closed source software", I already provided a completely free example: The generic shader-based VDPAU implementation of Gallium, which e.g. can be used with the entirely closed-source-firmware-free nouveau driver (that implementation is pretty much limited to MPEG2 so far, though). I'm currently using that implementation myself as I have one of the few UVD2 Radeon cards that still lack the required firmware.
     
  5. Rockthesmurf

    Rockthesmurf Advanced Member

    Joined:
    Jul 18, 2003
    Messages:
    1,097
    Location:
    Manchester, UK
    When ever I develop for Pandora and hit a bottle neck, the bottle neck always seems to be the GPU (I do not have a GHz unit for what it is worth), so the DSPs power doesn't really help any projects I have looked at so far.

    I get the feeling there are a few people on the boards that would quite like to do something cool with the DSP, but just don't quite know what. The ideal case would be where the end product really is twice as fast thanks to the DSP (rather than something contrived, using the DSP for the sake of it, potentially only getting modest gains). Sure I can think of things I could do on the DSP that would benefit a few projects, and maybe have a little gain, but I am nowhere near interested enough in any of these ideas to work on them to completion.

    Is there already a list of worthwhile ideas of what could be done on the DSP knocking around?
     
  6. rohezal

    rohezal Advanced Member

    Joined:
    Oct 18, 2009
    Messages:
    1,657
    Some where some posts. Some things:

    1.

    DSP Scalers for better images, this could speed up the gpu too.

    Let me explain:

    In Open GL2, the you have per pixel lightning. So you have to calculate the normal and the angle between the light souce(s) and the fragment per pixel. When you are are rendering at 400x240 you are only to calculate 1/4 of the image. This is a big nice.

    There must be a way to make the memory area where the texture is saved, to a shared memory for the dsp, so it wont have to be copied around.

    2. A video decoder for youtube vids. Higher youtube vids are laggy, which is not nice since we have some nice youtube apps. A video decoder on the dsp could be a big speed improvement.

    3. Some parallel AI stuff, like an fast iterrative fast algo to speed up games which have lots of units.
     
    Last edited by a moderator: Jan 23, 2014
  7. fantomid

    fantomid Very Active Member

    Joined:
    Oct 10, 2011
    Messages:
    287
    Location:
    Near Toulouse, France
    What about GNU Radio and Software Defined Radio for example ?
     
  8. ptitSeb

    ptitSeb Serial Porter

    Joined:
    Aug 15, 2012
    Messages:
    8,336
    Location:
    France, near Lyon
    GPU alone can do that quickly. I tried that on an FBO, and the bliting back of the FBO on the screen is not tacking time (a few ms). Not sure there is something to win here.
     
  9. WizardStan

    WizardStan Mega GP Mania

    Joined:
    May 24, 2008
    Messages:
    16,676
    Not if the GPU is already struggling with other stuff. If the GPU is the bottleneck then you need to take as much away from it as possible.
     
    PokeParadox likes this.
  10. ptitSeb

    ptitSeb Serial Porter

    Joined:
    Aug 15, 2012
    Messages:
    8,336
    Location:
    France, near Lyon
    I really don't think so. You will gain 2ms per frame, maximum, GPU stuggling or not. And to parallelize that bliting operation, you need to double the FBO, and you also need to create an egl context that still permit bliting to FB. A lot's of technical difficulties for 2ms / frame. If you're game struggle at, let's say, 10fps, that means you need 100ms per frame. so you can have 98fps per frame at best, so 10.2 fps... Sorry, I really don't think it's worth a try (but you can prove my wrong).

    better move OpenAL 3D sound code to DSP, it will be much more effective (you may gain 1 to 2 fps, maybe 3)
     
    Last edited by a moderator: Jan 23, 2014
  11. WizardStan

    WizardStan Mega GP Mania

    Joined:
    May 24, 2008
    Messages:
    16,676
    Nah, your numbers seem sound.
     
  12. Magic Sam

    Magic Sam Forever Homebrew

    Joined:
    Aug 10, 2007
    Messages:
    2,200
    Location:
    Innsmouth, MA
    Hi,

    OK, I have updated my Rebirth Pandora with the Upgrade Pandora OS tool, and ran the stresstest program (dsp_stresstest-14Jan2014b.tar.gz).

    I'm sorry to report it still hangs, without any error message ...

    Wi-fi stopped working, the XFCE menu disappeared and I had to reboot the Pandora :(

    I have also noticed some slight data corruption (files starting with question marks ??? ) at the root of the SD-card.

    Bye, and sorry for the bad news.

    Magic Sam
     
  13. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,911
    Location:
    Lithuania
    Strange, maybe you forgot to reboot after doing "Upgrade Pandora OS"? In that case you were still running old code.

    Could you also start up the terminal and type "uname -a" and report what date it prints there?
     
  14. Magic Sam

    Magic Sam Forever Homebrew

    Joined:
    Aug 10, 2007
    Messages:
    2,200
    Location:
    Innsmouth, MA
    No, I'm sure I did reboot the Pandora after the upgrade.

    And "uname -a" says the kernel is from Tue Jan 21 23:45:27 EET 2014.
     
  15. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,911
    Location:
    Lithuania
    Did you run "go64.sh" from dsp_stresstest-14Jan2014b.tar.gz ? If so you shouldn't do it, because it loads the old kernel module with all the problems.

    After fresh boot, run /usr/pandora/scripts/op_dsp_c64.sh , then ./hugetlb.sh and then ./stress_test.sh
     
  16. Magic Sam

    Magic Sam Forever Homebrew

    Joined:
    Aug 10, 2007
    Messages:
    2,200
    Location:
    Innsmouth, MA
    Yes I did run go64.sh, silly me :unsure:

    I'll try again with your method and report back if I face any more issues.

    PS: is there something I can do about data corruption, besides re-flashing the Pandora and reformatting the SD-card 
     
  17. Cloudef

    Cloudef Member

    Joined:
    Dec 30, 2009
    Messages:
    460
    Location:
    Gensokyo
    @bsp, would you have any idea how fitting dsp would be for matrix palette skinning?

    I've been trying to think uses for dsp, and thought skinning would fit the best, so NEON can be used for other tasks and GPU focuses on drawing.
     
  18. Rockthesmurf

    Rockthesmurf Advanced Member

    Joined:
    Jul 18, 2003
    Messages:
    1,097
    Location:
    Manchester, UK
    @Cloudef which part of the skinning? The per vertex part is presumably going to be fastest via a shader (although I take your point that having a simpler shader and move that work onto the DSP theoretically could have some improvement). Or were you thinking more of the work required to calculate the joint/bone matrices? For this part, I know in the past Exophase mentioned that it would a task that could be NEON optimized very well (although again if the DSP can free up CPU/NEON time, it could ultimately have an overall performance improvement).
     
  19. Cloudef

    Cloudef Member

    Joined:
    Dec 30, 2009
    Messages:
    460
    Location:
    Gensokyo
    The vertex part indeed, this would be used in GLES1 mode where shaders are not available

    (and might have even merit for GLES2, as my exprience with GLES2 on pandora SGX has been meh)

    Animator part indeed can be simdified.
     
    Last edited by a moderator: Feb 25, 2014
  20. Rockthesmurf

    Rockthesmurf Advanced Member

    Joined:
    Jul 18, 2003
    Messages:
    1,097
    Location:
    Manchester, UK
    Well you can sign me up as being interested in the answer; I have some skinned animation code that I have running on the Pandora; it could be optimized in many ways (I'm sure), but certainly the DSPs potential input is interesting to me.
     

Share This Page

Loading...