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

[Ilia Mirkin]

On Thu, Jul 2, 2015 at 11:57 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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?

The MESA_IR_DUMP_ALL=fd thing. You can't just have a single ID for the
TGSI/HW as it might change based on other states. By the time you get
it sufficiently robust, you might as well do the GL extension.

>
> 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.

What "name" would the driver supply here? And how would you link
things up together?

>
>
>> 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.

It should just be possible to dump the shader pre-opt and post-opt
(into a string or something). But yeah, I guess you don't want to have
to *always* do this.

  -ilia