On Tue, 28 Jan 2003 15:05:30 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> > I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this
> > code is disabled anyway, so there is not really a hurry to apply my
> > stupid little patch. About this reading backward thing, where is that
> >
Ian Romanick wrote:
Felix Kühling wrote:
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Good catch. It looks like this went into the Mesa
On Wed, 29 Jan 2003 03:00:00 +0100 (MET)
Peter Finderup Lund <[EMAIL PROTECTED]> wrote:
> On Tue, 28 Jan 2003, Felix Kühling wrote:
>
> > prefetching looks odd to me. In the first transform loop in
> > _mesa_3dnow_transform_normalize_normals memory is prefetched which is
> > never read but only w
Am Mittwoch, 29. Januar 2003 00:05 schrieb Ian Romanick:
> Felix Kühling wrote:
> > On Tue, 28 Jan 2003 13:10:41 -0800
> >
> > Ian Romanick <[EMAIL PROTECTED]> wrote:
> >>Felix Kühling wrote:
> >>>The patch moves the load operations back to the front of the loop as in
> >>>the G3TN_norm_w_lengths c
On Tue, 28 Jan 2003, Felix Kühling wrote:
> prefetching looks odd to me. In the first transform loop in
> _mesa_3dnow_transform_normalize_normals memory is prefetched which is
> never read but only written. This is obviously useless. Then in the
No -- at least not *obviously* useless. Whether it
Felix Kühling wrote:
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Good catch. It looks like this went into the Mesa tree back in October
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> 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
> >
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 glEna
