Bug 13728

I think we've got some glPolygonOffset issues, which have caused troubles for NWN on other drivers in the past.

After fixing a glPolygonOffset bug trying to fix this, I don't think that's the issue any more.

I can't help to notice this almost* exclusively happens for objects that would be in glowing mist when highlighted. Could this help to narrow the issue down?
(uneducated guess: shader related?)

*the exception being the targetting cross placed on ground when walking using the mouse

I'd noticed the same thing, but in scanning through the shaders used by nwn (strings on the binary will get you a collection) I didn't notice any that looked special.

I tried to modify those strings, but it didn't appear to change anything. Either the change is too subtle to be noticed by me, or they are not really used.

I was testing stuff in mesa/progs and came across 'mesa/progs/glsl/noise'
I'm not sure how it's supposed to be, but the same pattern can be seen on doors in neverwinter. It prints the following to stdout too:

Shader compiled OK
Shader compiled OK
Link success!
Uniform Scale location: 4
Uniform Bias location: 5
Uniform Slice location: 6
GL_RENDERER = Mesa DRI Intel(R) 965G 20061102
unsupport opcode 46 in fragment program
unsupport opcode 46 in fragment program
unsupport opcode 46 in fragment program
unsupport opcode 46 in fragment program

(In reply to comment #5)
> I was testing stuff in mesa/progs and came across 'mesa/progs/glsl/noise'
> I'm not sure how it's supposed to be, but the same pattern can be seen on doors
> in neverwinter. It prints the following to stdout too:
> 
> Shader compiled OK
> Shader compiled OK
> Link success!
> Uniform Scale location: 4
> Uniform Bias location: 5
> Uniform Slice location: 6
> GL_RENDERER = Mesa DRI Intel(R) 965G 20061102
> unsupport opcode 46 in fragment program
> unsupport opcode 46 in fragment program
> unsupport opcode 46 in fragment program
> unsupport opcode 46 in fragment program
> 

This is reported at bug#15217

I have tested this against Mesa 7.2 using both version 2.4.2 and 2.5.0(GEM) of xf86-video-intel. 

While there are still objects that are not displayed correctly, the "Swarm of pixels" issue is not there anymore as far as I have seen. I have checked some doors, chest and creatures that previously did not render good. They now look allright.

(Those objects that do not display right are some heads that are not rendered at all, and the highlighted chat is appears to be painted in some shroedingers color, but that is for another bug)

Clarifying my last comment: Cannot reproduce, with recent drivers. 
(All the other stuff I mentioned belong in another bug report)

Original issue is fixed per comment #7.

Mass version move, cvs -> git

This bug seems to be back, at least on my Arch Linux laptop with extra/mesa-libgl 11.1.0-1 and extra/xf86-video-intel 1:2.99.917+519+g8229390-1.

I have the swarm of transparent pixels on nearly all objects, like chests, doors and tables in Neverwinter Nights.

Moreover, this bug also occurs on the programming game TIS-100, which uses Unity3D. The effect is transparent/black pixels all over the text characters, making them basically unreadable.

Created attachment 120688 [details]
Bug showing in Neverwinter Nights

Created attachment 120689 [details]
Bug showing in TIS-100

(In reply to Sven Hesse from comment #11)
> This bug seems to be back, at least on my Arch Linux laptop with
> extra/mesa-libgl 11.1.0-1 and extra/xf86-video-intel
> 1:2.99.917+519+g8229390-1.

Taking into account that the original bug was created several years ago, when the hw specified was the norm, could you confirm that you are using the same hw (965GM)?
 
> I have the swarm of transparent pixels on nearly all objects, like chests,
> doors and tables in Neverwinter Nights.

FWIW, I tested Neverwinter Nights using both master and the 11-1 branch, on a Haswell machine, and no artifacts on that case.

> could you confirm that you are using the same hw (965GM)

Yes:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)

The CPU is an Intel Core 2 Duo T7100, the laptop a Dell XPS M1330, model number PP25L.

Arch is now at mesa-libgl 11.1.2-1, and the issue is still present there.

Okay, I managed to git bisect the issue.

The first bad commit is 797d606127c131a6ccff28150495d2b1f3f7e46
i965: Implement SIMD16 texturing on Gen4.

Created attachment 123215 [details]
Wireframe of the cupboard model in NWN

Here's the wireframe of the cupboard model in NWN, the one that shows the transparent pixels ingame on i965.

Note that the transparent pixels seem to be near the polygon boundaries.

Created attachment 123758 [details]
Bug showing on a chest in Neverwinter Nights

Added a screenshot of the bug showing on a chest placeable in Neverwinter Nights.

An API trace of the bug showing on that same chest is here: https://drmccoy.de/zeugs/nwmain.trace (58MB, so over the attachment file size limit, unfortunately).

Sven, great work!

I opened another bug report for this issue several years ago:
https://bugs.freedesktop.org/show_bug.cgi?id=59930

Feel free to close it as duplicate.

BTW, I can't even run the game on mesa 13.0.0rc2. On older versions (8.0.4-12.0.3) NWN worked but had this bug.

> I opened another bug report for this issue several years ago:
> https://bugs.freedesktop.org/show_bug.cgi?id=59930

Oh, I hadn't seen that. My bad.

> BTW, I can't even run the game on mesa 13.0.0rc2.

Okay, I can *not* confirm that. On my Arch laptop with extra/mesa-libgl 13.0.0rc2-2 and multilib/libg32-mesa-libgl 13.0.0rc2-1, I can still run Neverwinter Nights just fine. The bug is also still there, though.

*** Bug 59930 has been marked as a duplicate of this bug. ***

(In reply to Sven Hesse from comment #16)
> Okay, I managed to git bisect the issue.
> 
> The first bad commit is 797d606127c131a6ccff28150495d2b1f3f7e46
> i965: Implement SIMD16 texturing on Gen4.

To confirm, everything seemed to be working well before that commit?

> To confirm, everything seemed to be working well before that commit?

Yes, exactly. Everything seemed to be working well before that commit and the texture glitch appeared with that commit.

Hello Sven, this case is quite old, is this still valid with latest Mesa and gfx driver? Thank you.

The issue still persists with mesa 17.2.3 and xf86-video-intel 2.99.917+796+g04b4f3b7.

not sure if anyone will work on this but you could try using environment variable INTEL_DEBUG=no16 to workaround this bug

Thanks, Tapani! INTEL_DEBUG=no16 works, I can't see artifacts any more.

Today I spent some time looking at the TIS-100 bug, because it's a lot simpler to work with and possibly related.  I discovered that it's a shader with a discard that isn't working in SIMD16 mode.

The discard handling itself doesn't appear to be the problem.  I can disable all assembly code that even touches the pixel mask, and it still has the issue.

The render target message length appears to be 15, which is near the limit.

Specifically, these WM_IZ features are in play:

- Discard (kill pixels)
- Depth testing
- Stencil testing and stencil writes
- No depth writes
- No computed depth

Changing any of these appears to fix the issue:

- Eliminating discards at the NIR level (removing the WM_IZ bits and WM_STATE bits for killpix)
- Disabling stencil testing (brw->stencil_enabled = false, disabling the WM_IZ bits for stencil)
- Disabling depth testing

I'm pretty sure we're staring right at the problem, but I'm not seeing it yet.

Hi Sven, Vasyl,

TIS-100 and other Gen4-5 misrendering with SIMD16 should be fixed with the following commit on master.  Sorry this took so horribly long. :(

commit 08a5c395abdafd0d7556060596f78c238b4a989f
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Thu Aug 2 15:02:18 2018 -0700

    intel: Fix SIMD16 unaligned payload GRF reads on Gen4-5.
    
    When the SIMD16 Gen4-5 fragment shader payload contains source depth
    (g2-3), destination stencil (g4), and destination depth (g5-6), the
    single register of stencil makes the destination depth unaligned.
    
    We were generating this instruction in the RT write payload setup:
    
       mov(16)   m14<1>F   g5<8,8,1>F   { align1 compr };
    
    which is illegal, instructions with a source region spanning more than
    one register need to be aligned to even registers.  This is because the
    hardware implicitly does (nr | 1) instead of (nr + 1) when splitting the
    compressed instruction into two mov(8)'s.
    
    I believe this would cause the hardware to load g5 twice, replicating
    subspan 0-1's destination depth to subspan 2-3.  This showed up as 2x2
    artifact blocks in both TIS-100 and Reicast.
    
    Normally, we rely on the register allocator to even-align our virtual
    GRFs.  But we don't control the payload, so we need to lower SIMD widths
    to make it work.  To fix this, we teach lower_simd_width about the
    restriction, and then call it again after lower_load_payload (which is
    what generates the offending MOV).
    
    Fixes: 8aee87fe4cce0a883867df3546db0e0a36908086 (i965: Use SIMD16 instead of SIMD8 on Gen4 when possible.)
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107212
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=13728
    Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
    Tested-by: Diego Viola <diego.viola@gmail.com>

Hi Kenneth,

I can confirm that this fixes the bug in both Neverwinter Nights and TIS-100 for me. Thank you so much for taking the time to look into this! :)

Hi, Kenneth,

I can confirm the fix too. Thank you very much for solving this long-standing bug!