Bug 36776 - Artifacts and delayed rendering in xterm
Summary: Artifacts and delayed rendering in xterm
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-02 08:51 UTC by Cedric Sodhi
Modified: 2011-05-07 12:04 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (29.71 KB, application/octet-stream)
2011-05-02 08:51 UTC, Cedric Sodhi
no flags Details
lspci -nv (7.07 KB, application/octet-stream)
2011-05-02 08:53 UTC, Cedric Sodhi
no flags Details
Ensure that the batch is flushed. (1.90 KB, patch)
2011-05-07 11:55 UTC, Chris Wilson
no flags Details | Splinter Review

Description Cedric Sodhi 2011-05-02 08:51:31 UTC
Created attachment 46256 [details]
Xorg log

The setup is as follows:

Intel(R) Core(TM) i5 CPU       U 430
IGD Intel Arrandale (Hybrid Graphics with ATI Radeon CEDAR, powered off), KMS on both drivers, compiled in, regular FB con.

The problem is that despite DRI, DRI2, GLX acceleration and a WW and EE free Xorg.log I experience artifacts and wrong buffer redraws in xterm (rxvt-unicode to be exact). Same system, with the Radeon running, no such problem.

The problem is most apparent when xcompmgr is running and looks temporarily solved when latter is killed, but it persists nonetheless.

Attached, Xorg.0.log and lspci -nv

Driver version is 2.15
Server version is 1.9.5
Comment 1 Cedric Sodhi 2011-05-02 08:53:00 UTC
Created attachment 46257 [details]
lspci -nv
Comment 2 Chris Wilson 2011-05-07 11:55:09 UTC
Created attachment 46427 [details] [review]
Ensure that the batch is flushed.
Comment 3 Chris Wilson 2011-05-07 12:04:58 UTC
commit 3145530feed879082bcfab11ffc8e7fd0911c920
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat May 7 19:51:04 2011 +0100

    Ensure that the partial batch is flushed upon the blockhandler
    
    Currently, we require that a batch containing a dirty bo be submitted
    before we mark the device as requiring a flush. So if we never submit a
    batch between block handlers, we can end up sleeping without ever
    flushing either the partial batch or the rendering to the scanout.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36776
    Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


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.