[Mesa-dev] [RFC demos] a mesa equivalent to vulkaninfo

[Alejandro Piñeiro]

Hi,

some weeks ago Dave Airlie made the review for the
ARB_internalformat_query2 extension support (again, thanks a lot), and
at the end he suggested to create a "mesa-demos glxinfo super query app.
Something that does what vulkaninfo kinda does" [1]. As I mentioned at
the moment, I had a heavily modified piglit test that was doing
something similar when working on the extension. So after some cleaning
I have a standalone version of that program. But before start to work to
integrate it with mesa demos, and propose it to the list as a patch, I
have some doubts, and I hope someone is interested in answering me:

 * Formatting: right now I decided to format the outcome as csv. So
something like this:

64 bit, GL_SAMPLES, GL_RENDERBUFFER, GL_DEPTH_COMPONENT, "8,4"
64 bit, GL_SAMPLES, GL_RENDERBUFFER, GL_DEPTH_STENCIL, "8,4"
64 bit, GL_SAMPLES, GL_RENDERBUFFER, GL_RED, "8,4"
64 bit, GL_SAMPLES, GL_RENDERBUFFER, GL_RG, "8,4"

The value between quotes, because the number of possible values is
variable (although right now only SAMPLES can return more that one value).

The reason is that with so many possible target/internalformat/pname
combinations, there isn't a simple way to fit it on a table. I also
tried to not repeat the information on any line, but then you need to go
back and forth to know what you are seeing. I assume that this format is
good enough to dump the outcome to a file if you want to check something
in particular, and that any kind of pretty-print is out of the scope of
this little demo. I also guess that csv would be good enough if someone
wants to implement that pretty-printer as a something external.

In any case I'm open to any other kind of formatting.

* Getting the gl enum name: ok, now the hack. In order to get the name
for all the gl enums I just copied a method from
piglit-util-gl-enum-gen.c. That is a generated file. The correct thing
would be do as piglit, and generate that source file from the khronos
xml. But that sounded like an overkill to me. Additionally that khronos
xml is like 2.5M. vulkaninfo try to do some define/# magic, but I don't
think that the solution would be better for this case [2], where we have
more enums to take into account.

* For the initialization I used glut and glew, instead of something more
low-level like glxinfo. There are already several mesa-demos using both,
so I assumed that it would not be any problem to do the same here.

* Right now the name is query2-info. It is not really impressive, but I
can't think on anything better. Suggestion are welcome.

If someone wants to take a look to the standalone program, you can find
it here [3].

Thanks in advance.

BR

[1] https://lists.freedesktop.org/archives/mesa-dev/2016-March/108954.html
[2]
https://github.com/LunarG/VulkanTools/blob/master/demos/vulkaninfo.c#L204
[3] https://github.com/infapi00/query2-info