[Mesa-dev] [PATCH RFC 4/4] dri: Turn of a couple of glx extensions for gnome-shell on vmwgfx.

[Thomas Hellstrom]

On 05/09/2017 11:29 AM, Michel Dänzer wrote:
> On 09/05/17 06:12 PM, Thomas Hellstrom wrote:
>> On 05/09/2017 10:47 AM, Michel Dänzer wrote:
>>> On 09/05/17 05:32 PM, Thomas Hellstrom wrote:
>>>> On 05/09/2017 10:05 AM, Michel Dänzer wrote:
>>>>> On 05/05/17 11:02 PM, Thomas Hellstrom wrote:
>>>>>> Increases performance on vmwgfx since we're avoiding full buffer damage and
>>>>>> since we can't sync to vertical retrace anyway.
>>>>>>
>>>>>> Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
>>>>>> ---
>>>>>>  src/mesa/drivers/dri/common/drirc | 7 +++++++
>>>>>>  1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/src/mesa/drivers/dri/common/drirc b/src/mesa/drivers/dri/common/drirc
>>>>>> index 14d7713..a8f2ccf 100644
>>>>>> --- a/src/mesa/drivers/dri/common/drirc
>>>>>> +++ b/src/mesa/drivers/dri/common/drirc
>>>>>> @@ -137,4 +137,11 @@ TODO: document the other workarounds.
>>>>>>              <option name="glsl_zero_init" value="true"/>
>>>>>>          </application>
>>>>>>      </device>
>>>>>> +    <!-- vmwgfx doesn't like full buffer swaps and can't sync to vertical retraces.-->
>>>>>> +    <device driver="vmwgfx">
>>>>>> +        <application name="gnome-shell" executable="gnome-shell">
>>>>>> +            <option name="glx_disable_ext_buffer_age" value="true" />
>>>>>> +            <option name="glx_disable_oml_sync_control" value="true" />
>>>>>> +        </application>
>>>>>> +    </device>
>>>>>>  </driconf>
>>>>>>
>>>>> Why restrict this to gnome-shell? Wouldn't any application using these
>>>>> extensions be affected by the same issues?
>>>> So far I've only looked into gnome-shell because we had a noticeable
>>>> slowdown. The special thing with gnome-shell is that if
>>>> GLX_EXT_buffer_age is available, it prefers a "swapbuffer with damage"
>>>> path over copy_sub_buffer. Unfortunately the "swapbuffer with damage"
>>>> path is implemented as ordinary swapbuffer on GLX. Not so on EGL. For
>>>> real hardware this is a gain, I believe, since they end up page-flipping
>>>> so I can't really claim gnome-shell is doing something wrong.
>>> I don't think it's directly related to "SwapBuffers with damage" or page
>>> flipping. The idea of GLX_EXT_buffer_age is that it lets the application
>>> know if and when the current back buffer was already used as a back
>>> buffer previously. Based on this, the application can know that it
>>> doesn't need to draw to some areas of the back buffer, because they
>>> already have the desired contents.
>>>
>>> Is the problem maybe that you need to read back the back buffer contents
>>> from the host if the application doesn't fully clear it?
>> I don't think so. My understanding of the code
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.gnome.org_browse_mutter_tree_clutter_clutter_cogl_clutter-2Dstage-2Dcogl.c&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=Vv2TIj9fJv0pacKZnnUx2Rt4X0PVVVwfADJnlVmGevM&s=EtclRrb_yCMinIRtc71MvU1RnMFslfRza8lwX3vc1cM&e= 
>>
>> is that when gnome-shell (based on what you write above) decides it
>> doesn't need to draw some areas of the back buffer, it eventually ends
>> up calling  cogl_onscreen_swap_buffers_with_damage(). And the cogl GLX
>> backend ends up calling glxSwapBuffers(), in effect damaging the full
>> back buffer.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.gnome.org_browse_mutter_tree_cogl_cogl_winsys_cogl-2Dwinsys-2Dglx.c-23n2321&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=Vv2TIj9fJv0pacKZnnUx2Rt4X0PVVVwfADJnlVmGevM&s=JtgpIf2My3zGO2lUWC7-3py5Hgpk5QOOxlUYOjhg-zE&e= 
> Yes, this is as intended with GLX_EXT_buffer_age; if there was actual
> "SwapBuffers with damage" functionality, GLX_EXT_buffer_age would be
> kind of pointless, since the application could just only draw and swap
> the areas which changed since last time.
>
> Without page flipping, the "undamaged" areas will be unnecessarily
> blitted from back to front buffer, but GLX_EXT_buffer_age still provides
> some savings (compared to drawing the whole buffer and calling
> glXSwapBuffers) via the application not drawing those areas in the first
> place.
>
> In summary, gnome-shell is using GLX_EXT_buffer_age exactly as intended,
> I wouldn't expect other applications to use it any differently.

True, but OTOH I'm not sure other applications would provide such a
performance benefit by switching to copy_sub_buffer()
if it's *not* present. Also (although I'm not sure dri3 server-side
implements this), but I guess even vmware could to true
"page-flipping" in the sense of saving a copy, if rendering to a
redirected window.


>
>>>> For the OML_sync_control extension, some applications may actually notcd
>>>> behave worse with this extension present, even if the time source is
>>>> provided by the Xserver present extension "fake" backend.
>>>> In the gnome-shell case it's a slowdown, though.
>>> The Present fake CRTC ticks at 1 Hz, so it'll presumably slow down any
>>> application which is otherwise usable. :)
>>>
>>>
>> But the 1Hz clock is only when switched away or blanked, right?
>> Otherwise it should be a 60Hz clock. At least glxgears runs faithfully
>> at what it believes is 60Hz on Xwayland/glamor/dri3 and Xorg/vmwgfx/dri3
>> (yet to be pushed).
> Oh, I see present_fake_screen_init sets the interval to 1/60 s if the
> driver doesn't provide a get_crtc hook.
>
> Then I'm unsure again what the problem is, though — the presentation
> timing should be basically the same as on real hardware?
>
>
Yes for this extension, I haven't really examined in detail exactly why
we get increased latency with gnome-shell.

But in the end it might well be that we end up enabling these options
also for other apps, or perhaps by default.
But IMO more testing is needed.

Thanks,

Thomas