[Mesa-dev] Extension to get Mesa IRs (Was: [Bug 91173])

[Jose Fonseca]

On 02/07/15 16:34, Ilia Mirkin wrote:
> On Thu, Jul 2, 2015 at 1:55 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 01/07/15 22:30, bugzilla-daemon at freedesktop.org wrote:> *Comment # 14
>> <https://bugs.freedesktop.org/show_bug.cgi?id=91173#c14>
>>> on bug 91173 <https://bugs.freedesktop.org/show_bug.cgi?id=91173> from
>>> Ilia Mirkin <mailto:imirkin at alum.mit.edu> *
>>>
>>> Erm... ok...
>>>
>>> MOV R0.zw, c[A0.x + 9];
>>> MOV R1.x, c[0].w;
>>> ADD R0.x, c[A0.x + 9].y, R1;
>>> FLR R0.y, R0.x;
>>>
>>> vs
>>>
>>>     0: MAD TEMP[0].xy, IN[1], CONST[7].yyyy, CONST[7].xxxx
>>>     3: MOV TEMP[0].zw, CONST[ADDR[0].x+9]
>>>     7: FLR TEMP[0].y, CONST[0].wwww
>>>
>>> Could be that I'm matching the wrong shaders. But this seems highly
>>> suspect.
>>> Need to see if there's a good way of dumping mesa ir... I wonder if it
>>> doesn't
>>> notice the write-mask on the MOV R0.zw and thinks that R0 contains the
>>> value it
>>> wants.
>>
>> Nice detective work on this bug, Ilia.
>>
>>> Could be that I'm matching the wrong shaders.
>>
>> I think it could be quite useful if there was a
>> "GL_MESAX_get_internal_representation" Mesa specific extension to extract a
>> text representation of the current bound GLSL, TGSI, hardware speicfic, etc,
>> exclusively for debugging purposes.
>>
>> It doesn't even need to be advertised on non-debug builds of Mesa.  But
>> merely being able to see next to each other all the IRs at a given call in a
>> trace, will probably save some time / grief for us developers on similar
>> situations.
>>
>>
>> I did something akin to this for NVIDIA prioprietary drivers on
>> https://github.com/apitrace/apitrace/commit/49192a4e48d080e44a0d66f059e6897f07cf67f8
>> but I don't think GetProgramBinary is apropriate for Mesa (only one format.)
>>
>>
>> Instead, for Mesa we could have something like
>>
>>     GLint n;
>>     // this will trigget IRs being collected into an array internally
>>     glGetIntegerv(GL_NUM_ACTIVE_IRS, &n);
>>
>>     for (i=0; i < n; ++i) {
>>         GLint nameLength;
>>         char *name;
>>         GLint sourceLength;
>>         char *source;
>>         glGetActiveInternalRepr(&nameLength, NULL, &sourceLength, NULL);
>>         name = malloc(nameLength)
>>         source = malloc(sourceLength)
>>         glGetActiveInternalRepr(NULL, name, NULL, source);
>>     }
>>
>> And this would need to be plumbed through all the way inside the drivers,
>> each layer would  advertise additional IRs.
>>
>> And the information here would only be obtainable/valid immediately after a
>> draw call.
>>
>>
>> A completely different tack, is that apitrace's glretrace would advertise an
>> unique environment variable (e.g,MESA_IR_DUMP_ALL=fd), and all
>> drivers/layers would write shaders repres, and when they are
>> bound/unbound/destroyed on  a preestablished format:
>>
>> CREATE "GLSL/123"
>> ...
>> EOF
>>
>> CREATE TGSI/456
>> EOF
>>
>> BIND GLSL/123
>> BIND TGSI/456
>> BIND HW/789
>>
>> UNBIND GLSL/123
>> UNBIND TGSI/456
>> UNBIND HW/789
>>
>> DESTROY GLSL/123
>> DESTROY TGSI/456
>> DESTROY HW/789
>>
>>
>> I don't feel strongly either way, but I suspect that having a proper
>> extension, even if a little more work at start, will be more robust on the
>> long term.  And less runtime overhead.  GL extensions also give a mechanism
>> to revise/deprecate this functionality in the future.
>
> This would still require fairly extensive changes as you'd have to
> track all the bindings together.

Really? I don't think so.  Which alternative are you referring to?

Yet another option would be to provide a callback

   typedef void (*GLircallbackMESA)(const char *name, const char *body);

   void glGetActiveInternalReprMesa(GLircallbackMESA callback);

and basically each layer would dump the IRs, and invoke the downstream 
layers with the same callback.


> Anyways, *something* would be fantastic. It's also incredibly
> difficult to tell what shader is being used for a particular draw...
> I've resorted to taking mmt traces of nouveau to see what it's
> actually drawing with. Sometimes qapitrace doesn't show a shader,
> sometimes it's a fixed function shader, etc. Note that among other
> things, this has to account for any shader keys that might exist at
> any of the levels. And since bugs are often in optimization passes,
> being able to see both pre- and post-opt shaders would be *really*
> nice.


That's doable. Each layer just needs to keep the intermediate versions 
around.  We could have glretrace invoke a 
glEnable(GL_KEEP_ALL_IR_MESAX), so that the driver would have not have 
to do this all the time.


Jose