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

>
>> 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).

Thanks,

Thomas