Charl P. Botha wrote:
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.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 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.
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
-------------------------------------------------------
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
