[announce] c64_tools (DSP loader and IPC)

[ptitSeb]

BAM! Sent a message "add these two numbers", got a response with the right sum. Easy as pie. Now just to figure out something useful to do.

Arg, that is tempting! Now I want to try it too

 

[bsp]

I guess this would be a good moment for a c64_tools update:

http://tkscript.de/c64_tools/


** Changes

29-Sep-2013
- changed: removed CCS projects and renamed "c64_ccs_projects/" to "dsp/".
- added: makefile based DSP build system. This requires the following TI packages:
$HOME/ti/bios_5_42_01_09
$HOME/ti/c64xplus-iqmath_2_01_04_00
$HOME/ti/fastRTS_c62xc64x_1_42
$HOME/ti/TI_CGT_C6000_7.4.5
$HOME/ti/xdctools_3_25_03_72 [optional]

In order to build the DSP libraries and .out image,
change to the "dsp/" directory, run ". setenv.sh", then
"m all" to start the build.

- added "reg_read" and "reg_write" utilities (for dev. purposes only)
- changed: when "c64_fractal" is compiled with no DSP support, it no longer
requires "/dev/c64" to be present.
- fixed: DSP powerdown sequence when c64.ko module is unloaded
- added: DSP powersave mode. The system power consumption should now be not much
different when the DSP is running
(~0.35 W/h with the lid closed and WIFI off)

** NOTE ** The Open Pandora SuperZaxxon 1.55 kernel update is now located
in "pandora_sz1.55_kernel_update/".


p.s.: I left my Pandora on overnight, with the DSP running but the lid closed and WIFI off. In the morning (after ~7 hours), the battery was still ~78% full and immediately after "opening the box", the XFCE panel said that the battery would last for another 38 hours (~46 hours before I went to sleep). So, I guess the DSP powersave mode works!

p.p.s.: just re-ran my idle + stresstest script and produced a new plot with sysinfo:

At ~05:30 the DSP is booted, at ~06:00 the c64_fractal_dsponly test is run, at ~06:30 c64_fractal_gpponly, and at ~07:10 c64_fractal_gppdsp. The kernel module is unloaded at ~08:20 and the DSP is powered down.

p.p.p.s.: An interesting observation I made is that when I look at the current/voltage/power values in the sysinfo UI, it reports ~204 mA, 3.838V = ~783 mW/h with the DSP powered off, and ~224 mA, 3.838V = ~860 mW/h with the DSP idling around. I.e. according to that numbers, the DSP costs 77 mW/h. For some reason this does not show in the plot above (the difference there is ~203 mW/h). I guess these performance measurements should be taken with a big grain of salt.

 

[rohezal]

A question about the software rasterizer. It is possible to build something like xfire with it? Render half of the frame on the gpu and the other half on the dsp? Then combine the images and copy the result to the framebuffer? Maybe use 70% to 30% instead of 50/50%.


At least for an emulator this would be awesome to have some render power.

 

[bsp]

the fractal benchmark (_gppdsp variant) does sth. similar, it renders 20% with the GPP, and 80% with DSP.

Technically speaking it should be possible to combine the GPU and the DSP although I am not sure if there's a way to query the (physical) GPU framebuffer addresses via the SGX APIs -- you do not want to readback/copy data, that would be slow.

 

[_wb_]

I messed up the auto-updating of the plot templates, so you have to remove appdata/sysinfo/plot-templates to get more accurate estimates.

783 mW with the DSP off seems like a lot (assuming brightness at lowest, idle cpu and no wifi/usb). On my two units it's around 600mW without DSP and 800mW with idle DSP.

 

[bsp]

The 783/860 mW results (on a Ghz Pandora) are with display on, default brightness, LEDs on, default RAM/GPP/DSP clockrates (actually everything's at default). WIFI was off.
 

I just downloaded your latest sysinfo release (0.8), removed the plot-templates/ folder and re-ran the test script.

The results are practically the same, except there's a little bit more ARM activity (~0.5 W spikes every few seconds).

There's still the discrepancy between what sysinfo shows in the UI and what is plotted in the graphs.

With the lid closed, the "actual power" recorded by sysinfo is ~0.15 W without the DSP, and ~0.31 W with the DSP => 0.16 W DSP overhead.

With the lid open, the UI says that the power consumption (with the settings above), is ~783 mW without the DSP, and ~860mW with the DSP => 0.077 W DSP overhead

I am not saying that this is an issue with sysinfo, it just surprised me that the results resp. the overhead differs.

(with minimal display brightness I get ~662 mW w/o DSP and ~752 mW with the DSP. also interesting because I would not have expected that to have an effect on the DSP overhead.. with max. brightness I get ~1187 mW w/o DSP and ~1274 mW w/ DSP)

p.s.: I picked the lowest of ~10 sysinfo W values for both GPP/DSP

p.p.s.: You removed the toggle wifi (ctrl/alt?!) buttons in 0.8. That's good since they interfered with the switch workplaces XFCE shortcut

 

[_wb_]

Did you have USB host enabled?

My guess is that when you close the lid, some stuff can be turned off that is normally turned on. But having the DSP turned on somehow interferes with that, so the usual lid-closed power saving does not fully work (having the DSP turned on forces something else to stay on as well). That would explain why the "overhead" of the DSP seems to be bigger when the lid is closed.

Anyway, we can do more detailed power consumption benchmarking later. The point is that the DSP uses less power than the general-purpose CPU while for some tasks it is faster.

Is there a way to compile DSP binaries on the Pandora itself? Or is there only a x86 closed-source TI toolchain available?

 

[Linux-SWAT]

Is there a way to compile DSP binaries on the Pandora itself? Or is there only a x86 closed-source TI toolchain available?

I'd be happy to include all (redistributable) DSP stuff in SL4P, at least kinda of auto-downloads in case it breaks GPL.

 

[bsp]

according to sysinfo, the USB host is disabled.

My guess is that when you close the lid, some stuff can be turned off that is normally turned on.

your theory is probably right. I had similar thoughts.

I have no idea, though, what could be preventing the system to go to full powersave mode when the DSP is running. Did not see anything about that in the OMAP3530 ref. manual, but then again the whole clocking / powersaving setup is relatively complex and maybe the manual is not 100% complete (?!).

It is probably not really a big issue, since the battery life is still good (~60 hours with a full battery and the lid closed / DSP running), and the next c64_tools release will contain a script that automatically unloads the kernel mod. / powers down the DSP when the last application using it has exited.

Anyway, we can do more detailed power consumption benchmarking later. The point is that the DSP uses less power than the general-purpose CPU while for some tasks it is faster.

My conclusion -so far- is that the DSP is faster and more power efficient for all tasks that cause a medium to heavy load, but the GPP is better at light tasks / idling / powersaving

To come to a final conclusion, I will need to do some more testing, e.g. run some interpreter on the DSP and see how it stacks up against the GPP. That's the kind of code that's a worst-case scenario for the DSP (lots of control code / unpredictable branches).

Don't get me wrong, for practical reasons (ease of debugging to name one), ppl. should not move the majority of their code to the DSP.

The "user" region of the DSP code area will be limited to ~2 MBytes, anyway.

Maybe this should be discussed before this is integrated into the SZ firmware ?

Once a memory setup is decided for, it will be impossible to change that later on without breaking compatibility.

My idea so far regarding the DSP memory split is

  1) 1MB for DSP firmware (i.e. code that every application can expect to be there)

  2) 1MB split into 8 or 16 4 areas for application-specific code (e.g. non-standard codecs for mediaplayers or smaller non-standard utility code)

  3) 2MB for main-application-specific code (e.g. a 3D engine for a game or emulator)

Is there a way to compile DSP binaries on the Pandora itself? Or is there only a x86 closed-source TI toolchain available?

ha, I looked for this some days ago but could not find anything. (and TI also likes to click-wrap even source/include files in x86 installers, I wish they would at least use e.g. Java for that)

I was thinking about contacting them and requesting ARM versions of their core utils (cg/xdc), then scrapped the idea because I guess no one there would listen to the request of a hobbyist individual

 

[rohezal]

One noob question for the dsp:

The dsp can access the main RAM like the normal cpu (gpp), right? Or is it limited to the 2 MB?

 

[bsp]

It can access the main RAM, so the 4MB DSP image area would mainly contain code.

p.s.: ..and currently that means _all_ RAM and chip registers. The DSP has an MMU, though and for security reasons, DSP access should be restricted to the shared memory areas, the OMAPFB video memory, and a selected set of peripherals (e.g. EDMA3). I did not do this, yet, but I already had a look at how the MMU setup is done (simple).

 

[_wb_]

Maybe this should be discussed before this is integrated into the SZ firmware ?

Once a memory setup is decided for, it will be impossible to change that later on without breaking compatibility.

My idea so far regarding the DSP memory split is

  1) 1MB for DSP firmware (i.e. code that every application can expect to be there)

  2) 1MB split into 8 or 16 4 areas for application-specific code (e.g. non-standard codecs for mediaplayers or smaller non-standard utility code)

  3) 2MB for main-application-specific code (e.g. a 3D engine for a game or emulator)

Maybe we should reserve a bit more (e.g. 2MB) for general-purpose code. It is not straightforward to write your own application-specific DSP code, and ironically there is not even a toolchain available for ARM devices like the Pandora. So I think it makes more sense to try to come up with a reasonable standard library of useful general-purpose DSP routines (stuff like matrix multiplication, blitters, a couple of codecs, etc). That way it is easy to make use of the DSP without needing to install new toolchains, as long as you only use the standard code.

I think it makes most sense to try to optimize existing SZ libraries like notaz' SDL, ALSA, lunixbochs' libGL, and so on. The DSP code that is useful for those libraries would be included in the "DSP firmware" too.

 

[sparkymark79]

+1 for a light media player with shoulder buttons for track changes.

I have no idea about anything that I'm reading in this thread but it's still getting me excited!

 

[PokeParadox]

Would it be possible to run the "charging OS" on the DSP? Would this alleviate the need for essentially booting the entire system?

 

[crow_riot]

Great idea PokeParadox, like it. I was also thinking about trying to get some mini-mini-menu running entirely on the DSP

 

[_wb_]

Would it be possible to run the "charging OS" on the DSP? Would this alleviate the need for essentially booting the entire system?

I doubt something like that is possible, but it's also not needed. The CPU is better at being idle anyway. If we want a "charging OS", the best option is probably to just boot Linux and instead of starting all the usual stuff, it immediately loads a small application that does nothing but display a "battery charging" icon, doing a shutdown when the battery is full. That shouldn't be difficult to do - it just doesn't seem to be a priority to anyone. The only tricky thing would be to automatically decide between normal boot and "charging OS" boot - in other words, finding out whether the unit was turned on manually or because the charger was inserted.

There is nothing to gain by running a "charging OS" on the DSP, even if something like that were possible. Charging would be slightly slower because you would have to keep the DSP powered.

 

[PokeParadox]

Would it be possible to run the "charging OS" on the DSP? Would this alleviate the need for essentially booting the entire system?

I doubt something like that is possible, but it's also not needed. The CPU is better at being idle anyway. If we want a "charging OS", the best option is probably to just boot Linux and instead of starting all the usual stuff, it immediately loads a small application that does nothing but display a "battery charging" icon, doing a shutdown when the battery is full. That shouldn't be difficult to do - it just doesn't seem to be a priority to anyone. The only tricky thing would be to automatically decide between normal boot and "charging OS" boot - in other words, finding out whether the unit was turned on manually or because the charger was inserted.

There is nothing to gain by running a "charging OS" on the DSP, even if something like that were possible. Charging would be slightly slower because you would have to keep the DSP powered.

That does make sense I guess - I just was thinking if the ideas is to build a DSP "firmware" of sorts then parhaps a minimal OS that makes use of these firmware functions could run on charging/before main OS.

A couple of netbooks have done something similar with a basic music player being able to run without booting completely into full linux. But yes I was only interested in the feasibility of something like this.

 

[_wb_]

The "DSP firmware" would not be an OS, but rather a library: a collection of standard, general-purpose functions to be called (not directly but through libc64) from applications or from other libraries.

"firmware" is a confusing word - people are using it to describe anything from a tiny microcontroller rom to a full-blown GNU/Linux distro. In this case, it would be a bit like the firmware that is running on the GPU, and libc64 would be like the GPU driver. The main difference being that here we can write the firmware ourselves, which still has to be done, so we can make it FOSS - it's just a bit annoying that the DSP compiler is not FOSS, so we still have to rely on TI's binaries. But at least we get potentially more flexibility than with the GPU: e.g. user applications can use custom firmware if they want.

@bsp: feel free to correct me if I'm wrong - the above is how I understand things, but I may be wrong.

So now that we have the basic functionality working thanks to bsp, I guess the main task now is to make a first attempt at collecting a useful set of DSP routines. Maybe a good starting point would be some video/audio codecs from the TI website? And then, if we're lucky, it just boils down to replacing a few function calls in libgstreamer, libmp3lame etc.

 

[bsp]

You understood exactly right.

The DSP firmware would not be full fledged OS but a heavily simplified one that
  - handles the remote procedure calls
  - handles dynamic code section updates
  - handles power management
  - handles component (de-)registration
  - defines a standard set of enumerated syscalls, which dynamically loaded DSP components can use/rely on.
     (this will be implemented through "trampolines", i.e. similar to how interrupt vector tables work)

Reserving 2MB (just to be sure) for the firmware code is ok, I'll do that (although let's not forget that 1MB of code is already a lot. for reference: the entire Pandora Linux kernel is just ~3 MB, the entire OGLES+blitter graphics rasterizer we developed at work is ~800KBytes, that's ~60000 LOC, IIRC).

This would mean:

  1) 2MB resident/firmware code area
  2) 1MB for 4 * 256k dynamically loaded code areas (this could be seen as some kind of staging area. code placed here should be moved to the resident area once it is stable and is frequently used. It can also be used for not-so-frequently used code that does need the "big" area 3, of course)
  3) 1MB for dynamically loaded code (application specific)

The size of area 3) could be increased later on, should the need arise. It will be located at the end of the DSP memory.

And yes, accelerating SDL / libGL would make sense. It is not trivial but far from rocket science.

For SDL to leverage the DSP, it would need to collect BLIT calls in a shared memory displaylist, and let the DSP process that list when the application flips the framebuffers at the end of a frame, or when the app. locks a surface to do SW rendering with the ARM (this could be optimized so that the DSP call is only done if both GPP and DSP need to access the same memory area). The shared memory displaylist has to be double-buffered, so that the ARM can continue to fill a new list while the DSP processes the last one.
 

Last but not least, I will try to implement the dynamic loader in a way that it does not require root privileges. Once the MMU is enabled, the worst thing DSP code can do is crash the DSP and make all other ARM applications that used it at that moment, time out.

 

[ibisum]

This thread is *VERY* exciting and getting me out of hybernation mode ..