Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger: > Dieter Nützel wrote: > >>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? Ian, any thoughts? Thanks, Dieter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter NÃtzel:
Any change that someone look into this?
Ian, it seems that's related to your new SSE/MMX code.
Thanks,
Dieter
> Move window 'out' to the left.
>
> NO sigfault with MESA_NO_SSE and MESA_NO_MMX.
>
> With MMX:
> #0 0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
>from /usr/X11R6/lib/modules/dri/r200_dri.so
> (gdb) list
> 262
> 263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 *
> sizeof(GLubyte));
> 264assert(TempImage);
> 265 }
> 266
> 267
> 268 int
> 269 main( int argc, char *argv[] )
> 270 {
> 271GLboolean ciMode = GL_FALSE;
> (gdb) bt
> #0 0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
>from /usr/X11R6/lib/modules/dri/r200_dri.so
> #1 0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194,
> x=5, y=229, rgba=0x45024008) at spantmp2.h:415
> #2 0x40602944 in read_fast_rgba_pixels (ctx=0x8060928, x=5, y=20,
> width=2147465314, height=188, format=6408, type=5121,
> pixels=0x7fffb862, packing=0x45048000) at swrast/s_readpix.c:288
> #3 0x406029f5 in read_rgba_pixels (ctx=0x8060928, x=5, y=20, width=194,
> height=188, format=6408, type=5121, pixels=0x45024008,
> packing=0xbfffeb30) at swrast/s_readpix.c:324
> #4 0x40603237 in _swrast_ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
> height=188, format=6408, type=5121, packing=0xbfffeb30,
> pixels=0x45024008) at swrast/s_readpix.c:556
> #5 0x405552e5 in r200ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
> height=188, format=6408, type=5121, pack=0x8073c24, pixels=0x45024008)
> at r200_pixel.c:281
> #6 0x4064bd44 in _mesa_ReadPixels (x=2147465314, y=2147465314, width=194,
> height=188, format=2147465314, type=2147465314, pixels=0x7fffb862)
> at main/drawpix.c:171
> #7 0x0804942f in Display () at readpix.c:141
> #8 0x40045f8e in processWindowWorkList () from /usr/lib/libglut.so.3
> #9 0x4004601a in __glutProcessWindowWorkLists () from
> /usr/lib/libglut.so.3 #10 0x4004608b in glutMainLoop () from
> /usr/lib/libglut.so.3
> #11 0x080499e7 in main (argc=1, argv=0xbfffedf4) at readpix.c:287
> (gdb) info registers
> eax0x7fffb862 2147465314
> ecx0x45048000 1157922816
> edx0xfe12 -494
> ebx0x4091c140 1083294016
> esp0xbffe69e8 0xbffe69e8
> ebp0xbffe6a28 0xbffe6a28
> esi0x2ee750
> edi0x0 0
> eip0x406a92b5 0x406a92b5
> eflags 0x10212 66066
> cs 0x73 115
> ss 0x7b 123
> ds 0x7b 123
> es 0x7b 123
> fs 0x0 0
> gs 0x33 51
>
>
> With SSE:
> #0 0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
>from /usr/X11R6/lib/modules/dri/r200_dri.so
> (gdb) list
> 262
> 263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 *
> sizeof(GLubyte));
> 264assert(TempImage);
> 265 }
> 266
> 267
> 268 int
> 269 main( int argc, char *argv[] )
> 270 {
> 271GLboolean ciMode = GL_FALSE;
> (gdb) bt
> #0 0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
>from /usr/X11R6/lib/modules/dri/r200_dri.so
> #1 0xff131f11 in ?? ()
> (gdb) info registers
> eax0xff4d4d4d -11711155
> ecx0x4504826c 1157923436
> edx0x0 0
> ebx0x407f7404 1082094596
> esp0xbffe69e0 0xbffe69e0
> ebp0xbffe69f0 0xbffe69f0
> esi0xfddf -545
> edi0x0 0
> eip0x406a931d 0x406a931d
> eflags 0x10203 66051
> cs 0x73 115
> ss 0x7b 123
> ds 0x7b 123
> es 0x7b 123
> fs 0x0 0
> gs 0x33 51
--
Dieter NÃtzel
@home:
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Roland Scheidegger wrote: 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? Ah crap those UNLOCK_HARDWARE changes of course are not supposed to be there. They are just there to make my life a lot easier for debugging... Roland --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Dieter NÃtzel wrote:
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 - 1.7
+++ r200_span.c 1 Mar 2005 18:42:02 -
@@ -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 )
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Am Dienstag, 1. MÃrz 2005 18:06 schrieb Roland Scheidegger: > Dieter NÃtzel wrote: > > Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter NÃtzel: > > > > Any change that someone look into this? > > > > Ian, it seems that's related to your new SSE/MMX code. > > > > Thanks, > > Dieter > > > >>Move window 'out' to the left. > >> > >>NO sigfault with MESA_NO_SSE and MESA_NO_MMX. > >> > >>With MMX: > >>#0 0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX () > >> from /usr/X11R6/lib/modules/dri/r200_dri.so > >>#1 0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194, > >>x=5, y=229, rgba=0x45024008) at spantmp2.h:415 > > 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... ;-) Thanks, Dieter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger: > Dieter Nützel wrote: > >>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? Works, even without UNLOCK_HARDWARE changes ;-) Cheers, Dieter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Dieter NÃtzel wrote: Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter NÃtzel: Any change that someone look into this? Ian, it seems that's related to your new SSE/MMX code. Thanks, Dieter Move window 'out' to the left. NO sigfault with MESA_NO_SSE and MESA_NO_MMX. With MMX: #0 0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194, x=5, y=229, rgba=0x45024008) at spantmp2.h:415 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). 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... Roland --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
