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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Topi Pohjolainen <topi.pohjolainen at intel.com> ---
Among other things I had simplified the test and altered it report every faulty
pixel (instead of bailing out on first error). That way I had noticed that the
failing area is always a 4x4 block (16 pixels). And with the RGBA8 format I've
been concentrating on thus corresponding to one cache line of 64 bytes.
Moreover, the erroneous values are not just random garbage but exactly the
values expected to see for the 4x4 block in position 0,0 - 3,3. Hence I've been
suspecting the cache simply containing "old data".

Now, I also noticed that brw_meta_fast_clear() unconditionally issues a cache
flush (by calling brw_emit_mi_flush()). This doesn't happen when glsl-based
meta clears are used. On IVB I can specifically reproduce the error if fast
clears are _disabled_ but not with.
So I added a call for brw_emit_mi_flush() also after glsl-based clear in (in
the end of brw_clear()). That makes a difference on both IVB and SKL - I don't
seem to be able to reproduce the error anymore.
This is heavy flush and it maybe that the real bug is still hidden due to
change in runtime dynamics. In case of fast clears the spec specifically says
that the flush has to be made but with glsl based clears we are talking about
normal rendering and therefore the flush is not readily justified. I need to
read the specs some more.

-- 
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/20151007/6e9ef158/attachment.html>