Looking a bit at this, this seems to be caused because the number of pixels to read can be less than zero after CLIPSPAN (don't know if that's a bug in itself or not).
That was my first thought, too (moving the window out to the left...) ;-)
This is no problem for the generic read (since the for loop will just terminate instantly), but the mmx/sse/sse2 optimized routines only test if it's 0 pixels to read, and don't bail out if it's less than zero. I haven't looked closely what exactly will happen (i.e. the loops may never terminate at all), but this certainly seems like a bad thing...
Here's a one-liner fix, which will cause CLIPSPAN hopefully never return a negative n1. Seems to work here.
Ian, what do you think? Would it be better to have the optimized read/write functions deal with negative values instead?
Roland
Index: r200_span.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_span.c,v
retrieving revision 1.7
diff -u -r1.7 r200_span.c
--- r200_span.c 26 Jan 2005 18:05:03 -0000 1.7
+++ r200_span.c 1 Mar 2005 18:42:02 -0000
@@ -83,7 +83,7 @@
#define CLIPSPAN( _x, _y, _n, _x1, _n1, _i ) \
- if ( _y < miny || _y >= maxy ) { \
+ if ( _y < miny || _y >= maxy || _x + n < minx || _x >=maxx ) {
\
_n1 = 0, _x1 = x;
\
} else { \
_n1 = _n;
\
@@ -323,6 +323,7 @@
R200_FIREVERTICES( rmesa );
LOCK_HARDWARE( rmesa );
r200WaitForIdleLocked( rmesa );
+ UNLOCK_HARDWARE( rmesa );
/* Read & rewrite the first pixel in the frame buffer. This should
* be a noop, right? In fact without this conform fails as reading
@@ -346,7 +347,7 @@
{
r200ContextPtr rmesa = R200_CONTEXT( ctx );
_swrast_flush( ctx );
- UNLOCK_HARDWARE( rmesa );
+/* UNLOCK_HARDWARE( rmesa );*/
}
void r200InitSpanFuncs( GLcontext *ctx )
