[Bug 97448] [HSW] deqp-vk.api_.copy_and_blit.image_to_image_stencil regression
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Aug 23 13:00:55 UTC 2016
https://bugs.freedesktop.org/show_bug.cgi?id=97448
--- Comment #3 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
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?
--
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/20160823/a3b75ab1/attachment.html>
More information about the intel-3d-bugs
mailing list