On 05/10/2017 03:59 AM, Michel Dänzer wrote: > On 09/05/17 07:28 PM, Thomas Hellstrom wrote: >> On 05/09/2017 11:29 AM, Michel Dänzer wrote: >>> On 09/05/17 06:12 PM, Thomas Hellstrom wrote: >>>> 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 <thellst...@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://urldefense.proofpoint.com/v2/url?u=https-3A__git.gnome.org_browse_mutter_tree_clutter_clutter_cogl_clutter-2Dstage-2Dcogl.c&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=Vv2TIj9fJv0pacKZnnUx2Rt4X0PVVVwfADJnlVmGevM&s=EtclRrb_yCMinIRtc71MvU1RnMFslfRza8lwX3vc1cM&e= >>>> >>>> >>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git.gnome.org_browse_mutter_tree_cogl_cogl_winsys_cogl-2Dwinsys-2Dglx.c-23n2321&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=Vv2TIj9fJv0pacKZnnUx2Rt4X0PVVVwfADJnlVmGevM&s=JtgpIf2My3zGO2lUWC7-3py5Hgpk5QOOxlUYOjhg-zE&e= >>>> >>> Yes, this is as intended with GLX_EXT_buffer_age; if there was actual >>> "SwapBuffers with damage" functionality, GLX_EXT_buffer_age would be >>> kind of pointless, since the application could just only draw and swap >>> the areas which changed since last time. >>> >>> Without page flipping, the "undamaged" areas will be unnecessarily >>> blitted from back to front buffer, but GLX_EXT_buffer_age still provides >>> some savings (compared to drawing the whole buffer and calling >>> glXSwapBuffers) via the application not drawing those areas in the first >>> place. >>> >>> In summary, gnome-shell is using GLX_EXT_buffer_age exactly as intended, >>> I wouldn't expect other applications to use it any differently. >> True, but OTOH I'm not sure other applications would provide such a >> performance benefit by switching to copy_sub_buffer() >> if it's *not* present. > Yes, good point, that occurred to me as well in the meantime. > >> Also (although I'm not sure dri3 server-side implements this), but I guess >> even vmware could to true "page-flipping" in the sense of saving a copy, if >> rendering to a redirected window. > The xserver Present code currently only supports flipping for > unredirected fullscreen windows, everything else uses blits. > > >>>>>> 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). >>> Oh, I see present_fake_screen_init sets the interval to 1/60 s if the >>> driver doesn't provide a get_crtc hook. >>> >>> Then I'm unsure again what the problem is, though — the presentation >>> timing should be basically the same as on real hardware? >>> >>> >> Yes for this extension, I haven't really examined in detail exactly why >> we get increased latency with gnome-shell. > BTW, maybe you could achieve the same effect by setting vblank_mode to 0 > instead of disabling GLX_OML_sync_control? > > Perhaps. Although then I'd need to duplicate that option from "dri2" to the gallium driver option cache to be able to set it on a per-driver per-application basis. With the proposed code, if there is a duplicate, we prefer the driver instance over the "dri2" instance, and that might cause some confusion for people that are used to set this option for the "dri2" driver: driconf would create a default value for the driver in .drirc which would override the value for "dri2". I'm not sure we should consider that a problem though. It would be good to have also the vblank_mode option visible to driconf.
/Thomas _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev