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. > You're welcome.
At least with the mesa demos it works the same in 16 and 32 bpp... I did see some oddness in 16bpp before fixing the copies in the t_dd_vbtmp.h emit funcs. I don't have the HW docs, so someone else will have to address that. Any byteswapping at that level would have to be aware of the texel size or it'd also be swapping sub-32bpp texels out of order. But, if it is due to a hw capability, then the sw arch needs to handle that, i.e. make the PACK*LE configurable. Which would probably mean texutil would need to be compiled at the driver level, rather than the common level. ------------------------------------------------------- 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
