From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42EE0C433ED for ; Sat, 1 May 2021 00:35:50 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D07FC61407 for ; Sat, 1 May 2021 00:35:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D07FC61407 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 686306F61C; Sat, 1 May 2021 00:35:46 +0000 (UTC) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 341986F616 for ; Sat, 1 May 2021 00:35:45 +0000 (UTC) Received: by mail-ot1-x32c.google.com with SMTP id y14-20020a056830208eb02902a1c9fa4c64so86686otq.9 for ; Fri, 30 Apr 2021 17:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:date:message-id:in-reply-to:references:user-agent :subject:mime-version; bh=lQRYmgCaPlyiQPSqhkt/k7ys2QwwAU2JroYC2TvH5sg=; b=iDq/OAMgq1+bYj3cx4hL4Gty3kzsK9P+6LgdZA0aO0rDJV03YmfLGuJW4mWexFiR/L /5oGvTXLsDdJ7HSZUv9Hkf24emWesFRGwzQa6rEjIzVM/XxJB3mxt5io39L7qFBm1qSx TcI7KyIUBC1gb6qhJZjDxZ7gyXjSOqw618RlvPnsw1PVtvZ0kGTW4gDd6EX5Sx5ngJwE kdVWw+NWH7dBz0d78XNTBQbK1ooG6oYeyFGp2VBlxVmdmWLIHfj4/xAESr2fQ3ozFR2n d56nUBMs32j1Yf84AGGGWz1/KE5grBjpszxZm+AxUV8NXz9PxGdWHBXGYKPsjfJ82WG3 bxWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to :references:user-agent:subject:mime-version; bh=lQRYmgCaPlyiQPSqhkt/k7ys2QwwAU2JroYC2TvH5sg=; b=qMDJGGy3n5Mm9KympxM7QKYL+Qay2JRoNINJPtOxfDHmNeHO6QRhpKXQXd7ReozlgU 8H0y5kcYmxQ5rcyGKKLIFdRDZCB218yBkjJ2eu1Lr87h4y9lRN3gd/e1LhfRDq7F3OVY OKHnJ2bX+dUxpOxQstF8cs6W2LPlAM/uHOGhKqHVD0qmfZ9e1NLlYSYO8EaEpbg00rJT 4ey1rYmIpMj7duwJ0/9wyh9JvgmyCuEYFqxFv0+tiu2P9w8n1u03tHzzCh6p5BGUvWPT F8h0A4Jmuqs5ia6xB3Ns+zonrQ5hQQ2LO7fReUPUq7oDQSLE1JDGVQIto6IAyzAVWZId mCyQ== X-Gm-Message-State: AOAM530oUeGnZV+LIyfa6vIF0YaxKxQMrnZ5HODKAVx1w9iX7W9U39Gu Afxg2spVmvyWNjuufRLiGmJ1hA== X-Google-Smtp-Source: ABdhPJzuLHVoBS6Rdsx5oVjdZ2PDdSbRZd0RQz50RCqtY31pa4tU6xDtrhGT5pNZAUm6M6rmxcL5HA== X-Received: by 2002:a05:6830:2e1:: with SMTP id r1mr5778764ote.195.1619829344166; Fri, 30 Apr 2021 17:35:44 -0700 (PDT) Received: from [100.64.196.46] ([209.107.186.11]) by smtp.gmail.com with ESMTPSA id a4sm514615oib.17.2021.04.30.17.35.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Apr 2021 17:35:43 -0700 (PDT) From: Jason Ekstrand To: "Dixit, Ashutosh" , Umesh Nerlige Ramappa Date: Fri, 30 Apr 2021 19:35:41 -0500 Message-ID: <179255a3b48.2817.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net> In-Reply-To: <87czubbco1.wl-ashutosh.dixit@intel.com> References: <20210429003410.69754-1-umesh.nerlige.ramappa@intel.com> <20210429003410.69754-2-umesh.nerlige.ramappa@intel.com> <20210430222609.GC38093@orsosgc001.ra.intel.com> <87czubbco1.wl-ashutosh.dixit@intel.com> User-Agent: AquaMail/1.29.1-1808 (build: 102900007) Subject: Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel GFX , Maling list - DRI developers Content-Type: multipart/mixed; boundary="===============0641137119==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This is a multi-part message in MIME format. --===============0641137119== Content-Type: multipart/alternative; boundary="179255a3cb05f6d28177d11c5a" This is a multi-part message in MIME format. --179255a3cb05f6d28177d11c5a Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit On April 30, 2021 18:00:58 "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? Yeah, I think reporting the timestamp width is a good idea since we're reporting the period/frequency here. >> > How would exposing only the lower 32 bits of the timestamp work? > > 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. That's doesn't actually work since you can query the 64-bit timestamp value from the GPU. The way this is handled in Vulkan is that the number of timestamp bits is reported to the application as a queue property. --Jason > --179255a3cb05f6d28177d11c5a Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On April 30, 2021 18:00:= 58 "Dixit, Ashutosh" <ashutosh.dixit@intel.com> 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 s= hould I just
return the lower 32 bits of the timestamp?

Yeah, = I think reporting the timestamp width is a good idea since we're reporting = the period/frequency here.

How would exposing only the lower 32 bits of the timestam= p work?

The way to avoid exposing the width would be to expose th= e 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.

That's doesn't actual= ly work since you can query the 64-bit timestamp value from the GPU. The wa= y this is handled in Vulkan is that the number of timestamp bits is reporte= d to the application as a queue property.

=
--Jason

--179255a3cb05f6d28177d11c5a-- --===============0641137119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0641137119==--