Implemented a new parser to expose state change of GPU's rendering.

Implemented a new parser to expose state change of GPU's rendering.

This new parser (fbmsg_parser) parses events that are from linux
system tracing. It shows the time spent on each state when
GPU is rendering. Specifically, it exposes more detail about how
frame buffers are flipped. This helps developers in GPU field
to understand and optimize GPU's efficiency more easily.

On the other hand, this parser serves as a fix to existing
exynos parser's incorrect parsing of exynos_flip. fbmsg_parser
recognizes a new system event and fixes exynos_flip's bug by
putting different frame buffer's info in different row.
Therefore, events from different frame buffers are seperated,
which effectively avoids exynos parser's bug.

BUG=381

[dsinclair, 2013-08-09 14:08:15]

Before digging into this, is there a reason why this isn't part of the existing
exynos_parser.js file?

It sounds like there are existing issues with exynos_parser, can those be fixed
along with adding support for the new exynos_fb_msg.

[nduca, 2013-08-09 21:35:54]

yeah this should be part of exynos or you should make it exynos_fb_parser or
something that indicates its relationship to the other parsers in the system

[kao, 2013-08-12 02:11:45]

On 2013/08/09 14:08:15, dsinclair wrote:
> Before digging into this, is there a reason why this isn't part of the
existing
> exynos_parser.js file?
> 
> It sounds like there are existing issues with exynos_parser, can those be
fixed
> along with adding support for the new exynos_fb_msg.

The reason I separate it out is that the same event can be used by other drivers
(e.g. Intel driver), instead of exynos only. Would it be better if I add it
respectively in exynos_parser and i915_parser rather than having an independent
parser? If so, I will merge them into existing parser.

The issues with exynos_parser (and probably i915_parser, though not verified) is
that the flip event for each frame buffer should be independent. In other words,
multiple opening events and closing events may overlap. But the current exynos
parser simply matches the closing event with the nearest opening event, thus
failing to visualize the correct sequence. Therefore, to fix the issue, I
suggest removing the current flip event handler in exynos_parser, and turn to
the new fb_msg event.

Now I have another problem. I cannot figure out how to turn on the new event by
default. Currently I manually set_event in terminal, but can you help me on how
to automatically turn it on when starting chrome://tracing? Thanks.

[kao, 2013-08-12 02:34:02]

On 2013/08/12 02:11:45, kao wrote:
> On 2013/08/09 14:08:15, dsinclair wrote:
> > Before digging into this, is there a reason why this isn't part of the
> existing
> > exynos_parser.js file?
> > 
> > It sounds like there are existing issues with exynos_parser, can those be
> fixed
> > along with adding support for the new exynos_fb_msg.
> 
> The reason I separate it out is that the same event can be used by other
drivers
> (e.g. Intel driver), instead of exynos only. Would it be better if I add it
> respectively in exynos_parser and i915_parser rather than having an
independent
> parser? If so, I will merge them into existing parser.
> 
> The issues with exynos_parser (and probably i915_parser, though not verified)
is
> that the flip event for each frame buffer should be independent. In other
words,
> multiple opening events and closing events may overlap. But the current exynos
> parser simply matches the closing event with the nearest opening event, thus
> failing to visualize the correct sequence. Therefore, to fix the issue, I
> suggest removing the current flip event handler in exynos_parser, and turn to
> the new fb_msg event.
> 
> Now I have another problem. I cannot figure out how to turn on the new event
by
> default. Currently I manually set_event in terminal, but can you help me on
how
> to automatically turn it on when starting chrome://tracing? Thanks.

Just another point to note. fbmsg_parser will not only shows the flip event, but
it is a more generalized event handler. It visualizes the state-change of the
driver as follows:
IDLE -> WAIT_KDS -> WAIT_APPLY -> WAIT_FLIP -> ONSCREEN -> ONSCREEN_WAIT_KDS
The logic of state-change resides in the kernel, and the parser simply changes
state whenever it receives a new fb_msg_event from kernel.

[dsinclair, 2013-08-13 14:08:08]

This lg from a JS perspective. I'd like to get someone more familiar with the
Linux perf importer code to take a look before committing.

[nduca, 2013-08-13 22:41:14]

lets get jmg to do final review

[kao1, 2013-08-26 07:14:18]

On 2013/08/13 22:41:14, nduca wrote:
> lets get jmg to do final review

Hi jmg,

Could you help review this? Thanks.

[nduca, 2013-08-29 01:42:28]

lgtm given delay.

[dsinclair, 2013-09-11 15:15:28]

Is this CL still valid? Should we get it committed?

[jcliang, 2013-09-11 19:53:19]

On 2013/09/11 15:15:28, dsinclair wrote:
> Is this CL still valid? Should we get it committed?

Yes it is still valid. kao@ didn't have the chance to commit this before his
internship ends. I'd like to have this committed.

[dsinclair, 2013-09-12 14:36:39]

On 2013/09/11 19:53:19, jcliang wrote:
> On 2013/09/11 15:15:28, dsinclair wrote:
> > Is this CL still valid? Should we get it committed?
> 
> Yes it is still valid. kao@ didn't have the chance to commit this before his
> internship ends. I'd like to have this committed.

Done. Committed: https://code.google.com/p/trace-viewer/source/detail?r=981