Felix K�hling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm loop. So in the first cycle MM0 and MM1 were
undefined. Furthermore it read one extra normal at the end of the array
which was never processed.
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Felix
On Tue, 28 Jan 2003 18:02:57 +0100
Felix K�hling <[EMAIL PROTECTED]> wrote:
Hi,
I recently discovered some problem with normal vectors in the gflux hack
on my Duron, Radeon 7500 with and without TCL, even with
RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though.
A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals
in gflux and change glEnable(GL_NORMALIZE) to
glEnable(GL_RESCALE_NORMAL). By playing around with the -squares option
of gflux I could determine that every 216th normal vector is not
normalized correctly.
The normalization function used is
_mesa_3dnow_transform_normalize_normals in
xc/extras/Mesa/src/X86/3dnow_normal.S. I don't understand where the
"magical" 216 comes from. My guess is that
_mesa_3dnow_transform_normalize_normals always gets 216 normals to
transform and forgets one of them (first one or last one, can't tell). I
hope this info helps someone to spot the error quickly.
I've applied the patch to the Mesa and DRI trees. Thanks!
-Brian
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
