<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#c51">Comment # 51</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#c50">comment #50</a>) > 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, > And for the reference the section in bspec: Gen Graphics » BSpec » Memory Views » Common Surface Formats » Surface Padding Requirements » Sampling Engine Surface Even though I'm dealing with non-compressed textures here in this bug, I think the text found in the section discussing compressed textures hints that hardware has limitations w.r.t. linear orientation. It says: "This must be ensured regardless of whether the surface is stored tiled or linear. This is due to the potential rotation of cache line orientation from memory to cache."</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>