From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com> To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Intel GFX <intel-gfx@lists.freedesktop.org>, Maling list - DRI developers <dri-devel@lists.freedesktop.org>, Jason Ekstrand <jason@jlekstrand.net> Subject: Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy Date: Fri, 30 Apr 2021 16:23:57 -0700 [thread overview] Message-ID: <87bl9vbble.wl-ashutosh.dixit@intel.com> (raw) In-Reply-To: <87czubbco1.wl-ashutosh.dixit@intel.com> On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote: > > On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote: > > > > Looks like the engine can be dropped since all timestamps are in sync. I > > just have one more question here. The timestamp itself is 36 bits. Should > > the uapi also report the timestamp width to the user OR should I just > > return the lower 32 bits of the timestamp? > > How would exposing only the lower 32 bits of the timestamp work? It would work I guess but overflow every few seconds. So if the counters are sampled at a low frequency (once every few seconds) it would yield misleading timestamps. > The way to avoid exposing the width would be to expose the timestamp as a > regular 64 bit value. In the kernel engine state, have a variable for the > counter and keep on accumulating that (on each query) to full 64 bits in > spite of the 36 bit HW counter overflow. > > So not exposing the width (or exposing a 64 bit timestamp) is a cleaner > interface but also more work in the kernel. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com> To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Intel GFX <intel-gfx@lists.freedesktop.org>, Maling list - DRI developers <dri-devel@lists.freedesktop.org> Subject: Re: [Intel-gfx] [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy Date: Fri, 30 Apr 2021 16:23:57 -0700 [thread overview] Message-ID: <87bl9vbble.wl-ashutosh.dixit@intel.com> (raw) In-Reply-To: <87czubbco1.wl-ashutosh.dixit@intel.com> On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote: > > On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote: > > > > Looks like the engine can be dropped since all timestamps are in sync. I > > just have one more question here. The timestamp itself is 36 bits. Should > > the uapi also report the timestamp width to the user OR should I just > > return the lower 32 bits of the timestamp? > > How would exposing only the lower 32 bits of the timestamp work? It would work I guess but overflow every few seconds. So if the counters are sampled at a low frequency (once every few seconds) it would yield misleading timestamps. > The way to avoid exposing the width would be to expose the timestamp as a > regular 64 bit value. In the kernel engine state, have a variable for the > counter and keep on accumulating that (on each query) to full 64 bits in > spite of the 36 bit HW counter overflow. > > So not exposing the width (or exposing a 64 bit timestamp) is a cleaner > interface but also more work in the kernel. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-04-30 23:24 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-29 0:34 [PATCH 0/1] Add support for querying engine cycles Umesh Nerlige Ramappa 2021-04-29 0:34 ` [Intel-gfx] " Umesh Nerlige Ramappa 2021-04-29 0:34 ` [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy Umesh Nerlige Ramappa 2021-04-29 0:34 ` [Intel-gfx] " Umesh Nerlige Ramappa 2021-04-29 8:34 ` Lionel Landwerlin 2021-04-29 8:34 ` [Intel-gfx] " Lionel Landwerlin 2021-04-29 19:07 ` Jason Ekstrand 2021-04-29 19:07 ` [Intel-gfx] " Jason Ekstrand 2021-04-30 22:26 ` Umesh Nerlige Ramappa 2021-04-30 22:26 ` [Intel-gfx] " Umesh Nerlige Ramappa 2021-04-30 23:00 ` Dixit, Ashutosh 2021-04-30 23:00 ` [Intel-gfx] " Dixit, Ashutosh 2021-04-30 23:23 ` Dixit, Ashutosh [this message] 2021-04-30 23:23 ` Dixit, Ashutosh 2021-05-01 0:35 ` Jason Ekstrand 2021-05-01 0:35 ` [Intel-gfx] " Jason Ekstrand 2021-05-01 2:19 ` Umesh Nerlige Ramappa 2021-05-01 2:19 ` [Intel-gfx] " Umesh Nerlige Ramappa 2021-05-01 4:01 ` Dixit, Ashutosh 2021-05-01 4:01 ` [Intel-gfx] " Dixit, Ashutosh 2021-05-01 15:27 ` Jason Ekstrand 2021-05-01 15:27 ` [Intel-gfx] " Jason Ekstrand 2021-05-03 18:29 ` Umesh Nerlige Ramappa 2021-05-03 18:29 ` [Intel-gfx] " Umesh Nerlige Ramappa 2021-04-29 1:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for Add support for querying engine cycles Patchwork 2021-04-29 1:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-04-29 3:26 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork -- strict thread matches above, loose matches on Subject: below -- 2021-05-04 0:12 [PATCH 0/1] " Umesh Nerlige Ramappa 2021-05-04 0:12 ` [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy Umesh Nerlige Ramappa 2021-04-27 21:49 [Intel-gfx] [PATCH 0/1] Add support for querying engine cycles Umesh Nerlige Ramappa 2021-04-27 21:49 ` [Intel-gfx] [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy Umesh Nerlige Ramappa 2021-04-28 8:43 ` Jani Nikula 2021-04-28 19:24 ` Jason Ekstrand 2021-04-28 19:49 ` Lionel Landwerlin 2021-04-28 19:54 ` Jason Ekstrand 2021-04-28 20:14 ` Lionel Landwerlin 2021-04-28 20:16 ` Lionel Landwerlin 2021-04-28 20:45 ` Jason Ekstrand 2021-04-28 21:18 ` Lionel Landwerlin 2021-04-29 11:15 ` Daniel Vetter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87bl9vbble.wl-ashutosh.dixit@intel.com \ --to=ashutosh.dixit@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jason@jlekstrand.net \ --cc=umesh.nerlige.ramappa@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.