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
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.
For reference I am using c94f28c383f58c9de74678e0f1624db9c5f8a8cb as the common ancestor of a17577c942e774520ca61479e1e48a232b1e27d7.
I hit EIO with c94f28c383f58c9de74678e0f1624db9c5f8a8cb on g45. Care to do a little bisecting to reduce the range?
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.
It now returns to previous value.
verified.
But we can do better! ;-)
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.