Continues from: https://bugzilla.xfce.org/show_bug.cgi?id=11857#c1 Xfwm4 compositor - performance & functionality ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Baremetal GPU: - NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) - xf86-video-nouveau 1.0.11 Virtual GPU: - Red Hat, Inc. QXL paravirtual graphic card (rev 04) - xf86-video-qxl 0.1.2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - "Report epoxy support" Build Configuration for xfwm4 version 4.12.2git.20150328 revision 74633dd: Startup notification support: yes XSync support: yes Render support: yes Xrandr support: yes Embedded compositor: yes Epoxy support: yes KDE systray protocol proxy: no - Baremetal: performance OK & "tear-free" OK - Virtual: performance OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - "compositor: Add support for GLX" - w/ --disable-xpresent Build Configuration for xfwm4 version 4.12.2git.20150424 revision fee08ea: Startup notification support: yes XSync support: yes Render support: yes Xrandr support: yes Xpresent support: no <-- Embedded compositor: yes Epoxy support: yes KDE systray protocol proxy: no - Baremetal: performance OK & "tear-free" OK - Virtual: performance SLOW (MI factor 2)* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - "compositor/glx: Use actual texture type" Build Configuration for xfwm4 version 4.12.2git.20150424 revision 14c204d: Startup notification support: yes XSync support: yes Render support: yes Xrandr support: yes Xpresent support: yes <-- Embedded compositor: yes Epoxy support: yes KDE systray protocol proxy: no - Baremetal: performance OK & NO "tear-free" - Virtual: performance OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - "compositor/glx: Use actual texture type" - w/ --disable-xpresent Build Configuration for xfwm4 version 4.12.2git.20150424 revision 14c204d: Startup notification support: yes XSync support: yes Render support: yes Xrandr support: yes Xpresent support: no <-- Embedded compositor: yes Epoxy support: yes KDE systray protocol proxy: no - Baremetal: performance OK & "tear-free" OK - Virtual: performance SLOW (MI factor 3)* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Conclusion: It seem as when the Xpresent is present, performance on both Baremetal and Virtual is solid, but "tear-free" functionality is lost on Baremetal. On the other side as when the Xpresent is not present, performance on Baremetal is solid, but performance on Virtual is not so solid. However "tear-free" functionality is achieved on Baremetal. * "MI factor" i.e. Menu Item delay factor, is the amount of delay in selecting menu items of the "Applications Menu".
Created attachment 6223 glxinfo - QXL glxinfo output is the same in all four combinations.
> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) llvmpipe is blacklisted, means that OpenGL support is automatically disabled, so basically it should be the same as before (same code path).
Can you (re)try with current git master?
- "compositor: Fix clipping w/out OpenGL" Build Configuration for xfwm4 version 4.12.2git.20150427 revision 5eb0769: Startup notification support: yes XSync support: yes Render support: yes Xrandr support: yes Xpresent support: yes Embedded compositor: yes Epoxy support: yes KDE systray protocol proxy: no - Baremetal: performance OK & "tear-free" OK - Virtual: performance OK BTW "Synchronize drawing to the vertical blank" i.e. sync_to_vblank, looks like active during compositing, i.e. does not have to be explicitly enabled - set to TRUE.
(In reply to poma from comment #4) > - Baremetal: performance OK & "tear-free" OK > - Virtual: performance OK OK, great, closing then. > BTW "Synchronize drawing to the vertical blank" i.e. sync_to_vblank, > looks like active during compositing, > i.e. does not have to be explicitly enabled - set to TRUE. "Sync to VBlank now does an additional explicit wait-for-vblank but you are right, it /should/ not be needed because glXSwapBuffer() [1] is supposed to wait for vblank before actually doing the buffer flipping. Let's say it's left as a belt and braces approach. But for any decent driver it's not needed. [1] https://www.opengl.org/sdk/docs/man2/xhtml/glXSwapBuffers.xml
- DRI2: /var/log/Xorg.0.log: [ 3210.736] (II) Loading sub module "dri2" [ 3210.736] (II) LoadModule: "dri2" [ 3210.736] (II) Module "dri2" already built-in [ 3210.736] (==) NOUVEAU(0): Allowed maximum DRI level 2. [ 3210.877] (II) NOUVEAU(0): [DRI2] Setup complete [ 3210.894] (II) GLX: Initialized DRI2 GL provider for screen 0 $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI2 for screen 0 6231 frames in 5.0 seconds = 1246.081 FPS 6387 frames in 5.0 seconds = 1277.312 FPS 6421 frames in 5.0 seconds = 1284.023 FPS 6375 frames in 5.0 seconds = 1274.905 FPS 6399 frames in 5.0 seconds = 1279.609 FPS 6440 frames in 5.0 seconds = 1287.837 FPS 6371 frames in 5.0 seconds = 1274.142 FPS 6397 frames in 5.0 seconds = 1279.245 FPS 6429 frames in 5.0 seconds = 1285.668 FPS 6371 frames in 5.0 seconds = 1274.177 FPS ^C ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - DRI3: /etc/X11/xorg.conf.d/nouveau-dri3.conf: Section "Device" Identifier "Videocard0" Driver "nouveau" Option "DRI" "3" EndSection /var/log/Xorg.0.log: [ 3750.992] (II) Loading sub module "dri2" [ 3750.992] (II) LoadModule: "dri2" [ 3750.992] (II) Module "dri2" already built-in [ 3750.992] (**) NOUVEAU(0): Option "DRI" "3" [ 3750.992] (**) NOUVEAU(0): Allowed maximum DRI level 3. [ 3751.128] (II) NOUVEAU(0): [DRI2] Setup complete [ 3751.128] (II) NOUVEAU(0): DRI3 on EXA enabled [ 3751.145] (II) GLX: Initialized DRI2 GL provider for screen 0 $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: pci id for fd 4: 10de:06e4, driver nouveau libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI3 for screen 0 7261 frames in 5.0 seconds = 1452.136 FPS 7353 frames in 5.0 seconds = 1470.404 FPS 7354 frames in 5.0 seconds = 1470.652 FPS 7385 frames in 5.0 seconds = 1476.916 FPS 7337 frames in 5.0 seconds = 1467.380 FPS 7344 frames in 5.0 seconds = 1468.661 FPS 7360 frames in 5.0 seconds = 1471.951 FPS 7327 frames in 5.0 seconds = 1465.211 FPS 7345 frames in 5.0 seconds = 1468.992 FPS 7371 frames in 5.0 seconds = 1474.112 FPS ^C ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ xfwm4 --version This is xfwm4 version 4.12.3git.20150825 (revision 20150825) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.28, using GTK+-2.24.28. Build configuration and supported features: ... - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: No ... $ xfconf-query --channel xfwm4 --property /general/use_compositing true SW: xorg-x11-drv-nouveau-1.0.12-0.3.fc22.x86_64 xorg-x11-server-Xorg-1.17.3-1.fc22.x86_64 mesa-dri-drivers-10.6.9-1.20151008.fc22.x86_64 libdrm-2.4.61-3.fc22.x86_64 libXpresent-1.0.0-1.fc22.x86_64 xfwm4-4.12.3-15.1.xpresent.nv34.git20150825.fc22.x86_64 Conclusion: w/ DRI3/XPresent & xorg-x11-drv-nouveau (xf86-video-nouveau) v1.0.12 i.e. current git - Baremetal: performance OK(EXTRA) & "tear-free" OK
(In reply to poma from comment #0) > It seem as when the Xpresent is present, performance on both Baremetal and > Virtual is solid, > but "tear-free" functionality is lost on Baremetal. Which is normal, not all drives actually implement present, but since it's an xserver extenstion, it;s always advertised, i.e. xfwm4 has no way to tell if Xpresent is working or not. No bug here. > On the other side as when the Xpresent is not present, performance on > Baremetal is solid, > but performance on Virtual is not so solid. > However "tear-free" functionality is achieved on Baremetal. You mean when using GL instead of Present for tearing? Again, perfectly normal. > * "MI factor" i.e. Menu Item delay factor, is the amount of delay in > selecting menu items of the "Applications Menu". How is that relevant for the window manager? (In reply to poma from comment #6) > Conclusion: > w/ DRI3/XPresent & xorg-x11-drv-nouveau (xf86-video-nouveau) v1.0.12 i.e. > current git > - Baremetal: performance OK(EXTRA) & "tear-free" OK OK, so what is this bug about then? (sorry but if I need to spend any time trying to figure out what you may be trying to say in your bug reports, chances are that I will just ignore those completely).
These are -new- results - with the Xorg nouveau "v1.0.12" and DRI3/XPresent, which are ultimately better than with GLX/Epoxy This is now spinning on all machines with the NVIDIA GPUs. configure --disable-epoxy --enable-xpresent Build Configuration for xfwm4 Xpresent support: yes Epoxy support: no Thanks for "compositor: Add support for DRI3/Present".
Taking into account the results of the latest tests[1], I would reconsider to revert: compositor: Prefer GL over Present http://git.xfce.org/xfce/xfwm4/commit/?id=aee242c in favour of Present. Regardless, testing of -other- users, also those who use GPUs driven by amdgpu.ko(AMD GPU) and i915.ko(Intel Graphics), are more than welcome. This is important for the Xfce Desktop experience, therefore, the call for testing - would it be useful to advertise on the mailing list? [1] NV34 example = GLX = $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI2 for screen 0 380 frames in 5.0 seconds = 75.645 FPS 348 frames in 5.0 seconds = 69.465 FPS 337 frames in 5.0 seconds = 67.042 FPS 346 frames in 5.0 seconds = 68.837 FPS 334 frames in 5.0 seconds = 66.673 FPS 345 frames in 5.0 seconds = 68.960 FPS 345 frames in 5.0 seconds = 68.742 FPS 343 frames in 5.0 seconds = 67.973 FPS 371 frames in 5.0 seconds = 73.711 FPS 335 frames in 5.0 seconds = 66.832 FPS 349 frames in 5.0 seconds = 69.403 FPS ^C $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: pci id for fd 4: 10de:0322, driver nouveau libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI3 for screen 0 372 frames in 5.0 seconds = 74.122 FPS 356 frames in 5.0 seconds = 71.076 FPS 357 frames in 5.0 seconds = 71.145 FPS 352 frames in 5.0 seconds = 70.283 FPS 377 frames in 5.0 seconds = 74.997 FPS 365 frames in 5.0 seconds = 72.896 FPS 366 frames in 5.0 seconds = 73.025 FPS 374 frames in 5.0 seconds = 74.636 FPS 366 frames in 5.0 seconds = 72.620 FPS 341 frames in 5.0 seconds = 67.844 FPS 357 frames in 5.0 seconds = 70.990 FPS ^C ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = XPresent = $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI2 for screen 0 838 frames in 5.0 seconds = 167.420 FPS 911 frames in 5.0 seconds = 182.075 FPS 983 frames in 5.0 seconds = 196.494 FPS 1050 frames in 5.0 seconds = 209.690 FPS 966 frames in 5.0 seconds = 192.816 FPS 1061 frames in 5.0 seconds = 212.112 FPS 998 frames in 5.0 seconds = 198.989 FPS 862 frames in 5.0 seconds = 171.803 FPS 930 frames in 5.0 seconds = 185.852 FPS 1077 frames in 5.0 seconds = 215.056 FPS 951 frames in 5.0 seconds = 189.851 FPS ^C $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: pci id for fd 4: 10de:0322, driver nouveau libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI3 for screen 0 1210 frames in 5.0 seconds = 241.708 FPS 1143 frames in 5.0 seconds = 228.153 FPS 1059 frames in 5.0 seconds = 211.388 FPS 1061 frames in 5.0 seconds = 211.786 FPS 1013 frames in 5.0 seconds = 202.202 FPS 1057 frames in 5.0 seconds = 210.987 FPS 1155 frames in 5.0 seconds = 230.886 FPS 1057 frames in 5.0 seconds = 211.384 FPS 1120 frames in 5.0 seconds = 223.944 FPS 1113 frames in 5.0 seconds = 222.433 FPS 1171 frames in 5.0 seconds = 233.935 FPS ^C
(In reply to poma from comment #9) > Taking into account the results of the latest tests[1], > I would reconsider to revert: > > compositor: Prefer GL over Present > http://git.xfce.org/xfce/xfwm4/commit/?id=aee242c > > in favour of Present. No, as stated before, there is no way (that I know of) for the client to tell whether the present extension is functional or not, so glx should be preferred if both glx and present are available. If you still prefer present over glx, I have added in git master support for the environment variable XFWM4_USE_PRESENT for this. e,g,: $ XFWM4_USE_PRESENT=1 xfwm4 --replace & Will select present even if glx is available.
Created attachment 6541 compositor: make XPresent VSync default Compared with GLX, XPresent is more performant, proven in testing with: nouveau, radeon and intel - can be tested with: $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears using the following configuration: /etc/X11/xorg.conf.d/nouveau-dri3.conf Section "Device" Identifier "nvidia0" Driver "nouveau" Option "DRI" "3" EndSection Xorg.0.log: NOUVEAU(0): DRI3 on EXA enabled ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /etc/X11/xorg.conf.d/radeon-dri3.conf Section "Device" Identifier "amd0" Driver "radeon" Option "DRI3" "on" EndSection Xorg.0.log: RADEON(0): DRI3 enabled ~~~~~~~~~~~~~~~~~~~~~~~ /etc/X11/xorg.conf.d/intel-dri3.conf Section "Device" Identifier "intel0" Driver "intel" Option "DRI" "3" EndSection Xorg.0.log: intel(0): direct rendering: DRI2 DRI3 enabled ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In some cases, the user may prefer GLX over XPresent VSync, if both are present - can be checked with: $ xfwm4 --version An environment variable XFWM4_USE_PRESENT is for this purpose: $ XFWM4_USE_PRESENT=0 xfwm4 --replace & this will select GLX VSync even if XPresent is available.
$ xfwm4 --version This is xfwm4 version 4.12.3git.a64b743.20151126 (revision a64b743.20151126) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.28, using GTK+-2.24.28. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No = XPresent VSync = $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: pci id for fd 4: 10de:06e4, driver nouveau libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI3 for screen 0 7277 frames in 5.0 seconds = 1455.379 FPS 7363 frames in 5.0 seconds = 1472.523 FPS 7358 frames in 5.0 seconds = 1471.491 FPS 7372 frames in 5.0 seconds = 1474.345 FPS 7362 frames in 5.0 seconds = 1472.144 FPS ^C ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ XFWM4_USE_PRESENT=0 xfwm4 --replace & [1] 11434 $ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done = GLX VSync = $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: pci id for fd 4: 10de:06e4, driver nouveau libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so ATTENTION: default value of option vblank_mode overridden by environment. libGL: Using DRI3 for screen 0 5742 frames in 5.0 seconds = 1148.349 FPS 5804 frames in 5.0 seconds = 1160.696 FPS 5794 frames in 5.0 seconds = 1158.788 FPS 5793 frames in 5.0 seconds = 1158.443 FPS 5805 frames in 5.0 seconds = 1160.839 FPS ^C
Honestly, I am not making any sense of what you are trying to say here, so closing as fixed, if you fancy present, set the variable.
It is not about "fancy present", but XPresent has obvious advantages over GLX, with the Open Source GPU drivers, of course. Besides, how to automate applicability of an environment variable XFWM4_USE_PRESENT? Because each time to manually run it with each new xfce4-session, is really a bit ridiculous. Can you help with the answer?
(In reply to poma from comment #14) > It is not about "fancy present", but XPresent has obvious advantages over > GLX, with the Open Source GPU drivers, of course. > > Besides, how to automate applicability of an environment variable > XFWM4_USE_PRESENT? > Because each time to manually run it with each new xfce4-session, is really > a bit ridiculous. > > Can you help with the answer? Add an entry in /etc/profile.d/ ?
envvar XFWM4_USE_PRESENT as it is, cannot be used as a permanent solution - over-boots/sessions. I've tried everywhere and it just ain't working. That's why I created a patch. I can try with your example - if you have one, but I doubt it will work.
(In reply to poma from comment #16) > envvar XFWM4_USE_PRESENT as it is, cannot be used as a permanent solution - > over-boots/sessions. > I've tried everywhere and it just ain't working. > That's why I created a patch. > > I can try with your example - if you have one, but I doubt it will work. You can use /etc/profile.d/qt.sh as an example, it it works with qt I don't see why it wouldn't work with xfwm4. I agree an environment variable is sub-optimal, but it's still better than a command line option because users usually do not start their window manager themselves. I will not make present the default for the reasons I explained multiple times already. When it works it's still unstable and I've seen it lock up sessions after blanking or resume, and it's not available on all drivers (including proprietary drivers).
(In reply to Olivier Fourdan from comment #17) > (In reply to poma from comment #16) > > envvar XFWM4_USE_PRESENT as it is, cannot be used as a permanent solution - > > over-boots/sessions. > > I've tried everywhere and it just ain't working. > > That's why I created a patch. > > > > I can try with your example - if you have one, but I doubt it will work. > > You can use /etc/profile.d/qt.sh as an example, it it works with qt I don't > see why it wouldn't work with xfwm4. I agree an environment variable is > sub-optimal, but it's still better than a command line option because users > usually do not start their window manager themselves. > Vis-à-vis envvars and cmdline switches, there is the Xfconf - configuration system. And there is already available property, which can be reused just for this case. See #c5 - sync_to_vblank. > I will not make present the default for the reasons I explained multiple > times already. When it works it's still unstable and I've seen it lock up > sessions after blanking or resume, and it's not available on all drivers > (including proprietary drivers). Care to share links to related bugzilla reports?
(In reply to poma from comment #16) > envvar XFWM4_USE_PRESENT as it is, cannot be used as a permanent solution - > over-boots/sessions. > I've tried everywhere and it just ain't working. ... Pardon me, ENVVARS actually works -but- their usage is -inconsistent- across the distributions - user specific configuration, in contrast to Xfconf - configuration system.
(In reply to poma from comment #19) > ENVVARS actually works -but- their usage is -inconsistent- across the > distributions - user specific configuration, Environment variables are as old as shells, they work anywhere, it's how/where you set the envvar that might differ between distributions. But that's off topic. > in contrast to Xfconf - configuration system. xfconf is not an option, xfwm4 doesn't support switching backends on the fly.
(In reply to Olivier Fourdan from comment #20) > (In reply to poma from comment #19) > > ENVVARS actually works -but- their usage is -inconsistent- across the > > distributions - user specific configuration, > > Environment variables are as old as shells, they work anywhere, it's > how/where you set the envvar that might differ between distributions. But > that's off topic. > We're writing here about the Xfwm4, thus the Xfce4, not about "anywhere". :) Besides, consistency of "how/where" -is- very ON-topic, and not only here. > > in contrast to Xfconf - configuration system. > > xfconf is not an option, xfwm4 doesn't support switching backends on the fly. "Does not support" is not the same as "cannot support".
You have to specify a comment when changing the Resolution of a bug from (empty) to WONTFIX.