Present extension changes needed for GL/Vulkan vblank modes

[Michel Dänzer]

On 17/10/17 06:52 AM, Keith Packard wrote:
> 
> I know, Present was supposed to support all of the GL vblank modes, and
> it mostly does, except for the most common case...
> 
> In any case, here's a summary of four presentation modes from Vulkan,
> how you'd get that with GL and Present and what they mean:
> 
> Vulkan          GL                                      Present
> 
> IMMEDIATE       glXSwapIntervalEXT(dpy, draw, 0)        PresentPixmap(target-msc=0,
>                 glXSwapBuffers(dpy, draw)                 PresentOptionAsync)
> 
>                         Display the presented frame immediately, even if
>                         that makes the screen tear.
> 
> MAILBOX         glXSwapBuffersMscOML(dpy, draw, 0,      PresentPixmap(target-msc=0)
>                 	    0, 0, NULL, NULL, NULL)
> 
>                         Display the presented frame at the next vblank
>                         interval, replacing any frame already queued at
>                         that time.
> 
> FIFO            glXSwapIntervalEXT(dpy, draw, 1)        PresentPixmap(target-msc=previous-msc+1)
>                 glXSwapBuffers(dpy, draw)
>                 
>                         Place the frame to be presented at the end of a
>                         queue. At each vblank interval, if the queue is
>                         non-empty, display the first member of the
>                         queue.
> 
> 
> FIFO_RELAXED    glXSwapIntervalEXT(dpy, draw, -1)       PresentPixmap(target-msc=previous-msc+1,
>                 glXSwapBuffers(dpy, draw)                  PresentOptionAsync)
> 
>                         Place the frame to be presented at the end of a
>                         queue. At each vblank interval, if the queue is
>                         non-empty, display the first member of the
>                         queue. Additionally, if the queue was empty and
>                         no frame switch happened for this vblank
>                         interval, immediately switch to the new frame
> 
> From the X protocol perspective, I think we're all set for IMMEDIATE and
> MAILBOX.

However, the current implementation cannot do true MAILBOX behaviour,
because it cannot replace a frame which is already queued in the kernel.


> However, I think both FIFO and FIFO_RELAXED cannot be done
> because they rely on the client knowing the previous MSC (Media Stream
> Counter, or frame counter) value, which the client really isn't going to
> know unless it's presenting every frame.
> 
> To fix them, I think we need to add relative MSC values to Present,
> so we can ask that the X server do the right thing.
> 
> PresentOptionRelative
> 
>         If 'options' contains PresentOptionRelative, then the most
>         recent actual MSC for a PresentPixmap request to the same
>         drawable (i.e., the MSC value that would have been reported in
>         the associated PresentCompleteNotify event) will be added to
> [apparent copy-paste accident snipped]
>         target-msc.
> 
>         If no PresentPixmap request has been made to this drawable, then
>         the current MSC value for the drawable will be added to
>         target-msc.

I see an issue with basing the relative target on the last effective
MSC: Imagine that the application misses a large number of frames, e.g.
because the user hit Ctrl-Z. This means that the target MSC values will
trail the drawable's current MSC, and the application's presentation
timing may be "different" until it catches up.


How about this instead: If there are pending PresentPixmap requests for
the window, the relative target will be added to the latest target MSC
of the pending requests. Otherwise, it will be added to the drawable's
current MSC.


Other than that, I think the PresentOptionRelative flag makes sense.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 224 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171017/6b73a737/attachment.sig>