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

[Michel Dänzer]

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://git.gnome.org/browse/mutter/tree/clutter/clutter/cogl/clutter-stage-cogl.c
> 
> 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://git.gnome.org/browse/mutter/tree/cogl/cogl/winsys/cogl-winsys-glx.c#n2321

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.


>>> 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?


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