[announce] c64_tools (DSP loader and IPC)

[Hồng Thất Công]

Impressive!

Impressive!

 

[bsp]

"notaz and rohezal like this"

*g* notaz, does that mean that this is finally working ?

(the stresstest's been doing fine so far for ~3h on my 'Ghz' Pandora)

 

[notaz]

I think I have some good news (for a change).

I just transcribed the power on/off functions from SysLink (omap3530pwr.c) to c64_tools.

This resulted in the following improvements:

• udelay() call at the begining of dsp_poweroff() is no longer needed, even if the DSP is powercycled as fast as possible (in previous releases, removing that call resulted in sporadic 'in-band' errors in the klog)
• considerable decrease in power consumption during c64_pwrbench (powercycle-as-fast-as-possible)  (now ~1.6W instead of ~2.7W)
• considerable decrease in IDLE power consumption (barely measurable now, maybe ~10mW. In previous releases this was ~80mW, IIRC).

Great job! This thing can run TC_IDLE loop with "default" core.out! And no NAND crashes yet, but that one is difficult to verify. But man, dsp_poweroff() is now a monster, toggling RST2 like what, 4 times? Who cares about it as long as it works, but it's quite frightening we need such sequences to turn off some piece of silicon.

 

[bsp]

Woohoo!

Yeah, it's a monster, all right. I thought that even though we don't have direct TI support and there are (apparently) no erratas, they do release at least some of their code as open source, incorporating all the company internal erratas..,  and that's even better than some field engineer talking to you on the phone

 

[Hồng Thất Công]

Man! You two, bsp and notaz, are awesome and are genii (geniuses )  OMAP all the way!

 

[Hồng Thất Công]

What does this all mean now that bsp has unlocked the monster inside OMAP? (Sorry for the double posts )

Dreamcast full speed no more sound stuttering?

PPSSPP full speed?

3doh full speed and no more sound stuttering?

Dolphin full speed? (Sorry can't help)

 

[bsp]

Well, in this case, the credit has to be attributed to some unnamed TI devs from india, who most likely have been sweating about this issue for some time before coming up with the proper (workaround) code thanks guys!

 

[rohezal]

What does this all mean now that bsp has unlocked the monster inside OMAP? (Sorry for the double posts )

As far as I understood is the dsp power consumption is far lower (yeah!) and no NAND corruption occurs on older (Rebirth and CC) units, since a TI bug was fixed. Very very nice work .

Dreamcast full speed no more sound stuttering?

The dsp is not even used in an emulator. ptibseb wanted to write an audio plugin for the N64 with the dsp. Which would be done just for learning, since the audio code is currently passed mostly to the on board hardware. I am not sure how much could be done but in my limited understanding:

the Dreamcast audio could be handled by the dsp, since the pandora cpu is very busy to emulate the 200 mhz dreamcast cpu

the PSP attrac audio plugin could run on the dsp

maybe some n64 graphics stuff could be coded on the dsp which would be a very big pile of work and not sure if this speed things up

very very maybe: some expensive, independent loops (like vertex transforming in qemu) could be detected by the recompiler. And then executed by the dsp, while programm the keeps running until the result of the loop is needed. I am not sure if this is even possible.

 

[bsp]

So far we have DSP acceleration routines for

• Sprites (8x8 or 32x32 in 32bit), featuring alphatest / premultiplied and non-premultiplied srcover blend modes (about twice as fast as SGX hardware graphics accelerator)
• Planar to chunky graphics conversion (up to 8 Amiga style bitplanes with scroll 'registers' per bitplane)
• 2xSAI graphics scaler (by M-HT, unreleased, slightly faster than ARM/NEON)

That's nice, but only the tip of the iceberg.
 

 

[rohezal]

2xSAI graphics scaler (by M-HT, unreleased, slightly faster than ARM/NEON)

The best part is: the scaler can be used, when the cpu is allready calculating the game logic for the next frame. So hell yeah .

 

[Hồng Thất Công]

Man!  Too bad Pandora production is going to stop any day now and it's potential has yet been utilized to the fullest.  Hopefully even after the release of PYRA, devs still work on stuff for Pandora

 

[WizardStan]

Too bad Pandora production is going to stop any day now and it's potential has yet been utilized to the fullest.  Hopefully even after the release of PYRA, devs still work on stuff for Pandora

Assuming the OMAP5 is really really officially confirmed and not just sort-of-all-but-confirmed, then most stuff, including DSP work, should be very backwards compatible.Also the Pyra is going to be a year away at least, so lots of time.

 

[notaz]

Ok so I've been running tests for ~3h now, TC_IDLE loop first, then got bored of it and switched to dsp_stresstest, and everything is fine. Even if NAND corruption is still possible, the probability of it should be extremely low.

So all I'm going to do now for this is to wait for next *_dist.tar.gz to push it as fw update.

 

[levi]

According to public docs, the OMAP 5 line of devices contain a DSP which is a development of the one in the one in the Pandora's core that is to at least some degree backward compatible. So (as the user formerly known as WizardStan says) this work now will help coders writing for the Pyra, and likewise those coding on the Pyra will be able to backport some of the DSP code written for that back to the Pandora (subject to extensions and patches only found in the later revision, as we've already seen comparing the DM3730 chip in the GHz Pandora and the OMAP3530 in CC and Rebirth units)

 

[M-HT]

2xSAI graphics scaler (by M-HT, unreleased, slightly faster than ARM/NEON)

I already released it when I was testing scalers using dspbridge (together with Scale2x and Eagle2x).

 

[bsp]

@Levi and the-user-formerly-known-as-WizardStan: The OMAP5 DSP is heavily stripped down: Only 4 execution units instead of 8, no software pipelined loops, L1 and L2 SRAM cannot be used as flat memory. I really don't understand TI's decision to cripple it that way.

However, any application/function that's written in portable C code should be easy to port to either the OMAP5 DSP, or the CortexA15.

Fortunately, TI's DSP compiler is quite good at optimizations and DSP-specific compiler intrinsics can be emulated via macros or inline functions on other processors.

Typical DSP software will probably consist of just a handful of number-crunching functions, anyway. The porting effort should be manageable. It's also not uncommon to first write a C implementation of an algorithm before adding HW-specific optimizations.

Last but not least, as far as the Pyra is concerned: It's not that, once it becomes available, all Pandoras will stop working all of a sudden or will magically be replaced by new devices, all for free. I'd give the Pandora another couple of years.



I kept my 3730 Pandora on during the night. The 'c64_tc' stresstest ran for ~14 hours until I quit it.

I also did some power consumption measurements (via sysinfo). DSP idle really just consumes ~10mW.

This is very nice since now it makes sense for applications to use the DSP even if they don't need it all the time (e.g. just for repainting a UI when some event occurs).

 

So all I'm going to do now for this is to wait for next *_dist.tar.gz to push it as fw update.

And here it is:
 


** Changes

 18-Jan-2014

   - changed DSP power on/off sequences to match those found in TIs SysLink.

      This seems to fix stability issues on older OMAP3530 based Pandora devices
      (newer DM3730 based devices worked fine with the old sequences)

      Tests indicated that the stability issues were related to the way the DSP
       was powered off in previous releases.

      With the new power on/off code, the power consumption during c64_pwrbench
       (powercycling stresstest) dropped from ~2.7W to ~1.6W.

      DSP idle power consumption also dropped from ~80mW to ~10mW
       (when the 'c64' device is not in use, the DSP will still be completely
        powered off, though).

      The new power up sequence also keeps the IVA2 video sequencer (ARM926) in reset.

   - added: 'pwroff' kernel module parameter

      Setting this to 0 (i.e. 'insmod c64.ko pwroff=0') will prevent the kernel module
       from powering off the DSP when there are no client applications connected or
       when all DSP applications have called dsp_suspend().

      The DSP will still be powered off when the kernel module is unloaded via 'rmmod'.

   - changed: updated go64.sh script to support new 'pwroff' kmod parameter.

       Example:
        # export C64_PWROFF=0
         # export C64_PWRLOG=1
         # ./go64.sh

   - changed: removed dsp_send_forced_message() call in c64_load/main.c
      (this was only needed by very early version of c64_tools)

   - added TC_L2SRAM_RAND_CHKSUM_* testcases (46..49) to 'c64_tc'
Download: http://tkscript.de/c64_tools/c64_tools-18Jan2014_dist.tar.gz

 

[notaz]

OK update published. I still have the stress test running on 3530, so it's close to 24h now, everything is still fine.

 

[ekianjo]

So will there be an official 1.61 firmware update sometimes soon then ? 

 

[notaz]

That's upto ED to decide. As there is no "real" application using it yet, it's not a pressing matter I guess, everyone can run the online update for now.

 

[fantomid]

Impressive !!

could OpenH264 from CISCO be run on the DSP (http://www.openh264.org/) ?