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


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

The Present fake CRTC ticks at 1 Hz, so it'll presumably slow down any
application which is otherwise usable. :)


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