Michel � wrote:
On Thu, 2006-09-21 at 13:55 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell wrote:> Michel Dänzer wrote:> > On Wed, 2006-09-20 at 18:56 +0000, Keith Whitwell wrote:>
>>> >> Log message:> >> Support both big and little endian, more source types and more> >> destination formats
through the swizzle path. It would be great to> >> see this tested on eg, PPC machines...> > > > With the current trunk, glean
pixelFormats fails 201 combinations on big> > endian with both drivers, of which this commit broke 42 and the 'Extend
'Both drivers' referring to r200 and r300 BTW. I haven't tried softwareMesa yet.
swizzle support to all remaining source formats and texture destination> > formats.' commit the other 159 (yay
git-bisect! :).> > > > Changing type_endian_mapping() to return map_identity for> > GL_UNSIGNED_BYTE
brings it down to 144 and changing the last two> > components of map_3210 to { 7, 6 } to 138, > > I think this
must be a fluke - the 4,5 there refer to ZERO,ONE defined > elsewhere. Those values are always at 4,5 and are only
addressed as > elements in an array of bytes - I can't see how their positions might > change in littleEndian machines.
Yeah, as I said, I didn't really know what I was doing, it was justtrial and
error. :)
Michel,
Maybe we can look at the failures one at a time - the attached patch
causes the test to abort after the first real failure - can you use that
and maybe turn on the printf in compute_component_mapping() to get the
first failure and post it here?
from 1908/GL_RGBA to 1907/GL_RGB map 0 1 2 4 4 5
from 1907/GL_RGB to 1908/GL_RGBA map 0 1 2 5 4 5
i=0, srctype2ubyte_le[i]=3, src2base[i]=0, base2rgba[i]=0, rgba2dst[i]=3,
swap[i]=0
i=1, srctype2ubyte_le[i]=2, src2base[i]=1, base2rgba[i]=1, rgba2dst[i]=0,
swap[i]=1
i=2, srctype2ubyte_le[i]=1, src2base[i]=2, base2rgba[i]=2, rgba2dst[i]=1,
swap[i]=2
i=3, srctype2ubyte_le[i]=0, src2base[i]=4, base2rgba[i]=5, rgba2dst[i]=2,
swap[i]=3
map 5 3 2 1
pixelFormats failed at pixel (0,0), color channel 0:
Expected: 0xff 0x00 0x00 0x00
Found: 0x00 0x00 0xff 0x00
Format: GL_RGBA
Type: GL_UNSIGNED_BYTE
Internal Format: 3
BTW, software Mesa even fails 603 combinations with the trunk before
your last commit.
PS: Thanks a lot for your detailed explanation, but I'm afraid this is
still a bit above my head; I'm not sure I understand all the assumptions
before and after each of the mappings, and in particular I'm not sure
srcType alone is sufficient to determine the endianness mappings.
OK, so as you suggested, it looks like type_endian_mapping should be
identity for this case, as in the attached diff -- what happens next?
Keith
? cache-texenv.diff
? cache3-texenv.diff
? dfif
? diff
? ff.c
? rework-vbo-ptr-abandon.diff
? statekey
? texmipgen.c
Index: texstore.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/main/texstore.c,v
retrieving revision 1.128
diff -u -r1.128 texstore.c
--- texstore.c 21 Sep 2006 12:43:05 -0000 1.128
+++ texstore.c 21 Sep 2006 15:15:40 -0000
@@ -706,8 +706,8 @@
* were presented as GL_UNSIGNED_BYTEs on a littleEndian machine... I
* think...
*/
-static const GLubyte map_identity[6] = { 0, 1, 2, 3, 4, 5 };
-static const GLubyte map_3210[6] = { 3, 2, 1, 0, 4, 5 };
+static const GLubyte map_identity[6] = { 0, 1, 2, 3, ZERO, ONE };
+static const GLubyte map_3210[6] = { 3, 2, 1, 0, ZERO, ONE };
static const GLubyte *
@@ -718,10 +718,7 @@
switch (srcType) {
case GL_UNSIGNED_BYTE:
- if (littleEndian)
- return map_identity;
- else
- return map_3210;
+ return map_identity;
case GL_UNSIGNED_INT_8_8_8_8:
return map_identity;
case GL_UNSIGNED_INT_8_8_8_8_REV:
-------------------------------------------------------------------------
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
