bisected to: Author: Lionel Landwerlin <llandwerlin@gmail.com> anv: GetDeviceImageFormatProperties: fix TRANSFER formats We let the user believe we support some transfer formats which we don't. This can lead to crashes when actually trying to use those formats for example on dEQP-VK.api.copy_and_blit.image_to_image.* tests. Let all formats we can render to or sample from as meta implements transfers using attachments. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> test output: /tmp/build_root/m64/opt/deqp/modules/vulkan/deqp-vk --deqp-case=dEQP-VK.api.copy_and_blit.image_to_image_stencil --deqp-log-images=disable --deqp-gl-config-name=rgba8888d24s8 --deqp-surface-width=400 --deqp-surface-height=300 --deqp-visibility=hidden --deqp-surface-type=fbo dEQP Core git-7f2c0412f9df141c86469f9353ae5499e65fb5ff (0x7f2c0412) starting.. target implementation = 'Default' Test case 'dEQP-VK.api.copy_and_blit.image_to_image_stencil'.. Test case duration in microseconds = 3832 us Fail (CopiesAndBlitting test) DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%)
Unfortunate that this tests has been removed from the -dev branch of the CTS. All I could find was : dEQP-VK.api.copy_and_blit.image_to_image.simple_tests.stencil but this is passing on my machine with Mesa master. Will look at the CTS's master branch.
I'm using the vulkan-cts-1.0.0 branch.
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?
Created attachment 125973 [details] Expected
Created attachment 125974 [details] Actual
Fixed by : commit 91987c51e31306bcc52d2c9d18895a533ab08822 anv: meta_blit2d: adapt texel fetch pitch for fake w-tiled We need to compute detiling coordinates using the physical size of W tiling (128x32) rather than the logical size (64x64). v2: Correct comment (Jason) Fixes dEQP-VK.api.copy_and_blit.image_to_image_stencil Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97448 Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.