Updates to the Present and DRI3 extension specifications

[Keith Packard]

First off, I want to thank people for their review and comments about
these two extensions, in particular those attending XDC who helped
clarify several important points.

These updates include a proposal for the Present Redirection additions;
I'd love to get some comments here, especially from people implementing
compositing managers, but I don't expect to have that ready for the X
server freeze in a couple of weeks. Everything else only involves minor
changes to the current DRI3/Present implementation which I've been
running here for several months without any major issues.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

1. DRI3 changes.

        git://people.freedesktop.org/~keithp/dri3proto master

I've added the ability to take an existing SyncFence object and transfer
it to the client. That seems like a requirement to implement a
compositing manager in GL.

I've also realized that because there isn't any actual kernel support
for Fencing in the Intel driver, I'll probably end up just removing all
of the futex-based fake fences I'd done there and rely on implicit
synchronization for now. We need kernel fencing support in the intel
driver to do the cut-through page flipping that I want; if I get to that
point, I'll have 'real' kernel fence objects and won't have to play
games with futexes (or eventfds either, for that matter).

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2. Present changes. The full version of the specification is available
here. Below, I've summarized the changes over the last couple of weeks.

        git://people.freedesktop.org/~keithp/presentproto master

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2.1 PresentIdleNotify events

A GPU-resident fence is something queued to the GPU which causes
execution to halt until the fence is triggered. As such, the CPU will
queue such a fence long before it becomes triggered. Because pixmaps
used in PresentPixmap can become idle out of sequence, the client needs
to know which pixmap it should use in the next frame, but it doesn't
want to wait for the fence to be signaled as that would involve blocking
the CPU on GPU execution.

Sending an X event to let the client know which pixmap will become idle
next will allow the client to select the right pixmap to use for
subsequent operations. The client is expected to wait for the fence
before actually using it, but that wait can be queued to the GPU and not
block the CPU immediately.

For the Intel driver, which has no GPU fences, the IdleNotify event will be
used to select which pixmap to use next; no fence will be needed as the
X server will ensure that GPU operations are correctly serialized.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2.2 Present redirection

This version also tries to specify the semantics for Present
redirection. The design allows the compositing manager to catch
PresentPixmap operations to any redirected windows and handle them
itself. Clients will be completely unaware that redirection is
occurring, the apparent behavior will be as if the window was not
composited and the PresentPixmap operations were handled directly by the
X server itself.

Because this is not yet well understood, I don't think this will be
ready for X server 1.15 and I will remove it from the specification if
the X server doesn't include support for it. It would then be re-added
in a later version of the specification and X server and compositing
manager clients will be able to tell whether support is available by
looking at the extension version number.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2.3 Capabilities

Instead of requiring all drivers to support all Present features, I've
added a set of per-CRTC capabilities. Here's the current set:

	PresentCapabilityAsync means that the target device can flip
	the scanout buffer mid-frame instead of waiting for a vertical
	blank interval. The precise latency between the flip request
	and the actual scanout transition is not defined by this
	specification, but is intended to be no more than a few
	scanlines.

	PresentCapabilityFence means that the target device can take
	advantage of SyncFences in the Present operations to improve
	GPU throughput. The driver must operate correctly in the
	absense of fences, but may have reduced performance. Using
	fences for drivers not advertising this capability should have
	no performance impact.

	PresentCapabilityUST means that the target device can scanout
	the image at an arbitrary UST time value, and is not driven by
	a periodic scanout timer. Applications specifying UST times
	for PresentPixmap can expect that their image will appear to
	the user within a short amount of time from that specified in
	the request. The precise accuracy of the scanout time is not
	defined by the extension, but is expected to be on the order
	of milliseconds or less.

Adding new capabilities will require bumping the minor protocol version
so that clients can tell the difference between an unknown capability
and an unsupported capability.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄


2.4 Options

PresentPixmap now takes a set of options to control its behavior. There
are three defined:

        PresentOptionAsync - requests cut-through copy or flip instead
        of blocking for vblank

        PresentOptionCopy - requires that the X server *not* flip to the
        provided pixmap and instead copy from it. This allows lazy
        applications to know that their buffer will go idle when the
        PresentNotify event is delivered and that its contents will be
        precisely what was in it before the operation.

        PresentOptionUST - requests that the copy or flip occur at a
        specific UST (unadjusted system time, which on Linux is
        CLOCK_MONOTONIC). For hardware which doesn't have a periodic
        screen update, this allows applications to schedule updates at
        regular clock intervals.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2.5 CompleteModes

The PresentCompleteNotify event now tells the client what happened with
the pixmap it sent to PresentPixmap:

        PresentCompleteModeCopy - the bits were copied out of the pixmap
        and into the window. The buffer is now idle.

        PresentCompleteModeFlip - the pixmap is being used as a scanout
        buffer. The buffer will not be idle until it is not being used
        as scanout anymore.

        PresentCompleteSkip - when a subsequent PresentPixmap operation
        targets the same window at the same MSC, then any pending
        operations will appear to execute at the specified time, but the
        X server will not actually do anything with the
        contents. Applications should probably treat this the same as
        PresentCompleteModeCopy in most respects.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄

2.6 Wait fences

PresentPixmap now has a wait-fence parameter which it uses to
synchronize access with other clients. The PresentPixmap operation will
not occur until after the specified fence has been signaled.

			     ❄ ❄ ❄  ❄  ❄ ❄ ❄


-- 
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/20131018/187d034f/attachment.pgp>