Michel Dänzer wrote:
> 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.
In other words, for the swizzle path, the UNSIGNED_INT_8_8_8_8{_REV}
cases need to be byteswapped (relative to how they are currently), and
no other?
>> 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.
But maybe because the swizzle code tries to specify packed data ordering
in terms of array offsets, it is actually necessary to flip those
offsets on bigEndian machines to get the right results.
In other words, the dstMap values passed down to swizzle_ubyte_image
should be adjusted based on whether this is a big or littleendian machine.
>
> 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).
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.
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
