[PATCH] weston: Add weston rendering performance log

[Pekka Paalanen]

On Fri,  6 Feb 2015 17:52:06 +0800
Quanxian Wang <quanxian.wang at intel.com> wrote:

> With PERF_DEBUG is enabled, the performance log will be recorded
> for every key rendering path.
> 
> At the same time, with a tool provided, performance chart of weston apps
> could be generated.
> 
> This patch provides following changes.
> 1) Add performance log mechanism for server and client.
>    just like weston_log, weston_plog is used for performance log.
> 2) Touch performance log is added to monitor touch performance.
> 3) Some weston native apps performance logs are added.
>    For example weston-simple-egl, weston-terminal
> 
> Performance Anaylis Tools source code is located:
> https://github.com/quanxianwang/wr-graph.git
> 
> Related tools wiki:
> https://wiki.tizen.org/wiki/Wayland_Rendering_Analysis_Tool
> 
> Signed-Off-By Quanxian Wang <quanxian.wang at intel.com>
> Signed-Off-By Xiaoyanx Zhang <xiaoyanx.zhang at intel.com>
> ---
>  clients/perf_log_client.h | 51 ++++++++++++++++++++++++++++++++++++++++++++++
>  clients/simple-egl.c      |  6 ++++++
>  clients/window.c          |  5 +++++
>  desktop-shell/shell.c     | 12 ++++++++---
>  desktop-shell/shell.h     |  1 -
>  src/compositor.c          |  8 ++++++++
>  src/input.c               | 52 +++++++++++++++++++++++++++++++++++++++++++----
>  src/log.c                 | 23 ++++++++++++++++++++-
>  src/perf_log_server.h     | 38 ++++++++++++++++++++++++++++++++++
>  9 files changed, 187 insertions(+), 9 deletions(-)
>  create mode 100644 clients/perf_log_client.h
>  create mode 100644 src/perf_log_server.h

Hi,

like I explained in my earlier reply to you, Weston upstream already
has an ad hoc printf-based tracing infrastructure: JSON-timeline. I
don't think we want another one.

As I see, your proposal has the following advantages compared to what's
already in upstream:
- printf-logging in selected clients
- compositor peroformance events from input paths
- interval tracing with explicit start/end events
- a graphing tool with several kinds of high-level views

However, what upstream does better, IMO:
- recording identifying information about the surface, client, and
  output (protocol object ids are connection specific, not global)
- runtime enable/disable, not just on start-up
- JSON output format

Using the environment variable PERF_DEBUG and using the "perf"
namespace might conflict with the 'perf' tools and infrastructure - is
this intentional?

To get the best of both your and upstream approaches, would it be
possible for you to migrate to JSON-timeline?

You can add new events and recordable object types, so you can cover
also input paths. Interval tracing is possible with a simple change in
naming conventions that replaces your BEGIN/END flags.

Would it be hard to modify your graphing tool to consume JSON-timeline
data?

Logging in client processes is something you would need to keep as we
don't have a way to do that upstream and combine it with JSON-timeline
logs. Requiring modified client programs for tracing is bit a nuisance,
since you might not want that in production.

I think we should aim for a tracing infrastructure we can always build
in, and enable at runtime when needed, even in production environments.

Of course, this whole ad hoc printf logging is just a stop-gap measure.
What we would really like is something that integrates well with a
global performance and tracing infrastruture like 'perf'. Using perf to
gather performance data from the whole system at once, including the
kernel, kernel drivers, GPU actions, gfx buffer events, display server,
applications, everything; should be the ultimate goal.

What do you think?


Thanks,
pq