Fwd: Xft rendering corrupted with glamor enabled driver

[Gaetan Nadon]

Perhaps Wolfgang was not aware of the glamor mailing list.

-------- Original Message --------
Subject: 	Xft rendering corrupted with glamor enabled driver
Date: 	Sat, 14 Dec 2013 14:37:52 +0100
From: 	Wolfgang Draxinger <wdraxinger.maillist at draxit.de>
Organization: 	DraxIT
To: 	xorg-devel at lists.freedesktop.org



Hi,

I'm running a system of the following configuration 

lspci output on the graphics controller:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07)

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)

extracted from Xorg.log

X.Org X Server 1.14.3 - Release Date: 2013-09-12

X Protocol Version 11, Revision 0
Build Operating System: Linux 3.11.0-gentoo x86_64 Gentoo
Current Operating System: Linux narfi 3.11.0-gentoo #2 \
 SMP PREEMPT Sat Sep 14 14:51:00 CEST 2013 x86_64
Kernel command line: quiet root=/dev/sda2 \
 BOOT_IMAGE=/kernel-3.11.0-gentoo 
Build Date: 08 November 2013  01:42:15AM

(II) LoadModule: "intel"
(II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
     compiled for 1.14.3, module version = 2.21.15
     Module class: X.Org Video Driver
     ABI class: X.Org Video Driver, version 14.1

libXft version is 2.3.1

Now for my observation: When I build the video driver with glamor
support I notice that ocassionally glyphs rendered with Xft become
corrupted. It's not looking like random bitnoise, but that while Xft is
rendering to the pixel buffer, or while the pixel buffer is drawn to
the framebuffer the configuration of the buffer changes. The pixels
clearly come from a Xft rendering (the colors they have match those
found in the pixel values of the neighboring characters).

A foolproof way to trigger this was to have a full screen xterm and
dump it full of random characters (I have to admit I never tried what
happens if it were all the same character). And then you'd make the
xterm redraw (for example by repeatingly sending it expose events).
Then you'd see characters "flicker" between rendered corrupted and
intact. I didn't quantify it, but it looked like there was a certain
distance between characters being corrupted which was very regular. It
however never hit the same spots between each redraw but you could
clearly see some regularity and clustering. This was as if there was
some beating between the amount of characters drawn and the frequency
the corruption happens plus some undetermined offset due to noise
(other things drawn, timing differences in the scheduler, who knows).

When I first noticed that I had a lot of suspicions on the
cause (software and hardware problems and so on). I used the usual
divide and conquer methods to narrow down the problem to glamor.

Given my long time experience with OpenGL (and having exploited several
undefined things in particular implementations for various hacks) this
makes sense. To me it looks like a race condition between the code that
fills a pixel buffer (area) reserved for a glyph and the code that
brings it to the screen later. Most likely there is a synchronization
point missing somewhere in the command stream.

So if this is a race condition between an image object (PBO or texture)
being used for drawing and the same object being allocated, filled with
data or freed up, I can see two possible scenarios:

- The buffer is used for draw before fully prepared and having its
  drawing parameters set.

Or

- while the drawing progress happens the contents of the buffer or
  its associated drawing parameters are altered too early.

Of course it could be a combination of both. Right now I'm running a
glamor-less build and have no screenshots. But I could rebuild the
drivers with glamor (hoping the problem didn't magically vanish) and
provide screenshots if required.

So far I've seen the problem only happening for Xft, but I didn't look
at other XRender based stuff. It may be, that those are affected as
well. However I can rule out core drawing routines and regular OpenGL
operations from being affected.

I'm wondering if this is a problem isolated to the video-intel driver
or if this is located in the shared glamor code.

Given the fact that parts of glamor code may end up in Wayland based
rendering backend and that text is the most important information on a
computer screen I think that this problem deserves some attention.


Regards

Wolfgang
_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131214/11f9b544/attachment-0001.html>