Bug 28047

Summary: [bisected] x11perf regression caused by 2D driver
Product: xorg Reporter: zhao jian <jian.j.zhao>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: VERIFIED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high    
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg.0.log none

Description zhao jian 2010-05-10 00:37:23 UTC 
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
Comment 1 Chris Wilson 2010-05-10 00:46:29 UTC 
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.
Comment 2 Chris Wilson 2010-05-10 02:49:30 UTC 
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...
Comment 3 zhao jian 2010-05-14 08:47:34 UTC 
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.