Created attachment 35534 [details] xorg.0.log System Environment: -------------------------- Arch i386 Platform Pineview 945GM Libdrm: (master)6293152eb065016a2e5e4fcd047c2db5c2fb0f36 Mesa: (master)8ad3e0b55df50beac8ba3c5cafa0be79641a4977 Xserver: (master)72758287f79a4f1aa8fa388f20947042e3e14693 Xf86_video_intel: (master)848ab66384508c3ad3e5fb4884e4527f3ebd3bde Cairo: (master)9d863cd3942c3086c24d67305f7a5892604d0eeb Kernel: (drm-intel-next)0c09e3544863568c52bc4dab73d340e0cf168312 Bug detailed description: ------------------------- x11perf/rgb10text has about 40% regression caused by a commit in Xf86_video_intel on Pineview and 945GM. We bisected out the culprit commit is as following: commit a7b800513fcc94e063dfd68d2f63b6bab7fae47d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 14 21:14:34 2010 +0100 uxa: Extract sub-region from in-memory buffers. If the buffer is too large or not suitable for a GPU operation, we currently fallback and perform the composite on the CPU. An alternative is too extract the small region out of the source (as usually the sample extents are much smaller than the actual surface size) and try the composite with the new surface. The effect is particularly noticeable on pathological websites that use very large background images. For example, http://www.woodtv.com/ uses a 1299x15000 pattern that is obscured by another opaque pattern. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reproduce steps: ---------------- 1.xinit& 2. x11perf -rgb10text
Ouch - that is strange, we shouldn't be anywhere near this code path for rgb text... Oh noes... It's the fail at compositing, try to do 2-pass compositing - where in the first fail we attempt to extract the subregion.
commit f52b6e832292c02c0010b19882e38e1097beeda0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 10 09:39:44 2010 +0100 uxa: Rearrange checking and preparing of composite textures. x11perf regression caused by 2D driver https://bugs.freedesktop.org/show_bug.cgi?id=28047 caused by commit a7b800513fcc94e063dfd68d2f63b6bab7fae47d uxa: Extract sub-region from in-memory buffers. The issue is that as we extract the region prior to checking whether the composite can in fact be accelerated, we perform expensive surplus operations. This is particularly noticeable for ComponentAlpha text, such as rgb10text. The solution here is to rearrange the check_composite() prior to acquiring the sources, and only extracting the subregion if the render path can not actually handle the texture. Performance (on PineView): a7b800513^: aa=68600 glyphs/s, rgb=29900 glyphs/s a7b800513: aa=65700 glyphs/s, rgb=13200 glyphs/s now: aa=66800 glyph/s, rgb=28800 glyphs/s The residual lossage seems to be from the extra function call and dixPrivate lookups. Hmm. More warning is the extremely low performance, however the results are consistent so the improvement looks real...
It indeed fixed this performance regression. verified.
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.