On 02/07/15 16:34, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 1:55 AM, Jose Fonseca <jfons...@vmware.com> wrote:
On 01/07/15 22:30, bugzilla-dae...@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:imir...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
