From: Dave A. <ai...@li...> - 2003-05-21 22:02:44
|
> The i810 docs on Intel's web site say that bit 26 can be 0 or 1. If 0, > the "default" colour depth is used (I'm not sure where that's set). If > 1, 24:25 must be programmed. As you say, the i815 docs say bit 26 must > be 1, and thus 24:25 used. > > Does programming these correctly help? unfortunately not .. I've fixed up the calls to these and still no joy.. it's definitely the depth buffer color blt (one in i810_dri.c/i810_accel.c and the other in DRM dispatch_clear) that cause the issue, I could believe it to be a software issue if the BLT destroyed the start of the back buffer, but somehow it is corrupting a very specific area towards the end... so looks like hardware issue, I might be able to setup an ICE to break on a memory write in that region today, but I've had trouble before with getting the iCE and Linux to co-exist.. i'll probably escalate it to Intel developer support via the company I'm doing this for ... > There is some code in the 2D driver to work around an apparent bug. > See I810SubsequentScreenToScreenCopy(). The comment there is: > > /* > * This works around a bug in the i810 drawing engine. > * This was developed empirically so it may not catch all > * cases. > */ i've seen this but not had time to analyse it completely.... next on my list... Thanks all, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / ai...@sk... pam_smb / Linux DecStation / Linux VAX / ILUG person |