Enhancements for Render composite request

[Jesse Barnes]

On Tue, 25 Aug 2009 10:34:21 -0700
Keith Packard <keithp at keithp.com> wrote:

> The render composite request has a couple of glaring failures:
> 
>  1) Only one rectangle per request. Apps generate a lot of protocol,
>     the server spends a lot of time decoding requests and the driver
>     has to merge requests back together to hand more than one polygon
>     to the hardware. It's interesting that exa (and hence uxa by
>     derivation) have a poly-rectangle composite operation in their
>     driver interface.
> 
>  2) No vblank synchronization. Anyone wanting to double buffer 2D apps
>     has no way of avoiding tearing. I'd like this inside the X server
>     to make updates under a RandR transform sync to vblank.
> 
> As operation 1) is already supported by the EXA API, and can be
> emulated in DIX by executing multiple one-rectangle composite
> requests, this seems easy to add to the protocol in a completely
> compatible fashion:
> 
> COMPOSITERECT	[
> 			src-x, src-y:	INT16
> 			msk-x, msk-y:	INT16
> 			dst-x, dst-y:	INT16
> 			width, height:	CARD16
> 		]
> 
> CompositeRectangles
> 
> 	op:		PICTOP
> 	src:		PICTURE
> 	mask:		PICTURE or None
> 	dst:		PICTURE
> 	rects:		LISTofCOMPOSITERECT
> 
> 	This request is equivalent to a sequence of Composite requests
> 	using the same op/src/mask/dst values and stepping through
> 	rects.
> 
> It seems like operation 2) should be an option on the picture object;
> set a sync mode on the picture and all operations would be covered by
> that mode. It would be 'best effort', so that drivers not supporting
> the sync mode would simply skip it. The question is how fancy this
> option should be; in the simple case, we'd make it just avoid
> tearing, more complex cases could involve having sequential
> operations to the same picture wait for a specific frame number. I'd
> love to have comments on precisely which 'swap modes' would be useful
> here.

Avoiding tearing is the most important thing here, but if you're
writing a media app you'd probably want to be able to specify an
interval, e.g. never swap more than N frames/second.  Assuming you can
find a mode that's a multiple of the framerate you want, this is a
handy feature.  Check out the SGI_swap_control and OML_sync_control
extensions for more details on what GL expects (OML adds a few more
features like a swap counts, swaps on specific frame counts, etc.).

-- 
Jesse Barnes, Intel Open Source Technology Center