Created attachment 68353 [details]
Screenshot of bug with Mesa 8.0.4

Created attachment 68354 [details]
Screenshot of bug with Mesa git

I'm assuming you're still using "Gallium 0.4 on AMD JUNIPER".

It looks like the error in 8.0.4 is coming from a glCompressedTexImage2D(internalFormat=GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, width=511, height=256) call since width=511 is not a multiple of the block size.

That error check has been removed from Mesa 9.0 and later but I don't think this is the cause of the rendering issue since it appears that the texture in question is never actually used during drawing (at least for as far as your trace recorded).  Plus, the compressed image is all zeros.

I think the rendering problem is something else.  Perhaps you can use qapitrace to dig into the trace a bit further and find the bad texture when it's drawn.

Actually, I'm on Redwood, not Juniper, but the problem doesn't seem to be hardware specific, llvmpipe shows a similar problem.

Anyway, I'm not quite up to speed with apitrace or OpenGL in general to track down the specific call used to draw the texture. I did however track it down among the media assets for the game. 

The texture is indeed 511x256, and resizing it with the gimp-dds plugin to 512x256 makes it render fine in-game. 

Not sure if this means that there's still some issues with non-power-of-two textures in Mesa or if resizing it just hides the real problem.

Created attachment 68510 [details]
Screenshot: mesa(git)+my patch

I have older(git) debs of mesa with my patch(https://bugs.freedesktop.org/attachment.cgi?id=67879) applied. Image it produces, looks a bit different. I will modify my patch and check it with latest git revision, maybe it will shed some light on this problem(I doubt it).

If you look at the screenshots, you'll see the wall is constructed with a crumbly bit at the top, followed by a dark band with a curly motif, a stretch of plain bricks, and another curly-motif band at the bottom. In the screenshot of Mesa 8.0.4, you'll see that in the wall-segments that have the problem, everything from the upper band to the ground is missing. So, whatever problem Mesa is having, causes that entire texture to not work - the entire brick section, plus the bottom band.

However, if you look at the actual problematic texture (the 511x256 one) in the game's data files, it doesn't contain an entire brick section or a bottom band, it just has a few bricks in the middle with holes for emitting poison darts. In fact, if you look at attachment 68354 [details], the problematic texture covers *exactly* the area that's rendered as garbage.

Although it's not depicted in these screenshots, apparently if you can trick the game into moving the camera close to the wall so you can see the base texture instead of a mipmap, that renders just fine.

So, the game doesn't render this 511x256 texture directly, but apparently at some point it combines it with some other texture with a sensible size (all the other wall textures are 512x512) producing a texture whose mipmaps are a glitchy mess even though the base texture is OK. 

However, the obvious way to combine textures would be with glCompressedTexSubImage2D, and the apitraces linked in comment 0 contain no such calls. There's some calls to glTexSubImage2D, but very few, and all of them have x and y set to 0 - and our dart wall is being drawn in the middle of the original wall texture.

For the record, all these things are apparently sufficient (although none of them are necessary) to make the wall render as intended:

- resave the original texture without compression.
- resave the original texture after rescaling to 512px wide.
- resave the original texture without the precalculated mipmaps.

Created attachment 68653 [details]
The original scene with the problem texture decompressed.

Created attachment 68654 [details]
The original scene with the problem texture decompressed (closeup).

(In reply to comment #6)
> - resave the original texture without compression.

I was actually thinking of bug 55445 here; it turns out that decompressing the texture does *not* solve the issue.

I extracted the problematic texture from the game's data files, resaved it without compression (using version 2.2.1 of the GIMP DDS plugin), inserted it back into the game's data, and went back to the same place in the game that the first screenshots were taken from.

Both these new screenshots were taken with Debian's official Mesa 8.0.4 packages.

Attachment 68653 [details] shows that the uncompressed texture is glitchy in the same places that the compressed texture is glitchy, although here we get bright green stripes rather than compression-block squares. It also shows that the glitchiness affects multiple mipmap levels.

Attachment 68654 [details] shows the same scene, after I hit the 'pause' button (which causes the game to swoop the camera in close to the player). Here we can see that the base-level texture looks just fine - no corruption at all. The first mipmap level has the glitchiness, and if you look closely you can see that it's also sheared - as though something is using slightly the wrong pitch. Say, 512 pixels instead of 511.

Is this bug fixed? I can't seem to reproduce it with Mesa 9.2, but I might be looking in the wrong places?

Luckily, I still have the same character I used for taking the attached screenshots, and the game hasn't regenerated the levels in the intervening months. I don't have Mesa 9.2, I'm just using Debian's Mesa 9.1.6 packages, but I can report that yes, everything seems to look just fine now.

I guess it got accidentally fixed?

(In reply to comment #11)
> Luckily, I still have the same character I used for taking the attached
> screenshots, and the game hasn't regenerated the levels in the intervening
> months. I don't have Mesa 9.2, I'm just using Debian's Mesa 9.1.6 packages,
> but I can report that yes, everything seems to look just fine now.
> 
> I guess it got accidentally fixed?

Thanks for confirming! It would be interesting to know where/how it was fixed, but not so interesting that I'm going to bisect for the fix :)

Let's mark this as fixed for now.