<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#c50">Comment # 50</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>I wonder if I finally have something. I started slicing the update blit of the source texture (recall that this is the round overwriting a selected region, and although the error is always in the part that corresponds to pixels outside the region, still without this blit the error doesn't manifest itself). I have simplified the test on IVB so much that the only meaningful meta operation is this update-blit allowing me to freely hack things out in meta and in the i965-state setup conditionally using _mesa_meta_in_progress(). I found out that the nested meta stacking isn't a problem as without the final kick for drawing the error can't be reproduced (or at least I don't see it any 200 test rounds. Note that normally I get in the 2nd or 3rd round latest). I continued to i965-state tracking and got all the way down to texture surface setup. This is the temporary texture created to represent the pixel buffer object used as the source for the pixel values in the sub-region to be updated. Now the buffer is offset by y * pitch + x * bpp, in my hardcoded case 4 * 512 + 46 * 4 = 2232. This is used in gen7_emit_texture_surface_state() when the relocation entry (by drm_intel_bo_emit_reloc()) is set for the surface. I tried first taking away the offset together and realised that this makes a difference - I can't reproduce the error anymore. (Note that sampled values for the updated region are of course off but the simplified test only concerns itself on the region outside where original error takes place). I narrowed this some more and realized that 2048 + 64 + 64 + 32 + 16 = 2224 is still fine but 2225 trips over and the bug reproduces with high probability. When the surface is setup we also set vertical alignment to four (alternatives are four or eight). This pbo backed surface is linear but the documentation (bspec) seems to make no difference between tiled and linear - both should be large enough for the sampler engine to treat with aligned dimensions, Here the surface is set for dimensions 59 * 81 starting in offset 46,4. The underlying buffer has space for 128 * 64, with bpp = 4, and hence with row pitch 4 * 128 = 512, of total size 32768. The offset region without alignment goes to 59 * 512 + 2232 = 32440 which is still inside. But if the alignment of four is taken into account this trips over 32952 - 32768 = 184. Although note that going over with just 176 bytes doesn't seem to cause the error. I can't readily explain why this causes the seeming cache line failure but perhaps this somehow confuses the GPU due to the alignment restriction not being honored.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>