Bug 10491 - swizzle from rgba8888 to rgba8888_rev leads to corrupt texture
Summary: swizzle from rgba8888 to rgba8888_rev leads to corrupt texture
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: 6.5
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-31 12:22 UTC by Hans de Goede
Modified: 2007-04-02 09:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The texture format hack for R300 (520 bytes, patch)
2007-04-02 05:23 UTC, Oliver McFadden
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2007-03-31 12:22:28 UTC
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.
Comment 1 Roland Scheidegger 2007-04-02 03:53:37 UTC
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)
Comment 2 Hans de Goede 2007-04-02 04:12:14 UTC
(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.


Comment 3 Oliver McFadden 2007-04-02 05:09:12 UTC
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. 
Comment 4 Oliver McFadden 2007-04-02 05:16:23 UTC
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.
Comment 5 Oliver McFadden 2007-04-02 05:17:43 UTC
I just checked and my problem still persists even with the latest Git. :(
Comment 6 Oliver McFadden 2007-04-02 05:23:06 UTC
Created attachment 9422 [details] [review]
The texture format hack for R300
Comment 7 Hans de Goede 2007-04-02 09:48:23 UTC
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.