Intel driver fixes for 855GM - textures after resume

Peter Clifton pcjc2 at
Mon Oct 22 13:27:33 PDT 2007

Below is a workaround / fix for the bug I've been looking at
where textured surfaces are corrupted after resume from S3 sleep:

--- xserver-xorg-video-intel-2.1.1.orig/src/i830_driver.c       2007-10-21 22:08:58.000000000 +0100
+++ xserver-xorg-video-intel-2.1.1/src/i830_driver.c    2007-10-21 22:28:04.000000000 +0100
@@ -3055,6 +3067,7 @@
    /* Mark 3D state as being clobbered */
    *pI830->last_3d = LAST_3D_OTHER;
+   IntelEmitInvarientState(pScrn);
    return TRUE;

Whilst this fixes the symptom, its not clear why similar problems aren't
manifested on different chips using this same code-path.

I'm wondering if the underlying issue might be in the hand-off between
the DRI client(s) (MESA?), and the X-server as its VT is switched prior
to suspend. (I think this VT switch is still the case.)

It isn't immediately clear to me whether the
IntelEmitInvarientState(pScrn) call solves the issue with the state it
emits, such as:

      OUT_RING(pI830->logical_context->offset |

Or whether it has more to do with ensuring any DRI clients have their
context revoked (and will emit clean state when they get it back):

	/* Mark that the X Server was the last holder of the context */
	if (sarea)
		sarea->ctxOwner = DRIGetContext(pScrn->pScreen);

I'd appreciate comments as to whether this fix is the "correct" one to
apply, or whether there is some underlying issue with the ownership of
DRI context across suspend / resume.

Perhaps the invariant state emitted by the Xorg intel driver resets more
registers than MESA does when it regains the context?

Does anyone who knows the 3D systems / intel driver have any comments on
the above (I have very little understanding of the 3D architecture, not
helped by the lack of available documentation).

We'd _really_ like to get either this wokaround/fix, or a more complete
solution SRU'd for the recent Ubuntu release, and it would be far easier
to get this approved if someone who knows the code-base could comment on
the implications of the change.

Best wishes,

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,

Tel: +44 (0)7729 980173 - (No signal in the lab!)

More information about the xorg mailing list