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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
