|Summary:||2D performance regression on Ironlake|
|Product:||DRI||Reporter:||Yi Sun <yi.sun>|
|Component:||DRM/Intel||Assignee:||Chris Wilson <chris>|
|Status:||CLOSED FIXED||QA Contact:|
|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 <email@example.com> 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.