Issues adding driver support for present extension

Frank Binns frank.binns at imgtec.com
Tue Apr 15 09:12:31 PDT 2014


Hi,
I've been working on adding support for the present extension in the PVR 
video driver and I've hit a couple of issues related to flipping:
1) When the display driver supports async flipping this mode of 
operation is always used. This means that, when the swap interval is 
none 0, the present extension relies on vblank events to get 
synchronised flips. However, by the time we get the event, wait for any 
outstanding rendering and do the flip we have probably missed the vblank 
period meaning we get screen artefacts. Is there a good reason (other 
than simplifying the code) why present isn't relying on the default 
behaviour of drmModePageFlip() to get synchronised flips?

2) When the display driver doesn't support async flipping and the swap 
interval is 0 we see swaps alternating between flipping and blitting. 
This results in a back buffer continually being created and destroyed on 
the client side, which is obviously highly undesirable.

My understanding is that, in the async case, a vblank event gets 
requested for the next vblank. Any swaps that come in before this 
event's received never get presented to the screen. In addition to this, 
it's fairly unlikely that we catch things in the middle of a flip, i.e. 
we've called drmModePageFlip() but not got back the flip event, meaning 
that any queued vblank events, i.e. queued swaps, are going to be 
completed via a flip. However, in the non-async case we're very likely 
to catch things in the middle of a flip as a flip can only be completed 
during a vblank period. The result is this ping-ponging between flipping 
and blitting.

My current thoughts are that two things probably need to be done to fix 
this:
a) If present gets a swap for the same MSC as a pending flip then it 
should never try to do the presentation and send back 
PresentCompleteModeSkip in the reply.

b) If present gets a swap for an MSC in the future then it shouldn't be 
prevented from completing the swap via a flip just because there is 
currently a pending flip.

Does this sound reasonable, is there a better way of fixing this or am I 
missing something?

Thanks
Frank


More information about the xorg-devel mailing list