I can't speak for anyone else, but a giant pile of vendored code that you're
expected to not update seems like a really bad idea to me.
On Fri, Feb 12, 2021, at 18:09, Rob Clark wrote:
> I'm not really sure that is a fair statement.. the work scales
> according to the API change (which I'm not really sure if it changes
> much other than adding things).. if the API doesn't change, it is not
> really any effort to update two files in mesa git.
>
> As far as bug fixes.. it is a lot of code, but seems like the largest
> part of it is just generated protobuf serialization/deserialization
> code, rather than anything interesting.
>
> And again, I'm not a fan of their approach of "just vendor it".. but
> it is how perfetto is intended to be used, and in this case it seems
> like the best approach, since it is a situation where the protocol is
> the point of abi stability.
>
> BR,
> -R
>
> On Fri, Feb 12, 2021 at 5:51 PM Dylan Baker <dy...@pnwbakers.com> wrote:
> >
> > So, we're vendoring something that we know getting bug fixes for will be an
> > enormous pile of work? That sounds like a really bad idea.
> >
> > On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote:
> > > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker <dy...@pnwbakers.com> wrote:
> > > >
> > > >
> > > >
> > > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote:
> > > > > On Thu, Feb 11, 2021 at 5:40 PM John Bates <jba...@chromium.org>
> > > > > wrote:
> > > > > >
> > > > >
> > > > > <snip>
> > > > >
> > > > > > 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.
> > > > >
> > > > > IMHO, that size is negligible.. looking at freedreno, a mesa build
> > > > > *only* enabling freedreno is already ~6MB.. distros typically use
> > > > > "megadriver" (ie. all the drivers linked into a single .so with hard
> > > > > links for the different ${driver}_dri.so), which on my fedora laptop
> > > > > is ~21M. Maybe if anything is relevant it is how much of that
> > > > > actually gets paged into RAM from disk, but I think 500K isn't a thing
> > > > > to worry about too much.
> > > > >
> > > > > > 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.
> > > > >
> > > > > Mesa already tends to have plenty of threads.. some of that depends on
> > > > > the driver, I think currently radeonsi is the threading king, but
> > > > > there are several other drivers working on threaded_context and async
> > > > > compile thread pool.
> > > > >
> > > > > It is worth mentioning that, AFAIU, perfetto can operate in
> > > > > self-server mode, which seems like it would be useful for distros
> > > > > which do not have the system daemon. I'm not sure if we lose that
> > > > > with percetto?
> > > > >
> > > > > > 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.
> > > > >
> > > > > So, C++ on it's own isn't a showstopper, mesa has plenty of C++ code.
> > > > > But maybe we should verify that MSVC is happy with it, otherwise we
> > > > > need to take a bit more care in some parts of the codebase.
> > > > >
> > > > > As far as compile time, I wonder if we can regenerate the .cc/.h with
> > > > > only the gpu trace parts? But I wouldn't expect the .h to be
> > > > > something widely included. For example, for gpu timeline traces in
> > > > > freedreno, I'm expecting it to look like a freedreno_perfetto.cc with
> > > > > extern "C" {} around the callbacks that would hook into the
> > > > > u_tracepoint tracepoints. That one file would pull in the perfetto
> > > > > .h, and we'd just not build that file if perfetto was disabled.
> > > > >
> > > > > Overall having to add our own extern C wrappers in some places doesn't
> > > > > seem like the *end* of the world.. a bit annoying, but we might end up
> > > > > doing that regardless if other folks want the ability to hook in
> > > > > something other than perfetto?
> > > > >
> > > > > <snip>
> > > > >
> > > > > > Mesa Integration Alternatives
> > > > >
> > > > > I'm kind of leaning towards the "just slurp in the .cc/.h" approach..
> > > > > that is mostly because I expect to initially just add some basic gpu
> > > > > timeline tracepoints, but over time iterate on adding more.. it would
> > > > > be nice to not have to depend on a newer version of an external
> > > > > library at each step. That is ofc only my $0.02..
> > > > >
> > > > > BR,
> > > > > -R
> > > > > _______________________________________________
> > > > > mesa-dev mailing list
> > > > > mesa-dev@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > > > >
> > > >
> > > >
> > > > My experience is that vendoring just ends up being a huge pain for
> > > > everyone, especially if the ui code stops working with our forked
> > > > version, and we have to rebase all of our changes on upstream.
> > > >
> > > > Could we add meson build files and use a wrap for this if the distro
> > > > doesn't ship the library? Id be willing to do/help with an initial port
> > > > if that's what we wanted to do. But since this really a dev dependency
> > > > i don't see why using a wrap would be a big deal.
> > >
> > > I'm not a super huge fan of the perfetto approach of "just import the
> > > library", but at the end of the day the point of ABI compatibility is
> > > the protocol, not the API.. so it is actually safer to import the
> > > library into mesa's git tree
> > >
> > > BR,
> > > -R
> > >
> >
> > --
> > Dylan Baker
> > dy...@pnwbakers.com
>
--
Dylan Baker
dy...@pnwbakers.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
