On 12/07/15 01:49, Ilia Mirkin wrote:
On Thu, Jul 2, 2015 at 4:54 PM, Jose Fonseca <jfons...@vmware.com> wrote:
On 02/07/15 19:45, Ilia Mirkin wrote:
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.
Program object might not exist (e.g. when debugging fixed-function).
And the concept of program object looses meaning in the downstream layers
(e.g inside gallium pipe drivers, where TGSI can come from all sort of
utility modules and not just GLSL).
I have little doubts: for this to be feasible, it's imperative this applies
to the immediately validated state. Our stack has too many layer to do
anything else: it would be complex and buggy.
Jose
Jose,
Were you planning on working on something like this? I could _really_
use it for some bugs I'm tracking down (and failing thus far),
unfortunately the shaders are unreadable and get compiled very far
away from time of use, which makes it harder to track.
No, I'm afraid I don't have the time myself. It's not directly useful
to anything I'm working on at the moment. My goal was only to help come
up with good design for this, so that if/when somebody couldn't resist
the urge to scratch this itch, there was a tentative design/plan in
place already.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
