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

Wed May 10 06:35:05 UTC 2017

On 05/10/2017 03:59 AM, Michel Dänzer wrote:
> On 09/05/17 07:28 PM, Thomas Hellstrom wrote:
>> 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.
> Yes, good point, that occurred to me as well in the meantime.
>
>> 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.
> The xserver Present code currently only supports flipping for
> unredirected fullscreen windows, everything else uses blits.
>
>
>>>>>> 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.
> BTW, maybe you could achieve the same effect by setting vblank_mode to 0
> instead of disabling GLX_OML_sync_control?
>
>
Perhaps. Although then I'd need to duplicate that option from "dri2" to
the gallium driver option cache to be able to set it on a per-driver
per-application basis. With the proposed code, if there is a duplicate,
we prefer the driver instance over the "dri2" instance, and that might
cause some confusion for people that are used to set this option for the
"dri2" driver: driconf would create a default value for the driver in
.drirc  which would override the value for "dri2". I'm not sure we
should consider that a problem though. It would be good to have also the
vblank_mode option visible to driconf.

/Thomas