[Bug 91926] [SKL bisected] texsubimage pbo intermittent failures

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91926

--- Comment #75 from Topi Pohjolainen <topi.pohjolainen at intel.com> ---
(In reply to Topi Pohjolainen from comment #72)
> The final blit from the texture to the framebuffer is executed using
> fixed-function fragment shader. I hacked Mesa to simulate the color values
> in the test for R-component - the test uses values depending on the
> Y-component, specifically R = 4 * y.
> So I hacked Mesa to overwrite the R-component to 4 * y instead of using the
> value read from the texture:
> 
> pln(8)          g127<1>F        g5.4<0,1,0>F    g2<8,8,1>F
> pln(8)          g8<1>F          g6<0,1,0>F      g2<8,8,1>F
> pln(8)          g9<1>F          g6.4<0,1,0>F    g2<8,8,1>F
> pln(8)          g4<1>F          g7.4<0,1,0>F    g2<8,8,1>F
> mul(8)          g124<1>F        g9<8,8,1>F      4F              
> math inv(8)     g5<1>F          g4<8,8,1>F      null
> mul(8)          g2<1>F          g8<8,8,1>F      g5<8,8,1>F
> mul(8)          g3<1>F          g9<8,8,1>F      g5<8,8,1>F
> send(8)         g2<1>UW         g2<8,8,1>F
>    sampler sample SIMD8 Surface = 1 Sampler = 0 mlen 2 rlen 4 { align1 1Q };
> mov(8)          g125<1>F        g3<8,8,1>F
> mov(8)          g126<1>F        g4<8,8,1>F
> sendc(8)        null            g124<8,8,1>F
>    render RT write SIMD8 LastRT Surface = 0 mlen 4 rlen 0 { align1 1Q EOT };
> 
> 
> With this I can get the same intermittent pixel failures I'm seeing without:
> 
> 32:0:0:255 0:0:0:255 x=0 y=8 z=0
> 32:2:0:255 0:2:0:255 x=1 y=8 z=0
> 32:4:0:255 0:4:0:255 x=2 y=8 z=0
> 32:6:0:255 0:6:0:255 x=3 y=8 z=0
> 36:0:0:255 4:0:0:255 x=0 y=9 z=0
> 36:2:0:255 4:2:0:255 x=1 y=9 z=0
> 36:4:0:255 4:4:0:255 x=2 y=9 z=0
> 36:6:0:255 4:6:0:255 x=3 y=9 z=0
> 40:0:0:255 8:0:0:255 x=0 y=10 z=0
> 40:2:0:255 8:2:0:255 x=1 y=10 z=0
> 40:4:0:255 8:4:0:255 x=2 y=10 z=0
> 40:6:0:255 8:6:0:255 x=3 y=10 z=0
> 44:0:0:255 12:0:0:255 x=0 y=11 z=0
> 44:2:0:255 12:2:0:255 x=1 y=11 z=0
> 44:4:0:255 12:4:0:255 x=2 y=11 z=0
> 44:6:0:255 12:6:0:255 x=3 y=11 z=0
> 
> First four values are the expected, second four are the values read back.
> This tells us that the problem isn't necessarily sampling - it looks that
> the y-coordinate is being wrong during the tex-2-fb blit.

This comment on coordinates being false looks to be a wrong conclusion. Here I
hacked the blit program to mimick the expected values. Now on SKL I chose to
output running x,y coordinate values directly as color values. In the failing
two pixels wide column (on SKL in position 6,10 7,27) I'm seeing the original
values and it rather looks that the updating blit fails to write this column
altogether.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160301/e6f0f0b7/attachment.html>