Keith Whitwell wrote: > Michel Dänzer wrote: >>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).
The destination format (_mesa_format_*) is already explicit in specifying where each texel component sits in the word-, half-word-, or byte-sized texel. See the texformat.h file. > At the moment the swizzle path only touches texture formats which have > component boundaries on byte boundaries. > > The swizzle code shouldn't be doing anything *new* - all the information > on how to do the right thing is already there in each case, and the job > is being done correctly by the generic paths. > > I think from Brian's description of the meaning of the texture format > struct naming, a driver that wanted a different component order in a > packed field would have to specify a different texformat struct - ie the > component ordering for a given texformat struct is fixed. Correct. If one of the current mesa formats doesn't have the component layout you need, we should add a new format. -Brian ------------------------------------------------------------------------- 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
