The following set of patches is a follow-up to a discussion that took place on this list back in December [1]. It was about how the MSC-wait and swap-scheduling functions should behave when CRTC is not running because the display is shut off (in DPMS-off state). We left off with a set of patches (now in Git) that fixed the acute problem that prompted the discussion [2]. As a quick reminder, the problem was that when display went into DPMS-off state, swap function was returning immediately making the client run at uncontrolled pace, unnecessarily dissipating extra power on the CPU and GPU (and probably defeating the power savings achieved by shutting the display off).
The solution that was accepted was a simple one (block the client for a constant time period) and, at the end of the discussion, I promised to follow up with a more sophisticated solution: the one that would fully emulate a running CRTC and make the client run at the same pace that it was running while the display was on [3]. I was finally able to find some time to work on this (apologies for long delay). The patch-set that follows should achieve the stated objective. I managed to keep the modification confined to the DDX. No new functionality is needed from X-server or any other library except one #define in libdrm which should go into libdrm anyway (it was sent to dri-devel list but has not been merged yet [4]). The emulation of a running CRTC works like this: When CRTC is about to be turned off, the last vblank time, sequence number, and frequency are recorded. The vblank counter no longer progresses after this point. If MSC, MSC-wait or swap are requested while the CRTC is off, the DDX looks at the current time and the previously recorded information about vblanks and extrapolates how many vblanks would have passed by that time. If necessary, it looks at target_msc sent by the client and calculates at what time it would happen if the CRTC were running. At this point the DDX has all the information to schedule the wait or swap using Xorg's timers facility and make up the MSC by adding the extrapolated value to the last actual vblank value. When the CRTC goes back into the running state the DDX reverts back to normal use of vblanks, but the MSC number must now be offset by any number of vblanks that would fit in the time period spent in DPMS-off state (i.e., interpolated vblanks). As the CRTC goes in and out of DPMS on/off state the number of interpolated vblanks (offset added to vblank counter to produce MSC) accumulates. As the result, the MSC progresses continuously through DPMS states and the its frequency matches the vblank frequency determined by the last mode used on the CRTC. The end result is that regardless in which state the display is, the application sees the events (time and sequence numbers) that progress as if the CRTC is running and the events happen at right time points on the grid determined by the vlbanks (real or interpolated). thanks, Ilija [1] http://lists.x.org/archives/xorg-driver-ati/2012-December/024141.html [2] http://lists.x.org/archives/xorg-driver-ati/2012-December/024194.html [3] http://lists.x.org/archives/xorg-driver-ati/2012-December/024198.html [4] http://lists.freedesktop.org/archives/dri-devel/2012-November/030852.html _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
