15:32 <kusma> olv: Seems perfetto + g52 + CI = spam :( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32360?commit_id=576a87a5904765ef3cfd41f9d780d3cf026f15fc#note_2708632

15:37 <CounterPillow> Might get better with a mesa_logw_once if it's multiple times per process

15:41 <CounterPillow> But if I'm allowed to opine from my armchair, it seems weird this init function just returns with no way to communicate an error higher up other than by spamming the log. Like someone saw that this error isn't serious enough to let caller know about it but apparently the user/CI should

15:42 <daniels> logw_once will still spam CI pretty hard

15:45 <kusma> I wonder if... a) if this should've been skipped for g52, the MR seems to talk about v10... and b) we should do this without some sort of opt-in regardless.

15:46 <kusma> I mean, if nobody asked for perfetto to be used, it seems strange to complain about it failing to initialize

15:46 <CounterPillow> If modifying the function call signature is allowed then a negative error code return value and letting the caller decide what to do instead of logging would also benefit all the other unsuccessful exit paths in that function

15:55 <olv> It is fine to delete the warning and fail silently

15:56 <olv> Can you help with an MR to do that?

15:58 <kusma> But why are we doing this unconditionally at all? 99.9% of the time, I don't care about perfetto, and I want to spend zero nanoseconds on dealing with it...

16:27 <olv> Then you don't enable perfetto?

16:28 <kusma> panvk_utrace_perfetto_init() is called unconditionally

16:29 <olv> The file is not compiled if pefetto is disabled

16:29 <kusma> I think it should be opt-in, not opt-out. And at run-time.

16:30 <kusma> *having* perfetto and *using* perfetto shouldn't be the same thing IMO.

16:32 <kusma> Oh, I see. It *is* opt-in, but only in the build-system.

16:32 <kusma> I think it would be useful to be able to build using it, but not use it unless it's actually needed.

16:33 <kusma> I think then I disagree with CI that we should build with perfetto on in the normal build, but :shrug:

16:33 <daniels> mostly for coverage, so it doesn't silently break

16:34 <kusma> Sure, that's why I said "normal build" :P

16:34 <kusma> We have a few other builds that aren't the one we use when running tests etc.

16:35 <daniels> sure, feel free to push it over there if you feel strongly about it

16:35 <kusma> I don't just wondering why it's the way it is, but I guess the answer is "because that's how it ended up" or something :P

16:36 <kusma> missed a comma, but I'm sure you can figure out what I meant.

16:36 <daniels> yeah, I don't know of anyone who's ever deliberately ensured that perfetto was enabled in every single build

16:37 <daniels> or anyone else who even really has opinions about it tbh :P

16:37 <kusma> I think we have some opinions on tests taking as little time as possible, so it might be worth it, perfetto isn't small.

16:39 <kusma> I don't *really* care if someone had to opt in to perfetto and then gets warnings on g52. I do care about CI being without needless noise. So perhaps just moving it over to another build is the right fix here (for now).

16:44 <daniels> well yeah, no matter what happens it shouldn't spam out noise for expected conditions

16:44 <kusma> Fair enough.

16:45 <daniels> so like olv said, probably just nuke the warning entirely, and then move perfetto over if you want to make the build also go quicker?

16:45 <kusma> picture-of-a-thumb-up

16:45 <kusma> .jpg

17:04 <olv> sorry I was driving. I can do the MR (to nuke the warning) if you haven't started yet.

17:05 <kusma> I haven't started yet, and I don't have time until tomorrow. So feel free to look at it, and if you don't get around to it, I can deal with it tomorrow.