I've been debugging this all day, so I hope I can make things understood / clear. Basicly my problem was I had a clanlib - http://www.clanlib.org/ - using application: methane - http://methane.sourceforge.net/ . Which suffered from a corrupted display after a mesa 6.5.1 to 6.5.2 upgrade. The patch causing the corrupted display is this one: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff_plain;h=62d4dfbfe3f7c452f3c182bfdb9270a2f20e3f2d;hp=46c3bd29be4970a8b0c1c358aae0f1d7c05bc9f4 But AFAIK (after a day of debugging) this patch is fine, it does however expose another problem. In this case ClanLib basicly (stupidly) does the following to create and then upload a texture: glTexImage2D( GL_TEXTURE_2D, // target 0, // level GL_RGBA, // internalformat width, // width height, // height 0, // border GL_RGBA, // format 0); // texels (0 to avoid uploading) // upload glTexSubImage2D( GL_TEXTURE_2D, // target 0, // level 0, 0, // xoffset, yoffset src_rect.get_width(), // width src_rect.get_height(), // height GL_ABGR_EXT, // format GL_UNSIGNED_BYTE, // type data); // texels Notice how the texture is initially created with a format of GL_RGBA, and then uploaded with a format of GL_ABGR_EXT. The patch exposing the problem with the swizzle code: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff_plain;h=62d4dfbfe3f7c452f3c182bfdb9270a2f20e3f2d;hp=46c3bd29be4970a8b0c1c358aae0f1d7c05bc9f4 Causes mesa to choice rgba8888_rev as internal format for the created texture, perfectly matching GL_RGBA on little endian. Without this patch / in the past mesa / the r300 driver chose rgba8888 However the upload happens in GL_ABGR_EXT matching the default rgba8888 choice mesa used to make. So prior to this patch, _mesa_texstore_rgba8888 from src/mesa/main/texstore.c could use a straight memcpy. However with the (perfectly fine) patch the texture is represented internally as rgba8888_rev, which makes _mesa_texstore_rgba8888 from src/mesa/main/texstore.c enter the swizzle path. In the swizzle path the texture should get "swizzled" from rgba8888 to rgba8888_rev, as its uploaded in rgba8888, but internally represented in rgba8888_rev. however this somehow goes wrong, as I end up with a corrupted display. I've managed to reproduce this corrupted display problem on 3 different machines: x86_64 r300 / radeon 9800 pro, i386 r200 / radeon 9250, i386 r100 / radeon M6 Phew, I hope thats understandable if not please ask. For now I've fixed ClanLib to not be so stupid, but the swizzle code needs to be fixed too.
Hmm yes this makes a lot of sense, except I can't reproduce it, the texture gets swizzled here correctly... When you say corrupted texture you mean there are indeed only the components swizzled wrong, not some other errors (which would for instance happen when the texture data got misaligned if updating only regions, which I didn't really test). I'm using mesa git however, as a quick guess I suspect you might need this fix: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=9c09259b8bef8f120cc6f4bb1a44f0eae37d71b3 Note that there seem to be some problem (likely not related) with the texture format selection patch on r300, which noone really understands (https://bugs.freedesktop.org/show_bug.cgi?id=8489)
(In reply to comment #1) > Hmm yes this makes a lot of sense, except I can't reproduce it, the texture > gets swizzled here correctly... When you say corrupted texture you mean there > are indeed only the components swizzled wrong, not some other errors (which > would for instance happen when the texture data got misaligned if updating only > regions, which I didn't really test). I'm using mesa git however, as a quick > guess I suspect you might need this fix: > http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=9c09259b8bef8f120cc6f4bb1a44f0eae37d71b3 > Note that there seem to be some problem (likely not related) with the texture > format selection patch on r300, which noone really understands > (https://bugs.freedesktop.org/show_bug.cgi?id=8489) > Actually (and sorry for not explaining this clearer) The texture mess-up is not in the swizzling, it indeed looks much like a stride error, the colors are correct, but the rows are not properly aligned iow, pixels that should be in the same column, do not end up in the same column. Also the texture gets shrunk to about 3/5th off the size it should be. So this might indeed be very much related to bug 8489, and the chances are indeed good that the pointed to git commit fixes this (I will try later when I'm back home). Thinking more about this, I think that bug 8489 might also be fixed by the same commit as there changing from rgba to abgr also helps, just like it did in my case. So maybe its an idea to add a comment to bug 8489 requesting the reporter to try the same git patch.
I'm the one who reported bug #8489, and afaik this problem still persists even with the commit mentioned here. I'll confirm that soon by testing with the latest Git and seeing if the problem is still there.
Actually my fix was to change the texture format from _dri_texformat_argb8888 to _dri_texformat_rgba8888, not the other way around as you mentioned.
I just checked and my problem still persists even with the latest Git. :(
Created attachment 9422 [details] [review] The texture format hack for R300
I can confirm that the git patch pointed to in comment 1 : http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=9c09259b8bef8f120cc6f4bb1a44f0eae37d71b3 Indeed fixes this, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.