On Wed, 2002-07-17 at 03:32, Henry Worth wrote: > 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 was going to explain how 16 bit textures break with CONVERT_TEXEL instead of CONVERT_TEXEL_DWORD, but that was before APPEND16, which fixes the texel order. With this, it seems we could get away without PACK*LE in the radeon and r128, maybe even mach64 drivers. But can we assume that any chip can swap texel bytes? As chips likely will be little endian internally in the foreseeable future, I think defaulting to that is safest. > 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. That would be a possibility, maybe a texutil driver template. I don't think the current code is really bad though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
