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(®ion, &box, 0);
-
pPriv->swapsPending++;
-
- (*ds->CopyRegion)(pDraw, ®ion, 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 <[email protected]>
thanks,
-mario
*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: [email protected]
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)
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
