| Summary: | Mesa-9.1+ results in slow final redraw of windows (e.g. xterm) with E17 compositing manager | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Michael Shigorin <mike> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | minor | ||
| Priority: | medium | CC: | shrek |
| Version: | 9.1 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | `perf report` | ||
|
Description
Michael Shigorin
2013-03-04 19:39:23 UTC
A bisect would help narrow it down right quick. This could also be related to bug #61554. OK, I'll try bisecting. Didn't bisect successfully so far due to package build troubles; in the meanwhile, the commits referenced in https://bugs.freedesktop.org/show_bug.cgi?id=61554#c12 didn't change the behaviour described above (the complete build bailed out so copied over i965_dri.so alone judging on git log --stat anholt/fs-varying-uniform). OK, since bisecting apparently isn't working out, the instructions at http://dri.freedesktop.org/wiki/IntelPerformanceTuning/ (especially INTEL_DEBUG=perf) should help find where we should be looking. I haven't abandoned the hope to get down to bisecting yet as there were less than 10 steps at most between 9.0 and 9.1 IIRC; thanks for the advice, following it. The images in comment 0 are still available in case any soul decides to see what the bug looks like and maybe catch the familiar symptomes, BTW. Created attachment 80514 [details] `perf report` (In reply to comment #4) > http://dri.freedesktop.org/wiki/IntelPerformanceTuning/ Running E17 session with INTEL_DEBUG=perf (I've made sure it's in the environment of this enlightenment process) doesn't seem to yield any additional relevant output in ~/.xsession-errors:0; I've also tried running xinit -- :1 with enlightenment_start by hand just in case, the output looks the same. Packaged intel-gpu-tools 1.3 and mounted debugfs into /sys/kernel/debug; but dri/ is apparently empty under 3.4.x kernel I usually run so intel_gpu_top complained: Couldn't find path to dri/debugfs entry and didn't provide "ring busy" data among the remaining information; I wasn't able to push "render busy" numbers above 10% with the operations that degraded like (un)mapping the xterm window. Booted into Linux 3.9.4 and dri/ is now populated, no "ring busy", unable to push "render busy" higher than ~15% anyways. Not sure if E17 employs shaders as it runs just fine with its own software rendering so I doubt that INTEL_DEBUG=shader_time is worth trying. `perf report` done during "perf for GPU stalls" is attached in case you might find it useful; the data were collected by executing "/usr/bin/perf record -f -g -e i915:i915_gem_request_wait_begin -c 1 -a" and then starting/closing several xterms. I have archived a hybrid LiveCD image with Mesa 9.0 so can reproduce the desired behaviour and take some metrics off it if this helps: http://nightly.altlinux.org/sisyphus/archive/regular-e17-20130227-x86_64.iso Thank you guys. Still there in 9.2.2... Dear Reporter, This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested. Thank you. I actually had to stop using E17 due to graphics stack regressions -- quite a few wakeups have emerged where there used to be (almost) idle CPU/GPU, and battery time degradation became unacceptable; so I'm back with WindowMaker since last year. IIRC *this* particular bug has gone at some stage but I can't even recall Mesa version (seems it was considerably later than 2013), sorry. PS: ftp.linux.kiev.ua is no more due to US-backed ruination of former Ukraine. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.