My system has chipset 915GM configured in dual-display. One of the display is configured in rotation. I am running a Java application using XRender pipeline which does rendering at 30fps. With Intel driver 2.99.917, the rendering is fluid and top shows about 30% of idle CPU. With Intel driver 2.99.917+git20151217, the rendering is not fluid and top shows 30% in wa state (0% idle) I managed to git bisect the culprit commit 9a311f9 sna: Throw away the TearFree damage if it grows too big Reverting this commit makes the system behave normally (rendering is back to 30fps and CPU is 30% idle). Note that when both displays are in normal orientation, I do not see any performance issue.
Also, when both displays are configured in rotation, I see the performance hit no matter which driver version I use (tried 2.21.15, 2.99.917, 2.99.917+git20151217). The problem does not appear with a 945GM chipset.
Well that was contrary to my expectations. The change should be to apply the bbox of the damage rather than the individual boxes, which is beneficial when they are approximately the same - worst case is a pixel damaged top-left and pixel bottom-right. Tracking damage bbox per CRTC may be a compromise - that would help the case of having a clock in one corner of the display and rendering in the other. However, I think that doesn't explain the result with both being rotated. I wonder if there is not something fishy with the rotation code. Since this is is a 915gm, it will have to create a temporary surface with which to do the rotation as the source framebuffer will be much larger than the render pipeline can handle natively. Similarly the source framebuffer will be larger than a fence and so untiled - but the intermediate and final should be tiled. There's enough oddity here that having a read through of a full-debug log would be interesting. Could you recompile with ./configure --enable-debug=full and attach an xz compressed Xorg.0.log of ~10s of the various setups? The full-debug logs will be huge.
Created attachment 121312 [details] Xorg.0.log full-debug normal displays Xorg.0.log with full-debug enabled on driver 2.99.917+git20160125 (SHA1: 7bebe12). Configuration: Both displays are not rotated (i.e. normal) Log contains initialization of XServer, initialization of Java application, steady run during at least 10 seconds of the Java application, then stopping of the Java application.
Created attachment 121313 [details] Xorg.0.log full-debug one display rotated Xorg.0.log with full-debug enabled on driver 2.99.917+git20160125 (SHA1: 7bebe12). Configuration: One display is rotated (left) Log contains initialization of XServer, initialization of Java application, steady run during at least 10 seconds of the Java application, then stopping of the Java application.
Created attachment 121314 [details] Xorg.0.log full-debug both displays rotated Xorg.0.log with full-debug enabled on driver 2.99.917+git20160125 (SHA1: 7bebe12). Configuration: Both displays are rotated (left) Log contains initialization of XServer, initialization of Java application, steady run during at least 10 seconds of the Java application, then stopping of the Java application.
Created attachment 121315 [details] Xorg.0.log full-debug one display rotated -- Fixed wrong content type -- Xorg.0.log with full-debug enabled on driver 2.99.917+git20160125 (SHA1: 7bebe12). Configuration: One display is rotated (left) Log contains initialization of XServer, initialization of Java application, steady run during at least 10 seconds of the Java application, then stopping of the Java application.
Feel free to ask for more details if needed.
Created attachment 121324 [details] [review] Perform composite rotation on the individual damage boxes If you revert the bad patch and apply this, does it (work! I may have my source offsets work) speed up displaying the rotated outputs?
The patch fixed the performance issue on all configurations (single rotated output and dual rotated outputs). Thank you very much!
Ta! I pushed a partial revert of the first patch and this one: commit 2bee35a86b77bc7371a81dfa1586398edde56917 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 27 11:00:04 2016 +0000 sna: Restrict TearFree damage discarding to straightforward copies If we have a rotation, it is beneficial to keep the amount of work we need to do to a minimum. So restrict commit 9a311f9da612ba02b24458f6a40b6a5445ad4869 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Feb 13 14:03:16 2015 +0000 sna: Throw away the TearFree damage if it grows too big to only apply to TearFree and not if we have active RandR transforms. Reported-by: Frank Delache <franck.delache@grassvalley.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93864 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> commit 43fffc8ea93bef012928f077981d9bf7bb7c3023 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 27 10:42:47 2016 +0000 sna: Perform composite rotation on the individual damage elements As the rotation may need to perform intermediate copies (e.g. displays larger than the render pipeline), we can reduce the amount of overdraw by using the damage boxes rather than preparing to redraw the entire output. Reported-by: Frank Delache <franck.delache@grassvalley.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93864 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> That should be a good compromise I hope. Can you please double check with upstream/master?
I confirm the upstream commits (43fffc8 and 2bee35a) fix the issue. Marking the bug resolved fixed.
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.