Updates to the Present and DRI3 extension specifications

[Keith Packard]

davyaxel at free.fr writes:

> I have a few comments to share.

Thanks!

> In the context of XWayland, we may send the buffer to the
> Wayland compositor (when client asks Present Option Async),
> instead of doing a copy. I would like the specification to be
> clarified to include that the buffer may be used for something
> else than scanout and flipping.
>
> The same comment applies for the specification of the Present
> options and the PresentCompleteNotify event.

All of the Present options and capabilities are related to the physical
scanout process; if there's another level of indirection between the
client and that scanout engine, you'll have to ensure that the Async
option is respected through that layer (or not advertised as a
capability), and that the other layer also reports accurate MSC and UST
times for the scanout process.

Any PresentCompleteNotify events must be delayed until the scanout
process has started for the indicated frame.

> Could you explain if this capability is linked to what you
> mention in PresentIdleNotify: that idle-fence could be
> different that none in the PresentIdleNotify event, or if
> this tells the client if setting a non-null fence in PresentPixmap
> is useful.

I stuck the idle-fence in the PresentIdleNotify event because it seemed
like a good idea -- that fence will *always* be the idle-fence supplied
in the related PresentPixmap request.

The fencing capability indicates that the system would like clients to
provide fences for serialization; if the client *does* provide a fence,
then the X server can assume that the client will use it before doing
any further operations with the pixmap.

Here's some clarifications to how idle fences are supposed to be used.

diff --git a/presentproto.txt b/presentproto.txt
index f70978f..79bffb8 100644
--- a/presentproto.txt
+++ b/presentproto.txt
@@ -169,13 +169,23 @@ The name of this extension is "Present"
        
        When the X server has finished using 'pixmap' for this
        operation, it will send a PresentIdleNotify event and arrange
-       for the 'idle-fence' to be triggered. This may be at any time
+       for any 'idle-fence' to be triggered. This may be at any time
        following the PresentPixmap request -- the contents may be
        immediately copied to another buffer, copied just in time for
        the vblank interrupt or the pixmap may be used directly for
        display (in which case it will be busy until some future
        PresentPixmap operation).
 
+       If 'idle-fence' is not None, then the client guarantees to the
+       X server that it will wait for that fence to be signalled
+       before it uses the pixmap again. If 'idle-fence' is None, then
+       the X server must arrange for the pixmap to be re-usable by
+       the client as soon as the PresentIdleNotify event has been
+       received. Note that if PresentCapabilityFence is set for the
+       associated CRTC, then clients should use fences to improve
+       overall systme performance. If PresentCapabilityFence is not
+       set, then using fences offers no benefit, but also no cost.
+
        If 'target-msc' is greater than the current msc for 'window',
        the presentation will occur at (or after) the 'target-msc'
        field. Otherwise, the presentation will occur after the next
@@ -410,7 +420,8 @@ The name of this extension is "Present"
 
        'pixmap' is the pixmap which is ready for re-use.
 
-       'idle-fence' is the fence which is used to synchronize
+       'idle-fence' is the fence which was provided in the
+       originating PresentPixmap request and is used to synchronize
        rendering between the client and the X server's use of the
        buffer. If not None, then the client must wait for the fence
        to be signaled before using the pixmap.


> In the latter case, if we advertise the capability, has the client the
> obligation to put a non-null fence in PresentPixmap and respect it?

No. If the client fails to provide a fence when the capability is
indicated, then the X server is obligated to make things work correctly,
even if that ends up being significantly less efficient.

The fence capability indicates that clients *should* provide a fence and
use it to maximize performance of the system. This way, dumb clients can
still work correctly and smart clients will work both correctly and
efficiently.

The other option would cause dumb clients to operate incorrectly 
on some machines at random times.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131019/c45d4489/attachment.pgp>