On Fri, 8 Nov 2019 09:50:30 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote: > > Is it ok to build userspace to rely on these trace events during normal > > operations, e.g. for continuous adjustment of timings/timers? > > Aside discussion on this: If we add this (I think userspace might want > some information about the point of no return and why we missed it) then I > think we should expose that with an improved drm_event and clear > semantics. > > If we start to encourage compositors to use tracepoints to figure out why > the kernel doesn't behave (TEST_ONLY failure, or missed flip target), and > use that for behaviour, we've baked implementation details into the uapi. > And then we're screwed. > > So if you have any need for timing information that you see solved with a > tracepoint, pls bring this up so we can add proper uapi. And yes I know > that if someone doesn't we still need to keep that tracepoint working, but > with all things uapi the question isn't whether we'll screw up (we will), > but how often. And less often is massively better :-) Haha, sorry, that particular question was practically trolling, but OTOH something I can well imagine someone doing. Trying to fish out reasons for TEST_ONLY failing is a much better example. On third hand, profiling tools probably would depend on some trace points specifically. As for the uapi for a DRM flight recorder, I'd be happy to have that in Weston as my time permits. Alas, it needs two people and I can be only one: either the reviewer or the author. :-) I can see two ways to use a DRM flight recorder: - a file you grab as a whole after the fact, or - a stream you subscribe to and store the results in your own ring buffer The former is simpler, the latter would allow interleaving DRM and app notes as they happen rather than trying to rebuild a log from timestamps afterwards. Thanks, pq
Attachment:
pgpKG8p_sizmG.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
