<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f"
href="https://bugs.freedesktop.org/show_bug.cgi?id=101910#c11">Comment # 11</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f"
href="https://bugs.freedesktop.org/show_bug.cgi?id=101910">bug 101910</a>
from <span class="vcard"><a class="email" href="mailto:topi.pohjolainen@intel.com" title="Topi Pohjolainen <topi.pohjolainen@intel.com>"> <span class="fn">Topi Pohjolainen</span></a>
</span></b>
<pre>(In reply to Jason Ekstrand from <a href="show_bug.cgi?id=101910#c10">comment #10</a>)
<span class="quote">> (In reply to Topi Pohjolainen from <a href="show_bug.cgi?id=101910#c9">comment #9</a>)
> > While the failing tests themself don't create RGB32F surfaces to back
> > renderbuffers (in which case they would probably fail as i965 marks RGB32F
> > as non-renderable), the surfaces nonetheless end up as render targets. As
> > the titles of all the failing tests say, tests copy two images. Image copies
> > in turn are implemented in i965 using blorp (_mesa_CopyImageSubData() ->
> > brw_blorp_copy_miptrees()) which ends up using RGB32F as GPU render target.
>
> No, it doesn't. It should be using R32_UINT and manually offsetting to the
> slice to be copied. There may be bugs there though.</span >
You are correct, it does change the format. But the tiling vs align remains.
Old uses Y-tiling with valign 2 and new uses X-tiling with valign 2. Latter
should be correct while the former shouldn't.
<span class="quote">>
> > With respect to PRM, isl does the right thing and chooses X-tiling with
> > valign of 2. This for some reason, however, fails. Old miptree used contrary
> > to the spec Y-tiling with valign of 2 which for some reason works (at least
> > in these tests).
> > Also as mentioned a few comments earlier, for some reason at least
> > rgb32f_rgb32f.cubemap_to_cubemap works if one uses X-tiling and valign of 4
> > (which also is against the spec).
>
> My gut suspects something in our code to calculate offsets though I'm not
> sure.</span >
That would explain it. I'll take a look tomorrow.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>