<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [SKL bisected] texsubimage pbo intermittent failures" href="https://bugs.freedesktop.org/show_bug.cgi?id=91926#c75">Comment # 75</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [SKL bisected] texsubimage pbo intermittent failures" href="https://bugs.freedesktop.org/show_bug.cgi?id=91926">bug 91926</a> from <a class="email" href="mailto:topi.pohjolainen@intel.com" title="Topi Pohjolainen <topi.pohjolainen@intel.com>"> Topi Pohjolainen</a> <pre>(In reply to Topi Pohjolainen from <a href="show_bug.cgi?id=91926#c72">comment #72</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>