ZDoom

Fixed in [url=https://github.com/coelckers/gzdoom/commit/56557a17f16078faaf55387914e6d44a2d704023]56557a1[/url].

[url=https://github.com/coelckers/gzdoom/pull/833]Here[/url] is my attempt to fix it.

image_width_padded = allocated_size / image_height
padding = image_width_padded - image_width

I calculated it from size of memory allocated for image.
[code]image_width_padded = allocated_size / image_height
padding = image_width_padded - image_width[/code]
Alignment will be the next power of two of [b]padding[/b].
Hard to say about correctness of this approach according to the spec.

Seems the padding is mentioned in the spec: "VK_IMAGE_TILING_LINEAR specifies linear tiling (texels are laid out in memory in row-major order, possibly with some padding on each row)."

Unfortunately I'm not able to spot in the spec exactly how to read what that padding may be.

I moved this back to opened bugs subforum because a corrupted picture is still present.
Also, I updated the first post as this appeared to affect all software renderers.

My initial assumption was wrong, this has nothing to do with one channel image format.
This issue is caused by a buffer alignment only. In other words, everything works fine when horizontal resolution is divisible by some magic number.
For example, Intel graphics driver on Linux expects 64 bytes alignment while MoltenVK aligns memory by 128 bytes.
So, resolution like 1024x768 doesn't exhibit this problem on all hardware and OS combinations I tried.

I fixed the last error. The other ones went away on my computer once the SetActiveRenderTarget call was added.

[vulkan error] You cannot start a render pass using attachment 0 where the render pass initial layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL and the previous known layout of the attachment is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL. The layouts must match, or the render pass initial layout for the attachment must be VK_IMAGE_LAYOUT_UNDEFINED

[vulkan error] vkCmdPipelineBarrier(): Barriers cannot be set during subpass 0 of renderPass VkRenderPassSetup.RenderPass[VkRenderPassSetup.RenderPass] with no self-dependency specified. The Vulkan spec states: If vkCmdPipelineBarrier is called within a render pass instance, the render pass must have been created with at least one VkSubpassDependency instance in VkRenderPassCreateInfo::pDependencies that expresses a dependency from the current subpass to itself, and for which srcStageMask contains a subset of the bit values in VkSubpassDependency::srcStageMask, dstStageMask contains a subset of the bit values in VkSubpassDependency::dstStageMask, dependencyFlags is equal to VkSubpassDependency::dependencyFlags, srcAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::srcAccessMask, and dstAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::dstAccessMask (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-pDependencies-02285)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] Submitted command buffer expects image 0xa7[VkRenderBuffers.PipelineImage]  (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.

[vulkan error] vkGetQueryPoolResults: parameter dataSize must be greater than 0. The Vulkan spec states: dataSize must be greater than 0 (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkGetQueryPoolResults-dataSize-arraylength)

With validation layers enabled software renderer reports the following errors after entering a level. It's on macOS with integrated Intel graphics.[code][vulkan error] You cannot start a render pass using attachment 0 where the render pass initial layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL and the previous known layout of the attachment is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL. The layouts must match, or the render pass initial layout for the attachment must be VK_IMAGE_LAYOUT_UNDEFINED

[vulkan error] vkCmdPipelineBarrier(): Barriers cannot be set during subpass 0 of renderPass VkRenderPassSetup.RenderPass[VkRenderPassSetup.RenderPass] with no self-dependency specified. The Vulkan spec states: If vkCmdPipelineBarrier is called within a render pass instance, the render pass must have been created with at least one VkSubpassDependency instance in VkRenderPassCreateInfo::pDependencies that expresses a dependency from the current subpass to itself, and for which srcStageMask contains a subset of the bit values in VkSubpassDependency::srcStageMask, dstStageMask contains a subset of the bit values in VkSubpassDependency::dstStageMask, dependencyFlags is equal to VkSubpassDependency::dependencyFlags, srcAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::srcAccessMask, and dstAccessMask member of each element of pMemoryBarriers and pImageMemoryBarriers contains a subset of the bit values in VkSubpassDependency::dstAccessMask (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-pDependencies-02285)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] For image 0xa7[VkRenderBuffers.PipelineImage] you cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[vulkan error] Submitted command buffer expects image 0xa7[VkRenderBuffers.PipelineImage] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.
[/code]
Also, this is reported regardless of renderer selection before entering a level.[code][vulkan error] vkGetQueryPoolResults: parameter dataSize must be greater than 0. The Vulkan spec states: dataSize must be greater than 0 (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkGetQueryPoolResults-dataSize-arraylength)[/code]

Also, I'm seeing the same broken picture on Linux with much newer Intel graphics.

Hmm, I am not seeing this on my computer.

However I noticed that vk_debug 1 gives some errors when using software rendering. Those errors indicate that maybe it could create corrupted output on different hardware than my own.

[s]When Vulkan is enabled the final picture with classic and poly software renderers is rather broken.[/s]
When Vulkan is enabled software renderers may produce a corrupted picture depending on the current resolution and requirement for buffer alignment.

[attachment=0]Screenshot_Doom_20190503_124513.png[/attachment]
[s]I suspect it's just one spot where handling of 8-bit image format is missing. Although, I was unable to find it yet.[/s]