[Glamor] Xft rendering corrupted with glamor enabled driver

[zhigang gong]

I can't reproduce this bug on my system. Just did what you said,
dump a large file to the xterm console directly, and then send
expose to it repeatedly.  Everything seems work fine.

Could you send a full xorg.0.log to the list? And if possible, a photo
of the corrupted screen may be also helpful here.

Thanks,
Zhigang Gong.


On Sat, Dec 14, 2013 at 11:35 PM, Wolfgang Draxinger <
wdraxinger.maillist at draxit.de> wrote:

> Hi,
>
> I submitted the same report to the xorg-devel maillist and was kindly
> asked to submit this to the glamor maillist as well.
>
> 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
> _______________________________________________
> Glamor mailing list
> Glamor at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/glamor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/glamor/attachments/20131216/4dd8f380/attachment.html>