On 03/04/2018 15:06, Eero Tamminen wrote:
Hi,
On 03.04.2018 12:36, Tvrtko Ursulin wrote:
On 29/03/2018 15:30, Eero Tamminen wrote:
I tested this on HSW GT2, BYT, BDW GT3, SKL GT2 and KBL GT3e,
with Ubuntu 16.04 and 17.10, using Ubuntu default kernels (4.4 to 4.13)
and latest drm-tip build (4.16.0-rc7).
General comments
----------------
This will be used by our customers and people who aren't necessarily
familiar with i915 internal details. Therefore it should use
common terminology in the field and in similar tools, instead of
I3As (Intel 3-letter Acronyms).
For example:
- rcs -> 3D render
- bcs -> blitter
- vecs -> video
- vcs -> video decode
etc.
Done. And I am open to bike-shedding of the names and display format
for instance reporting.
New names look fine to me!
Old tool showed also GPU system memory interface (GAM) busyness.
That was valuable info, and reasonably accurate for stable loads.
Could this tool show also either that information (preferred), or
bandwidth utilized by GPU/CPU/display?
(Latest kernels offer GPU memory bandwidth usage through perf
"uncore_imc" "data_reads" & "date_writes" counters.)
Excellent suggestion and I've added IMC data_reads and data_writes to
the tool.
Thanks, it looks fine too. I'm just wondering about the numbers
it's reporting on SKL GT2...
AFAIK IMC counters are for uncore, so I though that they should
correspond to GTI (memory interface to outside of GPU) read and
write HW counter values. While it seemed in some cases quite close,
in some cases the it showed a lot smaller (2/3) value than expected.
I can understand why reads are sometimes larger, because I think
uncore will include also display engine display content reads.
However, I don't see how uncore writes could be considerably smaller
than the GTI interface write amount.
(GTI interface reports the expected value which corresponds directly
to what my test application is doing (64x blended FullHD layer writes).)
Idle machine read amounts are also much smaller (60-65MB/s) than what
I think display update read should be (1920*1080*4*60Hz = 475MiB/s).
Any ideas for these two discrepancies?
I'm afraid I am not familiar with the uncore IMC, but we could always
approach its authors?
Is "wait" value supposed to be IO-wait for given engine interface?
I never saw that change from 0%, although IO-wait in top jumped
from 0 to 20-30% with my test GPU load.
No, that is time spent in MI_WAIT_FOR_EVENT.
Could you add that info to the UI?
E.g. just have "MI" on top of the "wait" column.
Like a full header strip? Yeah makes sense, I'll add it.
> I think not very used in current codebase.
What you're using to validate that it reports correct value?
That would be igt/tests/perf_pmu/event-wait-rcs0.
HW specific test results
------------------------
BYT:
* Reports "Failed to initialize PMU!" although old intel_gpu_top
works fine.
HSW GT2, BDW GT3, SKL GT2 and KBL GT3e seems to work fine except
for the "wait" value.
I never saw blitter engine to do anything, but that's because
modesetting uses just 3D pipeline, and because I couldn't get
Intel DDX to work with rest of latest git version of X / 3D stack.
Thank you for testing this so thoroughly - this was really invaluable
since I don't have access too such number of platforms. I've tried to
fix all this in the latest version.
Machines are currently running tests, I'll check these tomorrow.
Thanks!
Kernel version support
----------------------
My HW specific testing above was with drm-tip kernel, but I did one test
also with Ubuntu 16.04 v4.4 kernel (which includes v4.6 or v4.8 i915
backport) on KBL. For that, the tool reported:
"Failed to detect engines!"
Although the previous intel_gpu_top works fine with that kernel version.
Same happens also with Ubuntu 17.04 v4.13 kernel.
-> If new version needs a certain kernel version, it should tell
which version is required.
Yep, at least 4.16 is needed so I have added this info to the error
message.
IMHO the message is a bit ambivalent:
Failed to detect engines! Kernel 4.16 or newer?
I would suggest checking whether kernel is new enough, and if not:
Kernel X.YY detected, 4.16 or newer required.
Maybe yeah. I was planning to improve error messages altogether but
forgot. Will see what improvements make sense.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
