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

[Emil Velikov]

On 7 July 2014 00:22, Kenneth Graunke <kenneth at whitecape.org> wrote:
> 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.
>
Thanks for the nice summary Ken.

IMHO it would be better to keep wflinfo as is and convert mesa-demos
to waffle. Then we can think of adding heuristics to detect the
winsys/api and/or improving the error output.

For anyone interested - wgl support in waffle it's almost complete[1].
It's not upstreamed yet as it requires some api/abi changes. The code
can be found here [2]. I'm afraid that my final GSoC step/task
(cleanup piglit and fully convert to waffle) has greater priority than
mesa-demos so I'm not sure when I'll have time to look into it.

Feel free to give it a go :)

-Emil

[1] wflinfo and gl_basic are working great, yet converting waffle's
tests to msvc is slightly painful :\
[2] https://github.com/evelikov/waffle

> --Ken