[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


--- Comment #3 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---

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

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