OSD: Fedora release 13 (Goddard)
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
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:
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
Fortunately this is one I think we can improve.
It now returns to previous value.
But we can do better! ;-)
Closing old verified+fixed.