On 7 July 2014 00:22, Kenneth Graunke <kenn...@whitecape.org> wrote: > On Saturday, July 05, 2014 01:04:02 PM Emil Velikov wrote: >> On 5 July 2014 08:53, Pekka Paalanen <ppaala...@gmail.com> wrote: >> > On Fri, 04 Jul 2014 08:45:00 +0100 >> > Steven Newbury <st...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
