[Mesa-dev] Perfetto CPU/GPU tracing

[John Bates]

I recently opened issue 4262
 to begin the
discussion on integrating perfetto into mesa.

*Background*

System-wide tracing is an invaluable tool for developers to find and fix
performance problems. The perfetto project enables a combined view of trace
data from kernel ftrace, GPU driver and various manually-instrumented
tracepoints throughout the application and system. This helps developers
quickly answer questions like:

   - How long are frames taking?
   - What caused a particular frame drop?
   - Is it CPU bound or GPU bound?
   - Did a CPU core frequency drop cause something to go slower than usual?
   - Is something else running that is stealing CPU or GPU time? Could I
   fix that with better thread/context priorities?
   - Are all CPU cores being used effectively? Do I need sched_setaffinity
   to keep my thread on a big or little core?
   - What’s the latency between CPU frame submit and GPU start?

*What Does Mesa + Perfetto Provide?*

Mesa is in a unique position to produce GPU trace data for several GPU
vendors without requiring the developer to build and install additional
tools like gfx-pps .

The key is making it easy for developers to use. Ideally, perfetto is
eventually available by default in mesa so that if your system has perfetto
traced running, you just need to run perfetto (perhaps along with setting
an environment variable) with the mesa categories to see:

   - GPU processing timeline events.
   - GPU counters.
   - CPU events for potentially slow functions in mesa like shader compiles.

Example of what this data might look like (with fake GPU events):
[image: percetto-gpu-example.png]

*Runtime Characteristics*

   - ~500KB additional binary size. Even with using only the basic features
   of perfetto, it will increase the binary size of mesa by about 500KB.
   - Background thread. Perfetto uses a background thread for communication
   with the system tracing daemon (traced) to advertise trace data and get
   notification of trace start/stop.
   - Runtime overhead when disabled is designed to be optimal with one
   predicted branch, typically a few CPU cycles
    per
   event. While enabled, the overhead can be around 1 us per event.

*Integration Challenges*

   - The perfetto SDK is C++ and designed around macros, lambdas, inline
   templates, etc. There are ongoing discussions on providing an official
   perfetto C API, but it is not yet clear when this will land on the perfetto
   roadmap.
   - The perfetto SDK is an amalgamated .h and .cc that adds up to 100K
   lines of code.
   - Anything that includes perfetto.h takes a long time to compile.
   - The current Perfetto SDK design is incompatible with being a shared
   library behind a C API.

*Percetto*

The percetto library  was recently
implemented to provide an interim C API for perfetto. It provides efficient
support for scoped trace events, multiple categories, counters, custom
timestamps, and debug data annotations. Percetto also provides some
features that are important to mesa, but not available yet with perfetto
SDK:

   - Trace events from multiple perfetto instances in separate shared
   libraries (like mesa and virglrenderer) show correctly in a single process
   and thread view.
   - Counter tracks and macro API.

Percetto is missing API for perfetto's GPU DataSource and counter support,
but that feature could be implemented next if it is important for mesa.
With the existing percetto API mesa could present GPU trace data as named
'slice' events and int64_t counters with custom timestamps as shown in the
image above (based on this sample
).

*Mesa Integration Alternatives*

Note: we have some pressing needs for performance analysis in Chrome OS, so
I'm intentionally leaving out the alternative of waiting for an official
perfetto C API. Of course, once that C API is available it would become an
option to migrate to it from any of the alternatives below.

Ordered by difficulty with easiest first:

   1. Statically link with percetto as an optional external dependency
(virglrenderer
   now has this approach
   
   ).
   - Pros: API already supports most common tracing needs. Tested and used
  by an increasing number of CrOS components.
  - Cons: External dependency for optional mesa build option.
   2. Embed Perfetto SDK + a Percetto fork/copy.
  - Pros: API already supports most common tracing needs. No added
  external dependency for mesa.
  - Cons: Percetto code divergence, bug fixes need to land in two trees.
   3. Embed Perfetto SDK + custom C wrapper.
  - Pros: Tailored API for mesa's needs.
  - Cons: Nontrivial development efforts and 

[Mesa-dev] 2021 X.Org Foundation Membership renewal and election schedule

[Harry Wentland]

The 2021 X.Org Foundation elections are rapidly approaching. In 
preparation of the elections we would like to remind you that members 
will need to renew their membership each year in order to vote. Please 
take the time to renew your membership by logging into 
https://members.x.org and clicking on the "Apply" button to apply for 
the 2021-2022 membership.


We would also like to encourage you to start considering yourself or 
someone else for nomination to the board. We will send another email to 
start the official nomination period when it opens.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] should we do GSoC 2021?

[Omar Emara]

Hi Trevor,

I see. That's unfortunate. Thanks for letting me know!

In any case, I will try to contribute to mesa independently and
hopefully become part of the community.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] lavapipe vulkan driver win32 port: call for help

[Jason Ekstrand]

Drive-by comment:  I'm afraid getting window-system stuff working
isn't "the last push".  It's probably 50-80% of the project.  I have
no idea how any of this works for LLVMpipe; maybe we can steal some
code from there?  In any case, you're unlikely to find a lot of win32
experts here.

--Jason

On Thu, Feb 11, 2021 at 3:09 AM Michel Zou  wrote:
>
> hello,
>
> I started to work on the software vulkan driver (lavapipe) win32 port:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7208
> up to the point it builds and "runs" but nothing is displayed with the vkcube 
> example (from Vulkan-Tools).
> It is probably an issue with the buffer not being properly copied or 
> something (I'm not really good with these windows apis)
>
> I dont know if I'll have time to work on it anymore.
> I'm looking for someone willing to help to give it the last push.
>
> Just in case, here is how to enable it:
> meson build -Dgallium-drivers=swrast -Dvulkan-drivers=swrast
> So far I only used mingw, not msvc.
>
>
>
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] lavapipe vulkan driver win32 port: call for help

[Michel Zou]

hello,

I started to work on the software vulkan driver (lavapipe) win32 port:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7208
up to the point it builds and "runs" but nothing is displayed with the vkcube 
example (from Vulkan-Tools).
It is probably an issue with the buffer not being properly copied or something 
(I'm not really good with these windows apis)

I dont know if I'll have time to work on it anymore.
I'm looking for someone willing to help to give it the last push.

Just in case, here is how to enable it:
meson build -Dgallium-drivers=swrast -Dvulkan-drivers=swrast
So far I only used mingw, not msvc.






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev