On Thu, Jul 2, 2015 at 2:31 PM, Jose Fonseca <jfons...@vmware.com> wrote: > On 02/07/15 17:49, Ilia Mirkin wrote: >> >> On Thu, Jul 2, 2015 at 12:40 PM, Jose Fonseca <jfons...@vmware.com> wrote: >>> >>> On 02/07/15 17:24, Ilia Mirkin wrote: >>>> >>>> >>>> On Thu, Jul 2, 2015 at 12:17 PM, Jose Fonseca <jfons...@vmware.com> >>>> wrote: > > >>>> Ah OK. So I guess tilers will have to disable their render queues for >>>> this one. Which seems like a reasonable trade-off... >>> >>> >>> >>> I don't see why. >>> >>> This is a purely SW query. So I don't see why the HW needs to see any >>> difference. >> >> >> It just won't have compiled the shaders, I think. I guess this could force >> it. > > > AFAIK, tiles defer the _rendering_, not the compilation. At least llvmpipe > compiles everything at draw time. > > >>> >>> That said, glretrace already does glReadPixels when dumping state, so one >>> way or the other, when inspecting state in qapitrace, everything will be >>> flushed and and synched. >> >> >> But that's too late -- you said the glGetActiveBla would go right >> after the draw call. Presumably if you did it right after glReadPixels >> it'd end up seeing the state left over from a blit or something? > > > Fair enough. It's the first thing after glDraw. Forget about glReadpixels. > > I guess just still don't understand what's special about tilers. But I > don't think it's pertinent now.
What's special about tilers is that they defer renders. Compiling the program can similarly get deferred because they can. (And sometimes entire renders get dropped due to clears, etc.) Should it get deferred? Dunno. I don't even remember if freedreno defers compilation, and never knew what vc4 did. > >> >> Perhaps the API should instead be >> >> glEnable(GL_PROGRAM_SAVE_DUMP) >> glProgramDumpDebugInfo(progid, callback) >> >> which would then optionally dump any info associated with that >> program. That way it doesn't even have to be internally active (due to >> a subsequent blit or who-knows-what). But it would rely on that >> program having been previously-drawn-with which would have generated >> the relevant data. > > > > Doing this immediately after draw call is no problem at all. I don't think > it's worth complicating things by allowing a lag between draw and shader > extraction. It just makes things more unreliable which defeats the point. Would it really complicate things though? Internally, it can never drop the debug info since a program might later be reused wholesale and there won't be another compilation, so it has to store the info on the program object. The additionally nice thing is that apitrace would know which program which debug info belongs to, rather than just having it all be part of a single "linked" thing. Obviously some code in one might affect the other (like clipping getting moved to fs, etc) but on average it might be nice to keep them separate. One counterpoint is that an driver for hw that has a different programming model wouldn't work as well. For example how would intel dump the programmable clipper code for gen4/5? Or something like PVR which I understand is totally crazy? That makes more the argument for an "all in one" type of thing. I guess I don't feel too strongly about it either way though. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
