On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Thu, 2006-09-21 at 16:29 +0100, Keith Whitwell wrote:> > OK, that's > > kooky. I guess I haven't got a handle on the problem yet for > bigEndian, > > it may be that there's another conversion needed on the back end. > > It could also be that there's now a mismatch between this code and > > thedriver... > > There should be no net change as a result of this work, so there > shouldn't be any need to change the driver. That's how it's worked on > littleEndian, anyway. > > I found one obvious bug which I'll commit, but I'm thinking I'll have to > disable this path on bigEndian until someone can explain to me: > > 1) How bigEndian affects how we interpret source data relative to its > format and type.
Should just require byte swapping for the conversion from packed type to byte array. > 2) How bigEndian affects how we layout hardware texture formats. It shouldn't right now, all the hardware drivers known to work on big endian take texture data in little endian. I'm investigating the swizzle paths, thanks for disabling them for now. My gut feeling is that the destination byte order should be handled slightly more explicitly; in particular, I don't see a way for drivers to specify which byte order they want for packed formats where component boundaries don't fall on byte boundaries (so _REV doesn't correspond to byte swapping). -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
