GNOME Bugzilla – Bug 738271
Gnome Shell not unredirecting fullscreen games in multi-monitor environments
Last modified: 2014-12-16 04:06:28 UTC
I think Mutter isn't unredirecting my games when I have a secondary monitor enabled, causing performance degradation and additional input latency. I've tested with CS:GO and here's what I noticed. With secondary monitor enabled: * There is a noticeable input lag when moving the mouse cursor in the menus and when trying to aim. * Even with vsync disabled, I get no tearing, which leads me to believe that compositing is still on and forcing vsync. * OSD elements like volume control don't cause the screen to flicker as it toggles compositing on and off, which is an indication that compositing is always on. With secondary monitor disabled: *Mouse cursor moves responsively both in menus and in-game. With vsync on, there's a slight degradation in input latency but nothing too bad to handle. *With vsync disabled in game, I get tearing, which means that Mutter isn't forcing vsync. *OSD elements like volume controls cause compositing to be toggled on/off while they're being displayed, which causes a slight flicker. Expected behavior: 1.) Mutter should always unredirect fullscreen apps regardless of how many monitors there are. For example, Unity is perfectly capable of unredirecting fullscreen games even with two or more monitors, and as a result gaming performance is top notch. Actual behavior: 1.) Mutter does not unredirect fullscreen applications when there are two monitors or more enabled. This causes games to run slower than they should. 2.) Fullscreen applications run fine when only one monitor is enabled. The game is properly unredirected.
(In reply to comment #0) > I think Mutter isn't unredirecting my games when I have a secondary monitor > enabled It is supposed to do that already and I just confirmed it by adding a print statement in the unredirection code path. > * OSD elements like volume control don't cause the screen to flicker as it > toggles compositing on and off, which is an indication that compositing is > always on. That shouldn't flicker (that's a different bug though). > 1.) Mutter should always unredirect fullscreen apps regardless of how many > monitors there are. For example, Unity is perfectly capable of unredirecting > fullscreen games even with two or more monitors, and as a result gaming > performance is top notch. That's what's supposed to happen and what happens here. (Tested with 3.14 though). > > Actual behavior: > 1.) Mutter does not unredirect fullscreen applications when there are two > monitors or more enabled. This causes games to run slower than they should. > 2.) Fullscreen applications run fine when only one monitor is enabled. The game > is properly unredirected. So we need to find out why it doesn't work for you: 1) Can you try 3.14? or 2) Can you try adding print statements in meta_window_actor_should_unredirect to check why it doesn't get unredirected? I suspect that meta_window_is_monitor_sized for some reason fails for you. What kind of monitor setup do you have?
I just got 3.14 from Debian testing and I tried it out. It exhibits the same results. Vsync seems to be forced on and there's a tangible input latency compared to single monitor use. I also tested Borderlands 2 and it seems to exhibit less latency, but it also runs smoother than CS:GO so it makes it hard to tell. Vsync also looks forced on for Borderlands 2 though. My monitor setup is a pretty standard TwinView setup: DFP-1: Secondary monitor 1440x900 +0+163 DFP-4: Primary monitor 1920x1080 +1440+0 I have these variables set in my .profile to tell my Nvidia card which screen to sync to when vsync is enabled: export __GL_SYNC_DISPLAY_DEVICE=DFP-4 export __VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-4 I am afraid I don't have enough technical know how about compiling Gnome on Debian to add the print statements. Is there another way for me to check?
Ah I found steps to reproduce! Okay so there seems to be a bug where if the monitor you're gaming on/fullscreening on is NOT the left most monitor, meaning NOT at screen offset +0+0, then unredirect fails to trigger. If the monitor is at +0+0, unredirect correctly triggers. I just tested this with CS:GO with vsync off in game settings on Gnome 3.14: Primary monitor on +0+0 (set as my left monitor): * I see scanlines (vsync is not being forced on) * Input latency is very good, overall performance is great. When primary monitor is at +1440+0 (set to the right of my 1440x900 monitor): * No scanlines even when in-game vsync settings are off * Input latency goes down the drain. So perhaps meta_window_is_monitor_sized is failing the +1440+0 case?
Sorry, I meant the monitor that you're fullscreening on HAS to be at +0+0 in order for unredirect to trigger. Anything else besides that will fail to trigger unredirect. So even for monitors that are on the left, if it has an offset of lets say +0+88, then it will fail to unredirect, causing bad performance.
Does gsettings set org.gnome.shell.overrides workspaces-only-on-primary false make it work? (You can set it back using gsettings set org.gnome.shell.overrides workspaces-only-on-primary true) after the test.
No, I already had it set to false before. I tested with both. Doesn't seem to make a difference.
(In reply to comment #2) > I just got 3.14 from Debian testing and I tried it out. It exhibits the same > results. Vsync seems to be forced on and there's a tangible input latency > compared to single monitor use. I also tested Borderlands 2 and it seems to > exhibit less latency, but it also runs smoother than CS:GO so it makes it hard > to tell. Vsync also looks forced on for Borderlands 2 though. > > My monitor setup is a pretty standard TwinView setup: > DFP-1: Secondary monitor 1440x900 +0+163 > DFP-4: Primary monitor 1920x1080 +1440+0 > > I have these variables set in my .profile to tell my Nvidia card which screen > to sync to when vsync is enabled: > > export __GL_SYNC_DISPLAY_DEVICE=DFP-4 > export __VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-4 I cannot reproduce it with the game on non primary monitor either. But you are telling the nvidia driver to use a specific display to vsync on ... and quoting from the nvidia readme: "Setting __GL_SYNC_TO_VBLANK=1 forces glXSwapBuffers to synchronize with the vertical blanking period. This is the default behavior." ... So apparently it forces vblank on on that monitor. Can you try running your game with "__GL_SYNC_TO_VBLANK=0 game" ?
No, it does not force vblank. __GL_SYNC_DISPLAY_DEVICE=DFP-4 is different from __GL_SYNC_TO_VBLANK=1 The first one only says, if vsync is enabled, sync to the monitor labeled DFP-4. The second variable IS the one that forces vsync. I do not have the second one enabled anywhere. Vsync is only on when I enable it in the game settings. Can you tell me your monitor id's, their resolution, and their offsets in the Nvidia settings? Also list which one is set to primary. I am able to reproduce consistently on monitors with an offset other than +0+0.
(In reply to comment #8) > No, it does not force vblank. > > __GL_SYNC_DISPLAY_DEVICE=DFP-4 is different from __GL_SYNC_TO_VBLANK=1 > > > The first one only says, if vsync is enabled, sync to the monitor labeled > DFP-4. The second variable IS the one that forces vsync. I do not have the > second one enabled anywhere. The second one is *enabled by default* according to the docs see: ftp://download.nvidia.com/XFree86/Linux-x86/343.22/README/openglenvvariables.html > Can you tell me your monitor id's, their resolution, and their offsets in the > Nvidia settings? Also list which one is set to primary. I am able to reproduce > consistently on monitors with an offset other than +0+0. xrandr -q Screen 0: minimum 8 x 8, current 3600 x 1080, maximum 8192 x 8192 DVI-I-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 disconnected (normal left inverted right x axis y axis) TV-0 disconnected (normal left inverted right x axis y axis) DVI-I-2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.88*+ 59.95 1440x900 59.89 1280x1024 75.02 60.02 1280x960 60.00 1152x864 75.00 1024x768 75.03 60.00 800x600 75.00 60.32 56.25 640x480 75.00 59.94 DVI-I-3 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 475mm x 267mm 1920x1080 60.00*+ 1280x1024 75.02 60.02 1152x864 75.00 1024x768 75.03 60.00 800x600 75.00 60.32 640x480 75.00 59.94
> The second one is *enabled by default* according to the docs see: ftp://download.nvidia.com/XFree86/Linux-x86/343.22/README/openglenvvariables.html I just retested it with __GL_SYNC_TO_VBLANK=0. I am still able to reproduce. I have a feeling that applications don't obey __GL_SYNC_TO_VBLANK because, if this really were the case, that would mean that even at offset +0+0, it would vsync, but it does not. For example: When I have +0+0 primary monitor with: * __GL_SYNC_TO_VBLANK=1 * __GL_SYNC_DISPLAY_DEVICE set to the correct monitor * in-game vsync set to OFF I still get screen tearing. When I have primary with +0+88 or anything that's not +0+0 with: * __GL_SYNC_TO_VBLANK=1 * __GL_SYNC_DISPLAY_DEVICE set to the correct monitor * in-game vsync set to OFF I get no screen tearing and a drop in game performance/input latency. Now the ONLY DIFFERENCE is the monitor offset. I am able to reproduce this regardless of which monitor I have set as primary. Now just to double check everything, I did one more test and recorded all my data. Here is my test where I am able to reproduce failure to unredirect the game (vsync is forced on by compositor, bad performance): ======================= Environment ======================= * __GL_SYNC_TO_VBLANK=0 * __GL_SYNC_DISPLAY_DEVICE is unset * in-game vsync set to OFF xrandr -q returns: Screen 0: minimum 8 x 8, current 3360 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 connected primary 1440x900+0+163 (normal left inverted right x axis y axis) 408mm x 255mm 1440x900 59.89*+ 74.98 1280x1024 75.02 60.02 1280x960 60.00 1152x864 75.00 1024x768 75.03 70.07 66.00 60.00 800x600 75.00 72.19 60.32 56.25 640x480 75.00 72.81 65.99 59.94 HDMI-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) DP-1 connected 1920x1080+1440+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+ 59.94 50.00 60.00 50.04 1680x1050 59.95 1440x900 74.98 59.89 1280x1024 75.02 60.02 1280x960 60.00 1280x720 60.00 59.94 50.00 1152x864 75.00 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 56.25 720x576 50.00 720x480 59.94 640x480 75.00 72.81 59.94 59.93 480x576 50.00 480x480 59.94 Now here is the test where unredirect works properly (vsync is not forced by compositor, good performance, lots of screen tearing): ======================= Environment ======================= * __GL_SYNC_TO_VBLANK=0 * __GL_SYNC_DISPLAY_DEVICE is unset * in-game vsync set to OFF xrandr -q returns: Screen 0: minimum 8 x 8, current 3360 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 408mm x 255mm 1440x900 59.89*+ 74.98 1280x1024 75.02 60.02 1280x960 60.00 1152x864 75.00 1024x768 75.03 70.07 66.00 60.00 800x600 75.00 72.19 60.32 56.25 640x480 75.00 72.81 65.99 59.94 HDMI-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) DP-1 connected 1920x1080+1440+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+ 59.94 50.00 60.00 50.04 1680x1050 59.95 1440x900 74.98 59.89 1280x1024 75.02 60.02 1280x960 60.00 1280x720 60.00 59.94 50.00 1152x864 75.00 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 56.25 720x576 50.00 720x480 59.94 640x480 75.00 72.81 59.94 59.93 480x576 50.00 480x480 59.94
Now if you're still unable to reproduce from my testcases, I may be able to build a debian package with debug statements if you tell me where to add them. Am I correct in assuming that I only have to rebuild libmutter0e? Also where will the debug statements be printed?
(In reply to comment #11) > Now if you're still unable to reproduce from my testcases, No I cannot unfortunately. > I may be able to > build a debian package with debug statements if you tell me where to add them. > > Am I correct in assuming that I only have to rebuild libmutter0e? Yes please applying the attached patch. >Also where will the debug statements be printed? In standard out / journal ... best way to test is to open a terminal and doing gnome-shell --replace or simply check journalctl.
Created attachment 288272 [details] [review] Unredirect debug [DO NOT REVIEW]
Also do you have any other windows open while playing the game? We only unredirect the *topmost* window.
> Also do you have any other windows open while playing the game? We only unredirect the *topmost* window. Yes I have other windows open, but the fullscreen game should be the topmost since it has focus.
Are you willing to modify the code to help us better debug?
> Are you willing to modify the code to help us better debug? Of course! Okay, I patched it. It was much easier than I thought! Love debian packages. Also thanks for the patch! Really appreciate you taking the time to debug this. So I ran gnome-shell --replace in the shell and I got a whole bunch of: Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 > At this point I quit the game and Steam became active window. Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Seems like its not unredirecting? I can apply more patches for debugging.
Whoops I forgot to add debug logs for the working use case when primary monitor is at +0+0: Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 > At this point I quit the game REDIRECTED : Counter-Strike: Global Offensive - OpenGL Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0
Can you try this one? diff --git a/src/compositor/meta-surface-actor-x11.c b/src/compositor/meta-surface-actor-x11.c index 8af5ca2..0cc8cba 100644 --- a/src/compositor/meta-surface-actor-x11.c +++ b/src/compositor/meta-surface-actor-x11.c @@ -258,8 +258,12 @@ meta_surface_actor_x11_should_unredirect (MetaSurfaceActor *actor) if (meta_surface_actor_is_argb32 (actor) && !meta_window_requested_bypass_compositor (window)) return FALSE; + g_print ("Checking for %s monitor size, is O-R %d\n", window->desc, window->override_redirect); if (!meta_window_is_monitor_sized (window)) - return FALSE; + { + g_print ("%s is not monitor sized\n", window->desc); + return FALSE; + } if (meta_window_requested_bypass_compositor (window)) return TRUE;
Here are the logs for the none working case when primary monitor is at +1440+0: Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 0x2a0000b (Counter-St) is not monitor sized > Game quit here Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking should_unredirect for Steam, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Checking for 0x100001b (Steam) monitor size, is O-R 0 0x100001b (Steam) is not monitor sized Here are the logs when primary is at +0+0 (working case): Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 REDIRECTED : Counter-Strike: Global Offensive - OpenGL Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking for 0x2802087 (benxiao@be) monitor size, is O-R 0 0x2802087 (benxiao@be) is not monitor sized Checking should_unredirect for benxiao@benxiao-debian01: ~/Documents/mutter, disable_unredirect_count = 0, should_unredirect = 0
I have a feeling that the problem lies in this function: gboolean meta_window_is_screen_sized (MetaWindow *window) { MetaRectangle window_rect; int screen_width, screen_height; meta_screen_get_size (window->screen, &screen_width, &screen_height); meta_window_get_frame_rect (window, &window_rect); if (window_rect.x == 0 && window_rect.y == 0 && window_rect.width == screen_width && window_rect.height == screen_height) return TRUE; return FALSE; } window_rect.x and window_rect.y are probably not 0 when primary monitor is set to offset +1440+0
(In reply to comment #21) > I have a feeling that the problem lies in this function: > > gboolean > meta_window_is_screen_sized (MetaWindow *window) > { > MetaRectangle window_rect; > int screen_width, screen_height; > > meta_screen_get_size (window->screen, &screen_width, &screen_height); > meta_window_get_frame_rect (window, &window_rect); > > if (window_rect.x == 0 && window_rect.y == 0 && > window_rect.width == screen_width && window_rect.height == screen_height) > return TRUE; > > return FALSE; > } > > window_rect.x and window_rect.y are probably not 0 when primary monitor is set > to offset +1440+0 No this check is correct it checks whether the window is screen sized (i.e as big as the whole x screen which may consists of multiple monitors). The odd part here is ... why isn't the window fullscreen? Can you try: diff --git a/src/core/window.c b/src/core/window.c index 404d05a..6b38ab5 100644 --- a/src/core/window.c +++ b/src/core/window.c @@ -2787,6 +2787,8 @@ meta_window_is_screen_sized (MetaWindow *window) gboolean meta_window_is_monitor_sized (MetaWindow *window) { + g_print("window: %s fullscreen=%d\n", window->desc, window->fullscreen); + if (window->fullscreen) return TRUE; ?
Btw. have you set the window to be actually fullscreen? Or did you select "borderless window" ?
Actually fullscreen. I never use borderless window for performance reasons.
> The odd part here is ... why isn't the window fullscreen? Can you try: I think it is fullscreen. Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1 Checking should_unredirect for Counter-Strike: Global Offensive - OpenGL, disable_unredirect_count = 0, should_unredirect = 0 Checking for 0x2a0000b (Counter-St) monitor size, is O-R 0 window: 0x2a0000b (Counter-St) fullscreen=1
Strange I noticed that it doesn't show the "0x2a0000b (Counter-St) is not monitor sized" message anymore, even though its still in the code. But either way, fullscreen is on, but it still doesn't unredirect.
if (!meta_window_is_monitor_sized (window)) { g_print ("%s is not monitor sized\n", window->desc); return FALSE; } if (meta_window_requested_bypass_compositor (window)) return TRUE; if (meta_window_is_override_redirect (window)) return TRUE; if (priv->does_full_damage) return TRUE; return FALSE; So that basically means, none of the if conditions after it are true? Maybe SDL is not requesting bypass?
Try this: diff --git a/src/compositor/meta-surface-actor-x11.c b/src/compositor/meta-surface-actor-x11.c index d7cd949..206a9c4 100644 --- a/src/compositor/meta-surface-actor-x11.c +++ b/src/compositor/meta-surface-actor-x11.c @@ -246,29 +246,57 @@ meta_surface_actor_x11_should_unredirect (MetaSurfaceActor *actor) MetaWindow *window = priv->window; + g_print("Called should_unredirect for %s:\n", window->desc); + if (meta_window_requested_dont_bypass_compositor (window)) - return FALSE; + { + g_print("window requested not to be unredirected -> NOT unredirecting\n"); + return FALSE; + } if (window->opacity != 0xFF) - return FALSE; + { + g_print("window has a opacity value != 0xFF (%x) -> NOT unredirecting \n", window->opacity); + return FALSE; + } if (window->shape_region != NULL) - return FALSE; + { + g_print("window is shaped -> NOT unredirecting\n"); + return FALSE; + } if (meta_surface_actor_is_argb32 (actor) && !meta_window_requested_bypass_compositor (window)) - return FALSE; + { + g_print("window is argb32 -> NOT unredirecting\n"); + return FALSE; + } if (!meta_window_is_monitor_sized (window)) - return FALSE; + { + g_print("window is not monitor sized -> NOT unredirecting\n"); + return FALSE; + } if (meta_window_requested_bypass_compositor (window)) - return TRUE; + { + g_print("window asked for unredirection -> unredirecting it\n"); + return TRUE; + } if (meta_window_is_override_redirect (window)) - return TRUE; + { + g_print("window is OR -> unredirecting it\n"); + return TRUE; + } if (priv->does_full_damage) - return TRUE; + { + g_print("window does full damage -> unredirecting it\n"); + return TRUE; + } + + g_print("No criteria applies -> NOT unredirecting\n"); return FALSE; }
(In reply to comment #27) > if (!meta_window_is_monitor_sized (window)) > { > g_print ("%s is not monitor sized\n", window->desc); > return FALSE; > } > > if (meta_window_requested_bypass_compositor (window)) > return TRUE; > > if (meta_window_is_override_redirect (window)) > return TRUE; > > if (priv->does_full_damage) > return TRUE; > > return FALSE; > > > So that basically means, none of the if conditions after it are true? Maybe SDL > is not requesting bypass? SDL2 does request bypass even if it doesn't it should hit the heuristics and be unredirected after 100 frames.
So I did a fresh checkout with only latest patch from drago01 Logs say: Called should_unredirect for 0x220000b (Counter-St): No criteria applies -> NOT unredirecting
Is the heuristics done by this if statement? if (priv->does_full_damage) return TRUE;
(In reply to comment #31) > Is the heuristics done by this if statement? > > if (priv->does_full_damage) > return TRUE; No that only checks the result. https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-x11.c#n191
Created attachment 288291 [details] [review] meta-surface-actor-x11: Fix unredirect heuristic Damage coordinates are relative to the drawable not to the screen. So we have to check whether x and y are 0 and not window_rect.x/y otherwise the herustic will never trigger for windows on monitors whos x and y are not 0.
OK I think I know what's going on, can you try the above patch? (it should fix it).
Review of attachment 288291 [details] [review]: I swore we fixed this one before, but git blame turns up nothing.
Comment on attachment 288291 [details] [review] meta-surface-actor-x11: Fix unredirect heuristic Attachment 288291 [details] pushed as cd32e4a - meta-surface-actor-x11: Fix unredirect heuristic
Review of attachment 288272 [details] [review]: This was never meant to be pushed.
I applied Attachment 288291 [details] and it works perfectly!!! Thanks guys and keep up the great work! I take it this change will appear in a bug fix release for 3.14?
(In reply to comment #38) > I applied Attachment 288291 [details] and it works perfectly!!! Thanks guys and keep up > the great work! Thanks for the help with debugging this. > I take it this change will appear in a bug fix release for 3.14? Yes it will be in 3.14.1 which is scheduled for Wednesday.
This fix probably caused vsync to break on Haswell graphics after an application is made full-screen on a secondary monitor. This problem only occured after upgrading to Fedora Workstation (21) from Fedora Desktop (20). https://bugzilla.gnome.org/show_bug.cgi?id=741376
(In reply to comment #40) > This fix probably caused vsync to break on Haswell graphics after an > application is made full-screen on a secondary monitor. This problem only > occured after upgrading to Fedora Workstation (21) from Fedora Desktop (20). > > https://bugzilla.gnome.org/show_bug.cgi?id=741376 Vsync was only working because the compositor was forcing it. The real issue here is the application that you're using is failing to properly vsync.
> Yes it will be in 3.14.1 which is scheduled for Wednesday. The problem only started happening after an upgrade from 3.10 to 3.14. It also happens with any standard app that's put full-screen regardless of the Xorg backend used. It also resolves itself occasionally when GNOME Shell is restarted enough times and then only when the full-screen app is closed completely. Usually it needs a full Xorg reset. On a single monitor system it would make sense to undirect the full-screen app for a game. But when using 1 and/or 2 secondary monitors in a multi-monitor configuration it has the net effect of breaking vsync on the secondary monitors. Xorg treats standard multi-monitor configurations as a single X-screen. So if one part of the X-screen suddenly undirects it would probably cause the others to lose vsync.
That doesn't make sense. Vsync should still happen on a per-monitor basis. This sounds more like an Intel driver bug.
(In reply to comment #42) > So if one part of the X-screen suddenly undirects it would probably > cause the others to lose vsync. No this is not what happens. Unredirecting one monitor doesn't cause the other monitors to lose compositing. What's happening here is that now with this fix, compositing is no longer incorrectly enabled for fullscreen apps. This exposes the underlying vsync issues of the app/video driver, because the compositor is no longer there to hide it. This is correct behavior. The underlying vsync issues should be resolved rather than hiding it. What I think is happening in your case is that the application is set to vsync to the primary monitor. When you fullscreen on the secondary monitor, compositing is disabled and therefore not forcing vsync, and the app tries to vsync to the primary monitor. Obviously this won't work since it's being displayed on the secondary. Does the tearing occur if you fullscreen on the primary monitor? On Nvidia cards, you can set which monitor to vsync to using the __GL_SYNC_DISPLAY_DEVICE variable. Perhaps there's a similar variable for Intel?
> On Nvidia cards, you can set which monitor to vsync to using the > __GL_SYNC_DISPLAY_DEVICE variable. Perhaps there's a similar variable for > Intel? This is a feature unique to the Nvidia closed-source proprietary driver. At home I have a Nvidia GPU and this is how I get VSYNC to work even on desktop environments that use an xrender based software compositing like MATE. This feature is unique to their drivers and is activated by adding the following to your MetaModes in Xorg: "{ ForceCompositionPipeline = On }" It seems after some reading that most modern FOSS graphics drivers such as Intel and Radeon for Linux/X11 assume that the OpenGL compositor is 100% responsible for managing VSYNC and they cannot force it at the driver level the way Nvidia can. This leaves a very large test-matrix being the combination of: 'gpu_vendors' x 'drivers' x 'xorg_versions' x 'third_party_apps' Where things could go wrong and make Mutter a very unreliable compositor when it comes to enforcing proper VSYNC. As a result forcing VSYNC on all windows and screens is the safest thing do to ensure that in 95% of use-cases, where the user is using GNOME as a work environment, they get the right experience.
(In reply to comment #45) > Where things could go wrong and make Mutter a very unreliable compositor when > it comes to enforcing proper VSYNC. As a result forcing VSYNC on all windows > and screens is the safest thing do to ensure that in 95% of use-cases, where > the user is using GNOME as a work environment, they get the right experience. Again, compositor is still enabled for other monitors that do not have fullscreen apps on them. Compositing is only disabled on the monitor that does have a fullscreen app running. At this point, the only thing that's doing vsyncing is the app itself (and how the OpenGL driver handles things), which means that any broken vsync issues lies with the app or GL driver itself, not with Gnome. Forcing the compositor to remain on in fullscreen apps is a HUGE performance drain and drastically decreases gaming performance on medium to low range machines. It is not a good experience. It is a performance regression. There are ways for applications to disable unredirection in Gnome, but it is up to the app to set that hint to the window manager. Perhaps an environment variable can be added to disable unredirection per app? So you can force compositor to stay on with "DISABLE_UNREDIRECT=1 appname"
> Again, compositor is still enabled for other monitors that do not have > fullscreen apps on them. Compositing is only disabled on the monitor that does > have a fullscreen app running. At this point, the only thing that's doing > vsyncing is the app itself (and how the OpenGL driver handles things), which > means that any broken vsync issues lies with the app or GL driver itself, not > with Gnome. Not in my experience, on the other monitors VSYNC itself is broken which means that compositing itself is broken as VSYNC is the main responsibility of an OpenGL compositor on modern graphics drivers. > Perhaps an environment variable can be added to disable unredirection per app? > So you can force compositor to stay on with "DISABLE_UNREDIRECT=1 appname" Forcing VSYNC globally is necessary until Wayland becomes more mature and can fully replace X11. It's the simple solution instead of making things more complex and leaving too much room for error. Having a variable leaves it up to the user, not a good idea or the third party app developers, also not a good idea.
(In reply to comment #47) > Not in my experience, on the other monitors VSYNC itself is broken which means > that compositing itself is broken as VSYNC is the main responsibility of an > OpenGL compositor on modern graphics drivers. > Vsync is NOT the main responsibility of the OpenGL compositor, COMPOSITING is. Right now, I can be running a fullscreen game on my primary monitor and my secondary monitor will have compositing enabled. I can see this because all the things that require compositing (window drop shadows, transparency, etc.) are still there and rendering fine. The compositor is NOT disabled for monitors that do not have fullscreen apps running on them. If vsync is breaking on the secondary monitors that is another issue and not related to the patch in this bug. > Forcing VSYNC globally is necessary until Wayland becomes more mature and can > fully replace X11. It's the simple solution instead of making things more > complex and leaving too much room for error. Having a variable leaves it up to > the user, not a good idea or the third party app developers, also not a good > idea. The patch in this bug was to fix a feature that was ALREADY implemented in Gnome. This is as simple as it gets. The developers had already decided that unredirection should happen for fullscreen apps, regardless of how many monitors there are. This patch was just to fix an issue where the behavior didn't trigger properly in certain monitor layouts (unredirection was happening when primary monitor was on the left, but not happening when it was on the right). You want to get rid of unredirection entirely, which goes against what the developers originally implemented and goes against what every other desktop environment is doing. Ubuntu Unity has unredirect fullscreen apps, and so does KDE. The problems that you're experiencing will happen in those DEs as well, or in any other environment that doesn't have compositing. Instead of actually fixing the root cause of your vsync issues, you're suggesting a fix that's one layer up. You basically want Gnome, KDE, Ubuntu Unity, etc. to all have patches that throw out their unredirection code instead of the simple way which is to fix vsync in virt-viewer. It's good that you suggested Wayland, because your issues will be fixed when Wayland comes around. That makes more sense than intentionally break an already implemented feature (unredirection), which is what reverting this patch or forcing global compositing will do.
There might still be a bug in GNOME, don't discount it. Do you see this behavior in KDE and Unity?
Apologies, I am not discounting anything. I am just saying that forcing compositing/vsync on everything like AGS is suggesting is not the right way to go. There may very well be an issue with vsync that is only triggered by unredirection in multi-monitor environments, but that should be fixed rather than disabling the feature entirely.
Hey AGS, Let's clarify this a little bit. Lets say you have two monitors. Monitor A (primary): Running RDP in a window Monitor B (secondary): Running virt-viewer in fullscreen. In this situation, it is expected that virt-viewer on B will have vsync issues because its running in fullscreen and compositing is disabled in which case applications have to do their own vsync, usually to the primary monitor (correct me if I am wrong). However, are you saying that on Monitor A, the RDP client has vsync issues while in a window? If so, then that's a bug in the compositor. Monitor A should still have compositing and vsync, and Monitor B should have no compositing.
Sorry for the late response but I usually don't pay much attention to closed bugs. On intel we now always do page flips so if you get any tearing in the composited environment is a driver bug. There are DRI3 fixes for both mesa and the xserver floating around that you could try: http://lists.freedesktop.org/archives/mesa-dev/2014-December/thread.html#72074 and those http://lists.x.org/archives/xorg-devel/2014-November/thread.html#44634 (which are likely to cause your issue).
> However, are you saying that on Monitor A, the RDP client has vsync issues > while in a window? If so, then that's a bug in the compositor. Monitor A should > still have compositing and vsync, and Monitor B should have no compositing. This is what's happening and strangely it's only on the two external monitors, the main laptop screen is unaffected: [laptop] normal [screen a] normal [screen b] normal [laptop] normal [screen a] fullscreen app --> tearing, artifacts [screen b] normal --> tearing [laptop] normal [screen a] fullscreen window closed --> tearing stops after a few seconds [screen b] normal --> tearing stops after a few seconds
(In reply to comment #52) > Sorry for the late response but I usually don't pay much attention to closed > bugs. On intel we now always do page flips so if you get any tearing in the > composited environment is a driver bug. > > There are DRI3 fixes for both mesa and the xserver floating around that you > could try: > > http://lists.freedesktop.org/archives/mesa-dev/2014-December/thread.html#72074 > > and those > > http://lists.x.org/archives/xorg-devel/2014-November/thread.html#44634 (which > are likely to cause your issue). How can I test this on Fedora 21?
(In reply to comment #54) > (In reply to comment #52) > > Sorry for the late response but I usually don't pay much attention to closed > > bugs. On intel we now always do page flips so if you get any tearing in the > > composited environment is a driver bug. > > > > There are DRI3 fixes for both mesa and the xserver floating around that you > > could try: > > > > http://lists.freedesktop.org/archives/mesa-dev/2014-December/thread.html#72074 > > > > and those > > > > http://lists.x.org/archives/xorg-devel/2014-November/thread.html#44634 (which > > are likely to cause your issue). > > How can I test this on Fedora 21? The xserver changes are in 1.16.2.901 which is in updates-testing so do yum --enablerepo=updates-testing update xorg-x11-server-Xorg
This is looking like a Mutter related bug after-all because it happens even after I updated to the following: mesa-dri-drivers.x86_64 10.3.5-1.20141207.fc21 @updates xorg-x11-server-Xorg.x86_64 1.16.2.901-1.fc21 @updates drago01@gmail.com, please follow the rest of my comments on bug #741376, which I've opened up, thank you. link: https://bugzilla.gnome.org/show_bug.cgi?id=741376
(In reply to comment #49) > There might still be a bug in GNOME, don't discount it. Do you see this > behavior in KDE and Unity? Jasper St. Pierre, please see https://bugzilla.gnome.org/show_bug.cgi?id=741376#c10, thank you.