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

[Mario Kleiner]

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.davy at ens.fr>
>
> Axel Davy