Created attachment 117508 [details] Snapshot of the artifacts with normal map Light blue garbled artifacts are affecting gallium nouveau on FreeSpace2 open source, with Star Wars : Original Trilogy mod. To Star Wars fans this may be unacceptable :-), so let't try to find clues to the problem I have checked the .dds normal map's texture compression format and in this mod it's always DXT5 If I disable 'normal maps' in wxLauncher there are no artifacts, but there are also no maps, which are one the beauties of the mod. Affected chipsets NV6x (GeForce 7025) NV8x (GeForce 8500, 8600), NV9x (GeForce 9600GT, GT120) , NVAx (GeForce 210) and NVDx (GeForce GT610). (cheched mesa with 10.6.x) Unaffected, meaning normal maps are fine with those: NVCx and NVEx chipsets (checked with mesa 10.6.x and 11.0.0devel git) NOTE: It's strange that NVDx chipsets are affected, if they rely on nvc0 driver You can find in the attachment the snapshot of the artifacts with normal maps and normal maps disabled (no artifacts), plus other log files/extracts. Mauro
Created attachment 117509 [details] Snapshot with normal maps disabled in wxlauncher for FS2open
Created attachment 117510 [details] glxinfo log
Created attachment 117511 [details] dmesg extract with 'nouveau E' entries These are related to FS2open process, but I'm not systematically seeing the 'nouveau E' errors when launching FS2open with normal maps enabled. It may help to see if it's related or a different problem requiring to fill in a new bug.
Created attachment 117512 [details] Xorg log
Created attachment 117513 [details] A sample of the DTXn compressed normal map in .dds format
Please see if this isn't an instance of the issue in bug 90887. If possible, make an apitrace so that I can reproduce this without working out how to operate your software. If not, please explain how I can reproduce this myself. FTR, I highly doubt that DXT compression has anything to do with it, but... stranger things have happened.
Hi, I've uploaded apitrace at the following shared link: http://www.mediafire.com/download/949r35rra31rpte/Tie_pilot_Nvidia_GT210_fs2_open_3.7.2.trace.7z I can see the heartstone artifacts on my Nvidia GT210, but I'm not able to check if the problem is the same I will test again Freespace2 with Star Wars Original Trilogy mod, when the patch for https://bugs.freedesktop.org/show_bug.cgi?id=90887 will be applied to mesa git, and report back. Thanks Mauro
Hi, I tried to apply the two patches proposed by jr, in https://bugs.freedesktop.org/show_bug.cgi?id=90887 thread, built patched nouveau_dri.so i386 target and checked about the artifacts on FS2open mod. In my use case the artifacts are still there. I'll check again with next proposed patches, I only need to playback the apitrace on specific HW Mauro
As I suspected, nothing to do with compressed textures. Should be at least partially fixed by commit ce28ca713364dbe83cb3c371ca034bc2c2947616 Author: Ilia Mirkin <imirkin@alum.mit.edu> Date: Thu Sep 10 03:55:06 2015 -0400 nv50/ir: fix emission of 8-byte wide interp instruction This can come up if the target register number is > 63, which is fairly rare. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91551 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> It still doesn't seem to render quite the same as nvc0 and llvmpipe. The lighting on the back of the spinning models is much brighter. Not sure why... those shaders are ENORMOUS by the way. I thought it might be due to glShadeModel(GL_FLAT) at first, which isn't properly handled, but that's not it -- it only ever calls glShadeModel(GL_SMOOTH) in the trace.
Ah, I suspect the remaining issues are due to the fact that we're encoding things like 119: mad f32 $r75 $r4 2.000000 $r75 (8) as e000092d 04000003 add sat f32 $r11 (mul $r4 0x40000000) $r11 Which... might not be *exactly* the same thing. Unfortunately there *is* no encoding for that instruction, the nv50 emitter isn't smart enough not to emit it. Shaders with > 64 regs are sufficiently rare :( I guess we need to add a post-RA fixup to load these immediates for non-encodable instructions. Of course the question is *where* to load it... ugh. Could try to reserve a special register at RA time for it...
Actually this particular instance of the issue had an easy fix -- we were manually "breaking" it. Oops! commit 74b86b971f3bf9b0482341b07c1cbc2e520fb1d0 Author: Ilia Mirkin <imirkin@alum.mit.edu> Date: Thu Sep 10 05:02:26 2015 -0400 nv50/ir: don't fold immediate into mad if registers are too high Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91551 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> Now the spinning model looks exactly as it did on nvc0.
Hi, Checked on 8500GT (NV86), I confirm the models are correctly rendered. Thank you very much, also on behalf of the SW Original Trilogy mod GNU/Linux community. Mauro
(In reply to Mauro Rossi from comment #12) > Hi, > > Checked on 8500GT (NV86), I confirm the models are correctly rendered. > > Thank you very much, also on behalf of the SW Original Trilogy mod GNU/Linux > community. > > Mauro By the way, out of your original card list, if there remain issues with nv30 driver (GeForce 7025) or nvc0 (GeForce 610), please file them separately and include traces.
Hi Ilia, nvc0 is not affected, while I have seen a different problem on integrated GeForce 6150 (NV4C chipset) Submitting new bug with logs and traces separately. Thanks Mauro
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.