Created attachment 141899 [details] Test case On Vega, the lowest mip levels (with at least one dimension smaller than the block size) of large block compressed textures can get corrupted when data is copied to them with vkCmdCopyBufferToImage(). It seems as though it only affects textures with non-power-of-two size, and also doesn't occur on smaller textures (1024x3072 is affected but 32x96 is not). The attached test case creates a 1024x3072 BC1_SRGB texture, with a complete mip chain, and then uses vkCmdCopyBufferToImage() to initialise each mip level with zero data. It then draws a quad sampling from mip level 9 (2x6) of that texture. This should render black, but instead it usually renders garbage (for example see the attached screenshot). Sometimes, though, it does correctly render black. If a RenderDoc capture is taken you can see that mip levels 9 to 12 are all corrupted. Reproduces on Vega 64 with Mesa git 5f0567a4f6 and 18.2, with LLVM 7.0. Doesn't occur on non-Vega cards, or on AMDVLK.
Created attachment 141900 [details] Screenshot from the test case
This also seems to be sometimes causing VM faults - I get a bunch of faults in the game that's affected by this bug, which go away if I skip vkCmdCopyBufferToImage calls which would get corrupted.
I can confirm that vega fails. I will try to look at it today.
Were you able to look at this at all?
Not yet sorry, I will let you know.
https://patchwork.freedesktop.org/patch/263716/ fixes the testcase (and hopefully does not regress anything else)
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.