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. 2) How bigEndian affects how we layout hardware texture formats. It doesn't help that the mesa texture format structs don't really specify the format -- they give a few details but they don't tie the structure down so it means you have to peer into the implementations of the fetch and store functions, or guess from the name to figure out what it really means. Hence you end up with things like "rgb" and "rgb888" having apparently different component ordering, for instance. Keith Keith ------------------------------------------------------------------------- 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
