GNOME Bugzilla – Bug 738670
GL Context on NVIDIA
Last modified: 2015-04-09 10:18:22 UTC
I have been playing with gdkgears on my NVIDIA system using the prop. NVIDIA drivers. It does not seem to work at all. First it fails to create a GLX context. Thats because the call in https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n761 generates a BadMatch. Setting the drawable to None and moving that to an else branch fixes the context creation. After fixing that it still does not work because the glXCreatePixmap call in glx_pixmap_get also triggers a BadMatch. I had to change it to use GLX_TEXTURE_2D_EXT (why isn't it trying to use that anyway?) and GLX_TEXTURE_FORMAT_RGB_EXT to get it to work. But "work" means no crashing the gears are spinning but with a black background and the window controls are white (but react to mouse events). At that point I decided to file a bug instead of digging deeper.
The 2D_EXT thing we should just switch by default, but i don't have an nvidia machine to test nvidia on in general :/
Created attachment 288957 [details] [review] gdkglcontext-x11: Fix gl context Do not create the dummy drawable when we have glx => 1.3, this causes a BadMath on NVIDIA's glx implementation.
Created attachment 288958 [details] [review] gdkglcontext-x11: Fix pixmap creation 1) Always use NPOT textures 2) Do not select a RGB fbconfig, we use RGBA for the texture format, mixing both will cause BadMatch.
(In reply to comment #1) > The 2D_EXT thing we should just switch by default, but i don't have an nvidia > machine to test nvidia on in general :/ I have debugged it some more. With the attached patches it now works for me on both NVIDIA and INTEL (haswell). I can split the second patch into two if you prefer that (i.e one for NPOT and one for the RGBA fbconfig).
Review of attachment 288957 [details] [review]: if you don't have access to GLX ≥ 1.3 then you cannot call glXCreateWindow(). the old code I wrote (which was taken from the equivalent code I wrote in Clutter) created a X11 dummy window, and used its XID with the GLX API, if the GLX version was < 1.3. the glXCreateWindow() call, and its GLXWindow XID was used only with GLX ≥ 1.3, so you're mismatching GLX use. ::: gdk/x11/gdkglcontext-x11.c @@ +762,3 @@ + info->dummy_glx = glXCreateWindow (dpy, config, info->dummy_xwin, NULL); + } + else coding style: this `else` is way overindented.
Review of attachment 288957 [details] [review]: Yeah, this seems pretty weird. Is NVidia GLX 1.3? If so we must have a glx window for it. And for non-1.3 we can't have any glx window.
Review of attachment 288958 [details] [review]: pushed this
(In reply to comment #6) > Review of attachment 288957 [details] [review]: > > Yeah, this seems pretty weird. > Is NVidia GLX 1.3? If so we must have a glx window for it. > And for non-1.3 we can't have any glx window. the way I implemented dummy windows for unattached contexts was to have a dummy drawable associated with the GLX context; at the time, though, the GdkGLContext objects were associated with a GdkDisplay, not with a GdkWindow.
(In reply to comment #6) > Review of attachment 288957 [details] [review]: > > Yeah, this seems pretty weird. Yeah that patch is wrong it just fixed it because it got rid of the first glXCreateWindow call which triggers a BadMatch. > Is NVidia GLX 1.3? Yes (actually 1.4). > If so we must have a glx window for it. And for non-1.3 we can't have any glx window. So the GLX < 1.3 path is already correct. The 1.3 one still is broken though. I am not sure if ebassi's old code worked (or got tested) but the code in cogl/clutter he based it on works just fine.
I updated some changes related to TEXTURE_2D vs TEXTURE_RECTANGLE_ARB. Can yo try nvidia on latest master?
(In reply to comment #10) > I updated some changes related to TEXTURE_2D vs TEXTURE_RECTANGLE_ARB. Can yo > try nvidia on latest master? I tested and as expected it does not work. Changes to the texture code won't make any difference as long as creating a gl context fails. The texturing issues I mentioned above where only visible after fixing the gl context creation. This line: https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n810 Triggers a bad match causing us to hit the trap here: https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n816 and thus have no GL context to work with. Removing that line and doing "info->glx_drawable = None" instead makes it work (see my first patch, the else branch was wrong though because we cannot do that on GLX 1.2).
(In reply to comment #11) > (In reply to comment #10) > > I updated some changes related to TEXTURE_2D vs TEXTURE_RECTANGLE_ARB. Can yo > > try nvidia on latest master? > > I tested and as expected it does not work. Changes to the texture code won't > make any difference as long as creating a gl context fails. The texturing > issues I mentioned above where only visible after fixing the gl context > creation. > > This line: > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n810 > > Triggers a bad match causing us to hit the trap here: > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n816 and thus > have no GL context to work with. > > Removing that line and doing "info->glx_drawable = None" instead makes it work > (see my first patch, the else branch was wrong though because we cannot do that > on GLX 1.2). i.e this: diff --git a/gdk/x11/gdkglcontext-x11.c b/gdk/x11/gdkglcontext-x11.c index accc8a5..a58d8ad 100644 --- a/gdk/x11/gdkglcontext-x11.c +++ b/gdk/x11/gdkglcontext-x11.c @@ -807,9 +807,7 @@ gdk_x11_window_create_gl_context (GdkWindow *window, if (GDK_X11_DISPLAY (display)->glx_version >= 13) { - info->glx_drawable = glXCreateWindow (dpy, config, - gdk_x11_window_get_xid (window->impl_window), - NULL); + info->glx_drawable = None; info->dummy_glx = glXCreateWindow (dpy, config, info->dummy_xwin, NULL); } is enough to make it work.
Created attachment 289504 [details] [review] gl context In my case I needed this patch to make it work
Another interesting crash: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () Missing separate debuginfos, use: debuginfo-install dbus-libs-1.6.12-9.fc20.x86_64 expat-2.1.0-7.fc20.x86_64 freetype-2.5.0-5.fc20.x86_64 glibc-2.18-16.fc20.x86_64 gmp-5.1.2-2.fc20.x86_64 gnutls-3.1.27-1.fc20.x86_64 keyutils-libs-1.5.9-1.fc20.x86_64 krb5-libs-1.11.5-11.fc20.x86_64 libICE-1.0.8-6.fc20.x86_64 libSM-1.2.1-6.fc20.x86_64 libX11-1.6.1-1.fc20.x86_64 libXau-1.0.8-2.fc20.x86_64 libXcomposite-0.4.4-4.fc20.x86_64 libXcursor-1.1.14-2.fc20.x86_64 libXdamage-1.1.4-4.fc20.x86_64 libXdmcp-1.1.1-5.fc20.x86_64 libXext-1.3.2-2.fc20.x86_64 libXfixes-5.0.1-2.fc20.x86_64 libXi-1.7.4-1.fc20.x86_64 libXinerama-1.1.3-2.fc20.x86_64 libXrandr-1.4.1-2.fc20.x86_64 libXrender-0.9.8-2.fc20.x86_64 libcom_err-1.42.8-3.fc20.x86_64 libdrm-2.4.54-1.fc20.x86_64 libffi-3.0.13-5.fc20.x86_64 libgcc-4.8.3-7.fc20.x86_64 libmodman-2.0.1-7.fc20.x86_64 libpng-1.6.6-3.fc20.x86_64 libproxy-0.4.11-8.fc20.x86_64 libselinux-2.2.1-6.fc20.x86_64 libstdc++-4.8.3-7.fc20.x86_64 libtasn1-3.8-2.fc20.x86_64 libuuid-2.24.2-1.fc20.x86_64 mesa-libEGL-10.1.5-1.20140607.fc20.x86_64 mesa-libgbm-10.1.5-1.20140607.fc20.x86_64 mesa-libglapi-10.1.5-1.20140607.fc20.x86_64 mesa-libwayland-egl-10.1.5-1.20140607.fc20.x86_64 nettle-2.7.1-3.fc20.x86_64 openssl-libs-1.0.1e-40.fc20.x86_64 pcre-8.33-6.fc20.x86_64 pixman-0.30.0-5.fc20.x86_64 systemd-libs-208-22.fc20.x86_64 trousers-0.3.13-1.fc20.x86_64 xz-libs-5.1.2-12alpha.fc20.x86_64 zlib-1.2.8-3.fc20.x86_64 (gdb) bt
+ Trace 234263
Review of attachment 289504 [details] [review]: ::: gdk/x11/gdkglcontext-x11.c @@ +592,2 @@ attrs[i++] = GLX_BLUE_SIZE; + attrs[i++] = 1; this is pretty much what Cogl does — i.e. discards the bits from the Visual and just ask for at least 1 bit. I assume it's Mesa being much more relaxed on the requirements. @@ +808,3 @@ if (GDK_X11_DISPLAY (display)->glx_version >= 13) { + info->glx_drawable = None; yeah, this is not going to happen. we really need a glXWindow XID created by glXCreateWindow() for GLX ≥ 1.3. this function is failing because of a BadMatch on the Visual, which is fairly odd.
> This line: > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n810 > > Triggers a bad match causing us to hit the trap here: > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkglcontext-x11.c#n816 and thus > have no GL context to work with. So, glXCreateWindow() returns badmatch if: BadMatch is generated if win was not created with a visual that corresponds to config. BadMatch is generated if config does not support rendering to windows (i.e., GLX_DRAWABLE_TYPE does not contain GLX_WINDOW_BIT). We filtered from GLX_WINDOW_BIT in find_fbconfig_for_visual(), so that seems unlikely. So i guess we're having some issue with visuals.
What is the output of: "glxinfo -v" and "xdpyinfo" on these systems?
Created attachment 289522 [details] glxinfo glxinfo output
Created attachment 289523 [details] xdpyinfo xdpyinfo output
Created attachment 289528 [details] [review] GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per:
With the above patch nacho gets gl running on non-rgba windows. However, i think there is a general problem with X visuals here. For instance, on my system the default visual is: visual: visual id: 0x20 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits Which matches this glx visual: Visual ID: 20 depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=8 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Using this as the default visual enforces a depthbuffer and stencil buffer for all windows, which we don't use, this is not ideal. I think we need to start from glx when choosing the default and rgba visuals that Gtk+ use.
Also, on my xserver there is only on rgba X visual: visual: visual id: 0x5e class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits and the corresponding glx visual: Visual ID: 5e depth=32 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=8 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Has depth+stencil buffers. Does this mean i can't draw using gl on this window without allocating a depth buffer?
I pushed the above patch and another fix. Can you try on nvidia, both the normal gl demos and: GDK_ALWAYS_USE_GL=true demos/gtk-demo/gtk3-demo
(In reply to comment #23) > I pushed the above patch and another fix. > Can you try on nvidia, both the normal gl demos and: gdkgears now works fine. > GDK_ALWAYS_USE_GL=true demos/gtk-demo/gtk3-demo This does not: (lt-gtk3-demo:7157): Gdk-WARNING **: Unable to force GL enabled: No available configurations for the given RGBA pixel format (lt-gtk3-demo:7157): Gdk-WARNING **: Unable to force GL enabled: Unable to create a GL context (lt-gtk3-demo:7157): Gdk-WARNING **: Unable to force GL enabled: Unable to create a GL context (lt-gtk3-demo:7157): Gdk-WARNING **: Unable to force GL enabled: Unable to create a GL context ....
Created attachment 289585 [details] [review] X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
Created attachment 289586 [details] [review] Cache default gdk visuals in the GDK_VISUALS property on the root window This means we don't have to try to initialize opengl in every gtk instance that is stated. It will only happen for the first one.
Attachment 289585 [details] pushed as dae4477 - X11: Pick better system and rgba visuals for GL Attachment 289586 [details] pushed as 8c7623d - Cache default gdk visuals in the GDK_VISUALS property on the root window
Closing this as fixed for now, i think the libepoxy crash from comment #14 needs to go in a new bug, ideally with the libepoxy people.
Created attachment 289592 [details] Blurry and overly transparent window
(In reply to comment #29) > Created an attachment (id=289592) [details] > Blurry and overly transparent window I cannot reproduce that. Current master works fine here for both gdkgears and gtkdemo with GDK_ALWAYS_USE_GL set to true.
Garret, drago01: Can you both give exact details on your setup. I.e. what driver version, what kind of gpu, what X version, what kind of desktop/WM/compositor.
1. WM: gnome-shell gnome-shell-3.10.4 (i.e F20) [1] 2. xserver: 1.14.4 (also what is on F20) 3. GPU: GTX 285 4. Driver: 340.46 1: Also works fine with gnome-shell/mutter master (built using jhbuild).
WM: metacity 2.34.13 (Ubuntu 14.04) X: 1.15.1 (Ubuntu 14.04) GPU: GeForce GT 635 Driver: 331.38
Can you guys test latest master? I changed how things render quite a bit.
(In reply to comment #34) > Can you guys test latest master? I changed how things render quite a bit. Still working fine here. gdkgears now gets ~59 FPS used to be ~30 before.
(In reply to comment #35) > (In reply to comment #34) > > Can you guys test latest master? I changed how things render quite a bit. > > Still working fine here. gdkgears now gets ~59 FPS used to be ~30 before. Performance increase is probably because of this: https://git.gnome.org/browse/gtk+/commit/?id=3c34ca3405f852b554bc05e07e460dbe9b9eae59 ... creating an FBO involves a round trip on NVIDIA.
drago01: Could you build: https://github.com/ebassi/graphene and https://github.com/alexlarsson/gthree And then try: GDK_DEBUG=frames examples/performance What kind of framerates does this give you? I'm interested in how this performs with the nvidia drivers.
Created attachment 290112 [details] Output of the gthree performance run
(In reply to comment #37) > drago01: Could you build: > https://github.com/ebassi/graphene > and > https://github.com/alexlarsson/gthree > > And then try: > GDK_DEBUG=frames examples/performance > > What kind of framerates does this give you? > I'm interested in how this performs with the nvidia drivers. See comment 38
That is similar times to what i get on my intel Sandybridge, not sure what to expect perfomance-wise though...
should we close this bug, since GdkGL works on nvidia binary blob drivers?
(In reply to comment #41) > should we close this bug, since GdkGL works on nvidia binary blob drivers? Garrett said that it didn't work for him. Garrett can you retest current master?
(In reply to comment #40) > That is similar times to what i get on my intel Sandybridge, not sure what to > expect perfomance-wise though... Well assuming its not CPU bound I'd expect a dedicated NVIDIA card to be faster then snb but we might be using code paths that favor UMA cards. Anyway we can investigate that latter that bug was about getting it to work at all.
Garrett ?
Sorry for the delay, it is now working just fine here.
(In reply to comment #45) > Sorry for the delay, it is now working just fine here. OK thanks; so yeah lets close this one.
Any idea why this change would cause rendering issues for GtkStatusIcon widgets with transparent background when the screen isn't composited? [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=737986#c10
Commenting on a closed bug without reopening it is not going to get people to look at it.
Sorry, I didn't think to reopen this bug because the issue might be in gtktrayicon-x11.c.
I assume the newly added code to cache the visuals interferes with the _NET_SYSTEM_TRAY_VISUAL property.
(In reply to Evangelos Foutras from comment #49) > Sorry, I didn't think to reopen this bug because the issue might be in > gtktrayicon-x11.c. It most definitely is; the X11 tray icon code likely needs to be updated.
It may probably help debugging along if you could step through pick_better_visual_for_gl() in GDB and look at what kind of compatible visuals it detects.
Created attachment 300466 [details] system_visual selected by pick_better_visual_for_gl() After commenting out the block that calls get_cached_gl_visuals(), it appears that pick_better_visual_for_gl() selects the visual with ID 0x20e while the default is 0x21. xdpyinfo doesn't show any differences between the two visuals; there are differences in glxinfo though. In the attached file, the GDB output is from a breakpoint in pick_better_visual_for_gl() right at the return statement in the first for loop. After printing each GdkVisual object, I included the information for each visual from xdpyinfo and glxinfo. Is any of this information helpful? I can continue poking around, though I'm not familiar with any of this stuff so I'm not sure how much insight I can offer.
Created attachment 300468 [details] system_visual selected by pick_better_visual_for_gl() Same as above but with fixed alignment in glxinfo output.
Is it possible that the issue is that the root window is using the 0x20e visual while the widget and its window are using 0x21 (the visual set by xfce4-panel via the _NET_SYSTEM_TRAY_VISUAL property)? Stepping through gtk_tray_icon_realize() in GDB right after the widget is realized the visuals are set as follows: ===================== (gdb) p/x gdk_x11_visual_get_xvisual (icon->priv->manager_visual)->visualid $1 = 0x21 (gdb) p/x gdk_x11_visual_get_xvisual (window->visual)->visualid $2 = 0x21 (gdb) p/x gdk_x11_visual_get_xvisual (window->parent->visual)->visualid $3 = 0x20e ===================== Furthermore, if I do "set window->parent->visual = window->visual" in GDB before continuing the execution, the icon renders correctly.
So it seems we're still setting a RGBA visual even if the system is asking for a RGB one?
I believe that's not the issue. Even if I make gtk3 pick a visual that is as close as possible to the system default, it still won't render properly. (All glxinfo properties being the same, except for stencilSize.) My guess at this point is that the "parent-relative background pixmap" thingy used in gtktrayicon-x11.c isn't behaving correctly when the widget's window and the root window have different visuals configured. A recap of what's going on (as I understand it): * The issue is affecting gtk3 status icons in the Xfce panel systray area and only occurs when the screen isn't composited. Icon updates are drawn on top of the previous icon and, when new status icons are added to the tray, their background is black instead of transparent. * The Xfce panel (that contains the systray manager) uses the system default visual with ID 0x21 and sets the _NET_SYSTEM_TRAY_VISUAL property to the same value. * I start my test gtk3 application which creates a GtkStatusIcon. The application's root window uses the visual with ID 0x20e (which selected by default in gtk 3.16.0). Before the status icon is realized, its visual is set to 0x21. Immediately after this, the widget's window is created and that also uses the visual 0x21. Bellow is the 'glxinfo -v' output for both visuals: Visual ID: 21 depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=8 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Visual ID: 20e depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=24 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=0 float=N sRGB=N auxBuffers=0 depthSize=0 stencilSize=0 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Another visual I tried (instead of 0x20e) but still didn't work: Visual ID: 1e0 depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=0 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque.
I filed bug 747524 so this can be properly tracked; my suggestion is to close this bug and continue discussion on bug 747524.
ok, lets do that.