Bug 32034 - 2D performance regression on Ironlake
Summary: 2D performance regression on Ironlake
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact:
Depends on:
Reported: 2010-12-01 19:09 UTC by Yi Sun
Modified: 2016-12-07 16:17 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Yi Sun 2010-12-01 19:09:47 UTC
Arch:           x86_64
OSD:      Fedora release 13 (Goddard)
Libdrm:   (master)2.4.22-17-g1443bea488f6ad47cb4469c01b35aea0377822c0
Mesa:    (master)31aeac5bf91f3b1daacb1aa27505bfb25215da87
Xserver: (master)xorg-server-1.9.0-332-g23e3d1f23318ce69623f91908f888a09f8b74ac2
Xf86_video_intel: (master)2.13.901-5-g0bb135c40e5ac1bf7593ec1d68d2815cbf47aa25

Bug detailed description:
On Ironlake platform, kernel causes 2D performance regression. We used the same X but different kernel and we get the apparent different mark:

x11perf -rgb10text:   592000.0/sec    491000.0/sec     17%regression

We got the fist data(592000) with kernel (drm-intel-next)a17577c942e774520ca61479e1e48a232b1e27d7
and the second date(491000) with kernel (drm-intel-next)7d2cb39c332146b0906651a8567f8b81af4b1584

Reproduce steps:
1. xinit& 
2. x11perf -rgb10text
Comment 1 Chris Wilson 2010-12-02 00:41:46 UTC
Ok, there are a bunch of correctness fixes in there that could impose a performance impact. I think just one of those could be reworked to be correct without degrading performance if indeed it is the culprit...

I presume this is the machine that fails to light up on output and so bisecting would be more difficult than usual? I shall see if I can reproduce the same regression on g45.
Comment 2 Chris Wilson 2010-12-02 00:50:43 UTC
For reference I am using c94f28c383f58c9de74678e0f1624db9c5f8a8cb as the common ancestor of a17577c942e774520ca61479e1e48a232b1e27d7.
Comment 3 Chris Wilson 2010-12-02 00:57:09 UTC
I hit EIO with c94f28c383f58c9de74678e0f1624db9c5f8a8cb on g45. Care to do a little bisecting to reduce the range?
Comment 4 Chris Wilson 2010-12-02 01:24:25 UTC
After a little bit of manual poking:

de18a29e0fa3904894b4e02fae0e712cd43f740c^: 452000.0/sec
de18a29e0fa3904894b4e02fae0e712cd43f740c:  337000.0/sec

commit de18a29e0fa3904894b4e02fae0e712cd43f740c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Nov 27 22:30:41 2010 +0100

    drm/i915: fix regression due to ba3d8d749b01548b9
    We don't track gpu flush request in any special way. So even with
    obj->write_domain == 0, a gpu flush might be outstanding but no
    yet executed. Even worse, the latest request might use the object
    only for reading. So and unconditional call to object_wait_rendering
    is needed for !pipelined.
    Hence revert that patch fully and untangle the flushing from the
    synchronization again.

Fortunately this is one I think we can improve.
Comment 5 zhao jian 2010-12-10 07:15:28 UTC
It now returns to previous value.
Comment 6 zhao jian 2010-12-10 07:15:50 UTC
Comment 7 Chris Wilson 2010-12-10 07:30:24 UTC
But we can do better! ;-)
Comment 8 Jari Tahvanainen 2016-12-07 16:17:12 UTC
Closing old verified+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.