Felix, On Sun, Oct 13, 2002 at 02:47:18AM +0200, Felix Kühling wrote:
More results:I get the same strange behaviour when I compile with -march=pentium2. I could narrow it down to lib/GL/mesa/src/drv/radeon/radeon_state.c. Then I split radeon_state.c and put only one non-static function at a time in a new radeon_state2.c along with the necessary static functions. Only radeon_state2 was compiled with -march=athlon. I could reproduce the error with only radeonUpdateScissor and radeonUpdateViewportOffset in radeon_state2.c. On the other hand I don't get the error if I compile everything with -march=athlon except radeon_state2.c which means that I've neatly isolated the problem :)
Nice detective work! ;-)
I don't have the Athlon processor documentation with me, but when usingI had gcc generate assembler output for radeon_state2.c with -mcpu=athlon and -march=athlon. A diff of the two assembler files and radeon_state2.c (for comparing line numbers) are attached. The version compiled with -march=athlon uses %mm0, the other one doesn't. My guess is that some other part of the radeon driver or Mesa makes assumptions about the MMX state which are not true when compiling with -march=athlon.
MMX there are two things that _usually_ must be done:
- never mix MMX with FP code, since they both use the same internal registers
- for the reason above, one has to call the EMMS instruction before
making FP calculations after using MMS
Both of these rules aren't being followed below. I know that newer
processors don't have some of these limitations (I know at least that
calling EMMS doesn't take so long as in the original Pentium MMX) but only once I refer to the specs I can be sure that gcc isn't generating wrong code here.
Another issue is that when using %mm0 it's moving 64 bits back and
forward, but on the pentium2 code, it only moves 32 bits. I'm not sure if
the code semantics allow this - it would be necessary to match the
assembly with the C code to actually see if this is OK.
I tried disabling MesaUse3DNow and MesaUseMMX in host.def, but that didn't help.
[...] If above is true, then it doesn't depend of MMX being used elsewhere to cause the bug. José Fonseca
@@ -212,25 +212,23 @@ .loc 1 93 0 movl 216(%ebx), %edx .loc 1 91 0 - movl -24(%ebp), %esi + movd -24(%ebp), %mm0 .loc 1 93 0 fildl 8(%edx) movl %ecx, -24(%ebp) flds -24(%ebp) fxch %st(1) - fucompp - fnstsw %ax - andb $69, %ah - xorb $64, %ah + fucomip %st(1), %st + fstp %st(0) jne .L14 + jp .L14 fildl 16(%edx) - movl %esi, -24(%ebp) + movd %mm0, -24(%ebp) flds -24(%ebp) fxch %st(1) - fucompp - fnstsw %ax - andb $69, %ah - cmpb $64, %ah + fucomip %st(1), %st + fstp %st(0) + jp .L14 je .L13 .L14: .loc 1 105 0 @@ -240,7 +238,7 @@ .LBE6: movl %ecx, 8(%edx) .loc 1 100 0 - movl %esi, 16(%edx) + movd %mm0, 16(%edx) .loc 1 111 0 .LBB7: movl $31, %edx
------------------------------------------------------- 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
