On 17 Jul 2002, Michel Dänzer wrote:

> On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
> > 
> > Attached are patches for r128 on ppc. Rather little change to the r128 code
> > was needed once I gave up on the char arrays for the vertex colors, and
> > embraced the hw specific ordered named fields provided in the *_color_t
> > provided by t_dd_vertex.h.
> > 
> > 1) Revert PACK*LE from texutil.c as per previous emails.
> 
> Thank you for breaking the radeon and mach64 drivers on big endian
> machines. ;) We've got to find a better solution here, I must confess I
> still don't understand how it can not work with PACK*LE though. Maybe
> the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in
> R128EngineInit() in the 2D driver) is interfering, causing the texture
> data to be byte-swapped in the HOST_DATA registers? If so, your changes
> should not be really correct for 16 bit anyway. I've been there while
> playing with the various possibilities of fixing endianness in the
> radeon driver, it looked mostly good but e.g. the floor texture in
> armagetron showed the problem.

I don't have r128 docs, so I'm not sure if it's analogous, but for mach64
we don't set HOST_BIG_ENDIAN_ENABLE in HOST_CNTL, and as far as I know the
DDX doesn't either, so that could make the difference.
 
> > 2) t_dd_vbtmp.h has color assignments in the emit functions that use
> >     char arrays for non-RGBA without attention to endiness. Changed
> >     to use the correctly ordered named fields from the t_dd_vertex.h 
> > definition
> >     of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw
> >     driver can pass in its hw vertex *_color_t; so the assignments can be
> >     made in correct order. Added macro definition to *_vb.c of the
> >     various drivers.
> > 
> > 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use
> >     the named fields instead of an char array.
> > 
> > 4) Added some casts to r128_ioctl.c to eliminate compile warnings.
> 
> These look very good to me, I'll commit them. Leif, can you verify they
> don't break x86? I'd be very surprised, but it wouldn't be the first
> time. :)

I'll give these a try once I've updated my tree, I was testing from 
binaries before.

-- 
Leif Delgass 
http://www.retinalburn.net




-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to