On 12/04/2014 11:20 AM, Axel Davy wrote:
On 02/12/2014 20:53, Mario Kleiner wrote :
Restores proper immediate tearing swap behaviour for
OpenGL bufferswap under DRI3/Present.
+ if (priv->swap_interval == 0)
+ options |= XCB_PRESENT_OPTION_ASYNC;
+
back->busy = 1;
Currently under DRI3 glx, you'll get triple buffering behaviour.
I agree this should not be the default, and your patches fixes that.
Ideally a user option should be added to control triple buffering.
The DRI2 implementation had a per-drawable "swap_limit" and
corresponding server api to get and set it. I'm not sure atm. if it was
ever exposed via mesa, but i think it wasn't. I agree i would be nice to
have some control there.
There is one more problem i noticed, of which i'm not yet sure if it is
related to mesa's n-buffering and the way it dynamically adapts n, or
some driver implementation bug, or some other weirdness, because intel
and nouveau behave differently. If a client does multiple swapbuffers
calls without any rendering inbetween, then something in the buffer
management seems to get confused for the rest of the session, even if
the client later behaves "properly" ie., draw -> swap -> draw -> swap ...
Good case:
During whole session: draw -> swap -> draw -> swap ...
Bad case:
At least once: swap -> swap
For the rest of the session, even if you do regular
draw->swap->draw->swap, at least under nouveau, you get proper display
for a few frames, followed by some frame displayed which contains pixel
trash, like from an uninitialized renderbuffer, then a few good frames
-> pixel trash and so on. First i thought it's unsynchronized rendering
to a swap pending buffer, ie., buffer presented while still rendered to.
But now i think it is a trash filled buffer presented every couple of
frames.
I didn't have time to track this one down, and probably won't have time
to look into it atm. I just made sure that my application never does
idle swaps, even if it only renders one useless pixel to keep mesa from
freaking out.
Could be a bug. Could be some assumption that gets broken in a rather
confusing way due to the triple/n-buffering.
If you add a comment above these lines, saying something like:
It is possible to enable triple buffering behaviour by not using
XCB_PRESENT_OPTION_ASYNC, but this should not be the default.
I'll add it literally, because anything i write in comments tends to
become a not very well written essay ;-). Or should i add a "...but this
triple buffering should probably not be the default in future
implementations but be made configurable by some new api"?
thanks,
-mario
You can add my
Reviewed-by: Axel Davy <axel.d...@ens.fr>
Axel Davy
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
