Opened 10 years ago

Last modified 10 years ago

#1419 new enhancement

Screen refresh rate should be dynamic to save power.

Reported by: jg Owned by: jg
Priority: normal Milestone: Opportunity
Component: x window system Version:
Keywords: power Cc: ajax, mlj, jg, rsmith
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


Up to 100mw of power can be saved by controlling the refresh speed of the screen. This is very significant in Ebook mode.

Whenever the X server transitions from not drawing to drawing, the refresh rate should be increased to its normal 50hz at the next vertical retrace (being slightly more clever than just going non-idle may be worthwhile; we can use the damage facilities, I suspect, to know if the screen has been touched). Whenever the X server goes idle, the refresh rate should be dropped to a frame rate of (tbd) at the next vertical retrace. This will require cooperation with the device driver.

Change History (10)

comment:1 Changed 10 years ago by jg

  • Keywords power added

comment:2 Changed 10 years ago by gnu

Unfortunately, slowing down refresh involves slowing the dot-clock rather than just inserting lots
of time between the end of the last pixel, and the beginning of the first pixel of the next frame,
the way old CRTs had a very long vertical retrace period to account for electron beam movement. The slow dot-clock means that we are stuck with a longer-than-usual delay before we can get either changed pixels, or changed settings (CPU image versus DCON internal image) to the screen.

Perhaps this can be re-examined in a Gen 1.5 or Gen 2 design. Programming the CPU video for a high speed dot-clock but only a few frames per second, would probably allow the refresh rate to be rapidly ramped up at all times. (If the CPU video is in vertical retrace when you ask it to change, it can just end the vertical retrace and start a new frame immediately. If it's in mid-frame, it can switch to the new vertical retrace timing at the end of that frame, immediately scanning out the next frame. I don't know if our current CPU video chips can change their vertical retrace timing on the fly without glitching.)

comment:3 Changed 10 years ago by jg

The power savings is from the lower frequency. So I don't think this idea works.

comment:4 Changed 10 years ago by kimquirk

  • Milestone changed from BTest-4 to Trial-2
  • Verified unset

Moving to next software release, Trial-2.

comment:5 Changed 10 years ago by JordanCrouse

  • Milestone changed from Trial-2 to Opportunity

As per #734, we'll be putting the DCON into a lower dotclock when the screen is frozen. Changing the GPU rate is a nasty trick, and I'm not entirely sure we can lock in the DOTPLL that slowly (I guess I should do the math). I recommend we do #734 immediately, and then move this out to opportunity to consider later. It shouldn't be anywhere near our current release path. We should be hanging about in the DCON source mode most of the time now, as per ajax's work.

comment:6 in reply to: ↑ description Changed 10 years ago by ajax

One thing I'm not clear on is how tolerant the DCON (and display proper) is to changing its refresh rate at arbitrary times. If it's just a clocked FIFO then in principle there's no reason we need to wait for vblank, and we could go immediately to the lowest power mode as soon as we enter DCON.

The current GPU only applies mode switch on vblank, so there's no real win to be had there. But that's okay. If you're animating, you want full speed updates, and if you're not, you want to be in the lowest possible power mode as soon as possible.

comment:7 Changed 10 years ago by jg

Mary Lou thinks that the LCD will be happy changing the dot-clock mid-frame, and it will likely be invisible. If the dcon doesn't care, the LCD won't either.

comment:8 Changed 10 years ago by JordanCrouse

ACtually, I'm way more worried about the CPU - changing the DOTPLL is a difficult event - we have to turn off the entire engine, switch the PLL and let it sync - thats a time consuming process. You might say that we can just do it while the DCON has the ball - but if thats the case, why even bother changing the GPU refresh rate at all? Turn off the GPU, and set whatever rate we want on the DCON - as per #734. Dynamically changing the GPU refresh rate is likely to be way more intrusive and delicate then we would like it to be.

comment:9 Changed 10 years ago by jg

  • Owner changed from JordanCrouse to ajax

comment:10 Changed 10 years ago by ajax

  • Owner changed from ajax to jg
Note: See TracTickets for help on using tickets.