<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [HSW] deqp-vk.api_.copy_and_blit.image_to_image_stencil regression"
href="https://bugs.freedesktop.org/show_bug.cgi?id=97448#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [HSW] deqp-vk.api_.copy_and_blit.image_to_image_stencil regression"
href="https://bugs.freedesktop.org/show_bug.cgi?id=97448">bug 97448</a>
from <span class="vcard"><a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> <span class="fn">Lionel Landwerlin</span></a>
</span></b>
<pre>Thanks,
We are dealing with a test that was previously skipped and is now enabled.
Attached are the expected and actual result of this test.
After a bit of digging I figure that the pitch of the destination surface
(R8_UINT W-tiled) has a pitch of 512, the actual picture having a pitch of 256
in linear tiling. It's kind of surprising, and forcing the pitch to 256 fixes
the test.
Here is an extract of the driver for pitch computation :
/* From the Broadwell PRM Vol 2d, RENDER_SURFACE_STATE::SurfacePitch:
*
* "If the surface is a stencil buffer (and thus has Tile Mode set
* to TILEMODE_WMAJOR), the pitch must be set to 2x the value
* computed based on width, as the stencil buffer is stored with two
* rows interleaved."
*
* This, together with the fact that stencil buffers are referred to as
* being Y-tiled in the PRMs for older hardware implies that the
* physical size of a W-tile is actually the same as for a Y-tile.
*/
I'm wondering whether we shouldn't double the pitch because as far as I
understand meta_copy renders to the buffer as a color attachment. Does this
constraint still apply in this case?
Also is this all going away once the blorp work Jason has been working on
lands?</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>