lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <15112867.uLZWGnKmhe@workhorse>
Date: Fri, 05 Dec 2025 11:47:40 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Chia-I Wu <olvaffe@...il.com>
Cc: Boris Brezillon <boris.brezillon@...labora.com>,
 Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 kernel@...labora.com, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org
Subject:
 Re: [PATCH 1/2] drm/panthor: Add tracepoint for hardware utilisation changes

On Thursday, 4 December 2025 21:21:08 Central European Standard Time Chia-I Wu wrote:
> On Wed, Dec 3, 2025 at 6:04 AM Nicolas Frattaroli
> <nicolas.frattaroli@...labora.com> wrote:
> >
> > Mali GPUs have three registers that indicate which parts of the hardware
> > are powered and active at any moment. These take the form of bitmaps. In
> > the case of SHADER_PWRACTIVE for example, a high bit indicates that the
> > shader core corresponding to that bit index is active. These bitmaps
> > aren't solely contiguous bits, as it's common to have holes in the
> > sequence of shader core indices, and the actual set of which cores are
> > present is defined by the "shader present" register.
> >
> > When the GPU finishes a power state transition, it fires a
> > GPU_IRQ_POWER_CHANGED_ALL interrupt. After such an interrupt is
> > received, the PWRACTIVE registers will likely contain interesting new
> > information.
> I am seeing
> 
>    irq/342-panthor-412     [000] .....   934.526754: gpu_power_active:
> shader_bitmap=0x0 tiler_bitmap=0x0 l2_bitmap=0x0
>    irq/342-panthor-412     [000] .....   936.640356: gpu_power_active:
> shader_bitmap=0x0 tiler_bitmap=0x0 l2_bitmap=0x0
> 
> on a gpu-bound test. It does not look like collecting samples on
> GPU_IRQ_POWER_CHANGED_ALL gives too much info.

On what GPU and SoC is that? If it's MT8196 then I wouldn't be
surprised if it just broke that hardware register, considering
what it did to the SHADER_PRESENT register.

On RK3588 (v10), GPU_IRQ_POWER_CHANGED_ALL reliably fires when
there is new information available in those registers. I haven't
tried on MT8196 (v13) yet because that still doesn't boot with
mainline so testing anything is a pain.

I don't have any v12 or v11 hardware to test with. From what I
understand, there's no open enough platform to do v11 testing on,
just the Pixel 8 and Pixel 9. I could look into the Cix SoC for v12
though some day, but I don't own one at the moment.

> 
> I think they are more useful to be collected periodically, such that
> we know that in the past X seconds, Y out of a total of Z samples
> indicates activities. That's best done in userspace, and panthor's
> role should be to provide an uapi such as
> https://lore.kernel.org/all/cover.1743517880.git.lukas.zapolskas@arm.com/.

This wouldn't give you information on the time a power transition has
completed, which is one of the motivations. A periodically collected
PWRACTIVE would just be roughly correlated to how busy the GPU is,
which isn't very useful additional information as the performance
counters themselves are likely a better source of that kind of info.

What I need to do is restrict this to <= v13 in the next revision
however, because v14 reworks this stuff.

Kind regards,
Nicolas Frattaroli



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ