[PATCH v2] Backtrace for android and linux
José Fonseca
jose.r.fonseca at gmail.com
Fri Apr 12 07:56:54 PDT 2013
On Fri, Apr 12, 2013 at 2:20 PM, Alexander Monakov <amonakov at ispras.ru>
wrote:
>
>
> On Fri, 12 Apr 2013, José Fonseca wrote:
>
>> Please provide sample output of apitrace dump with your patch so I can
>> better image what you're arguing for.
>
> See below (thanks Eugene).
Thanks. It helps.
This definitely should be a call detail, not a generic event. Because each
stack trace is paired with call, and is not an independent or asynchronous
event -- otherwise what guarantee do you have that another thread doesn't
emit a glFakeBacktraceFunction between your glFakeBacktraceFunction and the
next. How would you handle if a function internally calls another traced
function? All sort of problems.
I doubt that dvmDumpThreadStack() output will be consistent in future
releases. So I really think that it should be parsed in to an arrays of
(symbol, filename, lineno) tripplets, so we can be future proof.
>> No. If we need generic events, fine, but these generic events should
>> be distinct from call-enter/leave events in the trace file grammar.
>
> Fair enough, but what is the way forward then?
In order for me to accept this I must require that the trace gramar is
extended as I described before, and that the stack traces adheres to it.
> It appears that this patch and
> the patches for CPU+GPU timing are blocked now.
I haven't seen any recent CPU+GPU timing patches. The CPU timings should
also be call details. The GPU timings, as you described, should be
asynchronous events. If you want to propose a generic event type that can
be used not only for GPU timing, but other asynchronous call-related info
(e.g., CALL_ASYNC), that's fine.
CALL_ENTER 1234
CPU_TIMESTAMP
STACK_FRAME
FRAME
SYMBOL
"
Foo
"
FILENAME
"foo.cpp"
LINE_NO 1234
FRAME
SYMBOL
"
Boo
"
// no filename line info available for this frame
ARG 0
...
ARG 1
...
END
CALL_LEAVE 1234
CPU_TIMESTAMP
RET
...
END
CALL_A
S
YNC
1234
GPU_START
...
GPU_
LENGTH
...
END
The structure here is
EVENT
DETAIL
DETAIL
END
Each event implies holding a mutex for exclusive access for the
file
.
T
he trace parser / qapitrace will need to be updated to patch up the calls
with their GPU info when they saw the event.
Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20130412/5a14bb24/attachment-0001.html>
More information about the apitrace
mailing list