Bug 12923

Oh yes: using 
Option "AccelMethod" "EXA"
maybe this matters ...

I'm not seeing this issue with the latest git code. Are you still be able to reproduce it with the latest git code?

Does it work fine with XAA or NoAccel?

(In reply to comment #2)
> I'm not seeing this issue with the latest git code. Are you still be able to
> reproduce it with the latest git code?
> 
> Does it work fine with XAA or NoAccel?
> 

Yes; I am absolutely able to reproduce the described effect with current, git-checked out versions.
It may be easier to see if you maximize the glxgears window before moving another window in front of it, preferrably with it's upper or lower edge at a height at which the red wheel is displayed too. 

As bug #12922 is still present for me here, too, it is impossible for me to say if a disturbance takes place using XAA - I simply cannot see it.

With 
Option "NoAccel" "True"
the performance is unusably slow; it seems as if the disturbance does not occur. While glxgears displays about 70FPS at it's textual output, the visual impression suggests it's rather 2FPS or the like.

slightly changed setup info:
Dell latitude D830 w. intel 965GM graphics chip
linux 2.6.23.9
xorg-libs (from git 2007-12-10)
xorg-xserver  (from git 2007-12-10)
xorg-drivers (from git 2007-12-10)
Mesa (from git 2007-12-10)
drm (from git 2007-12-10)
pixman (from git 2007-12-10)

(In reply to comment #2)
> I'm not seeing this issue with the latest git code. Are you still be able to
> reproduce it with the latest git code?
> 
> Does it work fine with XAA or NoAccel?

Now that XAA is usable again here, I tried it with XAA. The effect is equally present as with EXA.

Jens, would you please post your x log file and xorg.conf file for reference here? 

Created attachment 13572 [details]
xorg.conf used on Dell D830 (intel 965GM)

Created attachment 13573 [details]
log of xorg which shows disturbance on GLX-content when other window gets moved above

For additional/updated information:

setup:

xorg libs from git (2008-01-07)
libdrm from git (2008-01-07)
pixman from git (2008-01-07)

xorg server 1.4-branch (2008-01-22)
video-intel 2.2-branch (2008-01-22)

Mesa-7.0.2
drm kernel modules from linux-2.6.23.14
linux kernel 2.6.23.14

The described "stripes" still happen when another window is moved above the one with GLX content.

So this happens on both git drivers and stable drivers (Jens performed 2.2.1 release testing).

Jens, would it be possible to get a screenshot or photo of the corruption you're seeing?

Created attachment 14173 [details]
disturbance on "teapot" display when moving xterm above

snapshot of the Mesa-example-application teapot when moving an xterm above it. The disturbances occur at the upper/lower boundaries of the xterm window to the left & the right of it. As the snapshot delays a little, this cannot exactly be seen on the picture.

Created attachment 14174 [details]
disturbance on "glxgears" when moving xterm above

Disturbance on an enlarged glxgears window. The effect is not as clearly visible as in the teapot example as too much of the window is black.

(In reply to comment #9)
> So this happens on both git drivers and stable drivers (Jens performed 2.2.1
> release testing).
> 

Just a tiny info bit:

The effect still persists with Mesa from git (mesa_7_0_branch for Mesa-7.0.3-rc1).

I may be seeing the same thing, though in my case the damaged portions of the glxgears display are restored when the next frame is displayed, so they're really transient.  Is that what you're seeing or is the damage permanent?

Also, do you see the problem if you force indirect rendering?  E.g. LIBGL_ALWAYS_INDIRECT=true glxgears?

(In reply to comment #14)
> I may be seeing the same thing, though in my case the damaged portions of the
> glxgears display are restored when the next frame is displayed, so they're
> really transient.  Is that what you're seeing or is the damage permanent?

No, that is the effect I am seeing too.
I was told to report this, however, as it was speculated if this effect would point to an underlying problem of greater importance (corruption somewhere).

> Also, do you see the problem if you force indirect rendering?  E.g.
> LIBGL_ALWAYS_INDIRECT=true glxgears?

Yes, I see this with LIBGL_ALWAYS_INDIRECT=true also. It's easier to see with the teapot example, though. There, too, it happens regardsless of LIBGL_ALWAYS_INDIRECT=true.

Thanks for providing a screenshot so I knew what to look for.

I've tried to reproduce this on my GM965 with mesa master and a gnome desktop (empathy window) dragged over a maximized glxgears or teapot, and can't see the pictured corruption.

I had no problem reproducing this using the 2.2.1 RC drop downloaded from:
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.2.0.90.tar.gz

Using 965GM and Ubuntu Gutsy. Maximized glxgears and then dragged a gnome calculator window around over it.

Here is two more screenshots:
http://files.minimum.se/bug_attachments/xorg_intel/bug12923/Screenshot-4.png
http://files.minimum.se/bug_attachments/xorg_intel/bug12923/moving_calculator_disturbs_glxgears.png

When running under NoAccel I could not trigger the bug though I got like 1 FPS.

Jens, can you try upgrading your Mesa to master along with your DRM modules?  From Eric's report, it sounds like this may be fixed in git...

(In reply to comment #18)
> Jens, can you try upgrading your Mesa to master along with your DRM modules? 
> From Eric's report, it sounds like this may be fixed in git...

Unfortunately, it's not.

Starting teapot (Mesa example app), dragging xterm up and down in front of it: stripes. It is not visible for the glxgears case, it seems. Doesn't make it easier...

This is with:

linux kernel 2.6.23.16

all parts of xorg (xserver, libs, drivers) from git HEAD of today (2008-02-20)
drm kernel modules from git HEAD of today (2008-02-20)
mesa from git HEAD of today (2008-02-20)

Ok, thanks Jens.  I'll have to dig into how we communicate damage around and how 3D window contents are preserved, I'm not very familiar with it...

I can produce this on mesa_7_0_branch with xserver-1.4, but can't produce with mesa master with xserver master. 

This should be a mesa problem. 

(In reply to comment #21)
> I can produce this on mesa_7_0_branch with xserver-1.4, but can't produce with
> mesa master with xserver master. 

I can reproduce it either way ... but

> This should be a mesa problem. 

you are probably right there, as it's in a GLX area after all...

I talked with Eric about this a little, and there are some potential issues:
  - apps dealing with expose events correctly?
    glxgears doesn't, so any lost bits will have to be re-rendered and
    displayed in the next frame
  - cliprect update races
    the X server will always draw with updated cliprects, but the frame
    displayed by a DRI app may have been rendered with a stale cliprect list
    since the sequence of events is:
    0) cliprects set to X
    1) DRI app acquires lock
    2) DRI app renders
    3) DRI app drops lock
    4) X server acquires lock
    5) X server sets cliprects to Y
    6) X server draws to screen
    7) X server drops lock
    so between 3 and when X renders, the cliprects may have changed, causing
    some artifacts like what you see

Eric, did I capture that right?  Re-directed direct rendering should solve this problem, since there won't be any clipping race, but it's odd that you see it with the latest bits while Zhenyu wasn't (I'll try again).

(In reply to comment #23)

> [..snipped..] Re-directed direct rendering should solve this
> problem, since there won't be any clipping race, but it's odd that you see it
> with the latest bits while Zhenyu wasn't (I'll try again).

The effect I'm seeing are black stripes across the displayed area, for which glxgears may not be too good an example to see them; especially if the are gone quite instantaneously.
The teapot program from Mesa might be better suited because of the lighter "floor". But it's definitely still there, checked it today with everything from git (2008-03-31).

Additionally, when teapot runs and I move a glxgears window up and down ANYWHERE on the screen, quite intense disturbances get displayed in the teapot area.

Marking this one as fixed since it should be with DRI2.

(In reply to comment #25)
> Marking this one as fixed since it should be with DRI2.
> 

I can confirm that it is.
It's also fixed with 

kernel 2.6.28
libdrm-2.4.4
xserver master
xorg-libs (all master)
xf86-video-intel-2.6.0

and running EXA, too.