A low refresh rate probably still requires the same display-side framebuffer as PSR.
With conventional PSR, I think the goal is to power off the link between the system framebuffer and the display controller and potentially power down the system framebuffer and GPU too. This may not be beneficial unless it can be left off long enough, and there may be substantial latency to fire it all back up. You do it around sleep modes where you are expecting a good long pause.
Targeting 1 Hz sounds like actually planning to clock down the link and the system framebuffer so they can run sustain low bandwidth in a more steady state fashion. Presumably you also want to clock down any app and GPU work to not waste time rendering screens nobody will see. This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
But why 1hz? Can’t the panel just leave the pixels on the screen for an arbitrary length of time until something triggers refresh? Only a small amount of my screen changes as I’m typing.
When PSR or adaptive refresh rate systems suspend or re-clock the link, this requires reengineering of the link and its controls. All of this evolved out of earlier display links, which evolved out of earlier display DACs for CRTs, which continuously scanned the system framebuffer to serialize pixel data into output signals. This scanning was synchronized to the current display mode and only changed timings when the display mode was set, often which a disruptive glitch and resynchronization period. Much of this design cruft is still there, including the whole idea of "sync to vblank".
When you have display persistence, you can imagine a very different architecture where you address screen regions and send update packets all the way to the screen. The screen in effect becomes a compositor. But then you may also want transactional boundaries, so do you end up wanting the screen's embedded buffers to also support double or triple buffering and a buffer-swap command? Or do you just want a sufficiently fast and coordinated "blank and refill" command that can send a whole screen update as a fast burst, and require the full buffer to be composited upstream of the display link?
This persistence and selective addressing is actually a special feature of the MIP screens embedded in watches etc. They have a link mode to address and update a small rectangular area of the framebuffer embedded in the screen. It sends a smaller packet of pixel data over the link, rather than sending the whole screen worth of pixels again. This requires different application and graphics driver structure to really support properly and with power efficiency benefits. I.e. you don't want to just set a smaller viewport and have the app continue to render into off-screen areas. You want it to focus on only rendering the smaller updated pixel area.
this is just regurgitating the manufacturer's claim. I believe it when I see it. Most of display energy use is to turn on the OLED/backlight. They're claiming, because our display flickers less, it's 48% more efficient now.
Haven't phones, watches and tablets been using low refresh rates to enable battery improvements for a while?
The Apple Watch Series 5 (2019) has a refresh rate down to 1Hz.
M4 iPad Pro lacks always-on display despite OLED panel with variable refresh rate (2024):
https://9to5mac.com/2024/05/09/m4-ipad-pro-always-on-display...
Is this materially different from panel self refresh?
A low refresh rate probably still requires the same display-side framebuffer as PSR.
With conventional PSR, I think the goal is to power off the link between the system framebuffer and the display controller and potentially power down the system framebuffer and GPU too. This may not be beneficial unless it can be left off long enough, and there may be substantial latency to fire it all back up. You do it around sleep modes where you are expecting a good long pause.
Targeting 1 Hz sounds like actually planning to clock down the link and the system framebuffer so they can run sustain low bandwidth in a more steady state fashion. Presumably you also want to clock down any app and GPU work to not waste time rendering screens nobody will see. This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
But why 1hz? Can’t the panel just leave the pixels on the screen for an arbitrary length of time until something triggers refresh? Only a small amount of my screen changes as I’m typing.
When PSR or adaptive refresh rate systems suspend or re-clock the link, this requires reengineering of the link and its controls. All of this evolved out of earlier display links, which evolved out of earlier display DACs for CRTs, which continuously scanned the system framebuffer to serialize pixel data into output signals. This scanning was synchronized to the current display mode and only changed timings when the display mode was set, often which a disruptive glitch and resynchronization period. Much of this design cruft is still there, including the whole idea of "sync to vblank".
When you have display persistence, you can imagine a very different architecture where you address screen regions and send update packets all the way to the screen. The screen in effect becomes a compositor. But then you may also want transactional boundaries, so do you end up wanting the screen's embedded buffers to also support double or triple buffering and a buffer-swap command? Or do you just want a sufficiently fast and coordinated "blank and refill" command that can send a whole screen update as a fast burst, and require the full buffer to be composited upstream of the display link?
This persistence and selective addressing is actually a special feature of the MIP screens embedded in watches etc. They have a link mode to address and update a small rectangular area of the framebuffer embedded in the screen. It sends a smaller packet of pixel data over the link, rather than sending the whole screen worth of pixels again. This requires different application and graphics driver structure to really support properly and with power efficiency benefits. I.e. you don't want to just set a smaller viewport and have the app continue to render into off-screen areas. You want it to focus on only rendering the smaller updated pixel area.
this is just regurgitating the manufacturer's claim. I believe it when I see it. Most of display energy use is to turn on the OLED/backlight. They're claiming, because our display flickers less, it's 48% more efficient now.