[Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits

Sun Jul 6 16:22:05 PDT 2014

On Saturday, July 05, 2014 01:04:02 PM Emil Velikov wrote:
> On 5 July 2014 08:53, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Fri, 04 Jul 2014 08:45:00 +0100
> > Steven Newbury <steve at snewbury.org.uk> wrote:
> >
> >> On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote:
> >> > On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury
> >> >  wrote:
> >> > >  On Thu, 2014-07-03 at 10:47 +0200, Andreas Boll wrote:
> >> > > >  2014-07-03 7:39 GMT+02:00 Steven Newbury
> >> > > > :
> >> > > > >   On Wed, 2014-07-02 at 21:04 +0200, Andreas Boll wrote:
> >> > > > > > >
> >> > > > > >   I'd like to make a new demos release on Friday, July 4th.
> >> > > > > >   The last release was on February 24th, 2013. Additionally
> >> > > > > > this
> >> > > > > >   release is needed to fix the build with mesa 10.2.
> >> > > > > > (fdo#78101)
> >> > > > > > > >
> >> > > > > >   Any objections?
> >> > > > > > > >
> >> > > > > >   Also I'd like to get these 3 patches included in the new
> >> > > > > >  release.
> >> > > > > > > >
> >> > > > > >   Andreas.
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > >   Fredrik Höglund (3):
> >> > > > > >     glxinfo: Print XFB, TBO, and UBO limits
> >> > > > > >     glxinfo: Print GL_ARB_vertex_attrib_binding limits
> >> > > > > >     glxinfo: Print GL_EXT_texture_array limits
> >> > > > > > > >
> >> > > > > >    src/xdemos/glinfo_common.c | 30
> >> > > > > > ++++++++++++++++++++++++++++++
> >> > > > > >    1 file changed, 30 insertions(+)
> >> > > > > > > >
> >> > > > > > >
> >> > > > >   What about extending eglinfo to have switches to enable
> >> > > > > printing
> >> > > > >  glxinfo
> >> > > > >   style output for each supported API?
> >> > > > > > >
> >> > > > >
> >> > > >  Sounds good, feel free to send a patch.
> >> > > >  Although I'm not planning to hold off this release.
> >> > > >  I can make further releases when required.
> >> > > > >
> >> > > > >
> >> > >  I've been giving this some more thought, it occurs to me that
> >> > > since
> >> > >  there's already es1_info/es2_info progs, what's really needed is
> >> > > an
> >> > >  EGL version of glxinfo/wglinfo (egl_glinfo?) which should be able
> >> > > to
> >> > >  share the glinfo_common code.
> >> > > >
> >> > >  While digging though the existing code I noticed the above
> >> > > mentioned
> >> > >  es*_info program only works with X11 EGL, that should probably be
> >> > >  improved too...
> >> > > >
> >> > >  Shall I see if I can code something up to get glinfo output
> >> > > through
> >> > >  EGL?  Would this be he best approach?
> >> >
> >> > I'm sure I'm missing something, but what's wrong with eglinfo?
> >> >
> >> > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglinfo.c
> >> >
> >> > It doesn't share the glinfo_common code, but that should be easily
> >> > arranged, I would think.
> >> Of course it's an option to extend eglinfo with switches to select
> >> API, but there is already es*_info, which is what made me thing it
> >> might be the better approach.  I'm perfectly happy to hack on eglinfo
> >> instead! :-)
> >
> > For me personally, the problem with eglinfo has been that it does
> > not create any GL context, so cannot report any GL info either. In
> > the past, the problem was that you needed window system specific
> > code to create the EGLDisplay and maybe the window too.
> >
> > EGL_DEFAULT_DISPLAY just won't work everywhere, and in Mesa it
> > might pick a wrong window system, and the window system will
> > affect at least EGL capabilities.
> >
> > Do we now have an acceptable plan of writing a multi-window-system
> > capable *info program, or are we still stuck with *info programs
> > written for specific window systems?
> >
> > I'd really like one that works e.g. on Wayland, and preferably does
> > not do anything very Mesa specific. Would also be very cool to
> > use the new extensions allowing to be explicit on which window
> > system you are intending to use, rather than rely on the EGL
> > implementation guessing based on your EGLNativeDisplay value.
> >
> > The other complication with writing a multi-API *info program is,
> > that you need to link to a different library depending on the API
> > you choose: libGLESv1_CM vs. libGLESv2 vs. libGL...
> >
> > Libepoxy to the rescue?
> > https://github.com/anholt/libepoxy
> >
> IMHO waffle [1] would be a better bet here. Build it once and control
> the platfrom/api via a command line arg and/or env var.
> 
> There is a minor catch though - waffle needs to stop explicit linking
> against libGL libEGL libGLES... and dlopen only the required the
> library.
> 
> -Emil
> 
> [1] https://github.com/waffle-gl/waffle

In fact Waffle already includes a "wflinfo" program, which supports 
GLX/EGL+X11/Wayland/GBM/Android and GL/ES1/ES2/ES3 today.

Improving wflinfo seems like the way to go.  There are a couple of obvious 
improvements that could be made:

1. It doesn't print out all the same information that glxinfo does (missing 
limits, visuals), and it could do a better job of pretty-printing.

2. The UI is obnoxious: running plain "wflinfo" generates the terse message:

Wflinfo usage error: --platform is required (see wflinfo --help)

Ideally, I'd like it to provide some sort of useful information.  One option 
would be to print a summary of what's currently supported on your system:

Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Haswell Mobile

Supported Window Systems:
- EGL 1.5: Wayland            (-p wayland)
- EGL 1.5: X11                (-p egl_x11)
- GLX 1.4: Direct Rendering   (-p glx)
- GLX 1.4: Indirect Rendering (-p glx --indirect)
- GBM (Offscreen)             (-p gbm)

Supported APIs:
- OpenGL 3.0                  (-a gl)
- OpenGL/Core 3.3             (-a gl --profile=core)
- OpenGL ES 1.0               (-a gles1)
- OpenGL ES 2.0               (-a gles2)
- OpenGL ES 3.0               (-a gles3)

For more information, run:
$ wflinfo -a gl --extensions
$ wflinfo -a gl --fbconfigs
$ wflinfo -a gl --limits

In other words, answer the usual questions of:
- What GL version(s) do I have?
- Am I using my hardware drivers?
- Do I have direct rendering?
without having to read through all of the visuals and extension 
information...and also suggest how to get more information.

Or, if people don't like the summary idea, it could at least autodetect things 
like "DISPLAY is set, maybe I should try egl_x11/glx" or "Wayland is running, 
use that", or GBM as a fallback...and maybe default to GL...generally anything 
would be more usable than the 1 line "you suck" message.  Heck, even just 
printing help instead of telling me to would save one invocation of the 
binary...

But, I think all of those could be fairly easily fixed...and having one tool 
to rule them all seems like a really nice feature.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140706/b3db01ca/attachment.sig>