Hi,
On 04/04/2018 13:15, Eero Tamminen wrote:
Hi,
I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.
Generic test results
--------------------
* Tool works on all of them
* The new error messages and headings look good
* Idle IMC read amounts correspond to expected values on SNB & HSW.
The much smaller values on BDW & SKL are due to FBC (how well
it compresses, naturally depends on screen content).
Hm OK, you managed to explain it. Because in the meantime I have
observed one oddity with write bandwidth on my headless SkullCanyon NUC.
It idles around 28MiB/s, while when I load it up with some command
streamer activity it drops to ~11MiB/s. I don't know, but just feels
suspect. (Read bandwidth goes from ~215MiB/s at idle to ~4.5GiB/s in my
load case.)
BYT & BSW
---------
* IMC, power usage and actual(?) freq values are missing.
-> You can get actual freq by polling CAGF register, represented by:
/sys/class/drm/card0/gt_act_freq_mhz
Yep, this is the i915 internal limitation that we cannot expose this for
consumption from PMU.
Normally i915 driver maps uncore power usage to GPU power usage,
but BYT is missing that (and ram power usage). However, RAPL
does report package & core values...
Suggestions
-----------
Maybe on platforms where RAPL doesn't report "uncore" power usage,
you could just deduct RAPL reported "core" power consumption from
the "package" power consumption, and report that as "GPU" power
usage? (Or do that in i915 directly)
What are you referring to as "uncore" in the context of RAPL?
Do I understood correctly you suggested to use "energy-pkg -
energy-cores" when "energy-gpu" is not available? If the former two are
there both on on BYT and BSW, this sounds okay to me.
You need also to either update the manual, or implement -o and -e
There is a manual, will do!
options for the new version of intel_gpu_top. CSV output of all
the reported values would be nice.
I would prefer to drop both -o and -e, since this is achievable via perf
stat. For instance:
perf stat -a -e power/energy-gpu/,i915/rcs0-busy/ -I 1000 -x, <command>
Gives CSV samples once per second.
On the other hand one argument I can think of to actually do implement
-o and -e, is that we need to do some extra normalization on some i915
counters perf tool would not do.
I don't have a feeling if anyone is actually using these options. If
unlikely, we should probably drop them regardless.
You might mention in manual as an example how to calculate
idle screen update bandwidth, and that it's impacted by:
- PSR (panel self refresh, depends on display supporting it):
/sys/kernel/debug/dri/0/i915_edp_psr_status
- FBC (frame buffer compression, enabled on newer GENs)
/sys/kernel/debug/dri/0/i915_fbc_status
- end-to-end RBC (render buffer compression, requires modifiers
support i.e. GEN9+ GPU and X & Mesa with DRI3 v1.2 [1] support)
Sounds useful for users, but I am a bit wary of feature creep. In this
specific example I'd want to push it for follow-up work.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
