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

[Thomas Hellstrom]

Hi, Michel,

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 have yet
to investigate other compositors, but at this point I can't claim other
compositors and applications are doing the same thing and if we, in that
case, break some actually wanted behaviour by disabling EXT_buffer_age.

For the OML_sync_control extension, some applications may actually not
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.

/Thomas