[Bug 101910] [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f

[bugzilla-daemon at freedesktop.org]

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

--- Comment #17 from Topi Pohjolainen <topi.pohjolainen at intel.com> ---
After realizing that writing level 6 actually interferes with level 1 (instead
of level 0 that I stated earlier), the bug started make more sense as levels 1
and 6 reside in the same tile. I reminded myself how Y-tiling is laid out and
how the individual levels reside respect to one and other. Then the difference
between valign == 2 and valign == 4 started to make more sense (initially the
intra tile offset difference (32, 0) vs. (0, 4) looked odd). After some more
digging I realized that the alignment difference itself wasn't significant -
valign == 4 case was just lucky to place levels on tile boundary with respect
to x-coordinate. And furthermore that our image copy logic failed to adjust
intra tile x-coordinate when it treated RGB surfaces as three times wide
R-only.

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