On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote:
On 10/26/18 10:53 AM, Ville Syrjälä wrote:
Speaking of timestamps. What is the expected behaviour of vblank timestamps when vrr is enabled?
When vrr is enabled the duration of the vertical front porch will be extended until flip or timeout occurs. The vblank timestamp will vary based on duration of the vertical front porch. The min/max duration for the front porch can be specified by the driver via the min/max range.
No changes to vblank timestamping handling should be necessary to accommodate variable refresh rate.
The problem is that the timestamp is supposed to correspond to the first active pixel. And since we don't know how long the front porch will be we can't realistically report the true value. So I guess just assuming min front porch length is as good as anything else?
That (and documenting that the timestamp corresponds to the earliest possible first active pixel, not necessarily the actual one, with VRR) might be good enough for the actual vblank event timestamps.
However, I'm not so sure about the timestamps of page flip completion events. Those could be very misleading if the flip completes towards the timeout, which could result in bad behaviour of applications which use them for animation timing.
Maybe the timestamp could be updated appropriately (yes, I'm hand-waving :) in drm_crtc_send_vblank_event?
Hmm. Updated how? Whether it's a page flip event or vblank even we won't know when the first active pixel will come. Although I suppose if there is some kind of vrr slew rate limit we could at least account for that to report a more correct "this is the earliest you migth be able to see your frame" timestamp.
Oh, or are you actually saying that shceduling a new flip before the timeout is actually going to latch that flip immediately? I figured that the flip would get latched on the next start of vblank regardless, and the act of scheduling a flip will just kick the hardware to start scanning the previously latched frame earlier.
scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank ^ ^ ^ ^ | | flip C latch C flip B latch B
This would kind of defeat the point of VRR, wouldn't it? If a flip was scheduled after the start of vblank, the vblank would always time out, resulting in the minimum refresh rate.
scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank ^ ^ ^ ^ | latch B | latch C flip B flip C
So this is what happens.
Regardless, when the flip is latched, AMD hardware generates a "pflip" interrupt, and its handler calls drm_crtc_send_vblank_event (and in the case of DC drm_crtc_accurate_vblank_count before that). So the time when drm_crtc_send_vblank_event is called might be a good approximation of when scanout of the next frame starts.
Another possibility might be to wait for the hardware vline counter to wrap around to 0 before calling drm_crtc_accurate_vblank_count, then the calculations should be based on 0 instead of crtc_vtotal.