Updates to the Present and DRI3 extension specifications

[davyaxel at free.fr]

Hi Keith,

I have a few comments to share.
>
>
> 			     ❄ ❄ ❄  ❄  ❄ ❄ ❄
>
> 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.

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.

>
>
> 	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.

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. 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?

Thanks,

Axel Davy