Re: drm/etnaviv: slow down FE idle polling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2023/6/15 21:41, Chris Healy wrote:
Jingfeng,

Does your design have any bus PMU counters that can be used to measure
DRAM bandwidth of the 3D GPU directly or even indirectly?

No,  It seems that we don't have such hardware.


What we can do is measure by the CPU,  say write a memcpy program.

Testing the system ram to vram and vram to system bandwidth.

system ram to system ram bandwidth.

Out 3a5000 system RAM bandwidth can be 10 GB/s (tested by memcpy testing program 1920x1080)

But the GPU is inside the north bridge,  Access memory from there is a bit slower.

because it need cross the HT bus.  But I don't mind.

Regards,

Chris

On Thu, Jun 15, 2023 at 2:53 AM Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote:
Am Donnerstag, dem 15.06.2023 um 17:37 +0800 schrieb Sui Jingfeng:
Hi,

[...]
+
+   /*
+    * Choose number of wait cycles to target a ~30us (1/32768) max latency
+    * until new work is picked up by the FE when it polls in the idle loop.
+    */
+   gpu->fe_waitcycles = min(gpu->base_rate_core >> (15 - gpu->freq_scale),
+                            0xffffUL);
This patch is NOT effective on our hardware GC1000 v5037 (ls7a1000 +
ls3a5000).

As the gpu->base_rate_core is 0,  so, in the end gpu->fe_waitcycles is
also zero.

Uh, that's a problem, as the patch will then have the opposite effect
on your platform by speeding up the idle loop. Thanks for catching
this! I'll improve the patch to keep a reasonable amount of wait cycles
in this case.
It's OK, no big problem as far as I can see. (it my platform's problem,
not your problem)

It will become a problem as it eats up the bandwidth that you want to
spend for real graphic work.

Merge it is also OK, if we found something wrong we could fix it with a
another patch.

Hmm.. I think that the fix for this problem is more or less an extra
if so I would love to see a proper fix
before this patch gets merged.
Right, we don't merge known broken stuff. We are all humans and bugs
and oversights happen, but we don't knowingly regress things.

It just no effect(at least I can't find).

I have tried, The score of glmark2 does not change, not become better,
not become worse.
That's because it only affects your system when the GPU is idle but
isn't in runtime PM yet. If you measure the DRAM bandwidth in that time
window you'll see that the GPU now uses much more bandwidth, slowing
down other workloads.

Regards,
Lucas

--
Jingfeng




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux