[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 #8 from Topi Pohjolainen <topi.pohjolainen at intel.com> ---
There is similar fallback in old miptree, in
brw_tex_layout.c::brw_miptree_choose_tiling(). Only that it never fired for
RGB32F:

   /* From the Ivy Bridge PRM, Vol4 Part1 2.12.2.1 (SURFACE_STATE for most
    * messages), on p64, under the heading "Surface Vertical Alignment":
    *
    *     This field must be set to VALIGN_4 for all tiled Y Render Target
    *     surfaces.
    *
    * So if the surface is renderable and uses a vertical alignment of 2,
    * force it to be X tiled.  This is somewhat conservative (it's possible
    * that the client won't ever render to this surface), but it's difficult
    * to know that ahead of time.  And besides, since we use a vertical
    * alignment of 4 as often as we can, this shouldn't happen very often.
    */
   if (brw->gen == 7 && mt->valign == 2 &&
       brw->mesa_format_supports_render[mt->format]) {
      return ISL_TILING_X;
   }

There the last bit: brw->mesa_format_supports_render[mt->format] yields false
for MESA_FORMAT_RGB_FLOAT32.

Therefore it looks that this used to work by luck, old logic used Y-tiling with
valign == 2 which should be illegal.

-- 
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/20170726/3968e662/attachment.html>