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.
> 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.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Index: src/mesa/main/texstore.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/main/texstore.c,v
retrieving revision 1.131
diff -p -u -r1.131 texstore.c
--- src/mesa/main/texstore.c 21 Sep 2006 22:43:51 -0000 1.131
+++ src/mesa/main/texstore.c 22 Sep 2006 09:08:28 -0000
@@ -721,9 +721,9 @@ type_mapping( GLenum srcType )
case GL_UNSIGNED_BYTE:
return map_identity;
case GL_UNSIGNED_INT_8_8_8_8:
- return map_3210;
+ return _mesa_little_endian() ? map_3210 : map_identity;
case GL_UNSIGNED_INT_8_8_8_8_REV:
- return map_identity;
+ return _mesa_little_endian() ? map_identity : map_3210;
default:
return NULL;
}
@@ -984,7 +986,6 @@ _mesa_texstore_rgba(TEXSTORE_PARAMS)
}
}
else if (!ctx->_ImageTransferState &&
- _mesa_little_endian() &&
CHAN_TYPE == GL_UNSIGNED_BYTE &&
(srcType == GL_UNSIGNED_BYTE ||
srcType == GL_UNSIGNED_INT_8_8_8_8 ||
@@ -1314,7 +1315,6 @@ _mesa_texstore_rgba8888(TEXSTORE_PARAMS)
srcAddr, srcPacking);
}
else if (!ctx->_ImageTransferState &&
- littleEndian &&
(srcType == GL_UNSIGNED_BYTE ||
srcType == GL_UNSIGNED_INT_8_8_8_8 ||
srcType == GL_UNSIGNED_INT_8_8_8_8_REV) &&
@@ -1529,7 +1529,6 @@ _mesa_texstore_argb8888(TEXSTORE_PARAMS)
}
}
else if (!ctx->_ImageTransferState &&
- littleEndian &&
(srcType == GL_UNSIGNED_BYTE ||
srcType == GL_UNSIGNED_INT_8_8_8_8 ||
srcType == GL_UNSIGNED_INT_8_8_8_8_REV) &&
@@ -1540,14 +1539,14 @@ _mesa_texstore_argb8888(TEXSTORE_PARAMS)
/* dstmap - how to swizzle from RGBA to dst format:
*/
- if (dstFormat == &_mesa_texformat_argb8888) {
+ if (!littleEndian || dstFormat == &_mesa_texformat_argb8888) {
dstmap[3] = 3; /* alpha */
dstmap[2] = 0; /* red */
dstmap[1] = 1; /* green */
dstmap[0] = 2; /* blue */
}
else {
- assert(dstFormat == &_mesa_texformat_argb8888_rev);
+ assert(!littleEndian || dstFormat == &_mesa_texformat_argb8888_rev);
dstmap[3] = 2;
dstmap[2] = 1;
dstmap[1] = 0;
@@ -1662,7 +1661,6 @@ _mesa_texstore_rgb888(TEXSTORE_PARAMS)
}
}
else if (!ctx->_ImageTransferState &&
- littleEndian &&
srcType == GL_UNSIGNED_BYTE &&
can_swizzle(baseInternalFormat) &&
can_swizzle(srcFormat)) {
@@ -1788,7 +1786,6 @@ _mesa_texstore_bgr888(TEXSTORE_PARAMS)
}
}
else if (!ctx->_ImageTransferState &&
- littleEndian &&
srcType == GL_UNSIGNED_BYTE &&
can_swizzle(baseInternalFormat) &&
can_swizzle(srcFormat)) {
@@ -2159,7 +2156,6 @@ _mesa_texstore_a8(TEXSTORE_PARAMS)
srcAddr, srcPacking);
}
else if (!ctx->_ImageTransferState &&
- _mesa_little_endian() &&
srcType == GL_UNSIGNED_BYTE &&
can_swizzle(baseInternalFormat) &&
can_swizzle(srcFormat)) {
-------------------------------------------------------------------------
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
