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 <[email protected]> >>> --- >>> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
