We're open source, tilting at windmills is what we do :D On Fri, Feb 12, 2021, at 18:49, Rob Clark wrote: > 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 >
-- Dylan Baker dy...@pnwbakers.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev