From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v2 03/20] drm/xe: Correlate engine and cpu timestamps with better accuracy
Date: Tue, 26 Sep 2023 12:52:10 -0700 [thread overview]
Message-ID: <ZRM2avt22erTAimS@unerlige-ril> (raw)
In-Reply-To: <ZRMr6JXpSurNe90N@intel.com>
On Tue, Sep 26, 2023 at 03:07:20PM -0400, Rodrigo Vivi wrote:
>On Tue, Sep 26, 2023 at 11:58:58AM -0700, Umesh Nerlige Ramappa wrote:
>> On Tue, Sep 26, 2023 at 02:48:13PM -0400, Rodrigo Vivi wrote:
>> > On Mon, Sep 25, 2023 at 06:37:12PM -0700, Umesh Nerlige Ramappa wrote:
>> > > On Wed, Sep 20, 2023 at 03:29:23PM -0400, Rodrigo Vivi wrote:
>> > > > From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>> > > >
>> > > > Perf measurements rely on CPU and engine timestamps to correlate
>> > > > events of interest across these time domains. Current mechanisms get
>> > > > these timestamps separately and the calculated delta between these
>> > > > timestamps lack enough accuracy.
>> > > >
>> > > > To improve the accuracy of these time measurements to within a few us,
>> > > > add a query that returns the engine and cpu timestamps captured as
>> > > > close to each other as possible.
>> > > >
>> > > > Prior work: https://patchwork.freedesktop.org/series/87552/
>> > > >
>> > > > Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>> > > > Signed-off-by: Francois Dugast <francois.dugast@intel.com>
>> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > > > ---
>> > >
>> > > Should already have an R-b from Jose based on this -
>> > > https://patchwork.freedesktop.org/patch/552682/?series=122440&rev=1
>> >
>> > While incorporating that and fixing IGT, I noticed the inconsistency
>> > present on the v2 that was not part of v1.
>> >
>> > Why we have the struct name as engine_cycles now but the query itself
>> > is still cs_cycles? Which one is correct? why do we need both and
>> > cannot align in a single name?
>>
>> Jose had commented that XE does not have the concept of CS and asked for a
>> rename to engine. In the latest revision of this series, I had replaces cs
>> with engine everywhere.
>>
>> We should use engine.
>>
>> Latest series - https://patchwork.freedesktop.org/series/122440/
>
>yeap, I got from there...
>I still see
>+#define DRM_XE_QUERY_CS_CYCLES 6
>there
>;)
>
>I can do the renaming locally if this is the right thing to do...
oh, I think I missed that. It should be changed to
DRM_XE_QUERY_ENGINE_CYCLES.
Thanks,
Umesh
>
>>
>> Thanks,
>> Umesh
>> >
>> > >
>> > > Thanks,
>> > > Umesh
next prev parent reply other threads:[~2023-09-26 19:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 19:29 [Intel-xe] [PATCH v2 00/20] uAPI Alignment - take 1 v2 Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 01/20] drm/xe: Fix array bounds check for queries Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 02/20] drm/xe: Set the correct type for xe_to_user_engine_class Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 03/20] drm/xe: Correlate engine and cpu timestamps with better accuracy Rodrigo Vivi
2023-09-26 1:37 ` Umesh Nerlige Ramappa
2023-09-26 18:48 ` Rodrigo Vivi
2023-09-26 18:58 ` Umesh Nerlige Ramappa
2023-09-26 19:07 ` Rodrigo Vivi
2023-09-26 19:52 ` Umesh Nerlige Ramappa [this message]
2023-09-26 21:42 ` Rodrigo Vivi
2023-09-27 1:05 ` Umesh Nerlige Ramappa
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 04/20] drm/xe/uapi: Separate VM_BIND's operation and flag Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 05/20] drm/xe/vm: Remove VM_BIND_OP macro Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 06/20] drm/xe/uapi: Remove MMIO ioctl Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 07/20] drm/xe: Fix xe_exec_queue_is_idle for parallel exec queues Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 08/20] drm/xe: Deprecate XE_EXEC_QUEUE_SET_PROPERTY_COMPUTE_MODE implementation Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 09/20] drm/xe: Rename exec_queue_kill_compute to xe_vm_remove_compute_exec_queue Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 10/20] drm/xe: Remove XE_EXEC_QUEUE_SET_PROPERTY_COMPUTE_MODE from uAPI Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 11/20] drm/xe/uapi: Use common drm_xe_ext_set_property extension Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 12/20] drm/xe: Kill XE_VM_PROPERTY_BIND_OP_ERROR_CAPTURE_ADDRESS extension Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 13/20] drm/xe/uapi: Document drm_xe_query_gt Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 14/20] drm/xe/uapi: Replace useless 'instance' per unique gt_id Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 15/20] drm/xe/uapi: Remove unused field of drm_xe_query_gt Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 16/20] drm/xe/uapi: Rename gts to gt_list Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 17/20] drm/xe/uapi: Fix naming of XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 18/20] drm/xe/uapi: Add documentation for query Rodrigo Vivi
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 19/20] drm/xe/uapi: Crystal Reference Clock updates Rodrigo Vivi
2023-09-20 19:56 ` Souza, Jose
2023-09-20 20:09 ` Rodrigo Vivi
2023-09-21 15:50 ` Souza, Jose
2023-09-21 20:49 ` Rodrigo Vivi
2023-09-21 21:04 ` Souza, Jose
2023-09-20 19:29 ` [Intel-xe] [PATCH v2 20/20] drm/xe: Extend drm_xe_vm_bind_op Rodrigo Vivi
2023-09-20 19:52 ` [Intel-xe] ✓ CI.Patch_applied: success for uAPI Alignment - take 1 v2 Patchwork
2023-09-20 19:52 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-09-20 19:53 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-09-20 20:00 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-20 20:01 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-09-20 20:02 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-09-20 20:36 ` [Intel-xe] ✗ CI.BAT: failure " Patchwork
2023-09-20 21:14 ` [Intel-xe] [PATCH v2 00/20] " Matt Roper
2023-09-20 21:54 ` Matthew Brost
2023-09-20 23:07 ` Matt Roper
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=ZRM2avt22erTAimS@unerlige-ril \
--to=umesh.nerlige.ramappa@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox