Corrupted picture with software renderers
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Corrupted picture with software renderers
When Vulkan is enabled the final picture with classic and poly software renderers is rather broken.
When Vulkan is enabled software renderers may produce a corrupted picture depending on the current resolution and requirement for buffer alignment.
I suspect it's just one spot where handling of 8-bit image format is missing. Although, I was unable to find it yet.
When Vulkan is enabled software renderers may produce a corrupted picture depending on the current resolution and requirement for buffer alignment.
I suspect it's just one spot where handling of 8-bit image format is missing. Although, I was unable to find it yet.
Last edited by _mental_ on Tue May 07, 2019 7:15 am, edited 1 time in total.
Re: Broken picture with 8-bit software renderers
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.
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.
Re: Broken picture with 8-bit software renderers
With validation layers enabled software renderer reports the following errors after entering a level. It's on macOS with integrated Intel graphics.
Also, this is reported regardless of renderer selection before entering a level.
Also, I'm seeing the same broken picture on Linux with much newer Intel graphics.
Code: Select all
[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: Select all
[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)
Re: Broken picture with 8-bit software renderers
I fixed the last error. The other ones went away on my computer once the SetActiveRenderTarget call was added.
Re: Corrupted picture with software renderers
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.
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.
Re: Corrupted picture with software renderers
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.
Unfortunately I'm not able to spot in the spec exactly how to read what that padding may be.
Re: Corrupted picture with software renderers
I calculated it from size of memory allocated for image.
Alignment will be the next power of two of padding.
Hard to say about correctness of this approach according to the spec.
Code: Select all
image_width_padded = allocated_size / image_height
padding = image_width_padded - image_width
Hard to say about correctness of this approach according to the spec.
Re: Corrupted picture with software renderers
Here is my attempt to fix it.