System Environment: -------------------------- Arch x86_64 Platform piketon Libdrm: (master)2.4.22-14-g877b2ce15b80975b4dac42657bdfb0a3da833e1c Mesa: (master)5b8ed2f6d2e14303c55aeca65cdbc20791e820f6 Xserver: (server-1.9-branch)xorg-server-1.9.2-7-g46314e1e7ad05d6ff6a2f722b09a76f2931db7f5 Xf86_video_intel: (master)2.13.901-2-g3c5b1399e29ef577b8b91655b5e1c215d1b6dfbb Kernel: (drm-intel-fixes)69669455b049c0f1f04bb306625c5d4db6838b11 Bug detailed description: ------------------------- cairo test operator-source, clear-source, device-offset-fractional, filter-nearest-offset, pixman-rotate and xcomposite-projection regresses on piketon. Bisect shows 3c5b1399e29ef577b8b91655b5e1c215d1b6dfbb is first bad commit. commit 3c5b1399e29ef577b8b91655b5e1c215d1b6dfbb Author: Chris Wilson <chris@chris-wilson.co.uk> AuthorDate: Tue Nov 9 20:20:06 2010 +0000 Commit: Chris Wilson <chris@chris-wilson.co.uk> CommitDate: Tue Nov 9 20:20:06 2010 +0000 i915: Disable maximum state addresses As the kernel controls the relocation of state buffers, we should not hard code the maximum permissible value for them. Fixes an eventual hang with full-gtt. Reported-by: Peter Clifton <pcjc2@cam.ac.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Interesting. Maximum GTT address on that branch is 0x10000000 so there should have been no functional change. :( Are the failures 100% reproducible? i.e. something like xinit & CAIRO_TEST_TARGET=xlib DISPLAyY=:0 ./cairo-test-suite xcomposite-projection is sufficient to reproduce?
Yes, it is sufficient to reproduce this. Output on screen: [root@x-pk1 test]#CAIRO_TEST_TARGET=xlib ./cairo-test-suite xcomposite-projection TESTING cairo-test-suite Compiled against cairo 1.11.1, running on 1.9.7. Compiled against pixman 0.19.5, running on 0.21.1. TESTING xcomposite-projection xcomposite-projection.xlib.argb32 [0]: FAIL xcomposite-projection.xlib.rgb24 [0]: FAIL xcomposite-projection.xlib-fallback.rgb24 [0]: PASS xcomposite-projection: FAIL (xlib) 0 Passed, 1 Failed [0 crashed, 0 expected], 0 Skipped xlib (argb32): 1 failed - xcomposite-projection xlib (rgb24): 1 failed - xcomposite-projection
Works for me :( I wonder if it was related to: 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. Reported-by: Keith Packard <keithp@keithp.com> Tested-by: Keith Packard <keithp@keithp.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I've been unable to reproduce, so I am assuming that the flush fix is good.
(Not that I understand how it relates to the bisected culprit.)
It works well with current code. 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.