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

[Emil Velikov]

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

>
> Thanks,
> pq
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev