Bug 31043

Summary: [bisected piketon] rendercheck repeat and triangles failed
Product: DRI Reporter: fangxun <xunx.fang>
Component: DRM/IntelAssignee: Chris Wilson <chris>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: jbarnes
Version: unspecified   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description fangxun 2010-10-22 01:58:45 UTC 
System Environment:
--------------------------
Arch    x86_64
Platform    piketon
Libdrm:         (master)2.4.22-3-g09b1062628f2cbddb3ebae20e7b3b8a0a93acebf
Mesa:           (master)289900439f0f327910496f6bc362b95930eebb53
Xserver: (master)xorg-server-1.9.0-177-gd738175eaf1098e29b8afb6de8e99b5098e366a7
Xf86_video_intel: (master)2.12.902-23-ga1c54f69643671ce296c57d132852e9846cc41d3
Kernel: (drm-intel-next)69dc4987cbe5fe70ae1c2a08906d431d53cdd242


Bug detailed description:
-------------------------
Bisect shows 9af90d19f8a166694753b3f0558d3a8bcd66c0b5 is the first bad commit.
commit 9af90d19f8a166694753b3f0558d3a8bcd66c0b5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Oct 17 10:01:56 2010 +0100

    drm/i915: cache the last object lookup during pin_and_relocate()

    The most frequent relocation within a batchbuffer is a contiguous sequence
    of vertex buffer relocations, for which we can virtually eliminate the
    drm_gem_object_lookup() overhead by caching the last handle to object
    translation.

    In doing so we refactor the pin and relocate retry loop out of
    do_execbuffer into its own helper function and so improve the error
    paths.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
 

Reproduce steps:
----------------
1.xinit&
2.run rendercheck repeat
Comment 1 Chris Wilson 2010-10-22 02:56:32 UTC 
commit 878a3c37d36142a192bdf5b6bfcf920832f431d7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 22 10:48:12 2010 +0100

    drm/i915: Fix flushing regression from 9af90d19f
    
    Whilst moving the code around in 9af90d19f, I dropped the or'ing in of
    new write domains which would zero out the write domain for a render
    target if later reused as a source later in the batch. This meant that
    we might drop a required flush before reading from the render target.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31043
    Reported-by: xunx.fang@intel.com
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 2 fangxun 2010-10-25 01:15:10 UTC 
Verified with Kernel:
(drm-intel-next)b6651458d33c309767762a6c3da041573413fd88
Comment 3 madbiologist 2010-11-03 08:59:02 UTC 
This fix has been included in kernel 2.6.37-rc1
Comment 4 Elizabeth 2017-10-06 14:53:36 UTC 
Closing old 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.