(After some initial confusion on my end whether this was a bug or not, I can conclude that git-bisect better handling checkouts than I am.) intel: Add an AllocTextureImageBuffer() implementation using miptrees. http://cgit.freedesktop.org/mesa/mesa/commit/?id=e928c34d3ec54bb8a6b80036e6b6a91977bf0865 This commit cause artifacts to show on even spaces on most textures in the game Neverwinter Nights. It seems to only affect every other texture, and it is dependent on how far away the scene is rendered. At one points the textures also seem to 'flip' in some manner so that the object looks slightly different. Zoom: So at close zoom, I have a correct scene, then as I zoom out a little some parts become darker too soon compared to the rest of the scene, then they lit up again at the 'flip' distance, to become darker again later. Since Neverwinter Nights is a proprietary game I'll try to make a video displaying the zoom behaviour, along with annotated screenshots. I've not yet attempted to revert this from current master, some naive trial last night got me into conflicts, and I have yet to learn how to solve that. -------------------------- This is tested on 3.1.0-rc8 x86_64 kernel Sandybridge HD3000 gfx (core i5) Module intel: vendor="X.Org Foundation" 5334-[ 12016.872] compiled for 1.10.99.902, module version = 2.16.0 (Fedora 16 alpha)
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)
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.