GNOME Bugzilla – Bug 646280
Maximum 3D size limitations
Last modified: 2019-03-20 10:53:22 UTC
The Intel GM945 chipset is very common, and has a limitation that the maximum 3D rendered area is 2048 pixels wide. Which isn't wide enough to handle a 1024x600 netbook + a 1280x1024 monitor. Mesa is pretty good about automatically falling back to software rendering, so the observed effect is that if you plug in such a monitor, things become dead slow and your system becomes unusable. See https://bugzilla.redhat.com/show_bug.cgi?id=678791 Here's a plan for how we should handle this case: * gnome-session-check-accelerated should query GL_MAX_RENDERBUFFER_SIZE_EXT and set the result as a property on the root window. ( _GNOME_MAX_SCREEN_SIZE) * When in non-fallback mode, the xrandr code in gnome-settings-daemon should check this property and then only pick monitor configurations that fit within GL_MAX_RENDERBUFFER_SIZE_EX. Ordering of the initial default configuration should be: - As currently, if it fits - Mirrored displays if that would result in a resolution of at least 1024x600 - Otherwise, only the primary monitor with the secondary output off * The panel should respect the same limitations, so if you try to enable the one monitor, then the other monitor turns off and the primary switches to the on monitor. The reasons for doing the query in gnome-session-check-accelerated are: - It already has the code to set up a glx context and query stuff from it - It's very important that this code doesn't run unless gnome-session-check-accelerated passed, since GLX crashing on initialization is reasonable common and we want to handle it gracefully.
Created attachment 222234 [details] [review] 0001-Set-_GNOME_MAX_SCREEN_SIZE-on-the-root-window.patch This should implement the gnome-session half of it, at least. The code is in check-accelerated-helper not check-accelerated, since the former is the one where we hide GLX setup. Tested on a Thinkpad T500: $ DISPLAY=:0 glxinfo | grep renderer OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset $ DISPLAY=:0 xprop -root | grep _GNOME _GNOME_BACKGROUND_REPRESENTATIVE_COLORS(STRING) = "rgb(48,49,82)" _GNOME_MAX_SCREEN_SIZE(CARDINAL) = 8192 _GNOME_SESSION_ACCELERATED(CARDINAL) = 1 $ DISPLAY=:0 ltrace /usr/libexec/gnome-session-check-accelerated-helper |& grep GetInteger glGetIntegerv(3379, 0x602104, 0x37fe7b0778, 0xfbad000c, 1) = 8192 glGetIntegerv(34024, 0x602108, 2, 0x7ff12c445155, 300731) = 8192
Review of attachment 222234 [details] [review]: ::: tools/gnome-session-check-accelerated-helper.c @@ +286,2 @@ if (_is_gl_renderer_blacklisted (renderer) != 0) goto out; If we fail here max_renderbuffer_size == 0 and max_texture_size == 0 @@ +297,3 @@ + if (glGetError() != GL_NO_ERROR) + max_renderbuffer_size = -1; + if we fail here, they equal -1. @@ +411,1 @@ return 1; in both cases @@ +414,3 @@ + if (size < DisplayWidth (display, screen) && + size < DisplayHeight (display, screen)) { + return 1; we fail, so it's not a problem in practice, but it's a little sloppy (not that you did it first). I would prefer a preliminary commit that: - uses -1 (or 0) everywhere for "it didn't work" and another preliminary commit that @@ +471,3 @@ } if (_is_max_texture_size_big_enough (display) != 0) { makes this function return true instead of of 0 for success. The whole "leave the code cleaner than you found it mantra" (if you're up for it) Then your commit on top (though I have some more comments coming)
Review of attachment 222234 [details] [review]: ::: tools/gnome-session-check-accelerated-helper.c @@ +411,3 @@ return 1; + for (screen = 0; screen < ScreenCount(display); screen++) { we actually only allow ScreenCount == 1 elsewhere in the code, since shell isn't capable of working in zaphod set ups right now. So, I wouldn't add this loop. In theory the loop future proofs the code, but if that's the spirit of the change then it should be in a preliminary commit that adds the loop everywhere screen is used, and then a small incremental commit for just this part. @@ +412,3 @@ + for (screen = 0; screen < ScreenCount(display); screen++) { + if (size < DisplayWidth (display, screen) && this should say || not && since we want to fail if either dimension is too small
(thanks for looking into this btw)
As per comments on desktop-devel-list, this will likely not get fixed "unless somebody with such a card writes a patch and tests it." So help is welcome. Adam: Do you have time to update your patch as per last comments?
Comment on attachment 222234 [details] [review] 0001-Set-_GNOME_MAX_SCREEN_SIZE-on-the-root-window.patch Updated the patch and moved it to gnome-session bug 688252
I filed bug 688270 against gnome-session so that it tries hard, on startup, to create a working display configuration if the spanning setup is causing problems for example. This bug will stay as the bug to handle the UI bits not allowing you to create a broken configuration.
*** Bug 702049 has been marked as a duplicate of this bug. ***
God *damn* it, what is with things being impossible to search in GNOME Bugzilla? I never, ever, ever, ever, EVER find the bug my bug is a dupe of, despite searching through the BGO search and Google site:bugzilla.gnome.org. Is there a special anti-search plugin or something? :) I even search for '2048 pixels', which is right there in the description of this bug, and didn't find it.
bugzilla.gnome.org isn't indexed by Google or any other search engines.
Best not continue off-topic for too long, but that seems unfortunate. I find Bugzilla's own search to be slow and not particularly good (see above). I search RH bugzilla using google site:bugzilla.redhat.com more than I use the in-built search, and usually with better results.
*** Bug 595839 has been marked as a duplicate of this bug. ***
*** Bug 645087 has been marked as a duplicate of this bug. ***
*** Bug 704810 has been marked as a duplicate of this bug. ***
This is an absolute killer bug, rendering recent gnome unusable in a lot of scenarios with the ubiquitous 945 chipset. Is there a workaround that can be applied with currently released Gnome (3.6 and 3.8) while a proper fix is worked on?
(In reply to comment #15) > This is an absolute killer bug, rendering recent gnome unusable in a lot of > scenarios with the ubiquitous 945 chipset. "Recent"? It never was capable of running higher resolutions in any version of gnome-shell. > Is there a workaround that can be > applied with currently released Gnome (3.6 and 3.8) while a proper fix is > worked on? Disconnect the external monitor, or use lower resolutions. The only thing fixing this bug would do is that it would lower the resolution or disconnect one of the monitors, it's not magically going to make your chipset handle larger textures and thus bigger screen sizes.
*** Bug 730210 has been marked as a duplicate of this bug. ***
*** Bug 657431 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/168.