All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
To: Krzysztof Karas <krzysztof.karas@intel.com>,
	Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Cc: <igt-dev@lists.freedesktop.org>,
	<kamil.konieczny@linux.intel.com>, <krzysztof.niemiec@intel.com>
Subject: Re: [PATCH i-g-t 4/8] tools/gputop/i915_gputop: add i915 PMU engine monitoring
Date: Wed, 30 Sep 2026 13:06:22 +0200	[thread overview]
Message-ID: <DLSLPB47KBCX.3B4RTMBTWH25L@intel.com> (raw)
In-Reply-To: <2wlmpoiinqrdba6skfdwswlvce7fh64zawqfb4cx7kp7dfjjfp@mrocbsbiys5e>

Hi, Krzysztof,
thanks for review.

On Mon Sep 28, 2026 at 1:01 PM CEST, Krzysztof Karas wrote:
> Hi Sebastian,
>
> The implementaion looks OK, I am wondering about the duplicated
> bits and whether it is worth it to make funcitons forcibly stand
> out from the Xe implementation, e.g. sometimes you have tiny bit
> of difference in formatting, or there is one more helper
> variable in one implementation, but not the other, etc.
>
> I'd say it would be worth considering extracting common parts
> into a shared file, but not necessarily in this patch series.
Agreed on not doing it in this series, and honestly, I'd lean towards
not doing it at all unless we actually get more backend. Each vendor
backend implements the same interface on its own terms, by design, so
each one can do things however makes sense for that hardware. Merging
the common bits now, with only two backends to generalize from, risks
guessing wrong about what's actually shared, and we'd
end up with an abstraction that doesn't fit either one cleanly.

It also helps that gputop is a small standalone tool, not core library
code, so a bit of duplication here is cheap. If another backend shows
up we can revisit this.


-- 
Best regards,
Sebastian


  reply	other threads:[~2026-09-30 11:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 10:57 [PATCH i-g-t 0/8] tools/gputop: add i915 PMU engine monitoring Sebastian Brzezinka
2026-09-25 10:57 ` [PATCH i-g-t 1/8] tools/gputop/xe_gputop: fix struct layout and PMU read Sebastian Brzezinka
2026-09-28  8:49   ` Krzysztof Karas
2026-09-30 12:30     ` Sebastian Brzezinka
2026-09-25 10:57 ` [PATCH i-g-t 2/8] tools/gputop/xe_gputop: fix CLAMP() usage Sebastian Brzezinka
2026-09-28  8:50   ` Krzysztof Karas
2026-09-29 10:14   ` Kamil Konieczny
2026-09-25 10:57 ` [PATCH i-g-t 3/8] tools/gputop/xe_gputop: fix return logic, cleanup and div by zero bugs Sebastian Brzezinka
2026-09-28  9:12   ` Krzysztof Karas
2026-09-25 10:57 ` [PATCH i-g-t 4/8] tools/gputop/i915_gputop: add i915 PMU engine monitoring Sebastian Brzezinka
2026-09-28 11:01   ` Krzysztof Karas
2026-09-30 11:06     ` Sebastian Brzezinka [this message]
2026-09-30 14:39       ` Kamil Konieczny
2026-10-02  2:29         ` vitaly prosyak
2026-10-02  8:59   ` Tvrtko Ursulin
2026-09-25 10:57 ` [PATCH i-g-t 5/8] tools/meson: build gputop PMU backends as part of gputop Sebastian Brzezinka
2026-09-29  5:58   ` Krzysztof Karas
2026-09-25 10:57 ` [PATCH i-g-t 6/8] tools/gputop/utils: guard ANSI macros against redefinition Sebastian Brzezinka
2026-09-29  5:58   ` Krzysztof Karas
2026-09-25 10:57 ` [PATCH i-g-t 7/8] tools/gputop: integrate i915 and xe PMU engine monitoring Sebastian Brzezinka
2026-09-29  8:49   ` Krzysztof Karas
2026-09-29  9:16     ` Jani Nikula
2026-09-25 10:57 ` [PATCH i-g-t 8/8] tests/tools_test: add gputop PMU engine monitoring subtests Sebastian Brzezinka
2026-09-29  9:39   ` Krzysztof Karas
2026-09-25 12:48 ` ✓ i915.CI.BAT: success for tools/gputop: add i915 PMU engine monitoring Patchwork
2026-09-25 13:02 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-25 20:21 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-26  5:44 ` ✗ i915.CI.Full: " Patchwork
2026-09-28 20:59 ` ✗ Xe.CI.BAT: failure for tools/gputop: add i915 PMU engine monitoring (rev2) Patchwork
2026-09-28 21:05 ` ✓ i915.CI.BAT: success " Patchwork
2026-09-29  2:59 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-29  5:06 ` ✓ i915.CI.Full: success " Patchwork

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=DLSLPB47KBCX.3B4RTMBTWH25L@intel.com \
    --to=sebastian.brzezinka@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=krzysztof.karas@intel.com \
    --cc=krzysztof.niemiec@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 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.