Mutter would need to expose that data, it's currently not available through the usual GL APIs. I'll reassign to mutter, and will fix the panel once mutter has the API to allow that.

*** Bug 758016 has been marked as a duplicate of this bug. ***

#include <gtk/gtk.h>
#include <epoxy/gl.h>

static void
on_map (GtkWidget *widget)
{
  GdkGLContext *context;

  context = gdk_window_create_gl_context (gtk_widget_get_window (widget), NULL);
  gdk_gl_context_make_current (context);
  g_print ("GL Vendor: %s\nGL Renderer: %s\nGL Version: %s\n",
           glGetString (GL_VENDOR),
           glGetString (GL_RENDERER),
           glGetString (GL_VERSION));
  gdk_gl_context_clear_current ();
  g_object_unref (context);
}

int
main (int argc, char *argv[])
{
  GtkWidget *win;

  gtk_init (NULL, NULL);
  win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect_after (win, "map", G_CALLBACK (on_map), NULL);
  gtk_widget_show (win);
  gtk_main ();

  return 0;
}



Compile with: 

gcc -g -o testgl testgl.c `pkg-config --cflags --libs gtk+-3.0 epoxy`


This prints the following under Wayland here:

$ ./testgl
GL Vendor: Intel Open Source Technology Center
GL Renderer: Mesa DRI Intel(R) Ivybridge Mobile 
GL Version: 3.3 (Core Profile) Mesa 11.1.0-devel (git-5ae37ae)

So I think you can do this in the control center without even having different code paths for X or Wayland.

That doesn't work with EGL (requested in another bug) nor does it enumerate all the cards when using a dual-GPU setup. I'd rather mutter exported that information.

EGL doesn't expose any of this information, as far as I can see.

The best you can get out of drmGetVersion() is

Name: i915
Date: 20151010
Description: Intel Graphics

(In reply to Bastien Nocera from comment #5)
> That doesn't work with EGL (requested in another bug) nor does it enumerate
> all the cards when using a dual-GPU setup. I'd rather mutter exported that
> information.

We don't have that information either. The proper EGL way to do this is EGLDevice to enumerate devices and libglvnd to do dispatch to the GL driver to figure out what the renderer will be in that case.

i don't think libglvnd supports egl yet?  

There's a way to query display attributes posted here: 

http://lists.freedesktop.org/archives/mesa-dev/2015-July/thread.html#89783

But i don't think it's landed yet, and the only attribute it supports is the card device node .

Regardless, there's two tiers to shoot for:

1) parity with X11
2) better output above X11

1 may be a more near term goal than 2.

Created attachment 337404 [details] [review]
check-accelerated: Fix warnings on startup

The Wayland session is now named "gnome" not "gnome-wayland", so don't
try to run the X11-specific code when under Wayland.

Created attachment 337405 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

Created attachment 337408 [details] [review]
info: Get renderer from gnome-session under Wayland

Now that gnome-session's acceleration helper can print the renderer
under Wayland, launch it locally. We need to launch it locally as
Wayland is not available at the time gnome-session would launch the
helper, as there's no Wayland compositor yet.

Would still be much easier to do in mutter directly, as we need to handle multiple cases:
- X11, get the GL or GLES renderer from gnome-session
- Wayland, get the GL or GLES renderer from the gnome-session helper
- X11/Wayland, get the GPUs available from switcheroo-control for dual-GPU systems:
  https://github.com/hadess/switcheroo-control

Would we have a way to simplify that?

(In reply to Bastien Nocera from comment #11)
> Created attachment 337408 [details] [review] [review]
> info: Get renderer from gnome-session under Wayland
> 
> Now that gnome-session's acceleration helper can print the renderer
> under Wayland, launch it locally. We need to launch it locally as
> Wayland is not available at the time gnome-session would launch the
> helper, as there's no Wayland compositor yet.

Does this work if gnome-session and gnome-control-center are compiled with different libexecdir? Some distributions don't like /usr/libexec and set it to /usr/lib/<pkgname> instead.

(In reply to Ting-Wei Lan from comment #13)
> (In reply to Bastien Nocera from comment #11)
> > Created attachment 337408 [details] [review] [review] [review]
> > info: Get renderer from gnome-session under Wayland
> > 
> > Now that gnome-session's acceleration helper can print the renderer
> > under Wayland, launch it locally. We need to launch it locally as
> > Wayland is not available at the time gnome-session would launch the
> > helper, as there's no Wayland compositor yet.
> 
> Does this work if gnome-session and gnome-control-center are compiled with
> different libexecdir? Some distributions don't like /usr/libexec and set it
> to /usr/lib/<pkgname> instead.

No, it doesn't.

I looked, and we can't detect it. Maybe gnome-session should run it after it has a compositor, but I'm not sure how we'd detect that.

(In reply to Bastien Nocera from comment #10)
> Created attachment 337405 [details] [review] [review]
> check-accelerated: Print the renderer under Wayland as well
> 
> Based on sample code by Matthias Clasen <mclasen@redhat.com>
> 
> We'll use this in gnome-control-center when gnome-session cannot provide
> a renderer, under Wayland, as the Wayland compositor runs after
> gnome-session's startup.

It doesn't work when gdk_window_create_gl_context fails. If the hardware or the driver doesn't support OpenGL 3, it is likely to fail.

(In reply to Ting-Wei Lan from comment #16)
> (In reply to Bastien Nocera from comment #10)
> > Created attachment 337405 [details] [review] [review] [review]
> > check-accelerated: Print the renderer under Wayland as well
> > 
> > Based on sample code by Matthias Clasen <mclasen@redhat.com>
> > 
> > We'll use this in gnome-control-center when gnome-session cannot provide
> > a renderer, under Wayland, as the Wayland compositor runs after
> > gnome-session's startup.
> 
> It doesn't work when gdk_window_create_gl_context fails. If the hardware or
> the driver doesn't support OpenGL 3, it is likely to fail.

It should show "Unknown". If not, you'll need to be more precise than that.

It shows '(null)' because there is no error checking.

$ gnome-session-check-accelerated

(gnome-session-check-accelerated:12011): Gdk-CRITICAL **: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed

(gnome-session-check-accelerated:12011): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(null)

Created attachment 337942 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.

(In reply to Ting-Wei Lan from comment #18)
> It shows '(null)' because there is no error checking.
> 
> $ gnome-session-check-accelerated
> 
> (gnome-session-check-accelerated:12011): Gdk-CRITICAL **:
> gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
> 
> (gnome-session-check-accelerated:12011): GLib-GObject-CRITICAL **:
> g_object_unref: assertion 'G_IS_OBJECT (object)' failed
> (null)

Can you please test with the patch from comment 19? It does error checking properly (or should).

Created attachment 337945 [details] [review]
info: Get renderer from gnome-session under Wayland

Now that gnome-session's acceleration helper can print the renderer
under Wayland, launch it locally. We need to launch it locally as
Wayland is not available at the time gnome-session would launch the
helper, as there's no Wayland compositor yet.

Note that this code expects the gnome-session helper scripts to live
in $libexecdir, but distributions can use
--with-gnome-session-libexecdir=DIR to pass another one.

(In reply to Ting-Wei Lan from comment #13)
> (In reply to Bastien Nocera from comment #11)
> > Created attachment 337408 [details] [review] [review] [review]
> > info: Get renderer from gnome-session under Wayland
> > 
> > Now that gnome-session's acceleration helper can print the renderer
> > under Wayland, launch it locally. We need to launch it locally as
> > Wayland is not available at the time gnome-session would launch the
> > helper, as there's no Wayland compositor yet.
> 
> Does this work if gnome-session and gnome-control-center are compiled with
> different libexecdir? Some distributions don't like /usr/libexec and set it
> to /usr/lib/<pkgname> instead.

And the patch in comment 21 should fix this particular problem.

thanks for pushing this forward, Bastien

*** Bug 758016 has been marked as a duplicate of this bug. ***

Review of attachment 337404 [details] [review]:

::: tools/gnome-session-check-accelerated.c
@@ +108,3 @@
          * assume wayland will work
          */
+        if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {

well the X11 session can be called gnome too ...  Fallback is implemented by having a wayland session and x11 session with the same name. This should probably be XDG_SESSION_TYPE, "wayland"

Review of attachment 337942 [details] [review]:

good enough! some possibilities below

::: tools/gnome-session-check-accelerated.c
@@ +115,3 @@
+
+        win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
+        g_signal_connect_after (win, "map", G_CALLBACK (on_map), &renderer);

I think "realize" is a better signal handler than "map"?  Though, maybe you can avoid the signal handler entirely and just do:

gtk_widget_realize (win)
create_gl_context
make_current
glGetString
etc

or is there some trickery that's preventing realize from working?

@@ +134,3 @@
 
+        gtk_init (NULL, NULL);
+

as an aside, we should probably feed argc and argv to this, but I guess you're just moving code around

@@ +141,3 @@
         if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {
+                renderer_string = get_gtk_gles_renderer ();
+                g_print ("%s", renderer_string);

if we're adding a g_print should probably put G_SPAWN_STDOUT_TO_DEV_NULL in the gnome-session caller. Though looking closer, we actually started doing the g_print in bug 768292 so maybe it doesn't matter. just clutters up the log a little, and the log is already pretty cluttered.

Review of attachment 337945 [details] [review]:

i sort of wonder if we should rename gnome-session-check-accelerated and make it live somewhere else now, but I can't think of a better place. anyway, seems okay.

::: panels/info/cc-info-panel.c
@@ +334,3 @@
+
+  if (!g_spawn_sync (NULL, (char **) argv, NULL, 0, NULL, NULL, &renderer, NULL, &status, NULL))
+    return NULL;

GSubprocess is the new cool, but I agree GSpawn is probably less code.

Created attachment 338113 [details] [review]
check-accelerated: Fix warnings on startup

The Wayland session is now named "gnome" not "gnome-wayland", so don't
try to run the X11-specific code when under Wayland.

Created attachment 338114 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.

(In reply to Ray Strode [halfline] from comment #26)
> Review of attachment 337942 [details] [review] [review]:
> 
> good enough! some possibilities below
> 
> ::: tools/gnome-session-check-accelerated.c
> @@ +115,3 @@
> +
> +        win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> +        g_signal_connect_after (win, "map", G_CALLBACK (on_map), &renderer);
> 
> I think "realize" is a better signal handler than "map"?  Though, maybe you
> can avoid the signal handler entirely and just do:
> 
> gtk_widget_realize (win)
> create_gl_context
> make_current
> glGetString
> etc

That worked, and stopped the window showing up for a few milliseconds, making it pop up in the gnome-shell menu list.

> or is there some trickery that's preventing realize from working?
> 
> @@ +134,3 @@
>  
> +        gtk_init (NULL, NULL);
> +
> 
> as an aside, we should probably feed argc and argv to this, but I guess
> you're just moving code around

Yep, just moving code around here.

> @@ +141,3 @@
>          if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {
> +                renderer_string = get_gtk_gles_renderer ();
> +                g_print ("%s", renderer_string);
> 
> if we're adding a g_print should probably put G_SPAWN_STDOUT_TO_DEV_NULL in
> the gnome-session caller. Though looking closer, we actually started doing
> the g_print in bug 768292 so maybe it doesn't matter. just clutters up the
> log a little, and the log is already pretty cluttered.

This command is not launched at all on Wayland (after the session type fix), until gnome-control-center's Details panel is launched. So no extra garbage in the logs. The different code paths for X11 and Wayland are pretty awful here, where the *need* the helper to be launched for X11, and not at all for Wayland. In the long term, we'll just remove all this X11 code, and live with it until now.

Created attachment 338119 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.

Attachment 338113 [details] pushed as 9055c11 - check-accelerated: Fix warnings on startup
Attachment 338119 [details] pushed as 6e474f9 - check-accelerated: Print the renderer under Wayland as well

Attachment 337945 [details] pushed as 83c8c57 in gnome-control-center - info: Get renderer from gnome-session under Wayland

Hi Bastien.

On a box without Wayland, I am getting this error:

panels/info/.libs/libinfo.a(cc-info-panel.o): In function `cc_info_panel_init':
cc-info-panel.c:(.text+0x2a4f): undefined reference to `GDK_IS_WAYLAND_DISPLAY'

That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is defined.

(In reply to Antoine Jacoutot from comment #34)
> Hi Bastien.
> 
> On a box without Wayland, I am getting this error:
> 
> panels/info/.libs/libinfo.a(cc-info-panel.o): In function
> `cc_info_panel_init':
> cc-info-panel.c:(.text+0x2a4f): undefined reference to
> `GDK_IS_WAYLAND_DISPLAY'
> 
> That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now
> reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is
> defined.

Bug for the wrong module to mention this. In the future, would also be nice for you to run your test builds *before* releases. That code has been there since November...

Cherry-picked in 4825881b129bdde0eaa5419ece6198ebda420825, as it was already fixed for gnome-3-24 and master.

(In reply to Bastien Nocera from comment #35)
> (In reply to Antoine Jacoutot from comment #34)
> > Hi Bastien.
> > 
> > On a box without Wayland, I am getting this error:
> > 
> > panels/info/.libs/libinfo.a(cc-info-panel.o): In function
> > `cc_info_panel_init':
> > cc-info-panel.c:(.text+0x2a4f): undefined reference to
> > `GDK_IS_WAYLAND_DISPLAY'
> > 
> > That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now
> > reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is
> > defined.
> 
> Bug for the wrong module to mention this. In the future, would also be nice

I used this BZ URL because it was mentioned in the commit (c5c3e04a3cbebbae7ecba64deb83a31970d7665a); but yeah, not the same module, sorry about that, I just assumed.

> for you to run your test builds *before* releases. That code has been there
> since November...

Unfortunately, I'm not currently in a position to do regression testing.

> Cherry-picked in 4825881b129bdde0eaa5419ece6198ebda420825, as it was already
> fixed for gnome-3-24 and master.

Thank you very much for your timely fix.