[Mesa-dev] [PATCH 3/5] glx/dri3: Request non-vsynced Present for swapinterval zero. (v2)

[Eero Tamminen]

Hi,

On 12/04/2014 11:38 PM, Mario Kleiner wrote:
> 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 ...

Could this be related to / explain also:
	https://bugs.freedesktop.org/show_bug.cgi?id=81204
?

(Another buffer swap related issue with DRI3 is bug 79715)


	- Eero

> 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.davy at ens.fr>
>>
>> Axel Davy
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev