Bug 61811 - Mesa-9.1+ results in slow final redraw of windows (e.g. xterm) with E17 compositing manager
Summary: Mesa-9.1+ results in slow final redraw of windows (e.g. xterm) with E17 compo...
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 9.1
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-04 19:39 UTC by Michael Shigorin
Modified: 2017-02-11 09:18 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
`perf report` (3.25 KB, text/plain)
2013-06-08 10:02 UTC, Michael Shigorin
Details

Description Michael Shigorin 2013-03-04 19:39:23 UTC
I've found out while testing Mesa 9.1 packages that while some things got better, Enlightenment's compositing degraded: e.g. a launched xterm window would fade in as a window border instead of opaque area and only get its own background (black) when fully displayed; behaviour with 9.0.3 was for the opaque window to fade in.

This is reproducible here on Intel HD4000 using this hybrid ALT Linux based LiveCD I've crafted to preview Mesa 9.1 and help catch this regression:

http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/e17/regular-e17-20130224-x86_64.iso
http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/e17/regular-e17-20130224-i586.iso

...try running "xterm -rv" from Terminology after getting through initial E17 configuration -- this effect doesn't manifest itself with plain xterm (white background) or Terminology itself.

I've tried varying xorg-drv-intel somewhat (2.21.{2,3}) and kernel (3.4.35, 3.7.x) but the combinations working with 9.0.3 would show this regression with the only change being an upgrade to 9.1.

Is there anything else I can provide to help isolate the bug?  Would be great to have 9.1.1 free from this particular one :-)

TIA
Comment 1 Ian Romanick 2013-03-04 19:49:44 UTC
A bisect would help narrow it down right quick.

This could also be related to bug #61554.
Comment 2 Michael Shigorin 2013-03-04 20:01:17 UTC
OK, I'll try bisecting.
Comment 3 Michael Shigorin 2013-03-14 22:55:41 UTC
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).
Comment 4 Eric Anholt 2013-06-08 00:40:03 UTC
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.
Comment 5 Michael Shigorin 2013-06-08 08:01:54 UTC
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.
Comment 6 Michael Shigorin 2013-06-08 10:02:12 UTC
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.
Comment 7 Michael Shigorin 2013-10-22 12:54:55 UTC
Still there in 9.2.2...
Comment 8 Annie 2017-02-10 22:38:56 UTC
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.
Comment 9 Michael Shigorin 2017-02-11 09:18:46 UTC
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.