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