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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #51 from Topi Pohjolainen <topi.pohjolainen at intel.com> ---
(In reply to Topi Pohjolainen from comment #50)
> 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."

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