Vulkan: FillWithDiscardPattern over ASTC uses unaligned bufferRowLength

[ShabbyX]

Description of Bug

When replaying a trace that uses ASTC 6x6, I hit an internal driver assertion that led to the discovery of this issue. In summary FillWithDiscardPattern, violates VUID-vkCmdCopyBufferToImage-bufferRowLength-09106 if the texel block size does not divide 256 (i.e. PatternBatchWidth).

RenderDoc issues a warning before reaching this code in replay_driver.cpp:

  else if(fmt.type == ResourceFormatType::ETC2 || fmt.type == ResourceFormatType::EAC ||
          fmt.type == ResourceFormatType::ASTC || fmt.type == ResourceFormatType::PVRTC ||
          fmt.type == ResourceFormatType::YUV8 || fmt.type == ResourceFormatType::YUV10 ||
          fmt.type == ResourceFormatType::YUV12 || fmt.type == ResourceFormatType::YUV16)
  {
    RDCERR("Format %s not supported for proper discard pattern", fmt.Name().c_str());
  }

But I believe that's only saying the discard pattern won't "look nice", rather than won't be done. Later in this stack trace:

#4  0x00007ffff5d2be95 in VulkanDebugManager::FillWithDiscardPattern(VkCommandBuffer_T*, DiscardType, VkImage_T*, VkImageLayout, VkImageSubresourceRange, VkRect2D)
    (this=0x7fff7068f530, cmd=0x7ffe212ef260, type=DiscardType::UndefinedTransition, image=0x7fff714de800, curLayout=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, discardRange=..., discardRect=...) at /home/syoussefi/renderdoc/renderdoc/driver/vulkan/vk_debug.cpp:2566
#5  0x00007ffff6373763 in WrappedVulkan::Serialise_vkCmdPipelineBarrier<ReadSerialiser>(ReadSerialiser&, VkCommandBuffer_T*, unsigned int, unsigned int, unsigned int, unsigned int, VkMemoryBarrier const*, unsigned int, VkBufferMemoryBarrier const*, unsigned int, VkImageMemoryBarrier const*)
    (this=0x7fff70008650, ser=..., commandBuffer=0x7ffe212ef260, srcStageMask=1, destStageMask=4096, dependencyFlags=0, memoryBarrierCount=0, pMemoryBarriers=0x0, bufferMemoryBarrierCount=0, pBufferMemoryBarriers=0x0, imageMemoryBarrierCount=1, pImageMemoryBarriers=0x7ffe22d5e7f0)
    at /home/syoussefi/renderdoc/renderdoc/driver/vulkan/wrappers/vk_cmd_funcs.cpp:4145
#6  0x00007ffff5cae1bc in WrappedVulkan::ProcessChunk(ReadSerialiser&, VulkanChunk) (this=0x7fff70008650, ser=..., chunk=VulkanChunk::vkCmdPipelineBarrier) at /home/syoussefi/renderdoc/renderdoc/driver/vulkan/vk_core.cpp:3996

RenderDoc issues a copy command for example with this info:

(gdb) p mainCopies[0]
$14 = (VkBufferImageCopy &) @0x7ffe21ff3c20: {
  bufferOffset = 0,
  bufferRowLength = 256,
  bufferImageHeight = 0,
  imageSubresource = {
    aspectMask = 1,
    mipLevel = 0,
    baseArrayLayer = 0,
    layerCount = 1
  },
  imageOffset = {
    x = 0,
    y = 0,
    z = 0
  },
  imageExtent = {
    width = 32,
    height = 32,
    depth = 1
  }
}

In the trace I hit this, the format of the image is VK_FORMAT_ASTC_6x6_SRGB_BLOCK, so texel block width (6) doesn't divide 256 and the above VU is

For each element of pRegions, bufferRowLength must be a multiple of the texel block extent width of the VkFormat of dstImage

Steps to reproduce

Any trace using a small 6x6 ASTC image should reproduce this. Simply capture, then replay and assert/log what happens in that code. I should be able to procure a capture over Intel/mesa is needed, but can't be shared publicly.

Environment

• RenderDoc version: 52199656846b9d2d7155599abd176e22ae46013e
• Operating System: Linux
• Graphics API: Vulkan
• Driver: Caught with SwiftShader, but I don't see an indication that it would be different on any driver with ASTC support.

[cmannett85-arm]

I should be able to procure a capture over Intel/mesa is needed, but can't be shared publicly.

If possible that would be great, as it'll speed up testing. You can send it to me directly on camden.mannett at arm.com.

[ShabbyX]

I should be able to procure a capture over Intel/mesa is needed, but can't be shared publicly.

If possible that would be great, as it'll speed up testing. You can send it to me directly on camden.mannett at arm.com.

Thanks, I'll reach out privately.

[hanbim520]

https://github.com/baldurk/renderdoc/issues/3432 This question has already been asked

[cmannett85-arm]

@hanbim520, not quite as this issue is for Vulkan though I suspect the fix will be related.

[hanbim520]

I compiled it from source, and everything works fine; there's no longer that asset log issue. However, the official version still has this problem. I suspect that the RenderDoc Android APK was not recompiled, as all the RenderDoc APKs I have locally are compiled by myself.

[baldurk]

This issue is entirely different to the one you linked which has been closed, please do not comment on here talking about a different issue. If you are encountering a bug please file an issue about it with a reproducible test case.