Michel Dänzer wrote:
> On Fri, 2006-09-22 at 09:17 +0100, Keith Whitwell wrote:
>> Michel Dänzer wrote:
>>> On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
>>>> 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?
>
> That's what I'd expect, yes.
>
>>>> 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.
>
> Curiously enough, this seems true in one case but not the others. The
> attached patch works for me with the r300 driver.
>
>
>>> 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 suspect there may be mixed assumptions about packed type vs. byte
> array, which happens not to make a difference with little endian.
Indeed.
>> 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.
>
> Ah, I was confused by the different meanings of the _REV suffix for the
> OpenGL formats and Mesa's internal hardware formats. Looks like it just
> means byte swapping for the latter.
In fact, given the naming scheme for the mesa texformats, I wonder why
the _rev designation is necessary at all -- shouldn't _argb8888_rev just
be called bgra8888 ?
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
