Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

| Tasklist |

FS#8668 - battery runtime: experimental gui boost

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Saturday, 01 March 2008, 14:45 GMT+2
Last edited by Andree Buschmann (Buschel) - Friday, 02 May 2008, 14:05 GMT+2
Task Type Patches
Category Applications
Status Assigned
Assigned To Andree Buschmann (Buschel)
Player Type PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

We could take this kind of "quick-and-dirty" solution as a starting point for further work on GUI boost for iPod's.

The attached patch does the following:
- returning BUTTON_SCROLL_BACK/BUTTON_SCROLL_FWD out of scrollwheel driver (which was missing before)
- boost CPU on each received button and unboost after 1s, if the were no further button events

This patch should work for all iPod's with a 4G scrollwheel for now.
   gui_boost_v01.patch (2.4 KiB) 
 drivers/button.c                    |   35 +++++++++++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c |    4 +++-
 2 files changed, 38 insertions(+), 1 deletion(-)

This task depends upon

Comment by Andree Buschmann (Buschel) - Friday, 02 May 2008, 14:04 GMT+2
Next experimental version does set NORMAL_CLOCK to 15MHz (svn = 30MHz) to achieve better runtime for high efficiency codecs (like mpc and especially flac).

Remark 1: mpc-playback without WPS needs ~26.5MHz. With this patch the runtime is about 14.5h (svn = 14h).

Remark 2: flac-playback without WPS needs ~15MHz. I hope to see runtime >16h with this patch -- measurement will follow.

Remark 3: This patch is just to get an impression of the gui boost and to go ahead for the maximum possible runtime, it does not take any care about plugin-behaviour. This patch is no svn-candidate.

Remark 4: Should also work for non-iPod PP-targets.
   gui_boost_v02.patch (5.4 KiB) 
 drivers/button.c                            |   35 ++++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c         |    4 ++-
 target/arm/sandisk/sansa-e200/button-e200.c |    2 +
 target/arm/system-pp502x.c                  |   11 ++++++--
 target/arm/system-target.h                  |    4 +--
 5 files changed, 50 insertions(+), 6 deletions(-)

Comment by Andree Buschmann (Buschel) - Sunday, 04 May 2008, 11:03 GMT+2
Additional small patch attached which disabled the lineout of the WM8758 which is used in 5G (no_lineout_v01.patch). Through this another 0.5-0.6mA can be saved -- of course only if you do not need the line out at all.
--------------------------------------------------
Battery bench results with gui boost (@15MHz) and disabled lineout (details attached):

MPC:
overall = 14:24h
90%-10% = 12:09h

FLAC:
overall = 12:46h
90%-10% = 11:10h

FLAC saves a lot of current via very low CPU-usage (~4mA vs. MPC), but needs a lot of additional current for the buffering from HDD (~7.5mA vs. MPC).
--------------------------------------------------
Attached a 3rd version of gui boost with 24MHz normal clock -- as this seems to be more effective than running @15MHz normal clock (gui_boost_v03.patch).
   no_lineout_v01.patch (0.5 KiB) 
 wm8758.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

   battery_bench_mpc_080504_15MHz_boost_no_lineout.t... (110 KiB)
   battery_bench_flac_080504_15MHz_boost_no_lineout.... (101.4 KiB)
   gui_boost_v03.patch (4.6 KiB) 
 drivers/button.c                            |   35 ++++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c         |    4 ++-
 target/arm/sandisk/sansa-e200/button-e200.c |    2 +
 target/arm/system-pp502x.c                  |    4 ++-
 target/arm/system-target.h                  |    4 +--
 5 files changed, 45 insertions(+), 4 deletions(-)

Comment by Andree Buschmann (Buschel) - Monday, 05 May 2008, 20:12 GMT+2
Using the 24MHz version fo the gui boost + lineout disable:

MPC:
overall = 14:42h
90%-10% = 12:31h

(for a 5.5G 30GB of course)
   battery_bench_080505_mpc_24_nolineout.txt (112.9 KiB)
Comment by Andree Buschmann (Buschel) - Monday, 12 May 2008, 11:09 GMT+2
updated patch against svn.
   gui_boost_v04.patch (3 KiB) 
 drivers/button.c           |   35 +++++++++++++++++++++++++++++++++++
 target/arm/system-pp502x.c |    4 +++-
 target/arm/system-target.h |    4 ++--
 3 files changed, 40 insertions(+), 3 deletions(-)

Comment by Andree Buschmann (Buschel) - Monday, 12 May 2008, 18:33 GMT+2
updated patch against svn.
   gui_boost_v05.patch (5.4 KiB) 
 drivers/button.c                              |   35 ++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c           |    3 ++
 target/arm/ipod/button-target.h               |    5 ++-
 target/arm/sandisk/sansa-e200/button-e200.c   |    3 ++
 target/arm/sandisk/sansa-e200/button-target.h |    1 
 target/arm/system-pp502x.c                    |    6 +++-
 target/arm/system-target.h                    |    4 +-
 7 files changed, 52 insertions(+), 5 deletions(-)

Comment by Glenn (DancemasterGlenn) - Sunday, 29 June 2008, 08:16 GMT+2
Is this something that is intended to eventually be committed, or is it a more base work that uses techniques that wouldn't be approved in the normal builds? I'm asking because I do think this would be very useful, and it seems like you've done good work here (you know, because you NEVER do good work). Do you want/need people to test it for you? Now that I actually know how to patch and junk, I'd be glad to help out if I can. Even if it's just simple stuff (actually, that's probably all I'm capable of at this point).

Let me know!
Comment by Andree Buschmann (Buschel) - Tuesday, 01 July 2008, 21:46 GMT+2
Hi, any test efforts are welcome. Of special interest is the behaviour when using plugins (e.g. games). Is there any sideffect visible through the boost/unboost after short scrollwhell activity (unboost happens 1s after last scroll-activity)?
Comment by Travis Tooke (tdtooke) - Wednesday, 02 July 2008, 22:59 GMT+2
I'm beginning to test this now. The only thing I've noticed so far is when you start to scroll when it first boosts it tends to be a bit jerky at first. This may be just me getting used to the wheel responding so much better though. I'll make a point to put it through the motions in plugins and get back to you. I went ahead and included this in the build I put out so if there are any really negative side effects I'll know shortly. Just so you know I really will be scientific about this :-), if I have bug reports I will reproduce them in a build with only this patch first before I bother you with bugs that have nothing to do with this patch.
Comment by Glenn (DancemasterGlenn) - Thursday, 03 July 2008, 20:08 GMT+2
All right, after testing all plugins, here are a couple that were affected by this patch: Brickmania, bubbles and spacerocks were the most obviously borked games... all three became more jumpy (or maybe just erratic) when using the scroll wheel to move around. In terms of demos, many of them would speed up for a moment when I scrolled. Plasma is probably the best example of this... upon scrolling, the animation goes into overdrive for about a second (the amount of time the cpu is boosted). I wanted to test pictureflow, but haven't yet as my database isn't currently enabled. I'll test it later if tdtooke does not.

I hope this is helpful, let me know if you want any more tests run.
Comment by Andree Buschmann (Buschel) - Thursday, 03 July 2008, 22:10 GMT+2
Thanks for testing. This leads to the assumption that I might take some time to check the possibility to only boost when in list-context... I'll be back :)
Comment by Glenn (DancemasterGlenn) - Thursday, 03 July 2008, 22:39 GMT+2
You may or may not want to also let it apply to the WPS context, as well. It might be useful in making volume changes or whatnot more robust, but I can't recall how that worked out in testing.
Comment by Travis Tooke (tdtooke) - Friday, 04 July 2008, 01:08 GMT+2
Pictureflow is very jerky as well with this patch so sticking to list context and maybe WPS context might be the way to go.
Comment by Glenn (DancemasterGlenn) - Sunday, 22 February 2009, 07:55 GMT+2
Came back to this since you mentioned it in Boris' other patch. Did any more work get done on this? I remember getting very solid improvement from the work you did do. Just curious.
Comment by Andree Buschmann (Buschel) - Sunday, 22 February 2009, 10:29 GMT+2
I did not further work on this patch, but I keep it updated for my local build since ages. With a small change though: 100MHz boosted + 24MHz normal clock.
From discussions on irc the solution provided here is not wanted in svn. Until there has a proper solution been found, I will just keep using this implementation as I am not experiencing any issues with gaming (I just never used games :)

I have updated the patch against r20076. Patch v6 uses 100MHz maximum clock for PP5022/24 and keeps 80MHz for PP5020. As this runs stable on my 5.5G for >1 year now I do not expect any drawbacks. Main advantage is faster buffering which may save some power on the HDD-targets.
   gui_boost_v06.patch (6.5 KiB) 
 drivers/button.c                              |   35 ++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c           |    5 ++-
 target/arm/ipod/button-target.h               |    5 ++-
 target/arm/sandisk/sansa-e200/button-e200.c   |    3 ++
 target/arm/sandisk/sansa-e200/button-target.h |    1 
 target/arm/system-pp502x.c                    |   11 +++++---
 target/arm/system-target.h                    |    6 ++--
 7 files changed, 57 insertions(+), 9 deletions(-)

Comment by Glenn (DancemasterGlenn) - Sunday, 22 February 2009, 17:26 GMT+2
It's been forever since I patched my own build, but I do remember that combining this patch with dircache made my responsiveness absolutely fierce. Thanks for the updated patch, I think I may take a trip down memory lane with this one. It's a shame this won't be in SVN, I also don't use games ,so it was never a problem for me. The implementation wasn't able to be confined to list context? Or did it not matter, possibly it was seen as hackish? Just wondering where the discussion ended up.

Also, it's a total pipe dream, but I totally wish there was some sort of advanced mode for rbutil that you could feed patches. I don't mind the process terribly, but it's a process nonetheless.

Thanks again!
Comment by Andree Buschmann (Buschel) - Sunday, 22 February 2009, 18:15 GMT+2
Well, the patch's approach for gui boost is quite dumb. Boost with short timeout on each button activity. So, the advantage is that the gui becomes responsive as soon and as long as you interact with it. The bad thing is that this approach leads to jumpy behaviour of other plugins (especially games or demos) because of the boost timing out -- fast on button interaction, slow in between. Maybe the easiest thing would be to forbid boosting in plugin context...

Other discussed approaches try to boost the CPU each time an update of the display (drawing) is taking place. Doing so will need seemless clockswitching (no sync time for PLL) to be able to boost/unboost several times per second. Nevertheless I do personally not like this idea as I expect rockbox to waste power for unneeded boosting: e.g. WPS-updates run smooth @24MHz, but they will be boosted then. Therefor rockbox would need to use a very low normal clock (<24MHz) which allows the codecs to use such boosts for buffer filling -- otherwise the boost for e.g. WPS-updates come on top of the codec boosts. But very low clocks (I have done runtime measurements with 15MHz, see above) seem to be less efficient in terms of mA/MHz.
Comment by Glenn (DancemasterGlenn) - Monday, 23 February 2009, 00:45 GMT+2
Yeah, I remember us talking briefly (just on this page) about not using the boost within the context of plugins. Which also seems a bit odd, but the benefits to responsiveness speak for themselves. I can see why it would be frowned upon though. It's a shame that the other ideas are such a tightrope walk between responsiveness and efficiency. Hopefully an eventual middle ground can be met (though I suspect that middle ground may be our current setup.

Either way, I'll probably make use of this patch for a while. I appreciate it.
Comment by Andree Buschmann (Buschel) - Monday, 23 February 2009, 08:09 GMT+2
Just let me know whether you experience any problems with the 100MHz clock.
Comment by Dave Hooper (stripwax) - Friday, 06 March 2009, 00:48 GMT+2
This latest patch with 100MHz clock seems to cause fatal problems on my 5g 60GB ipod - "Prefetch abort at D1B71758" right after Rockbox logo. Also appears to have made my ipod unresponsive to the menu+select reset. That's on a fresh svn build (build without the patch, works fine, add in the patch and rebuild, -> death)
Comment by Andree Buschmann (Buschel) - Friday, 06 March 2009, 07:58 GMT+2
Wow. I did not expect such as my 5.5G 30GB runs @100MHz without any problems since >1 year...
Comment by Karl Anderson (D-Shadow) - Saturday, 07 March 2009, 10:58 GMT+2
Yeah the same happens for me too. I cannot go past the rockbox logo, I'm greeted with a data abort error every time.
Comment by Andree Buschmann (Buschel) - Saturday, 07 March 2009, 12:28 GMT+2
D-Shadow, what device do you use? Is it a 5G?
Comment by Karl Anderson (D-Shadow) - Tuesday, 10 March 2009, 16:27 GMT+2
It's the 5.5G 80 Gig version.
Comment by Seth (froggyman) - Thursday, 26 March 2009, 22:53 GMT+2
I have a 30GB iPod video 5.5G, and i installed this patch on to rockbox. I definately noticed changes in how the plugins were affected like how others have metioned but also with snake2 and xobox. Those 2 seemed to repsond to exactly what the patch is doing (the game will speed up when interacted then slow down when not). But overall it really helped with running the games and music loading seemed to be faster (i could be wrong though with the music).

I like the idea though of having the overclocking being used when drawing is occuring, that would most likely help with the overall smoothness of games and the OCing of the just the general screen!
Comment by Dave Hooper (stripwax) - Saturday, 28 March 2009, 15:40 GMT+2
Patched build seems unable to build for non-arm devices, but I supposed that's expected? Error due to USEC_TIMER not defined in button.c
Comment by Andree Buschmann (Buschel) - Saturday, 28 March 2009, 18:49 GMT+2
stripwax, in fact I have never tried to build the patch for non-arm...
Comment by Seth (froggyman) - Monday, 30 March 2009, 01:40 GMT+2
do you think a patch for this will ever be made that has like an on/off feature in the menus? For i think that might be a useful idea, because it would give you the choice to run the boost when you want to and vice versa.
Comment by Andree Buschmann (Buschel) - Monday, 30 March 2009, 08:33 GMT+2
No, I don't think this patch will be committed as a new option. The reason for having this gui boost is that you need it (at least for iPod Video) with a lower "normal" clock. A lower clock leads to massive savings in battery runtime.
There are some discussions going about alternative solutions for gui boost -- like boosting while drawing.
Comment by Andree Buschmann (Buschel) - Monday, 30 March 2009, 20:16 GMT+2
New version which does not use USEC_TIMER but current_tick. Should compile for non-PP targets.
   gui_boost_v07.patch (6.5 KiB) 
 drivers/button.c                              |   34 ++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c           |    5 +++
 target/arm/ipod/button-target.h               |    5 ++-
 target/arm/sandisk/sansa-e200/button-e200.c   |    3 ++
 target/arm/sandisk/sansa-e200/button-target.h |    1 
 target/arm/system-pp502x.c                    |   11 ++++++--
 target/arm/system-target.h                    |    6 ++--
 7 files changed, 56 insertions(+), 9 deletions(-)

Comment by Boris Gjenero (dreamlayers) - Tuesday, 31 March 2009, 15:47 GMT+2
Earlier, I used v06 for a while on my 5G 30GB iPod, and I didn't get any crashes. Now I get what seem to be heat-related crashes with r20590 and both v06 and v07. First, my iPod was charging and it was impossible to get to the main menu. Then after resting a while it started up ok but crashed while starting Doom. Then I again couldn't get to the main menu. The next morning it again crashed while starting Doom, and after that I wasn't able to get to the main menu. (I'm not going to list the crashes here. They're the sort of nonsensical crashes one would expect from unstable hardware.)
Comment by Andree Buschmann (Buschel) - Tuesday, 31 March 2009, 16:11 GMT+2
Well, it seems I have one of the seldom PP5021's which can be clocked with high frequency. Somehow the idea of PP5021 being selected PP5022 with lower maximum clock comes up again...

I hope the attached 80MHz-version is patchable (cannot test at work). Otherwise I'll update in a few hours.
   gui_boost_80MHz_v08.patch (6.5 KiB) 
 drivers/button.c                              |   34 ++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c           |    5 +++
 target/arm/ipod/button-target.h               |    5 ++-
 target/arm/sandisk/sansa-e200/button-e200.c   |    3 ++
 target/arm/sandisk/sansa-e200/button-target.h |    1 
 target/arm/system-pp502x.c                    |   11 ++++++--
 target/arm/system-target.h                    |    4 +--
 7 files changed, 55 insertions(+), 8 deletions(-)

Comment by Boris Gjenero (dreamlayers) - Wednesday, 01 April 2009, 16:16 GMT+2
Thanks! The 80 Mhz patch is stable.
Comment by Dave Hooper (stripwax) - Tuesday, 23 June 2009, 02:10 GMT+2
The previous version interacted badly with Pictureflow (essentially prevented scrolling repeatedly fast through covers - any continuous scrolling would seem to be interpreted as scrolling through a couple of album covers only, and you would need to stop scrolling and then start scrolling again to skip through the next two or three covers - essentially unusable). I'll see if the newer version using current_tick fixes this issue
Comment by Thomas Martitz (kugel.) - Tuesday, 23 June 2009, 02:14 GMT+2
What is the problem with pictureflow? AFAIK you're not supposed to be able to skip covers.
Comment by Dave Hooper (stripwax) - Friday, 03 July 2009, 01:56 GMT+2
By skip I just mean 'move from one to the next'. Without the patch you can keep twirling your finger on the scrollwheel and the covers will keep whooshing past. With the past, about one or maybe two will whoosh past and then you stop, you need to physically take your finger off the scrollwheel, put it back on, and twirl your finger some more.
The version using current_tick does not appear to fix the issue.
Comment by Andree Buschmann (Buschel) - Sunday, 21 March 2010, 20:08 GMT+2
Update patch against r25276.
   gui_boost_v09_80MHz.patch (4.9 KiB) 
 drivers/button.c                              |   34 ++++++++++++++++++++++++++
 target/arm/ipod/button-clickwheel.c           |    3 ++
 target/arm/ipod/button-target.h               |    5 ++-
 target/arm/sandisk/sansa-e200/button-e200.c   |    3 ++
 target/arm/sandisk/sansa-e200/button-target.h |    1 
 target/arm/system-pp502x.c                    |    2 -
 target/arm/system-target.h                    |    4 +--
 7 files changed, 47 insertions(+), 5 deletions(-)

Loading...