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 18:05:54 -0700 [thread overview]
Message-ID: <ZRN/8lN/1nCuFwj+@unerlige-ril> (raw)
In-Reply-To: <ZRNQRSE3dxYTCaD3@intel.com>
On Tue, Sep 26, 2023 at 05:42:29PM -0400, Rodrigo Vivi wrote:
>On Tue, Sep 26, 2023 at 12:52:10PM -0700, Umesh Nerlige Ramappa wrote:
>> 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.
>
>while finishing the rename here and looking to this query, I got
>myself thinking, why isn't this already doing the gpu_timestamp
>calculation and showing that directly instead of sending the cycles
>and the crystal clock reference for umd to calculate?
>
>the gpu_timestamp directly would align better with the other fields
>in the struct. and by itself already avoid the gt reference clock
>duplication in the uapi.
Depends on what the user is using the GPU time/ticks for. In OA, the
user space tool compares the cs_cycles directly to the timestamp field
in the OA reports (which is also in cycles). Providing both ref clock
and cycles gives the user flexibility to use it in different scenarios.
Thanks,
Umesh
>
>>
>> Thanks,
>> Umesh
>> >
>> > >
>> > > Thanks,
>> > > Umesh
>> > > >
>> > > > >
>> > > > > Thanks,
>> > > > > Umesh
next prev parent reply other threads:[~2023-09-27 1:06 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
2023-09-26 21:42 ` Rodrigo Vivi
2023-09-27 1:05 ` Umesh Nerlige Ramappa [this message]
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=ZRN/8lN/1nCuFwj+@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