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

Michel Dänzer michel at daenzer.net
Wed May 10 01:59:14 UTC 2017


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?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the mesa-dev mailing list