From: Felix <fx...@gm...> - 2003-01-28 20:46:37
|
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 <fx...@gm...> 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. __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |