[PATCH] dri2: Pass AsyncSwap [swap_interval=0] requests to the drivers

Mario Kleiner mario.kleiner at tuebingen.mpg.de
Tue Feb 21 10:01:51 PST 2012


On Feb 21, 2012, at 10:55 AM, Chris Wilson wrote:

> Currently, the midlayer dri2 code intercepts swap_interval=0 (ala
> vblank_mode=0) SwapBuffers and converts it to a CopyRegion request.
> This prevents the backend from doing anything meaningful in this case
> and typically ends up being vsync'ed since the drivers cannot  
> distinguish
> it from a regular CopyRegion request.
>
> v2: Only invalidate the drawable on the behest of the backend, so that
> existing behaviour of not invalidating for async blit copies is
> preserved, suggested by Simon Farnsworh. And rebase for the  
> intervening
> 12 months since v1.
>

...snip...

>  int
>  DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, CARD64  
> target_msc,
>  		CARD64 divisor, CARD64 remainder, CARD64 *swap_target,
> @@ -876,20 +900,11 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr  
> pDraw, CARD64 target_msc,
>
>      /* Old DDX or no swap interval, just blit */
>      if (!ds->ScheduleSwap || !pPriv->swap_interval) {
> -	BoxRec box;
> -	RegionRec region;
> -
> -	box.x1 = 0;
> -	box.y1 = 0;
> -	box.x2 = pDraw->width;
> -	box.y2 = pDraw->height;
> -	RegionInit(&region, &box, 0);
> -
>  	pPriv->swapsPending++;
> -
> -	(*ds->CopyRegion)(pDraw, &region, pDestBuffer, pSrcBuffer);
> -	DRI2SwapComplete(client, pDraw, target_msc, 0, 0,  
> DRI2_BLIT_COMPLETE,
> -			 func, data);
> +	if ((*ds->AsyncSwap)(client, pDraw,
> +			     pDestBuffer, pSrcBuffer,
> +			     func, data))
> +	    DRI2InvalidateDrawable(pDraw);
>  	return Success;
>      }
>

One thing i'm not sure about, maybe just a false alert, maybe a tiny  
race: The ddx could call DRI2SwapComplete() in *ds->AsyncSwap()  
before the server calls DRI2InvalidateDrawable() afterwards.

Normally DRI2InvalidateDrawable() -> As soon as client tries to  
render again -> invalidated buffers -> Client calls  
DRI2GetBuffersWithFormat() -> DRI2ThrottleClient() -> Server usually  
waits for DRI2SwapComplete().

With the current implementation the server could only process  
DRI2SwapComplete() [as triggered by a received vblank event or  
pageflip completion event from the kernel], after  
DRI2InvalidateDrawable() at the end of DRI2SwapBuffers().

a) A single threaded client can't start rendering before return from  
glXSwapBuffers[MscOML](), so no problem.

b) A multi-threaded gl client could wait/poll for swap completion via  
glXWaitForSbcOML(), glXGetSyncValuesOML() or via the  
INTEL_swap_events extension, so it could be that a 2nd rendering  
thread would get released by DRI2SwapComplete() and start rendering  
again before receiving the buffer invalidate events.

I'm not sure if this is a real problem, or if i'm missing something,  
but it could be prevented if the ds->AsyncSwap code itself would call  
DRI2InvalidateDrawable() at the proper time instead of the server  
calling it afterwards.

... <snip> ...

> +
> +    /* added in version 7 */
> +
> +    /* Used when the client requests swap_interval=0, i.e. swap  
> immediately
> +     * with no throttling. Whether to tear or not is left up to  
> the driver.

I wonder if there is any case when the option of "not tearing" would  
make sense for a swaplimit of 0? The only when i set a swaplimit of  
zero in my apps is if i want to benchmark how fast the whole  
rendering loop could go in the best case, so i want it to tear. Same  
for benchmarks.

Other than that

Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>

thanks,
-mario

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner at tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)



More information about the xorg-devel mailing list