A lot of code, which like I said is mostly just generated ser/deser
and not very interesting.. and 90% of it we won't use (unless mesa
becomes a wifi driver, and more or less the rest of an OS). And if
there is a need to update it, we update it.. it's two files. But *if*
there are any API changes, we can deal with that in the same commit.
I'm not saying it is great.. just that it is least bad.
I completely understand the argument against vendoring.. and I also
completely understand the argument against tilting at windmills ;-)
BR,
-R
On Fri, Feb 12, 2021 at 6:15 PM Dylan Baker <dy...@pnwbakers.com> wrote:
>
> 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
