Bug 41451

Created attachment 51978 [details]
Screenshot of nwn displaying bug on snow texture

Attached screenshot, also uploaded a video on youtube about this bug. Also shown on this video is bug 39730. Just ignore any flickering pixels with regard to this bug.

http://www.youtube.com/watch?v=-67OYVFS9WA

What is not shown in either video or screenshot is that also minor part of the game's GUI elements also got affected. They appear as distorted. The compass for instance appered to me as upside down and stretched, so only part of it was seen.

fixed in git at commit 9c697a9d004da4aa7a26d3bda17cc473f50345ea (not bisected)

*stabs self* Ignore previous.
I had forgot to unset LIBGL_ALWAYS_INDIRECT=1 after testing another bug.

But if I do, the artifacts do not show up.

author Eric Anholt <eric@anholt.net> 2011-09-21 21:43:20 (GMT) 
committer Eric Anholt <eric@anholt.net> 2011-10-03 20:29:37 (GMT) 
commit e928c34d3ec54bb8a6b80036e6b6a91977bf0865

intel: Add an AllocTextureImageBuffer() implementation using miptrees.
Now we can rely on Mesa core for uploads of data without introducing
an extra copy at validate time.

I can confirm that commit e0304180c32227342dbb67b707bfae446543bb48 introduces artefacts with some textures. I see those artefacts on a "GM45 Express Chipset" with osgviewer. The models that misrender have OpenGL ARB compressed textures.

> I can confirm that commit e0304180c32227342dbb67b707bfae446543bb48 ...
I think that's a copypaste mistake, as that is the commit just before the bug.

I've narrowed it down a bit, if I comment out the second if-block added in http://cgit.freedesktop.org/mesa/mesa/commit/?id=e928c34d3ec54bb8a6b80036e6b6a91977bf0865
that begins with...
   else if (image->Border == 0) {
...then the textures display correctly.

But, I've not been able to get the DBG macros to work inside that particular function at all. I'm wondering if the application somehow silences them, because if the code isn't executed - how can it introduce a bug?

Created attachment 53129 [details]
Small distortion detail.

More observations:

By comparing a small gui element (10x zoom or more advised on the attachment) I can see that only half of the texture is loaded. Attached is a comparison (left good, right bad) where one can see that only half of the textures is there.

The images are likely 16x16 pixels
Lower half of each image has texture data.
Upper half varies each run.
Bottom 1/4th is rendered correct.
The other 1/4th texture data is rendered at wrong position.

(It is also possible to provide custom textures by placing them into a 'overrides' directory, but it appears the bug will be circumvented by doing this)

I must have flunked the last git bisect step. Now I arrive at first bad at:

mesa: Convert _mesa_generate_mipmap to MapTexImage()-based access.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e0304180c32227342dbb67b707bfae446543bb48

Above is false. above. I was getting lost in trees and patches.

OK, confirmed the bisect and that there are obvious rendering issues from it right in the starting zone.

status update: I've spent a couple of days trying to track it down.  At this point, we're trying to get apitrace to work on it so that we can get a minimal trace reproducing the problem -- without that, the amount of debug information is just too big.

Maybe same or similar? bug 42955

A fix!

http://lists.freedesktop.org/archives/mesa-dev/2011-November/015289.html

Except that now on SNB it's GPU hanging at startup due to HiZ.  That's high on the priority list.  Easy workaround for now is to revert e5411d8fdc6a7dda18d82746b84197ef83ee0a13 which has no conflicts yet.

That works. :)  Thank you Eric!

commit bda361e0d47a670f318664abcdf0a065bef22883
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Nov 30 12:04:14 2011 -0800

    mesa: Fix glCompressedTexImage when dstRowStride != srcRowStride.
    
    Since the MapTextureImage changes on Intel, nwn had corruption in the
    scrollbar at the load game menu, and corrupted ground textures in the
    starting zone.  Heroes of Newerth's intro screen was also thoroughly
    garbled.  A new piglit test "compressedteximage" was created to
    regression test this.
    
    The issue was this code now seeing dstRowStride aligned to hardware
    requirements instead of a temporary buffer that gets uploaded to
    hardware later.  The existing code was just trying to memcpy
    srcRowStride * height / bh, while the glCompressedTexSubImage2D()
    storage code nearby did the correct walking by blockheight rows at a
    time.  Just reuse the subimage upload instead of duplicating that
    logic.
    
    v2: Update comment at the top of the function (suggestion by Joel
    Forsberg)