On Tue, 10 Dec 2002 10:37:07 +0000
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Charl P. Botha wrote:
> > On Mon, Dec 09, 2002 at 10:30:35PM +0000, Keith Whitwell wrote:
> >
> >>Charl P. Botha wrote:
> >>
> >>>On Mon, Dec 09, 2002 at 09:45:12PM +0000, Keith Whitwell wrote:
> >>>
> >>>>There's a fix for this in recent cvs:
> >>>>
> >>>> /* Mask out highest bit, which is used by AMD for 3dnow
> >>>> * Newer Intel have this bit set, but do not support 3dnow
> >>>> */
> >>>> AND_L ( CONST(0X7FFFFFFF), EAX)
> >>>
> >>>
> >>>I still could reproduce this SIGFPE with yesterday's CVS. I just did a
> >>>grep
> >>>though all the .c and .h files in my DRI CVS tree for "Mask out highest
> >>>bit"
> >>>but could not find the above. In which file should this be?
> >>
> >>xc/extras/Mesa/src/X86/common_x86_asm.S
> >
> >
> > Okay, I just checked and I can still reproduce a SIGFPE with today's CVS.
> > I've made doubly sure that the new libGL is used. Here is a backtrace:
> >
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x4246fe4a in _mesa_sse_transform_points3_general ()
> > from /usr/X11R6/lib/modules/dri/radeon_dri.so
> > (gdb) bt
> > #0 0x4246fe4a in _mesa_sse_transform_points3_general ()
> > from /usr/X11R6/lib/modules/dri/radeon_dri.so
> > #1 0x0840b6a0 in ?? ()
> > #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174)
> > at t_vb_vertex.c:286
> > #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154
> > #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089
> > #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60)
> > at t_imm_exec.c:399
> > #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60)
> > at t_imm_exec.c:424
> > #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60)
> > at t_imm_exec.c:493
> > #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60)
> > at t_imm_api.c:77
> > #9 0x4241e5f1 in _tnl_Vertex3f (x=39.2000008, y=46.7999992, z=17)
> > at t_imm_api.c:834
> > #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657,
> > y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660,
> > diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0)
> > at
>/home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113
> >
> > DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any
> > ideas?
>
> It looks like a new/different problem to the one fixed earlier. It's tempting
> to say it's a bug in the assembly, but otoh that code has been pretty widely
> used without change over the last couple of years.
>
> It may be a result of the new gcc's ability to put sse, mmx into normal code -
> this has bitten us a couple of times.
As far as I can tell it is a bug in gcc if you get mmx instructions in
normal output. It would break the kernel. As a test I once compiled my
kernel with gcc-3.2 -S and grepped for "%mm". All I found was some
inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems
is to compile with -mno-mmx -mno-3dnow.
The use of SSE for normal floating point operations is another thing,
though. But according to gcc-3.2 docs -mfpmath=387 should be the
default.
>
> The debugger should be able to show you the assembly instruction on which this
> fails. 'disassemble' is the command. 'info regs' will show the contents of
> the registers at this point.
>
> Basically it's standard debugging: What went wrong, why?
>
> Keith
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
