On Thu, Jul 2, 2015 at 12:17 PM, Jose Fonseca <jfons...@vmware.com> wrote: > On 02/07/15 17:08, Ilia Mirkin wrote: >> >> On Thu, Jul 2, 2015 at 11:57 AM, Jose Fonseca <jfons...@vmware.com> wrote: >>> >>> 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? >> >> >> 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? > > > Giving llvmpipe example, which I'm more familiar, > > - src/mesa/state_tracKer would invoke with "state_tracker/tgsi/{vs,fs}" > and "glsl-ir/{vs,fs}" > - and invoke pipe_context::get_active_ir (callback) if the pipe driver > implements it > - src/gallium/drivers/llvmpipe would invoke with > - "llvmpipe/tgsi/{vs,fs}" (which might differ from the state tracker due > to draw module > - "llvmpipe/llvm/{vs,fs,setup}_{full,partial}" > - and maybe even "llvmpipe/x86/{vs,fs} > > The idea is that this glGetActiveInternalReprMesa() call dumps what's active > _now_, which is only makes sense immediately after draw calls. So the only > thing the drivers need to do is dump what they see bound.
Ah OK. So I guess tilers will have to disable their render queues for this one. Which seems like a reasonable trade-off... One issue is that this won't capture "internal" renders that happen on blit/drawpixels/readpixels/etc, but those are less interesting. Now I see what you meant about keeping the various IR's around for this one, that might be more painful. But they could easily dump strings into a buffer associated with that object. This seems pretty reasonable in principle. Of course more experienced GL people should probably take a look :) -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
