[waffle] [PATCH v2 1/4] waffle utils: add wflinfo utility
Chad Versace
chad.versace at linux.intel.com
Wed Jan 8 18:03:03 PST 2014
On Tue, Jan 07, 2014 at 03:12:14PM -0800, Jordan Justen wrote:
> On Mon, Jan 6, 2014 at 10:00 AM, Chad Versace
> <chad.versace at linux.intel.com> wrote:
> > On Mon, Dec 23, 2013 at 09:48:33PM -0800, Jordan Justen wrote:
> >> +static void
> >> +print_extensions(bool use_stringi)
> >> +{
> >> + GLint count = 0, i;
> >> + const char *ext;
> >> +
> >> + printf("OpenGL extensions: ");
> >> + if (use_stringi) {
> >> + glGetIntegerv(GL_NUM_EXTENSIONS, &count);
> >> + if (glGetError() != GL_NO_ERROR) {
> >> + printf("GL ERROR");
> >
> > The space in "GL ERROR" could confuse applications that parse wflinfo's
> > output, because extension names do not contain spaces. Let's instead
> > print "GL_ERROR".
>
> I was concerned about using GL_ERROR since it looks like something
> that could be part of GL.
>
> How about WFLINFO_GL_ERROR?
WFLINFO_GL_ERROR sounds good to me. That's non-ambiguous.
> >> + if (opts->verbose)
> >> + print_extensions(need_getstringi);
> >
> > Hmm... I believe that wflinfo should print extensions by default.
> > Usually, a verbose flag enables printing non-essential info, but
> > extensions are not non-essential. Extensions comprise critical
> > information about the context, perhaps just as significant as the
> > context version.
> >
> > Why did you choose to print the extensions only with verbose? Let's
> > discuss it at the office.
>
> I would say that 95% of the time I run glxinfo, I just want to see the
> OpenGL version string. But, 100% of the time, I have to pipe it to
> less or grep to pick that out.
>
> Although, the second most often thing I look for is the extensions
> list, it still is reasonably rare, and quite verbose.
I see the source of our disagreement. Nearly every time I have ran
glxinfo or es2_info, my main interest was the extension string.
However, I concede to you here. If wflinfo iterates over all platforms
and apis by default, then extension strings will clutter the output
making it significantly less readable.
> I think we should consider short parameters so:
> wflinfo --verbose --platform=glx --api=gl
> could be
> wflinfo -v -p glx -a gl
I think short options are a good idea.
> Although, even with that change, wflinfo has some parameter usability
> issues compared to glxinfo. :)
Yes, it definitely has some usability issues :)
I never intended the gl_basic example to be more than an example for
others who may want to target waffle, and as a sanity test of sorts.
Completeness was my goal in the command line parameters, not usability.
That sort of goal makes sense for a developer tool private to the
project.
But yeah, wflinfo should be easier to use since it's a user-facing
tool.
On this note, at face value the --debug option doesn't do what you
expect it to do: print debug info for wflinfo. To follow the principle
of least surprise, --debug should probably be renamed to
--debug-context, and --forward-compatible renamed to follow the same
pattern, --forward-compatible-context.
> I think Ken was not impressed on that front, and thought we should
> consider something that allows us to run wflinfo with little or no
> parameters.
>
> One thing I thought about is if we add output like this:
> Waffle platform & api: glx gl
>
> And, then we might consider trying multiple combinations, and the
> output could be mapped to a particular platform/api combination.
>
> Maybe if wflinfo is run without parameters, then it would try
> everything, and print out info for all combinations that work. (At
> that point, printing the extensions list by default for each context
> created would produce a lot of output.)
>
> If --platform is used without --api, then we could try all APIs on
> that platform, and vise-versa.
I'm in favor of the default value of --api and --platform becoming
'all', as long as we can define reasonable behavior in that case.
If we go down this route, then I think wflinfo should accept --api=all
and --platform=all on the cmdline. That would enable users to do
something like this, while requiring nearly no additional code in
wflinfo.
wflinfo -p wayland -a all
wflinfo -p all -a gles2
Now, I see three issues that need resolving before wflinfo's default
behavior is to iterate over api and platform:
1. Issue: For api=gl, over which version and profile should wflinfo iterate
by default?
Proposal: I'm open to alternative proposals, but I think what
glxinfo does is fairly sensible. It prints info on exactly one core
and one compatibility context. However, glxinfo has some
misunderstandings about when GLX_CONTEXT_CORE_PROFILE_BIT_ARB is
applicable and the subtle situation around GL 3.0 and 3.1; wflinfo
shouldn't reproduce that behavior.
Here's pseudo-code for my proposal:
// Of contexts that belong to the core profile or is 3.1 without
// GL_ARB_compatibility, print info on the context with the
// highest available version.
func print_core_info() {
var ctx
// Iterate over all versions for which
// GLX/EGL_CONTEXT_CORE_PROFILE_BIT is recognized.
for version in [4.4, 4.3, 4.2, 4.1, 4.0, 3.3, 3.2] {
ctx = create_context(version, profile=core)
if (ctx) {
print_ctx_info(ctx)
return
}
}
// We failed to create a context with the core profile. Let's
// check if 3.1 without GL_ARB_compatibility is available. If
// so, consider it a core context.
ctx = create_context(3.1, profile=none)
if (ctx and !context_has_extension("GL_ARB_compatibility")) {
print_ctx_info(ctx)
return
}
// No core context is supported.
return
}
// Of contexts that belong to the compatibility profile, lack
// a profile altogether, or is 3.1 with GL_ARB_compatibility,
// print info on the context with the highest available version.
func print_compat_info() {
var ctx
ctx = create_context(version=undefined, profile=none)
}
print_core_info()
print_compat_info()
2. Issue: What should be the output format when wflinfo prints info
about mutliple contexts?
Proposal:
I dilike glxinfo's use of an empty line as the block separator.
It's too easy to miss when visually scanning copious output.
I propose '----' as the block separator, but I don't really care
as long the chosen separator visually jumps out.
$ wflinfo -p x11_egl
Waffle platform: x11_egl
Waffle api: GL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL context flags: (none)
----
Waffle platform: x11_egl
Waffle api: GL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: 3.0 Mesa 9.2.0
----
Waffle platform: x11_egl
Waffle api: GLES1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: OpenGL ES 1.1 Mesa 9.2.0
----
Waffle platform: x11_egl
Waffle api: GLES2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: OpenGL ES 3.0 Mesa 9.2.0
----
Waffle platform: x11_egl
Waffle api: GLES3
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: OpenGL ES 3.0 Mesa 9.2.0
3. Issue: What approach should wflinfo use to iterate over multiple
EGL platforms? This is problematic because Mesa's libEGL segfaults
if the client attempts to use more than one platform in a single
process. It's an outstanding bug that must be fixed before Mesa can
support the EGL_EXT_platform extensions. The bug exists in
Mesa <= 9.2. It may still exist in 10.0, but I haven't tested it.
Proposal #1: When the user runs `wflinfo -p all`, it internally
does this:
int
main(int argc, char **argv) {
// The list of platforms here is controlled by an #ifdef.
for plat in ["glx", "x11_egl", "wayland", "gbm"] {
child_pid = fork()
if (child_pid < 0) {
raise_error();
} else if (child_pid == 0) {
// We want output from the subprocess only if it
// succeeds in initializing to the given platform.
// Otherwise, it should silently fail. To accomplish
// that, tell print_info if it's running in a slave
// process.
print_platform_info(slave_process=true, plat, other_args);
} else {
wait(child_pid);
}
}
}
This is the same pattern used by gl_basic_test.
The extra effort to support --platform=all and --api=all is non-trivial.
If you'd like to wrap up the patch series as-is, get it committed, and
add the other features as follow-up patches, I'm not opposed to that
plan. Or if you'd like to do it all in one patch series up front, that's
fine too.
-Chad
More information about the waffle
mailing list